JEP 189: Shenandoah: An Ultra-Low-Pause-Time Garbage Collector

[Roman Kennke]

Am Freitag, den 21.02.2014, 15:16 -0800 schrieb Krystal Mok:
> Hi Roman and Christine,
> 
> 
> I'd like to ask another question, on object pointer comparison.
> 
> 
> Now that the source code has been released, people from the outside
> can finally peek into the details ;-)
> I've noticed that there's special handling in the interpreter for
> if_acmp:
> http://icedtea.classpath.org/hg/shenandoah/openjdk8/hotspot/file/ae4e705df435/src/cpu/x86/vm/templateTable_x86_64.cpp#l1860
> 
> 
> 
> Could you please elaborate a little bit on the design of oop
> comparison in Shenandoah?

Yes. The problem with object comparison is that both the left and right
object can move at any time. This means that if we get an left object
pointing to from-space copy and a right object pointing to to-space
copy, we may get a false negative. We make sure that this doesn't happen
by first preemptively copying (if necessary) the left object, and then
resolving the right object (e.g. if we just copied the left object, and
right is the same as left, we follow the forward pointer to the new
copy). It is very unfortunate that we need to do this, I'd be very happy
to have a better/faster way.

The same problem applies to compare-and-swap, except that it is even
worse: we need to write-resolve the value-in-memory (including an
additional CAS to write back the forwarded oop, to avoid race with other
threads), then read-resolve the cmp value, then also read-resolve the
new value, and of course write-resolve the object being written to.

Again, I'd be very happy if somebody can come up with a better way to
deal with that. (Would be great if we could have DCAS...)

Cheers,
Roman

> 
> 
> (P.S. Sad that the FOSDEM presentation video isn't available...)
> 
> 
> Thanks,
> Kris
> 
> 
> On Tue, Feb 4, 2014 at 3:39 PM, Roman Kennke <rkennke at redhat.com>
> wrote:
>         Hi Krystal,
>         
>         
>         > 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?
>         
>         
>         Yes.
>         
>         >  The read barrier is a Brooks-style barrier, but the write
>         barrier is
>         > more than a plain SATB write barrier (as in G1), right?
>         
>         
>         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?
>         
>         
>         It uses the G1 barrier for SATB and extends it for the
>         preemptive
>         copying.
>         
>         We don't use memory protection tricks ;-) Actually we can't,
>         if we
>         protecting our from-spaces, which would be a great thing to
>         do, at least
>         for debugging, we couldn't update the brooks pointers any more
>         when we
>         do the evacuation.
>         
>         Best regards,
>         Roman
>         
>         > e.g. The Chakra JavaScript engine from Microsoft apparently
>         uses a
>         > write barrier implemented via memory protection trick, as
>         noted in one
>         > of their blog
>         > posts:
>         http://blogs.msdn.com/b/ie/archive/2012/06/13/advances-in-javascript-performance-in-ie10-and-windows-8.aspx
>         >
>         >
>         > "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, reducing pauses."
>         >
>         >
>         > Thanks,
>         > Kris
>         >
>         >
>         > 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.
>         >
>         >         Cheers,
>         >         Roman
>         >
>         >         Am Mittwoch, den 15.01.2014, 11:49 -0800 schrieb
>         >         mark.reinhold at oracle.com:
>         >         > Posted: http://openjdk.java.net/jeps/189
>         >         >
>         >         > - Mark
>         >
>         >
>         >
>         >
>         >
>         
>         
>         
> 
>