With bug 765956, I think we can remove JSScript::evalHashLink by using a Vector in the eval cache instead of embedding the link. This would save a word and make njn smile.
Created attachment 638585 [details] [diff] [review]
Might as well. Plus, the eval cache logic was bothering me so I turned it into a proper HashSet.
A few notes:
- evalCache is cleared on every GC
- compartment now implies principals (CPG) which is why I replaced the principals subsumption check with compartment equality
- that EvalKernel assert I removed is already in DirectEval
Comment on attachment 638585 [details] [diff] [review]
Review of attachment 638585 [details] [diff] [review]:
I know I owe you like 100 reviews but I barely know anything about the EvalCache so this r+ is very rubber-stampy... you should probably get someone else to check it :/
One useful thing I can say: if you haven't already, please save yourself some trouble later by checking that the sizeof(JSScript) static assertion passes on all eight combinations of:
- 32-bit vs 64-bit
- opt vs debug
- methodjit enabled vs disabled
@@ -63,5 @@
> - h *= JS_GOLDEN_RATIO;
> - h >>= 32 - SHIFT;
> - JS_ASSERT(h < ArrayLength(table_));
> - return &table_[h];
Good riddance to ad hoc hash tables.
Unfortunately bug 772303 (https://hg.mozilla.org/integration/mozilla-inbound/rev/fad7d06d7dd5) had to be backed out for winxp pgo-only jsreftest failures.
This bug (amongst others) either caused unresolvable (for someone who doesn't work on the JS engine at least) conflicts with the backout of fad7d06d7dd5, or else bugzilla dependencies indicated that one of it's dependants had now been backed out.
Since there was no one in #developers that could resolve the conflicts, unfortunately this bug has been backed out: