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

[Erik Gahlin]

Metadata looks good (trace.xml).

/E

Staffan Friberg skrev 2014-09-06 00:20:
> Hi,
>
> I have uploaded a new webrev here, 
> cr.openjdk.java.net/~sfriberg/8055845/webrev.03
>
> It contains several changes
>
>     - Split event into two events (PromoteObjectInNewPLAB, 
> PromoteObjectOutsidePLAB)
>     - Moved events to "vm/gc/detailed/PromoteObject..."
>     - Supporting ParNew+CMS and ParNew+SerialOld tenuring
>          - Not sure if the way I do it with passing the ParNewTracer 
> is the best solution, please let me know if you have an idea how to 
> improve it
>     - Simplified the G1 code to avoid sending age and having a single 
> call site
>     - Fixed so that the generated event has size information in bytes 
> rather than words
>
> Thanks for offline comments and suggestions from Dmitry and Thomas.
>
> Cheers,
> Staffan
>
> On 08/29/2014 03:32 PM, Staffan Friberg wrote:
>> Hi Erik,
>>
>> On 08/28/2014 11:34 PM, Erik Helin wrote:
>>> (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.
>>>
>>
>> Ok I see what you mean with CMS, basically the equivalent to getting 
>> a PLAB would be when we refill the CFLS_LAB in the alloc function. It 
>> still does the allocation to a small memory (~ size of object) area 
>> from the freelist, but at least we did extra work to refill the local 
>> CFLS_LAB. Need to do some analysis to see how often we refill so the 
>> overhead doesn't get too high.
>> The only issue I run into is how I can in a nice way get access to 
>> the ParNewTracer from ParNewGeneration to call the report function. 
>> Let's sync up next week and see how it can be solved.
>>
>> The tenured GC requires something similar to be supported, however 
>> since ParNewGC is deprecated for usage without CMS in JDK 8 we might 
>> want to skip that combination.
>>
>>
>>>
>>> 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.
>>>
>> Yes, tenured would be independent of having two events, only PLAB 
>> size and directAllocation would be affected when having two event types.
>>
>> *Erik Gahlin*, any preference from your end?
>>
>>
>>
>>> 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?
>>>
>> Done
>>
>> //Staffan
>

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