You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
[MERGE #3846@BoCupp] Add support for a Recycler-managed "Host Heap" to facilitate tracing of objects which relate to scriptable types
Merge pull request #3846 from BoCupp:build/pcupp/recycler_visited_host_heap
This change exposes functions that will allocate memory inside of Chakra's GC. This memory can be precisely traced or leaf, and either finalizable or not. Traced objects will have IRecyclerVisitedObject::Trace called on them during ProcessMark if they were added to a new type of mark stack during Mark. Trace implementations will use a new API to tell the marking context to add a set of pointers to the appropriate mark stack.
Finalizable objects will have Dispose called when the the object is no longer reachable, in order to perform unmanaged resource cleanup.
These objects (except for non-finalizable leaf objects) will all live inside a new heap block type. Currently there is only support for small and medium blocks.
GCStress has been updated to allocate objects of the various new types. Finalizable objects hold onto some unmanaged heap resources which would point out (via OOM) if objects are not correctly being cleaned up.
More details:
- Add support for small and medium RecyclerVisitedHostHeapBlockTypes
- For now, add failfast for RecyclerVisitedObjects that are placed in the LargeHeapBlock
- Publish IRecyclerVisitedObject interface which adds new method (compared to FinalizableObject) for precise tracing support
- The old FinalizableObject is now a specialization of RecyclerVisitedObject and is used internally by Chakra
- For host allocations, the host is expected to provide an appropriate implementation of IRecyclerVisitedObject
- Publish IRecyclerHeapMarkingContext (used as the argument to IRecyclerVisitedObject::Trace)
- The host must implement precisely tracing the (non-leaf) memory it allocates by calling IRecyclerHeapMarkingContext::MarkObjects from inside its implementation of IRecyclerVisitedObject::Trace
- It is implemented by a stack wrapper on MarkContext that captures the parallel and interior template parameters from MarkContext::ProcessMark. We always use false for doSpecialMark, since all calls to Mark that originate from ProcessMark would pass false (the only place we pass true is when scanning the stack)
- Create Chakra exports for allocation and rootaddref/release functions
- Introduce a new RecyclerHeap lib in chakra that defines the exports in the cpp and declares them in the h
- Add support for RecyclerVisitedObjects in GCStress
Note: this change is derived from a rebase of work done by Daniel Libby - all credit to him for the work to enable this concept.
0 commit comments