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)

defect
Not set
normal

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.
Why is |arr| being allocated in the nursery?  It should have singleton type and therefore be tenured.
(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.
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
Blocks: 1146867
Blocks: 1507445
You need to log in before you can comment on or make changes to this bug.