Closed Bug 1114064 Opened 5 years ago Closed 5 years ago

Make it possible to have an MCallDOMNative for a jitinfo which is AliasNone

Categories

(Core :: JavaScript Engine: JIT, defect)

x86
macOS
defect
Not set

Tracking

()

RESOLVED FIXED
mozilla37

People

(Reporter: bzbarsky, Assigned: bzbarsky)

References

Details

Attachments

(1 file)

Right now the JIT assumes that the jitinfo for a DOM method (as opposed to getter) cannot be AliasNone.  I'd like to actually create some AliasNone methods, so this assumption needs to be rectified.
Comment on attachment 8539714 [details] [diff] [review]
Support AliasNone DOM methods in ion compilation

Review of attachment 8539714 [details] [diff] [review]:
-----------------------------------------------------------------

I was just thinking about these and noting that we would have to clean this up. r=me
Attachment #8539714 - Flags: review?(efaustbmo) → review+
Out of curiosity, what methods are these?
(In reply to Jeff Walden [:Waldo] (remove +bmo to email) from comment #3)
> Out of curiosity, what methods are these?

This should be MCallDOMNative::getAliasSet(). We have a system by which the DOM bindings can specify the alias sets of various functions via JitInfo, and we are expanding that system.
No, what *DOM* methods.  :-)
Oh. I think mostly performance.now() is one that aliases nothing that we want to allow people to hoist around.
Yeah, for now performance.now().  But in general, methods that guarantee that all observable behavior is async might fall into this bucket, and people are adding more async methods to the platform.
Comment on attachment 8539714 [details] [diff] [review]
Support AliasNone DOM methods in ion compilation

Relanded in https://hg.mozilla.org/integration/mozilla-inbound/rev/206763e2c234
Attachment #8539714 - Flags: checkin+
https://hg.mozilla.org/mozilla-central/rev/206763e2c234
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.