582770 - (asymmGC) Multiple mutator support for GC instances

Reporter

Description

•

14 years ago

Attached file Initial patch (obsolete) (deleted) — Details

Using threads for internal VM functions is currently difficult as an instance of MMgc's managed memory allocator/collector, GC, will support only a single mutator. Internal VM threads will need to allocate or access managed ABC metadata objects and VM objects, hence they would appear as (unsupported) concurrent mutators to their containing VM's GC instance. This patch, combined with the thread-safepointing implementation (bug 575544) addresses this issue by allowing a GC to be shared between a single ActionScript-executing application thread, and any number of internal VM threads. The design report for this work is currently an internal document that I'm working to get on to bugzilla. In the mean time, email me if you want a copy, and below is also a brief summary. Note the current implementation requires plenty of optimizations, particularly on allocation and write-barrier fast-paths. These will be added to this bug in due course. Summary: The overall model is for application-threads to retain the GC::ThreadEnter/Exit() mechanism of claiming exclusive ownership of a GC. VM-threads on the other hand use a different entry-point, which simply informs a GC that they wish to 'attach'. A GC maintains a list of attached VM-threads, which may concurrently (with each other and an applciation-thread) allocate managed objects and mutate the GC's managed object graph. A VM-thread may attach or detach from a GC at any point, independently of any application-thread ownership of the GC. Note that VM-threads are not tied to any particular VM instance, they may attach to any VM's GC. Hence, VM-threads can be shared across VM instances, allowing, for example, compilation threads to service a whole Flash Player process. A VM-thread may not, however, attach to multiple GC's at the same time, or recursively attach to the same GC. These patterns are required for an application-thread's execution, but are unnecessary for a VM-thread that we assume will be non-reentrant when calling out of VM code. From a GC engineering perspective it is attractive to allow any mutator thread to become the collector thread if its allocation request triggers a collection phase (or, better still, have a dedicated collector thread). Neither of these are possible however, as they would be disruptive to finalization semantics within client-code. Specifically, the ZCT-reap and sweep/finalize phases eagerly invoke collected objects' finalizers, hence, VM-threads would likely execute application-thread code when acting as a collector. We are therefore compelled to use only the application-thread in all collection phases except incremental-marking. In the current avmshell proof-of-concept, however, two builds are available: * AVMFEATURE_THREADSAFE_GC_CLIENT_COLLECT, where the application-thread acts as the collector in all phases. * AVMFEATURE_THREADSAFE_GC, where any thread can act as collector (as all finalizers within the VM, GC and shell code-bases are thread agnostic). Having only the application-thread available as a collector imposes some extra complications for VM-threads. Specifically, if the allocation request of a VM-thread triggers a collection, then it must be suspended until the collection occurs; hence to prevent deadlocks, the following must be enforced: * While requesting an allocation, a VM-thread cannot hold any lock which is acquirable by an application-thread (in mutator code). * An application-thread cannot be suspended in mutator code pending a notification from a VM-thread. The first of these constraints is difficult to work-around in an efficient way, however, it is a corner-case scenario and doesn't severely impact what can be done with VM-threads. The second of the constraints is much more important to remove, particularly in the context of cleanly shutting down a VM instance. Specifically, when an application-thread shuts down a VM's GC instance, something must be done with it's attached VM-threads which are blocked awaiting a collection. The two solutions to this are: * Allow failed allocations (or throw some exception) within VM-threads when an application-thread is no long available for collection work. * Provide a 'wait' construct that re-purposes an application-thread to act as a dedicated collector-thread whilst suspended in mutator code. The first of these is very unattractive as it breaks the existing allocation guarantees of MMgc. The second solution is much cleaner, and has been implemented as a general solution within the GCCollectorCondition class. For an example of its utility beyond VM-shutdown, see the ExecutorFuture implementation of the 'future' concurrency construct, which allows an application-thread to wait on a future executed within a VM-thread. A final design point for discussion is a policy decision: if an allocation request from a VM-thread cannot be satisfied, should all of the GC's mutators be stopped so that the application-thread can transition into a collector phase preemptively? Or should a VM-thread wait until the application thread naturally transitions into a collection phase based on its own allocation characteristics? In the current implementation (when configured so that only the application-thread performs all collector phases), VM-threads to do not normally trigger phase transitions, instead they wait for the application-thread to naturally enter the required phase (except, of course, when the application-thread is acting as a dedicated collector via GCCollectorCondition).

Initial patch 14 years ago Simon Wilkinson (deleted), application/octet-stream		Details
Initial patch 14 years ago Simon Wilkinson (deleted), patch		Details \| Diff \| Splinter Review
Latest. MMgc module changes only. 14 years ago Simon Wilkinson (deleted), patch		Details \| Diff \| Splinter Review
Latest. core and shell changes. 14 years ago Simon Wilkinson (deleted), patch		Details \| Diff \| Splinter Review