Merge wasm::Instance and TlsData
Categories
(Core :: JavaScript: WebAssembly, enhancement, P3)
Tracking
()
Tracking | Status | |
---|---|---|
firefox100 | --- | fixed |
People
(Reporter: rhunt, Assigned: rhunt)
References
Details
Attachments
(8 files)
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review |
Filing this for the future.
wasm::Instance and TlsData are 1:1 and have the same lifetime. TlsData has special alignment requirements and also has a trailing global data area attached to it. Theoretically, the two could be merged by applying the alignment requirements to Instance and adding the global data area to the end of Instance.
The primary benefit would be removing 'switches' between *Instance and *TlsData when we have one and need the other.
For example, non-constant memory.copy does the following:
- Instance call in JIT loads instance pointer from WasmTlsReg
- Call to Instance::memCopy_mNN with instance pointer
- Instance::memCopy_mNN loads Instance::tls_ to get the JSContext*
The secondary benefit would be simplifying the decision about where to put data, as either location may be appropriate.
The primary drawback is that this would be a very invasive change, especially if there is renaming done. The 'tls' naming is used extensively. A potential other drawback is that by combining the fields of TlsData and Instance, we may push certain fields out of range for optimal instruction load encodings in JIT code. This would need further investigation.
Comment 1•3 years ago
|
||
For bug 1709578 I will probably want to assume that the memoryBase is no more than 4K away from whatever base pointer we use. This base pointer will end up in a FuncRef table where the Tls is now, and I will want to assume that loading from *(tls + offsetof(TlsData, memoryBase)) will fault if the tls is null, so that I don't have to do a null check.
Updated•3 years ago
|
Assignee | ||
Comment 2•3 years ago
|
||
Assignee | ||
Comment 3•3 years ago
|
||
Depends on D139535
Assignee | ||
Comment 4•3 years ago
|
||
- Move fields and accessors from TlsData to Instance
- Allocate Instance using extra alignment
- Leave TlsData as a subtype of Instance with no fields
- This leaves all references to TlsData as valid, although
the type is never constructed
- This leaves all references to TlsData as valid, although
- Leave instance->tlsData() and tls->instance() as identity
operations to be cleaned up later.
The net result is that tlsdata and instance are the same
object in memory, just with different names.
Depends on D139536
Assignee | ||
Comment 5•3 years ago
|
||
Depends on D139537
Assignee | ||
Comment 6•3 years ago
|
||
Depends on D139538
Assignee | ||
Comment 7•3 years ago
|
||
Depends on D139539
Assignee | ||
Comment 8•3 years ago
|
||
Stop loading tls->instance and just use instance, as they are
now the same thing.
Depends on D139540
Assignee | ||
Comment 9•3 years ago
|
||
I've slowly written the patches to do this. Posting my work so far that does everything except for the renaming of 'tls' to 'instance' across variables/fields.
I think the end result is fairly nice, the last three patches illustrate all of the pointer chasing that is removed by merging these two concepts. However, I think there will be a lot of churn in the patches to do the renaming so I want to be sure everyone agrees this is worth doing before writing those.
Comment 10•3 years ago
|
||
Soft r+ on this; a wrenching change but very plausible and a desirable simplification.
Updated•3 years ago
|
Updated•3 years ago
|
Updated•3 years ago
|
Updated•3 years ago
|
Updated•3 years ago
|
Updated•3 years ago
|
Updated•3 years ago
|
Assignee | ||
Comment 11•3 years ago
|
||
This re-orders some Instance fields for clarity, and adds comments
and assertions that the first fields of Instance are reserved for
critical data that should be accessable using compact encodings.
Depends on D139541
Updated•3 years ago
|
Comment 12•3 years ago
|
||
Comment 13•3 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/a430610af717
https://hg.mozilla.org/mozilla-central/rev/a961313a61ee
https://hg.mozilla.org/mozilla-central/rev/0942b789d2eb
https://hg.mozilla.org/mozilla-central/rev/a18404abc271
https://hg.mozilla.org/mozilla-central/rev/26289a2d4b03
https://hg.mozilla.org/mozilla-central/rev/f4192317dd41
https://hg.mozilla.org/mozilla-central/rev/d25caad49188
https://hg.mozilla.org/mozilla-central/rev/30534620399d
Description
•