396493 - Allow moving tracers.

Status: RESOLVED WONTFIX

(Core :: JavaScript Engine, enhancement)

Description

[Igor Bukanov]

This is a spin-off of bug 157334.

It would be nice if a tracing API would allow to implement a tracer that can move move things on GC heap. For that it should be sufficient to change the signature of various trace calls to return a pointer to to a new location of GC thing and then change the trace implementation to store the result.

Comment 1

[Igor Bukanov]

This is another spin-off of the bug 157334.

Comment 2

[Brendan Eich [:brendan]]

Igor, did you want to redo this? I can extract the patch if you like.

/be

Comment 3

[Igor Bukanov]

(In reply to comment #2)
> Igor, did you want to redo this? I can extract the patch if you like.

I was going to extract that part and apply it myself and apply it as is perhaps with checking that the code does not access the value before the move. 

My plan is to use such patch to see if it is worth to use a generic copy collector for doubles. They do not have a finalizer so a copy collector would allow to skip expensive free list construction for them.

Comment 4

[Brendan Eich [:brendan]]

See bug 161110 comment 21 for an alternative that could be even better. Copying collectors are a pain for JITting and may not beat "stack" GC, but it is hard to beat a real stack for temporaries!

/be

Comment 5

[Igor Bukanov]

(In reply to comment #4)
> Copying
> collectors are a pain for JITting and may not beat "stack" GC,

AFAICS the "stack" GC is just a generational copy GC where the generation is defined by the size of GC arena and which assumes that anything falling outside interpreter's stack is long lived and should be delegated to mark-and-sweep.

> but it is hard to beat a real stack for temporaries!

When most of double does not survive GC, a copy GC for them should be theoretically comparable with stack in performance. That is, the allocation is just a normal stack push with a lock taken only very occasionally. The deallocation is also cheap since the GC touches just few long-live double results and never touches/scans/sweeps the garbage. 

Of cause practice can be far from the theory, so one never knows until tries. But to prove/disprove it it is necessary to have copy-collector-friendly API that a patch for this bug should provide.

Also note that a copy collector for SM would work only for doubles. For strings one has to sweep the garbage to run the finalizers unless one allocates string's chars also on heap. But even in that case the copy phase of GC can be expensive as the live/garbage ratio for strings is much higher then for doubles.

Comment 6

[Brendan Eich [:brendan]]

I'm with you in wanting copying for the local-gc idea in bug 157334, to reduce re-tracing overhead. A real stack-based GC would do escape analysis and try to allocate in the right frame, or in the heap, and not copy at all -- but that is for another bug.

/be

Comment 7

[Igor Bukanov]

Attachment: v 0.2

Patch backup: it would not compile in xpconnect.

Comment 8

[Igor Bukanov]

The moving tracers would not work as SM uses copy-of-rooted model for GC things. That is, SM assumes that it is ok to pass to function and store in local variables jsval and other GC things as long as it is a copy of a value stored in the rooted location. Such copies are not reported to the tracing API so the tracer can not move GC things as it does not know all the locations.