427030 - Actionmonkey MMgc: recursive postmark hook or A => B API

Status: VERIFIED WONTFIX

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

Description

[Benjamin Smedberg]

In several (many?) places in XPCOMGC I have situations where the aliveness of an object A (XPCNativeMap) implies that one or more other objects B must stay alive.

Object B, however, is not reachable directly from object A: it is maintained in an out-of-band map of some sort.

The canonical example of this is xpconnect JS wrappers around XPCOM objects:

* the wrapper should stay alive as long as the XPCOM object
* there may be multiple wrappers per XPCOM object
* most XPCOM objects don't have wrappers, so we don't want to spend a word per-object

But the specific case I'm dealing with right now is ClassInfo2NativeSetMap in xpcmaps.h.

Comment 1

[Jason Orendorff [:jorendorff]]

Attachment: v1

Here is a very basic (potentially very very slow) implementation of an A=>B API in MMgc.  The public APIs are MMgc::GC::{Link,Unlink}(void *source, void *target).  A link from A to B makes the GC act as though A actually contains a pointer to B.  The patch includes tests illustrating this.

API rule:  Don't gc->Free(x) if any links to x might exist.  (Whether this restriction makes any sense is debatable.  For now it is convenient.)

Known issues:  This causes GC.h to #include <map> and <utility>, which makes the SpiderMonkey build slow.  It also needs comments on GC::Lock and GC::Unlock.

Comment 2

[Jason Orendorff [:jorendorff]]

In the last sentence of comment 1, I meant "GC::Link and GC::Unlink".

Comment 3

[Jason Orendorff [:jorendorff]]

Mass-WONTFIXing ActionMonkey bugs.