623284 - Need a generic unmanaged handle facility

Status: RESOLVED WONTFIX

(Tamarin Graveyard :: Garbage Collection (mmGC), defect, P1)

Description

[Tommy Reilly]

In at least two places and possibly more in the player we need the ability to have a ref counted unmanaged "handle" that acts like a weak ref.   This will allow handles to go places weak refs can't (ie places the GC doesn't trace) but keep the actual storage of the GC pointer in the GC and out of the mutator.

The thinking is that this would be surfaced as a subclass of GCFinalizedObject so that the handle's pointer could be nulled out in the objects dtor (essentially moving something that happens now in the client into the GC).

Consider this bug a soap box for alternative solutions.

Comment 1

[Lars T Hansen]

One or two specific use cases with details (*not* suggestions for solutions) would make this bug possible to understand; so far the discussion here and in email has assumed a problem that has in fact gone unstated.  Please state it here.  :-)

Comment 2

[Tommy Reilly]

More abstractly the player needs to have the ability to retrieve a GC object or NULL if it was GC'd from some sort of unmanaged "handle" that can.   If the solution entails have an unmanaged heap allocation point to a GC object then the solution needs to live in the GC since that's against the new safegc rules.   

There are however other ways the problem could be solved entirely in the client.   Currently I'm thinking the player could just use an incremented by one counter to uniquely identify each object and look them up in a GCHashtable<uintptr_t,GCObject*>.    Then the "handle" is a just an int.

Comment 3

[Tommy Reilly]

(In reply to comment #2)
> More abstractly the player needs to have the ability to retrieve a GC object or
> NULL if it was GC'd from some sort of unmanaged "handle" that can ...

be stored in areas of the heap not scanned by the GC.

Comment 4

[Lars T Hansen]

Again, this bug needs a problem statement.

Comment 5

[Tommy Reilly]

Let's try that again: Client's need to have the ability to have a weak reference to a GCObject that isn't itself a GCObject.

Comment 6

[Tommy Reilly]

Use case: I want to store a reference to a GCObject in some opaque "void*" handle field in some OS callback and be able to safely retrieve that GCObject (or NULL if it was collected) later on in a different context.

Comment 7

[Lars T Hansen]

That can be implemented as a GCRoot pointing to a GCWeakRef, no?  (And the logic can be encapsulated in a "Handle" type on the client side, it would seem.)  That might not be efficient, but for a small number of objects and a low allocation rate it might be OK.  Do we have data other than your observation about two places in the code?

Comment 8

[Tommy Reilly]

Use case involves some very popular objects.   This idiom isn't used all over the place but one instance of it is pretty high volume so I'm didn't really consider the GCRoot/GCWeakRef approach.  Also I didn't want to increase the GC work load.

There's another similar use case that's a "cache" where a GCObject can have a reference to some expensive resource (a bitmap) and a cache item is created which has a reference to the GCObject and the resource.  Currently the unmanaged cache item has a direct pointer to the GCObject and the cache item is whacked when the GCObject dies (its a GCFinalizedObject) so the unsafe pointer is guaranteed to never be a dangling pointer.

Comment 9

[Lars T Hansen]

Tommy, is this item somehow related to the background for bug 625145?  The background there - via Steven - is a list of GC references that is used a couple of places in the Player without being visible to the GC, and a convoluted set of conditions that makes that safe.  The effect is a list of weakly held pointers without the overhead of weakrefs.

Comment 10

[Lars T Hansen]

(Assigning, as unassigned P1 items are senseless.)

Comment 11

[Tommy Reilly]

Lars this could be related to the 625145 but I haven't seriously considered the weak ref wrapped in a GCRoot solution, the high allocation rate worried me, more so for GCRoots than weak refs.

Comment 12

[Tommy Reilly]

This is no longer needed, I think we can do it with WeakRef list or Unmanaged pointer lists.