Thread-local storage should support nested VM entry

NEW
Unassigned

Status

Tamarin
Virtual Machine
7 years ago
7 years ago

People

(Reporter: Simon Wilkinson, Unassigned)

Tracking

unspecified
Future
Bug Flags:
flashplayer-qrb +

Details

(Reporter)

Description

7 years ago
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.
(Reporter)

Updated

7 years ago
See Also: → bug 619858
(Reporter)

Updated

7 years ago
Assignee: nobody → kpalacz

Updated

7 years ago
Assignee: kpalacz → nobody

Updated

7 years ago
Flags: flashplayer-qrb+
Target Milestone: --- → Future
You need to log in before you can comment on or make changes to this bug.