RFR(S): 8007701: Hotspot trace Allocation Events
Bengt Rutisson
bengt.rutisson at oracle.com
Mon Mar 25 19:41:56 UTC 2013
Hi Nils,
On 3/25/13 2:34 PM, Nils Eliasson wrote:
> Hi Bengt,
>
> Well, collectedHeap already includes all kinds of gc-stuff -
> "gc_implementation/shared/gcTrace.hpp" for example.
Not sure I understand this comment, but that's ok.
>
> Anyway - I moved them out. Had to have both a cpp and a hpp file since
> collectedHeap can't include trace/tracing.hpp which the events require.
Thanks, I like this much better.
One thought. If you make the send methods instance methods instead of
static methods on the class you could stack allocate an AllocTracer in
the top level functions and pass a reference to that instance to the sub
methods instead of passing the klass. The AllocTracer would have to keep
track of the klass. This would not reduce the number of parameters you
need to pass around, but it kind of explains the purpose of why you need
to pass it a bit.
What do you think?
>
> C1-Allocations is covered when using the flag -XX:-FastTLABRefill
> (will be documented). And when running with G1 it is already default
> off (because of the barriers that is required). FastTLABRefill could
> probably be retired when proper regression anlysis has been done.
> Wouldn't miss the pages of platform dependent code.
OK. Sounds like a good plan. Is there an RFE filed to retire FastTLABRefill?
Thanks,
Bengt
>
>
> New rev:
> http://cr.openjdk.java.net/~neliasso/8007701/webrev.07/
>
> //Nils Eliasson
>
>
>
>
>
> On 2013-03-22 13:53, Bengt Rutisson wrote:
>>
>> Hi Nils,
>>
>> Overall this looks good, but I have two questions.
>>
>> Could we add a new class (maybe called AllocTracer?) instead of
>> adding the two static send methods to GCTracer? It feels a bit wrong
>> to have the GCTracer handle things that don't happen during a GC.
>>
>> How do we handle the fact that this does not cover the C1 tlab
>> allocations? Is there a bug to track that?
>>
>> Thanks,
>> Bengt
>>
>> On 3/22/13 10:12 AM, Nils Eliasson wrote:
>>> Latest webrev after more feedback:
>>>
>>> http://cr.openjdk.java.net/~neliasso/8007701/webrev.06/
>>>
>>> //N
>>>
>>>
>>> On 2013-03-20 16:24, Nils Eliasson wrote:
>>>> Thanks for your review Erik,
>>>>
>>>> Updated the webrev with your suggestions
>>>> - Moved alloction events to GCTrace
>>>> - Renamed class event field to "class"
>>>>
>>>> http://cr.openjdk.java.net/~neliasso/8007701/webrev.04/
>>>> http://bugs.sun.com/view_bug.do?bug_id=8007701
>>>>
>>>> //Nils Eliasson
>>>>
>>>>
>>>> On 2013-03-14 21:42, Nils Eliasson wrote:
>>>>> Hi all,
>>>>>
>>>>> I would like a review for this change that introduces two new
>>>>> tracing events.
>>>>>
>>>>> "AllocationInNewTLAB" is sent for the first object in a new TLAB
>>>>> and gives a reasonably cheap and reasonably fair object sampling.
>>>>> "AllocationOutsideTLAB" is sent for each object that gets
>>>>> allocated outside the TLABs. (The object doesn't fit or would
>>>>> cause too much wasted free space if the tlab was discarded.)
>>>>>
>>>>> These events use the allocation slow path in CollectedHeap which
>>>>> is used by default in the template interpreter and the C2
>>>>> compiler. It is also used for all TLAB refills in the C1-compiler
>>>>> if the flag -XX:-FastTLABRefill is supplied.
>>>>>
>>>>> http://cr.openjdk.java.net/~neliasso/8007701/webrev.03/
>>>>> http://bugs.sun.com/view_bug.do?bug_id=8007701
>>>>>
>>>>> The event code for AllocationOutsideTLAB had to be put in
>>>>> CollectedHeap.cpp since tracing.hpp can't be included into
>>>>> CollectedHeap.inline.hpp.
>>>>>
>>>>> Thanks,
>>>>> Nils Eliasson
>>>>
>>>
>>
>
More information about the hotspot-gc-dev
mailing list