[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-serviceability-dev
Subject:    Re: RFR: JDK-8055845 - Add trace event for promoted objects
From:       Staffan Friberg <staffan.friberg () oracle ! com>
Date:       2014-08-29 22:32:15
Message-ID: 5400FF6F.5040203 () oracle ! com
[Download RAW message or body]

Hi Erik,

On 08/28/2014 11:34 PM, Erik Helin wrote:
> (it seems like we lost hotspot-gc-dev@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

[Attachment #3 (text/html)]

<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">Hi Erik,<br>
      <br>
      On 08/28/2014 11:34 PM, Erik Helin wrote:<br>
    </div>
    <blockquote cite="mid:54001EFF.3030802@oracle.com" type="cite">(it
      seems like we lost <a class="moz-txt-link-abbreviated" \
href="mailto:hotspot-gc-dev@openjdk.java.net">hotspot-gc-dev@openjdk.java.net</a> \
somewhere in  this thread, I'm adding it back)
      <br>
      <br>
      On 2014-08-28 23:15, Staffan Friberg wrote:
      <br>
      <blockquote type="cite">Hi Erik,
        <br>
        <br>
        Thanks for the comments.
        <br>
        <blockquote type="cite">- Aren't the events for promotion to the
          tenured generation (SerialOld)
          <br>
            and the CMS generation missing?
          <br>
        </blockquote>
        The reason for leaving out these two, Serial completely and CMS
        <br>
        promotion, was due to that neither as far as I understand make
        use of
        <br>
        PLABs.
        <br>
      </blockquote>
      <br>
      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.
      <br>
      <br>
      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.
      <br>
      <br>
      Given this, I think we should add events for Serial and CMS as
      well.
      <br>
      <br>
    </blockquote>
    <br>
    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.<br>
    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.<br>
    <br>
    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.<br>
    <br>
    <br>
    <blockquote cite="mid:54001EFF.3030802@oracle.com" type="cite">
      <br>
      On 2014-08-28 23:15, Staffan Friberg wrote:
      <br>
      <blockquote type="cite">
        <blockquote type="cite">- Would it make sense to differentiate,
          either by separate events or by
          <br>
            a field in a event, between promotions to to-space and to
          the old
          <br>
            generation?
          <br>
          - The are two events for TLAB allocations,
          <br>
            java/object_alloc_in_new_TLAB and
          java/object_alloc_outside_TLAB.
          <br>
            What do you think about using two events for PLAB
          allocations as well:
          <br>
            - java/object_alloc_in_new_PLAB
          <br>
            - java/object_alloc_outside_PLAB
          <br>
        </blockquote>
        I think this is a matter of taste and probably how similar we
        want the
        <br>
        event to be to the existing allocation event. I personally
        prefer a
        <br>
        single event but if the GC team and serviceability team feel it
        would be
        <br>
        better to have two I can certainly rewrite. The reason for me
        preferring
        <br>
        a single event is just ease of analysis, you can easily filter a
        list of
        <br>
        events on a field, it is harder to merge two different events
        with
        <br>
        different fields and work with them in an straight forward
        fashion.
        <br>
        <br>
        Any general preference for having a single or multiple events?
        <br>
      </blockquote>
      <br>
      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.
      <br>
      <br>
    </blockquote>
    Yes, tenured would be independent of having two events, only PLAB
    size and directAllocation would be affected when having two event
    types.<br>
    <br>
    <b>Erik Gahlin</b>, any preference from your end?<br>
    <br>
    <br>
    <br>
    <blockquote cite="mid:54001EFF.3030802@oracle.com" type="cite">On
      2014-08-28 23:15, Staffan Friberg wrote:
      <br>
      <blockquote type="cite">
        <blockquote type="cite">- In PSPromotionManager, instead of
          utilizing the C++ friendship with
          <br>
            PSScavenge, should we add a getter function for the
          gc_tracer?
          <br>
        </blockquote>
        Created a getter function.
        <br>
      </blockquote>
      <br>
      Thanks! If you make report_promotion_sample const, then the getter
      can return a const ParallelScavengeTracer*, right?
      <br>
      <br>
    </blockquote>
    Done<br>
    <br>
    //Staffan<br>
  </body>
</html>



[prev in list] [next in list] [prev in thread] [next in thread]