RFR 7097567: G1: abstract and encapsulate collector phases and transitions between them

[Derek White]

On 1/27/15 6:03 PM, Claes Redestad wrote:
> Hi,
>
> Assuming ref.1 is the baseline and cms.1 is with the patch applied 
> (running G1?),
> it actually looks like all significant results are regressions, not 
> improvements. Some
> regressions even appear pretty severe.
>

Thanks Claes,

I made some beginner mistakes here. Yes, ref is the baseline, and I read 
+/- backwards.  But I didn't specify g1 (or any options at all) in the 
refworkload property file. So the changed code should not have run at 
all, which really leaves the differences unexplained.

In any case, running baseline and changed code again with g1 specified.
> Grouping state changed often(?) together could be increasing overall 
> false sharing
> costs and the added indirections could have some effect. I think it'd 
> be good with a
> more thorough performance analysis of this.

The fields were moved to another class, but it's more like a struct 
inlined within G1CollectorPolicy. There is not an actually separately 
allocated object, so in theory the compiler can generate the exact same 
code as before. If I still see a regression I'll have to look at the 
generated code to see if the compiler gave up at some point.

Also, what more thorough performance analysis would you recommend (if 
it's needed).

Thanks!

  - Derek


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20150127/d12f64cf/attachment.htm>