638
edits
GC API: Difference between revisions
Jump to navigation
Jump to search
→Allocation
No edit summary |
|||
| Line 92: | Line 92: | ||
'''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: | '''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). | |||
# The map must not keep cyclic garbage alive. | |||
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. | 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. | ||
| Line 102: | Line 103: | ||
'''Figure 1: nonworking straw man solution to this problem''' | '''Figure 1: nonworking straw man solution to this problem''' | ||
[[Image: weakcachegraph1.png]] | [[Image: weakcachegraph1.png]] | ||
This has properties 1-3 but not property 4; if there is a cycle between Key and Value (which can easily happen, given XPCOM and XPConnect) then the map keeps it alive. | |||
'''Figure 2: working straw man solution''' | |||
[[Image:weakcachegraph2.png]] | |||
This has all four properties but costs at least one pointer field per Value. | |||
== Explicit deallocation == | == Explicit deallocation == | ||