RFR (XS): 8212753: Improve oopDesc::forward_to_atomic

Thomas Schatzl thomas.schatzl at oracle.com
Tue Oct 23 11:03:42 UTC 2018


Hi,

  thanks for your review.

On Mon, 2018-10-22 at 21:49 -0400, Kim Barrett wrote:
> > On Oct 22, 2018, at 9:02 AM, Thomas Schatzl <
> > thomas.schatzl at oracle.com> wrote:
> > 
> > CR:
> > https://bugs.openjdk.java.net/browse/JDK-8212753
> > Webrev:
> > http://cr.openjdk.java.net/~tschatzl/8212753/webrev/
> > Testing:
> > hs-tier1-3
> > 
> > Thanks,
> >  Thomas
> 
> There’s an additional change to the G1 code here:
> src/hotspot/share/gc/g1/g1ParScanThreadState.cpp
>  313     } else if (!obj->is_typeArray()) {
> 
> which seems unrelated to the described change and unmentioned in the
> RFR.
> Is this change intentional here? 

No.

> Is this a measurable optimization? 

On parallel GC and jbb2005 (and probably some specjvm2008 applications
as I believe this is the class of applications parallel has been
optimized for), it seems to decrease pause time measurably slightly
(did some ad-hoc testing right now).

For G1 the situation is more fuzzy, as its pause time readings are much
more noisy. The change for G1 is very old now, lying around for maybe
years, so it slipped in when cutting up some recent improvements.Sorry, wasn't intentional. 

> For the CMS-conditionalized asserts in forward_to_atomic, please add
> a comment that CMS may CAS in a special pseudo-oop value.

Done.

http://cr.openjdk.java.net/~tschatzl/8212753/webrev.0_to_1 (diff)
http://cr.openjdk.java.net/~tschatzl/8212753/webrev.1/ (full)

Thanks,
  Thomas





More information about the hotspot-gc-dev mailing list