Fixed, now checking the allocation result before sending event.
I'm checking in all four instances, even if it is only necessary to
check the direct allocation. If we get a new fresh PLAB I would expect
the allocation to always succeed since we have checked the size before
getting the PLAB.
Thanks,
Staffan
On 09/15/2014 05:06 AM, Bengt Rutisson wrote:
Hi Staffan,
psPromotionManager.inline.hpp
I think the PSPromotionManager::copy_to_survivor_space() might send
multiple events. If the allocation to the young gen fails we will fall
through to do an old gen allocation. But we send the events before we
realize that the allocation has failed, i.e. new_obj is NULL.
I talked to Erik a bit about how to handle the gc_tracer in
par_promote. He'll get back to you with some thoughts on that.
Thanks,
Bengt
On 2014-09-06 00:20, Staffan Friberg wrote:
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-...@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
