638
edits
GC API: Difference between revisions
Jump to navigation
Jump to search
→Allocation
(→Decisions: update after today's meeting) |
|||
| Line 89: | Line 89: | ||
'''Open issue:''' Weak references. (At the moment I'm leaning toward just providing an end-of-mark-phase GC callback and a IsAboutToBeCollected API and letting users build weakrefs on top of this.) | '''Open issue:''' Weak references. (At the moment I'm leaning toward just providing an end-of-mark-phase GC callback and a IsAboutToBeCollected API and letting users build weakrefs on top of this.) | ||
'''Open issue:''' Weak caches. For example, there's a cache in Mozilla where we have Key and Value objects, both of which will become GC-allocated, and the map needs to have this behavior: | |||
* Entries do not keep Values alive. | |||
* As long as the Value is reachable, keep the entry (keeping the Key alive). | |||
* Whenever a Value is collected, remove all corresponding entries (the Key can then be collected, preferably in the same GC cycle). | |||
We could do it without special GC API support if we're willing to add a pointer field on ''every'' XPCOM object ''AND'' we have something resembling weak references. Even that might be slow. | |||
Another case has both keys and values keeping each other (and the relevant entries) alive. | |||
== Explicit deallocation == | == Explicit deallocation == | ||