GC API: Difference between revisions

Jump to navigation Jump to search

GC API (view source)

Revision as of 14:23, 1 April 2008

961 bytes added ,  1 April 2008
revise per March 31 meeting (not done yet)
(update next meeting time)
(revise per March 31 meeting (not done yet))
Line 15: Line 15:
We will support C++ objects somehow, as well as something like spam's "onion" layout.
We will support C++ objects somehow, as well as something like spam's "onion" layout.


We won't bend over backwards to make the API support [[mdc:MMgc|MMgc]] in the fastest or most natural way.  For example, the fastest possible MMgc write barrier requires the caller to know the beginning-of-allocation pointers for both the object containing the field being written and the pointer being stored there.  This is a pain for the user, and a card-marking GC doesn't need those pointers anyway.  So our API will *not* provide this information; the MMgc wrapper will have to calculate it each time the write barrier hits.  This will make MMgc look slow, but we can live with that.
We won't bend over backwards to make the API support [[mdc:MMgc|MMgc]] in the fastest or most natural way.  For example, the fastest possible MMgc write barrier requires the caller to know the beginning-of-allocation pointers for both the object containing the field being written and the pointer being stored there.  This is a pain for the user, and a card-marking GC doesn't need those pointers anyway.  So our API will ''not'' provide this information; the MMgc wrapper will have to calculate it each time the write barrier hits.  This will make MMgc look slow, but we can live with that.


The purpose of this API is to support switching to a different GC implementation ''at compile time'', not at run time.  (Each implementation will have its own header file, with its own inline functions or function-like macros.  Maybe we'll produce a GC API header file that has no inline anything, just showing the signatures the implementation must provide, for reference.)
The purpose of this API is to support switching to a different GC implementation ''at compile time'', not at run time.  (Each implementation will have its own header file, with its own inline functions or function-like macros.  Maybe we'll produce a GC API header file that has no inline anything, just showing the signatures the implementation must provide, for reference.)
Line 30: Line 30:
==Allocation==
==Allocation==


  void * '''gc_alloc_no_pointers'''(gcheap_t heap, size_t size);
(BTW we haven't established naming conventions; this is just a sketch)
 
  void * '''gc_alloc_contains_pointers'''(gcheap_t heap, size_t size, gclayout_t layout);
The idea here is to support allocations of different types: <code>raw</code> allocations are leaf objects and never contain pointers at all; <code>object</code> and <code>array</code> allocations have a known layout that governs which fields are pointers; and <code>conservative</code> allocations might contain pointers at any pointer-aligned offset and must be conservatively scanned.
   
 
  void * '''gc_alloc_conservative'''(gcheap_t heap, size_t size);
(Where the layout information isn't a speed win, the implementation can of course just discard it.  A hacky implementation can just delegate <code>gc_alloc_object</code> and <code>gc_alloc_array</code> to <code>gc_alloc_conservative</code>.  Sloppy, but fine by me.)
 
 
All these functions return a pointer to a newly allocated region of memory that is subject to GC (that is, the GC may collect it when it becomes unreachable), or <code>NULL</code> on failure.
 
All allocations are <code>malloc</code>-aligned (that is, alignment is such that the pointer can be cast to any reasonable C/C++ type and used).
 
  void * '''gc_alloc_raw'''(GCHeap heap, size_t size);
 
Allocate ''size'' bytes of memory, not necessarily zeroed. The GC will assume the memory never contains pointers to other GC allocations.
 
  void * '''gc_alloc_conservative'''(GCHeap heap, size_t size);
 
Allocate and zero out ''size'' bytes of memory.  The GC will conservatively scan the memory for pointers.


(BTW we haven't established naming conventions; this is just a sketch)
void * '''gc_alloc_onion'''(GCHeap, size_t rawSize, size_t ptrsSize);
 
Allocate ''rawSize'' + ''ptrsSize'' bytes of memory.  Both sizes must be pointer-size-aligned.  The first ''rawSize'' bytes are not necessarily zeroed.  They GC will assume that they never contain pointers.  The next ''ptrsSize'' bytes are treated as an array of "possible pointers" (<code>jsval</code>, really; see below).


The idea here is to support allocations of different types: <code>no_pointers</code> allocations are leaf objects and never contain pointers at all; <code>contains_pointers</code> allocations have a known layout that governs which fields are pointers; and <code>conservative</code> allocations might contain pointers at any pointer-aligned offset and must be conservatively scanned.
  void * '''gc_alloc_object'''(GCHeap heap, GCLayout layout);


(Where the layout information isn't a speed win, the implementation can of course just discard it. A hacky implementation can just delegate <code>gc_alloc_contains_pointers</code> to <code>gc_alloc_conservative</code>.  Sloppy, but fine by me.)
Allocate and zero out memory for an object.  The ''layout'' specifies the size of the allocation and which words of it may contain pointers. Layout is described in more detail below.


'''Open issue:''' Do we need <code>gc_alloc_conservative</code>?
void * '''gc_alloc_array'''(GCHeap heap,
                            GCLayout headerLayout,
                            GCLayout elementLayout,
                            size_t count);


'''Open issue:''' We don't know exactly what the layout information is yet.  Speculation is, for C++ objects it's a bitmap with one or two bits per word of the object, and for onions it gives the number of contains-pointers words in the onion.  We can, using some kind of static header-preprocessing magic ([[Dehydra]]), autogenerate layout information for C++ classes.
Allocate and zero out memory for an array.  The layout of the array consists of an optional header described by ''headerLayout'', followed by ''count'' array elements, each described by ''elementLayout''.  Returns a pointer to the beginning of the allocation (the header).


'''Open issue:''' How to handle types like <code>[[mdc:jsval|jsval]]</code>, which contains tag bits indicating whether it's a pointer or not. (And in tamarin-tracing, there's a 64-bit type in which bits in the high 32 bits tell you whether the low 32 bits are a pointer or not!)
'''Open issue:''' API for onions.


'''Open issue:''' Reference counting (or DRC) and/or other nasty tricks to keep memory usage down.
'''Open issue:''' Reference counting (or DRC) and/or other nasty tricks to keep memory usage down.
Line 53: Line 71:


'''Open issue:''' Weak references.
'''Open issue:''' Weak references.
== Layout ==
'''TODO'''


== Write barrier ==
== Write barrier ==
Jorend
638

edits

Retrieved from "https://wiki.mozilla.org/Special:MobileDiff/88638"

Navigation menu