RFR: JDK-8055845 - Add trace event for promoted objects
Erik Gahlin
erik.gahlin at oracle.com
Mon Sep 15 13:56:05 UTC 2014
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: <http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20140915/4191e9fd/attachment.html>
More information about the serviceability-dev
mailing list