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

Erik Helin erik.helin at oracle.com
Fri Aug 29 06:34:39 UTC 2014 

(it seems like we lost hotspot-gc-dev at openjdk.java.net somewhere in this 
thread, I'm adding it back)

On 2014-08-28 23:15, Staffan Friberg wrote:
> 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.

I might be wrong here, but looking at the function 
TenuredGeneration::par_promote (in tenuredGeneration.cpp) it looks to me 
like SerialOld is using PLABs when ParNew is promoting objects from 
young to old.

As for CMS, looking at ConcurrentMarkSweepGeneration::par_promote (in 
concurrentMarkSweepGeneration.cpp) it seems like each 
CMSParGCThreadState has a CFLS_LAB (CompactibleFreeListSpace Local 
Allocation Buffer) that is a thread-local allocation buffer. See 
compactibleFreeListSpace.{hpp,cpp} for more details.

Given this, I think we should add events for Serial and CMS as well.

On 2014-08-28 23:15, Staffan Friberg wrote:
> 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.

Thanks!

On 2014-08-28 23:15, Staffan Friberg wrote:
>> - 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?

I would prefer to have two events in this case and try to follow the 
existing allocation events as much as possible (both in naming and in 
style). Keeping the tenured field (I missed it the first time I read the 
patch) is good.

On 2014-08-28 23:15, Staffan Friberg wrote:
>> - In PSPromotionManager, instead of utilizing the C++ friendship with
>>   PSScavenge, should we add a getter function for the gc_tracer?
> Created a getter function.

Thanks! If you make report_promotion_sample const, then the getter can 
return a const ParallelScavengeTracer*, right?

Thanks,
Erik

> 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 hotspot-gc-dev mailing list