650095 - GC: Switch to bump-pointer allocation

Status: RESOLVED DUPLICATE of bug 601075

(Core :: JavaScript Engine, defect)

Description

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

We should be able to do this right now. The main goal is to avoid having to build up the free list in FinalizeArenaList.

The idea I have is to break up arenas into runs of free objects, with allocated objects in between. We would still use a free list, but the structure would be different. Only the first and last object in a run of free objects would have a freelist pointer. The first object in the run would point to the last, and the last would point to the first object in the next run of free objects.

We would use bump pointer allocation within a run of free objects. There would be an allocation pointer and a limit pointer. To allocate, we would increment the alloc pointer until reaching the limit.

We would initialize the allocation pointer to the start of a run of free objects, and the limit pointer to the end of the run. Upon reaching the limit, we would be at the last free object in the run. We would use its next pointer to reset the allocation and limit pointers to the next free run.

With this scheme, as long as runs of free objects are long, we would touch much less memory while setting up the free list in each sweep. Generational collection should ensure that we have very long runs of free objects in the young generation. But even now I'm guessing that free runs are reasonably long.

Coupled with bug 648320, we could almost completely eliminate the cost of sweeping and finalization.

Comment 1

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

Igor did this a while ago.