Closed Bug 1370868 Opened 8 years ago Closed 8 years ago

Try using HeapPtr for all heap pointers that are not members of a GC thing

Categories

(Core :: JavaScript: GC, enhancement)

Product:
Core
Component:
JavaScript: GC
Version:
55 Branch
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: jonco, Unassigned)

Details

The current situation is that we use GCPtr for pointers in the heap that have GC lifetime (GC things and anything owned by them) and HeapPtr elsewhere. The problem is all the 'and anything owned by them' allocations, which feel like they should have GC lifetime too, but in practice do not (failure to instantiate for various reasons results in them being deleted immediately, outside of GC). This necessitate GCManagedDeletePolicy, which is a horrible hack and requires developers that use GCPtrs to realise that they need this and opt into it. If there is no performance penalty it would be better to use HeapPtr (slightly slower but without the limitations of GCPtr) for everything that's not a member of a GC thing and kill GCManagedDeletePolicy. For bonus points we should make an analysis that enforces this. (This came about investigating why the fix for bug 1358073 causes crashes on esr52 but nowhere else).
Further to the above, there's no point using HeapPtr in places where it's destructor won't be called (e.g. IC stubs) and so other schemes to handle delayed freeing of memory containing GCPtrs will have to remain in place.
This is more difficult that I first thought because HeapPtr has a pre-barrier that gets the zone from the contained pointer. If this happens during finalisation it may access a GC thing that's already been swept and crash.
This didn't work out as per comment 2. An alternative approach is bug 1371234.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.