638
edits
GC API: Difference between revisions
steal bsmedberg's description of layout
m (→Allocation: onions) |
(steal bsmedberg's description of layout) |
||
| Line 26: | Line 26: | ||
== Heap setup/teardown == | == Heap setup/teardown == | ||
We support multiple heaps; each heap is a disjoint universe of objects and can be collected separately. Implementations are expected not to trace pointers across heaps. | |||
typedef ... '''GCHeap'''; | |||
GCHeap '''gc_heap_create'''(); | |||
void '''gc_destroy_heap'''(GCHeap heap); | |||
==Allocation== | ==Allocation== | ||
| Line 75: | Line 81: | ||
== Layout == | == Layout == | ||
''' | typedef ... '''GCLayout'''; | ||
GCLayout gc_create_layout(GCHeap heap, size_t size, | |||
unsigned char *bitmap); | |||
Create a layout object which represents the layout of pointers within an object type. | |||
''bitmap'' is an array of bytes. Each byte represents one word of the target object (there must be <code>''size''/sizeof(void *)</code> entries) | |||
:0 - the word is not a pointer | |||
:1 - the word is a pointer, perhaps an interior pointer, and perhaps a pointer to an rcobject | |||
:2 - the word is a jsval | |||
:3 - the word is the possibly-pointer-containing half of a ttbox | |||
3 only makes sense on 32-bit platforms for now. | |||
'''Open issue:''' GCLayout lifetime - gc'd? or lifetime of heap? | |||
== Write barrier == | == Write barrier == | ||
| Line 113: | Line 136: | ||
This is a description of the API that the allocator needs to provide to the GC engine which runs atop it: | This is a description of the API that the allocator needs to provide to the GC engine which runs atop it: | ||
/* Allocation API */ | /* Allocation API */ | ||