Closed Bug 511591 Opened 15 years ago Closed 14 years ago

Move property tree from runtime to thread data


(Core :: JavaScript Engine, defect)

Not set





(Reporter: brendan, Unassigned)




(1 file)

Bug 497789 will make shapes of empty objects other than Object.prototype non-zero and dependent on the newborn's proto-shape.

What's more, cross-origin access checking for defense in depth against unintended capability leak bugs [1] wants even Object.prototype's shape to become non-zero and per-origin in a future patch.

Therefore the property tree should be per thread, since there can be no useful sharing among standard object subgraphs for different origins. The optimizations from long ago to avoid locking and allow duplicates created complexity which can now be eliminated, along with the locking itself.

This bug's patch will remove the thread safety and relocate the property tree structures to JSThreadData.


(In reply to comment #0)
> Therefore the property tree should be per thread, since there can be no useful
> sharing among standard object subgraphs for different origins.

And (unstated in comment 0) only different origins could use different threads concurrently for execution, to preserve run-to-completion execution and shared object sanity.

Some embeddings might see a bit more memory in use due to this bug's patch plus patches for bug 497789 et seq. but I don't think it's worth #ifdef'ing the code to pieces to allow maximal sharing for a "single-origin" (single trust domain) multi-threaded embedding.

Oh yeah, this means multi-thread accessible objects own their own properties. No sharing of a particular thread's JSScopeProperty nodes across threads.

yes, this is an awesome idea, even bites in sunspider according to plockstat data
Isolating MT scopes to own private property nodes (not in any tree) will also help delete perf (bug 473228). Next step in this patch: replace MIDDLE_DELETE with OWNED_PROPS (need better name; this will fix bug 473228).

Blocks: 473228
Blocks: 363059
What about thread workers where an implementation can migrate the worker to a different thread? That is, even in Firefox an object can be accessed from different threads even if the access is fully serialized. 

A workaround for that can be an explicit API to migrate JSThread to a different native thread.
No longer blocks: 473228
Assignee: brendan → jorendorff
The plan of record for eliminating JS_THREADSAFE without throwing away thread safety where needed (even in Gecko and Firefox, we have consumers; replacing them is not a cost-free good) is being written up by Jason, and this bug figures in it. Happy to help, want to avoid it lingering on my list, though.

No longer blocks: 497789
I may steal back, if it's ok with jorendorff. With bug 497789 patched this is so close it is crying "patch me!" like a hungry yet cute baby bug.

Depends on: 497789
By all means.
Assignee: jorendorff → general
"like a hungry yet cute baby bug"... nice
Bug 558451 moves property trees into per-prototype emptyScope roots, so this bug is WONTFIX or INVALID. Going with WONTFIX.

Closed: 14 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.