Closed Bug 1010178 Opened 9 years ago Closed 8 years ago

PJS GC: Scan the result array only when it has references, and in parallel

Categories

(Core :: JavaScript Engine, defect)

x86_64
Linux
defect
Not set
normal

Tracking

()

RESOLVED WONTFIX

People

(Reporter: lth, Unassigned)

References

Details

Followup to bug 933313 and bug 993347; optimizations.

During a PJS minor or evacuating collection the "result" array for a ForkJoin section is currently scanned in its entirety by all the workers, each looking for pointers into its own nursery.  The expectation is that there are few live objects in the nursery, so result array scanning could be a significant part of the GC cost.

There are two obvious optimizations.

One is to scan the result array only when its type is "complex", ie, it can contain pointers.  This probably amounts to little more than a type check.  If the GC's scanning code for TypedObject arrays already performs such a check (TBD) then no more work is needed.

The other is to scan the result array in parallel, ie, each worker should not look for pointers to its own heap everywhere but only in sections where it knows that it's written.  Work stealing makes this somewhat complicated.  Two possibilities are a byte map tracking the worker that worked on a slice, and a work log per worker.

The size of a byte map is the number of slices, ie, relatively much smaller than the result array.  However it must be allocated and initialized sequentially and must be scanned in its entirety.

A work log can probably be allocated very cheaply (bump a pointer in the nursery, no initialization needed) by each worker, and would keep track of array indices for each slice taken by the worker.
Re the need to scan the array at all, I think this is already good:

If the result array is a TypedObject array then there is a tracer on the Class, namely TypedObject::obj_trace() in TypedObject.cpp.  That method correctly skips any tracing if the element type is known not to contain references.

If the result array is a regular Array then it appears that the only representation we have contains boxed and tagged values; the provision to convert int to double on storing into the array does not make the array a pure double array that we can avoid scanning, from what I can tell - non-int non-double values are stored as what they are.
Assignee: lhansen → nobody
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.