JEP 189: Shenandoah: An Ultra-Low-Pause-Time Garbage Collector
rednaxelafx at gmail.com
Tue Feb 4 15:11:32 PST 2014
Hi Roman and Christine,
I'd like to ask a couple of questions about the barriers, out of curiosity.
The JEP says:
"...All reads by the Java Threads indirect through this forwarding pointer.
All writes to objects in targeted regions must first copy the object and
then write to the object in its new location."
Does this mean Shenandoah employs both read and write barriers? The read
barrier is a Brooks-style barrier, but the write barrier is more than a
plain SATB write barrier (as in G1), right?
Will Shenandoah try to reuse the existing write barrier logic in HotSpot
and extend it to catch all field writes as opposed to just reference field
writes, or will it use some other form of write barrier?
barrier implemented via memory protection trick, as noted in one of their
"Because Chakra's collector works concurrently with the main script thread,
the running script may modify or create new objects on pages that have
already been processed. To make sure such objects aren't prematurely
collected, Chakra write-protects pages before the mark phase starts. Pages
that have been written to during the mark phase must be later rescanned on
the main script thread. Because leaf objects don't require such processing,
pages from the leaf object space don't need to be write-protected or
rescanned later. This saves precious time on the main script thread,
On Fri, Jan 17, 2014 at 11:28 AM, Roman Kennke <rkennke at redhat.com> wrote:
> Hi there,
> Sorry being so silent... we are very happy that the Shenandoah JEP has
> finally been posted and would welcome any comments, questions,
> discussion from the community.
> Am Mittwoch, den 15.01.2014, 11:49 -0800 schrieb
> mark.reinhold at oracle.com:
> > Posted: http://openjdk.java.net/jeps/189
> > - Mark
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the hotspot-gc-dev