The TLS solution currently used in MMgc (GCThreadLocal), and the very similar TLS solution used for asymmGC and safepoints (vmbase::VMThreadLocal) provide a traditional mechanism: simply map a static key via a per-thread table. But this approach totally disregards the fact that we must support nested VM entry, hence MMgc, asymmGC and safepoints must take care to stash and then restore TLS values per-key at exit and exit points. Having adhoc mechanisms at entry and exit points is probably unsustainable as our use of TLS increases (e.g. bug 582782 converts AvmCore::exceptionAddr and AvmCore::exceptionFrame to VMThreadLocals). A more general solution should be 'contextual', i.e. it must include some facility for stashing and then restoring a thread's complete TLS table. This is done implicitly by ExecEnv (bug 619858), but even that solution proposes a fall-back of VMThreadLocal versions of the fields hanging off an ExecEnv. No patch or even a design yet. This bug is to solicit feedback.
You need to log in before you can comment on or make changes to this bug.