RFR: JDK-8055845 - Add trace event for promoted objects

Staffan Friberg staffan.friberg at oracle.com
Thu Aug 28 21:15:44 UTC 2014 

Hi Erik,

Thanks for the comments.
> - Aren't the events for promotion to the tenured generation (SerialOld)
>   and the CMS generation missing?
The reason for leaving out these two, Serial completely and CMS 
promotion, was due to that neither as far as I understand make use of 
PLABs. So without a good sampling type of event it would end up being an 
event for each aging and/or promotion that happened in the GC. As this 
would be a very large number of events so I decided not to support those 
cases due to performance concerns. If you have a good idea on how to 
support it please let me know. I would see CMS as the priority of the 
two, client workloads can usually be analyzed with a different collector 
which might not be the case for a latency sensitive application.

> - We try to keep the trace dependency (the header file) in
>   gcTraceSend.cpp, see the pattern for all the other events in
>   gcTrace.cpp (they all have a "report" and a "send" function).
Will update it to follow that pattern.

> - Would it make sense to differentiate, either by separate events or by
>   a field in a event, between promotions to to-space and to the old
>   generation?
> - The are two events for TLAB allocations,
>   java/object_alloc_in_new_TLAB and java/object_alloc_outside_TLAB.
>   What do you think about using two events for PLAB allocations as well:
>   - java/object_alloc_in_new_PLAB
>   - java/object_alloc_outside_PLAB
I think this is a matter of taste and probably how similar we want the 
event to be to the existing allocation event. I personally prefer a 
single event but if the GC team and serviceability team feel it would be 
better to have two I can certainly rewrite. The reason for me preferring 
a single event is just ease of analysis, you can easily filter a list of 
events on a field, it is harder to merge two different events with 
different fields and work with them in an straight forward fashion.

Any general preference for having a single or multiple events?

> - In PSPromotionManager, instead of utilizing the C++ friendship with
>   PSScavenge, should we add a getter function for the gc_tracer? 
Created a getter function.

Will upload a new webrev shortly.

//Staffan

On 08/28/2014 02:27 AM, Erik Helin wrote:
> Hi Staffan,
>
> thanks for the patch, looks like a useful event!
>
> A few initial comments:
> - Aren't the events for promotion to the tenured generation (SerialOld)
>   and the CMS generation missing?
> - We try to keep the trace dependency (the header file) in
>   gcTraceSend.cpp, see the pattern for all the other events in
>   gcTrace.cpp (they all have a "report" and a "send" function).
> - Would it make sense to differentiate, either by separate events or by
>   a field in a event, between promotions to to-space and to the old
>   generation?
> - The are two events for TLAB allocations,
>   java/object_alloc_in_new_TLAB and java/object_alloc_outside_TLAB.
>   What do you think about using two events for PLAB allocations as well:
>   - java/object_alloc_in_new_PLAB
>   - java/object_alloc_outside_PLAB
> - In PSPromotionManager, instead of utilizing the C++ friendship with
>   PSScavenge, should we add a getter function for the gc_tracer?
>
> Thanks,
> Erik
>
> On 2014-08-27 16:28, Bengt Rutisson wrote:
>>
>>
>> Hi Staffan,
>>
>> Overall I think this change looks fine. I know that Erik Helin has some
>> thoughts on the naming of the events. I'll let him communicate those
>> thoughts.
>>
>> Apart from Erik's comments and the missing test case (that I know you
>> are working on) I think the change looks good.
>>
>> Thanks,
>> Bengt
>>
>> On 8/26/14 10:50 AM, Bengt Rutisson wrote:
>>>
>>> Hi all,
>>>
>>> Staffan sent me an updated webrev based on Erik's comments. I uploaded
>>> it here:
>>> http://cr.openjdk.java.net/~brutisso/8055845/webrev.01/
>>>
>>> Thanks,
>>> Bengt
>>>
>>>
>>> On 2014-08-25 19:32, Staffan Friberg wrote:
>>>> Hi Erik,
>>>>
>>>> No issue with naming the field class, since the event is similar to
>>>> the Allocation event I used that as a starting point and it also uses
>>>> class as name together with a couple of other events.
>>>>
>>>> Will go through the descriptions and remove periods.
>>>>
>>>> Object age is basically the how many times an object has been kept in
>>>> survivor region, it is incremented each time a YC happens and the
>>>> object is aged.
>>>> Will see how I can update the description to make it clearer. Calling
>>>> the field tenuringAge might help?
>>>>
>>>>> From the documentation,
>>>>> http://docs.oracle.com/javase/8/docs/technotes/tools/unix/java.html
>>>>>
>>>>> -XX:MaxTenuringThreshold=/threshold/
>>>>>
>>>>>     Sets the maximum tenuring threshold for use in adaptive GC
>>>>>     sizing. The largest value is 15. The default value is 15 for the
>>>>>     parallel (throughput) collector, and 6 for the CMS collector.
>>>>>
>>>>>     The following example shows how to set the maximum tenuring
>>>>>     threshold to 10:
>>>>>
>>>>>     -XX:MaxTenuringThreshold=10
>>>>>
>>>>>
>>>>> -XX:+PrintTenuringDistribution
>>>>>
>>>>>     Enables printing of tenuring age information. The following is
>>>>>     an example of the output:
>>>>>
>>>>>     Desired survivor size 48286924 bytes, new threshold 10 (max 10)
>>>>>     - age 1: 28992024 bytes, 28992024 total
>>>>>     - age 2: 1366864 bytes, 30358888 total
>>>>>     - age 3: 1425912 bytes, 31784800 total
>>>>>     ...
>>>>>
>>>>>     Age 1 objects are the youngest survivors (they were created
>>>>>     after the previous scavenge, survived the latest scavenge, and
>>>>>     moved from eden to survivor space). Age 2 objects have survived
>>>>>     two scavenges (during the second scavenge they were copied from
>>>>>     one survivor space to the next). And so on.
>>>>>
>>>>>     In the preceding example, 28 992 024 bytes survived one scavenge
>>>>>     and were copied from eden to survivor space, 1 366 864 bytes are
>>>>>     occupied by age 2 objects, etc. The third value in each row is
>>>>>     the cumulative size of objects of age n or less.
>>>>>
>>>>>     By default, this option is disabled.
>>>>>
>>>>
>>>> Thanks for the comments,
>>>> Staffan
>>>>
>>>> On 08/25/2014 09:55 AM, Erik Gahlin wrote:
>>>>> Did you manage to call the field "class"? It's a reserved word in
>>>>> C++, so we had to use "klass" in the past
>>>>>
>>>>> Descriptions with only one sentence shouldn't end with "."
>>>>>
>>>>> How is "Object Age" measured?
>>>>>
>>>>> As a user, I would expect the number to be in seconds/minutes/hours,
>>>>> but that is not the case. Perhaps an explanation in the description
>>>>> and/or a field name that better reflects what we really mean with 
>>>>> age.
>>>>>
>>>>> Otherwise trace.xml looks good!
>>>>>
>>>>> Erik
>>>>>
>>>>> Staffan Friberg skrev 25/08/14 18:28:
>>>>>> Hi,
>>>>>>
>>>>>> Could I please get reviews for this RFE that adds a trace event for
>>>>>> aging and promotion for young collections in G1, CMS and Parallel 
>>>>>> GC.
>>>>>> It works similarly to allocation events, and generates the event on
>>>>>> the slow path when either a direct copy occurs or a new PLAB is
>>>>>> request.
>>>>>>
>>>>>> Since I'm adding an event I cc:ed the serviceability list in case
>>>>>> anyone has any comments on the event and changes to trace.xml.
>>>>>>
>>>>>> RFE: https://bugs.openjdk.java.net/browse/JDK-8055845
>>>>>> Webrev: http://cr.openjdk.java.net/~brutisso/8055845/webrev.00
>>>>>>
>>>>>> Bengt has been kind and agreed to both sponsor and host the the
>>>>>> webrev.
>>>>>>
>>>>>> Thanks,
>>>>>> Staffan
>>>>>>
>>>>>
>>>>
>>>
>>

More information about the serviceability-dev mailing list