RFR: JDK-8055845 - Add trace event for promoted objects
Staffan Friberg
staffan.friberg at oracle.com
Fri Sep 5 22:20:32 UTC 2014
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/20140905/e467fa1c/attachment.html>
More information about the serviceability-dev
mailing list