RFR (L): 8073013: Add detailed information about PLAB memory usage

[Jon Masamitsu]

Thomas,

Basically looks good.  Some questions around the edges.

http://cr.openjdk.java.net/~tschatzl/8073013/webrev/src/share/vm/gc/g1/g1CollectedHeap.hpp.frames.html

>   248   // Manages all kinds of allocations within regions. This excludes only
>   249   // humongous object allocations.
>   250   G1Allocator* _allocator;

Would this comment be more exact?

// Manages all allocations with regions except humongous object allocations.

http://cr.openjdk.java.net/~tschatzl/8073013/webrev/src/share/vm/gc/g1/g1EvacStats.cpp.html

   85 void G1EvacStats::send_obj_copy_mem_event(int for_gen) {
   86   EventGCG1EvacuationMemoryStatistics e;
   87   if (e.should_commit()) {
   88     e.set_gcId(GCId::peek().id());
   89     e.set_gen(for_gen);

Can the conversion of  InCSetState values to generation numbers be put into
the send_obj_copy_mem_event()?

http://cr.openjdk.java.net/~tschatzl/8073013/webrev/src/share/vm/trace/trace.xml.frames.html

  318       <value type="UINT" field="gen" label="Generation" description="Generation these PLAB statistics are for"/>


Can the "gen" field be a character string with "young" or "old" instead 
of a number?

http://cr.openjdk.java.net/~tschatzl/8073013/webrev/src/share/vm/gc/g1/g1EvacStats.hpp.html

Are these alternative comments correct?   Perhaps better for the less G1 
knowledgeable?

   38   // Number of words allocated during evacuation failure in the regions that failed evacuation.

// Number of words in live objects remaining in regions that ultimately suffered an
// evacuation failure.  This is used space in the regions when the regions are made old regions.


   39   size_t _failure_used;

   40   // Number of words wasted during evacuation failure in the regions that failed evacuation.

// Number of words wasted in regions which failed evacuation.  This is the sum of space for
// objects successfully copied out of the regions (now dead space) plus waste at the end of
// regions.

   41   size_t _failure_waste;


Not sure how ingrained the term "inline" allocation, but why "inline"?  It means that
the allocation was directly into the region and not in a LAB in the region, right?
Would _directly_allocated or _direct_allocations work for you?

>    36   size_t _inline_allocated; // Number of words allocated directly into the regions.

That's all.

Jon



On 8/6/2015 8:49 AM, Thomas Schatzl wrote:
> Hi all,
>
>    can I have reviews for this change that prepares for a lot of changes
> related to 8030849 "Investigate high fragmentation/waste in some
> situations during allocation during GC in G1"?
>
> Before investigating and fixing fragmentation during PLAB, we need to
> track that information.
>
> For this reason, PLABStats has been extended in a G1EvacStats class with
> the necessary information that is needed to do better PLAB sizing, in
> particular G1EvacStats::_region_end_waste that tracks the waste at the
> end of regions during refill, G1EvacStats::_regions_filled that tracks
> the number of region refills, G1EvacStats::_inline_allocated that tracks
> the amount of inline allocation (excluding PLAB allocation),
> G1EvacStats::_failure_used and G1EvacStats::_failure_waste that track
> memory usage in regions where evacuation failure occurred.
>
> There had to be somewhat extensive changes particularly to get the
> _region_end_waste in the allocation classes, which is what makes this
> change a bit large.
>
> Overall there is no change in the sizing policy except for accounting
> _region_end_waste.
>
> As you may notice, there is a new JFR event, but no real additional
> logging for the log file (the -XX:+PrintPLAB message has been extended
> though). That will be added in an extra CR, as soon as the new logging
> framework has been added.
>
> CR:
> https://bugs.openjdk.java.net/browse/JDK-8073013
>
> Webrev:
> http://cr.openjdk.java.net/~tschatzl/8073013/webrev
>
> Testing:
> jprt, a few aurora runs, local testing, lots of benchmarks mainly in
> conjunction with the following changes.
>
> Thanks,
>    Thomas
>
>