638
edits
GC API: Difference between revisions
add more open issues, semicolons
(GC_LAST_ROOTING) |
(add more open issues, semicolons) |
||
| Line 24: | Line 24: | ||
'''Open issue:''' We should detect dumb implementation mismatches at link time and bomb out. I don't know the trick, but I bet bsmedberg does. | '''Open issue:''' We should detect dumb implementation mismatches at link time and bomb out. I don't know the trick, but I bet bsmedberg does. | ||
'''Open issue:''' The JSAPI allows JSObjects to contain pointers to non-GC-allocated data which may contain pointers back to GC-allocated stuff (objects, strings, numbers). See [[devmo:JSClass.mark]]. This existing API seems impossible to reimplementi on top of the GC API as it stands. First, the GC API doesn't offer a per-object custom marking hook. Second, the GC API insists on a write barrier (the JSAPI doesn't). | |||
'''Open issue:''' Need to document which operations require arequest. | |||
=API areas= | =API areas= | ||
| Line 37: | Line 41: | ||
==Allocation== | ==Allocation== | ||
(BTW we haven't established naming conventions; this is just a sketch) | (BTW we haven't established naming conventions; this is just a sketch) | ||
| Line 155: | Line 158: | ||
== GC == | == GC == | ||
void '''gc_collect'''() | void '''gc_collect'''(); | ||
Unconditionally collect garbage now. The current thread must be in a request. | Unconditionally collect garbage now. The current thread must be in a request. | ||
void '''gc_maybe_collect'''(int msecs) | void '''gc_maybe_collect'''(int msecs); | ||
Suggest to the Garbage collector API that now might be a good time to collect garbage. The GC may decide to begin or continue incremental garbage collection during this callback. <var>msecs</var> is an application hint to the garbage collector indicating how many milliseconds incremental marking should be allowed to consume. There is no guarantee about the actual time consumed by the function. | Suggest to the Garbage collector API that now might be a good time to collect garbage. The GC may decide to begin or continue incremental garbage collection during this callback. <var>msecs</var> is an application hint to the garbage collector indicating how many milliseconds incremental marking should be allowed to consume. There is no guarantee about the actual time consumed by the function. | ||
| Line 183: | Line 186: | ||
void '''gc_add_callback'''(gc_callback callback); | void '''gc_add_callback'''(gc_callback callback); | ||
'''Open issue:''' Need to document which callbacks may call which GC API functions. | |||
The next two issues can only be resolved by taking a good hard look at SpiderMonkey internals. | |||
'''Open issue:''' We may need to add callbacks for entering and leaving stop-the-world mode (what the MMGC_THREADSAFE comments call "exclusiveGC"). These are distinct from the pre-sweep and post-sweep callbacks, which only fire when a GC cycle ends; incremental marking stops the world too, but shouldn't fire those. | |||
'''Open issue:''' We may need to expose the GC lock somehow. SpiderMonkey currently uses it two ways: uses it as a general-purpose mutex (dubious); and creates condition variables protected by it (not quite as dubious, but still). | |||
== Rooting == | == Rooting == | ||
The rooting API provides a simple way to treat a particular GC object as a root. More complex rooting scenarios can be accomplished with a precollect hook. | The rooting API provides a simple way to treat a particular GC object as a root. More complex rooting scenarios can be accomplished with a precollect hook. | ||