Open
Bug 721662
Opened 12 years ago
Updated 2 years ago
IonMonkey: Consider not emitting a type barrier after VM calls
Categories
(Core :: JavaScript Engine, defect)
Core
JavaScript Engine
Tracking
()
NEW
People
(Reporter: jandem, Unassigned)
References
(Blocks 1 open bug)
Details
(Whiteboard: [ion:t])
See bug 718683 comment 17. The interpreter stub handles the barrier so maybe we could get rid of the barrier or use an infallible unbox or something. VM calls should be rare and I don't think it's worth the complexity/time right now, but it can't hurt to investigate this later.
Comment 1•12 years ago
|
||
JM+TI originally updated observed type sets in the stubs, but this turned out to be slow and changing things to update the types in jitcode immediately after the stubcall returned helped a lot with fixing the dromaeo regressions that came in with JM+TI. Eventually IonMonkey will be able to handle certain property accesses in jitcode that have to be stubbed in JM+TI, but I would still expect there to be a lot of calls made by IM in certain cases.
Updated•12 years ago
|
Whiteboard: [ion:t]
Assignee | ||
Updated•10 years ago
|
Assignee: general → nobody
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•