Status

()

--
enhancement
RESOLVED WONTFIX
11 years ago
11 years ago

People

(Reporter: igor, Assigned: igor)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Assignee)

Description

11 years ago
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.
(Assignee)

Comment 1

11 years ago
This is another spin-off of the bug 157334.
Igor, did you want to redo this? I can extract the patch if you like.

/be
(Assignee)

Comment 3

11 years ago
(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.
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
(Assignee)

Comment 5

11 years ago
(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.

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
(Assignee)

Comment 7

11 years ago
Created attachment 290099 [details] [diff] [review]
v 0.2

Patch backup: it would not compile in xpconnect.
Assignee: general → igor
Status: NEW → ASSIGNED
(Assignee)

Comment 8

11 years ago
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.
Status: ASSIGNED → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.