Closed
Bug 979449
Opened 10 years ago
Closed 10 years ago
Invalidate scripts when the GC moves baked in pointers
Categories
(Core :: JavaScript Engine, defect)
Core
JavaScript Engine
Tracking
()
RESOLVED
WONTFIX
People
(Reporter: terrence, Unassigned)
References
(Blocks 2 open bugs)
Details
Currently we have to be extremely careful what we embed in jitcode; in particular if the GC could move it in the future, we cannot embed it. A canonical micro-benchmark is: var arr = new Float64Array(2); function test(m) { arr[1] = m; } for(var i=0; i<20000; ++i, Array('x')) test(0); In this case |arr| will get allocated in the nursery and every subsequent |operator[]| will need to reload the elements pointer from the object before doing the write, whereas before the elements pointer would get baked into code. Instead, we should continue to bake in the elements and use TI to invalidate the code when the elements move. This should always be a better choice that deciding to not inline the elements: either the object will be long-lived so recompiling scripts that touch it will be a net performance win; or if the object is short-lived, it won't survive and thus won't need to invalidate scripts. The reason we can't do this currently is that the GC only normally has access to the runtime and TI is still on the context. The GC does use TI a bit, but this is only for optimizations currently, not for correctness. If we switch to adding constraints that affect correctness, we'll need a fast way to map from the runtime+object to the relevant TI info.
Comment 1•10 years ago
|
||
Why is |arr| being allocated in the nursery? It should have singleton type and therefore be tenured.
Comment 2•10 years ago
|
||
(In reply to Terrence Cole [:terrence] from comment #0) > Currently we have to be extremely careful what we embed in jitcode; in > particular if the GC could move it in the future, we cannot embed it. I want to come back on this affirmation. Ion is made with the idea that pointers could be replaced. We can mark pointers within the Jit code, and we even have the infrastructure for patching branch/data pointers. see: ::TraceDataRelocations Assembler::patchDataWithValueCheck I think we should not invalidate, but mutate the code in-place when we are moving pointers.
Reporter | ||
Comment 3•10 years ago
|
||
This isn't really an issue for now. If we do make a performance-targeted GC mode in the future that needs this, we can open a new bug.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → WONTFIX
You need to log in
before you can comment on or make changes to this bug.
Description
•