On Mon, Mar 1, 2010 at 6:45 AM, Luke Terry <ljt06@...> wrote:
> Hi all,
> I've been developing a classical Baker-style semi-space incremental
> garbage collector using RVM-777 (NewMMTkGlue) and have run into some
> difficulties with memory consumption.
> To adapt the MMTk to support incremental collection I have added an
> incremental phase, which causes k objects to be traced by the collector
> threads. The incremental phase continues in the same place poll() is
> called (for work-based collection), it actually just yields to collector
> threads if there is still incremental work to be done.
> To support a baker-style read barrier I introduced allocCopy methods
> into the mutator context so that mutator threads can performing the
> forwarding of objects. This also means that the mutator threads end up
> adding objects that need to be scanned into a TraceWriteBuffer.
> Firing the initial collection at 30-40% of the total heap size leads to
> GC live ratio warnings, I assume because I'm not collecting enough
> objects to finish collection before allocations fill the remaining
> space. However, I noticed that the meta space is expanding far beyond
> what you might expect, this is due to the remembered sets in the mutator
> - to ensure that I don't miss objects during the trace I flush the
> remembered sets after each forward. I realise this is very inefficient
> and have tried flushing mutators before each incremental step, but this
> led to objects being missed.
It is possible to use a soft handshake to lazily perform the flushing as
part of the termination condition of the collection process. Once one thread
runs out of work, it can request that all threads have their buffers
> I would like to simplify the process by introducing an implicit
> work-queue, by iterating over to-space with a bump-pointer. This would
> mean that I would not need to flush anything out of the mutators and
> would use less meta-space memory. I would appreciate some guidance on
> how best to take this approach.
I would start by implementing a Cheney-style semi-space, using the
getObjectEndAddress/getObjectFromStartAddress methods as used for linear
scanning of bump pointer spaces.
> Further, there is an issue with Magic reading fields directly (for
> instance when performing reflection operations) when it disables GC i.e.
> 1: incremental collection starts (scans the stacks),
> 2: mutators resume and Magic is used to grab a field address (in
> 3: the object (whose address was read by magic) is forwarded during
> incremental work or a read-barrier,
> 4: the address grabbed using magic is then used (for instance to compare
> method code locations) breaking the tri-colour invariant.
> Is it possible to implement a read barrier for Magic code? As the
> alternative (rescan the stack after an object is forwarded) is horrendous.
You should not need any additional barriers, the read-barrier should be
called whenever an object is read from the heap. If this is not the case, it
is not a question of adding barriers to magic in general, but finding which
magic is at fault and making sure it is barriered.
In the example you mention (code) it is an error for code objects to be
included in your semi-space collection, they should be non-moving.
Your email has reminded me that I have some concurrent collection work
(partly concurrent mark sweep) that I need to commit back to the branch (and
then the head) very shortly. This week is quite hectic, but I have been
debugging it in the background, and recently worked out (at least some of)
the bugs that were causing so much grief.
> Luke Terry
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> Jikesrvm-researchers mailing list