record object number in AgeTable for G1

[臧琳]

Hi Thomas, 
	Thanks a lot for your suggestion. 
	Yes, the mainly purpose of this change is to calculate the distribution of objects at each age, after rethink of it , I agree with you that this change is more like an instrumentation for profiling rather than feature for product, and it more or less takes effect of the pause time, since most of the change works in g1 pause phase. So I think it may not be necessary to have a patch for it. 
	And thanks a lot for the info of measuring GC performance, I will use it for performance evaluation of my future changes in GC. 
	BTW, My company (JD.COM or Beijing Wodong Tianjun Information Technology Co. Ltd) has signed the OCA. So I may have more discussion or patches related with GC in future. 

BRs,
Lin
	
-----Original Message-----
From: Thomas Schatzl <thomas.schatzl at oracle.com> 
Sent: Thursday, January 17, 2019 6:44 PM
To: 臧琳 <zanglin5 at jd.com>; hotspot-gc-dev at openjdk.java.net
Subject: Re: record object number in AgeTable for G1

Hi,

On Wed, 2019-01-16 at 01:29 +0000, 臧琳 wrote:
> Hi Thomas, 
>       Thanks for your suggestion, I will try to get some performance 
> number. Btw, do you have any recommendation of the benchmark/micro- 
> bench for pause time measurement?

  I would start with a simple JMH benchmark that copies over quite a lot of data.[0]

Try to reduce variance in the results by e.g. fixing generation sizes and maxing out region size (to decrease the overhead of allocating new regions).

Btw, g1's "Object Copy" phase readings are probably exactly what you want to look at btw.

Specjbb2005 [3] pause times tend to also be somewhat sensitive to changes to the evacuation loop. At least it is very reproducible.

There are other benchmarks like the DaCapo benchmark [4] (or Scalabench
[5]) available, but from a GC POV they tend to be a bit too small for reasonable heap sizes/systems for good measurements.

After that, look at Specjbb2015 if you have access to it. A regression in critical-jops would basically be a no-go unless there is significant other gains elsewhere.

Note that with current machines (depending on what you have) you probably want to run with quite large configurations to reduce the impact of noise.

Before going into this lengthy testing process, that I would like to ask what you think the gain from this information (number of objects per age group) would be?

I admit that I once or maybe twice hacked information like this in for some investigations, but it do not remember it yielding interesting enough information to base decisions on it. I always ended up adding more instrumentation, that was way too intrusive for the product...

Lastly, there are some procedural issues that we need to cover before we can accept a patch: are you covered by an Oracle Contributor Agreement (either individually or via an employer who is sponsoring this work)? 
I haven't found your name (that is, the Pinyin for the name you used in this email) so you don't appear to be covered and this needs to be dealt first [1].

Since you also seem to be a first-time contributor, you need a sponsor of the patch to help you with procedural issues (like getting a bug id in the bug tracker). For the actual review, changes of more than some trivial extent generally get packaged for review using the webrev tool, and published on cr.openjdk.java.net [2]. Your sponsor can also help you with that.

A sponsor should be someone currently involved in OpenJDK GC development, preferably in an area related to the patch. It's not required that they be an Oracle employee, though for some things that might help. I can help you find someone. (It might be me, but I don't want to commit to that today.)

Thanks,
  Thomas

[0] http://openjdk.java.net/projects/code-tools/jmh/
[1] https://openjdk.java.net/contribute/
[2] https://openjdk.java.net/guide/codeReview.html
[3] http://www.spec.org/jbb2005/
[4] http://dacapobench.org/
[5] http://scalabench.org/