It might also make sense to check the time to safepoint, paging (esp. during the collection) and also if there's any numa-related stalls involved.
--
You received this message because you are subscribed to the Google Groups "mechanical-sympathy" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mechanical-symp...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
To unsubscribe from this group and stop receiving emails from it, send an email to mechanical-sympathy+unsub...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "mechanical-sympathy" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mechanical-sympathy+unsub...@googlegroups.com.
What are good java shared mem IPC
queues?
If you allocate more objects during concurrent marking than you end up collecting, you will eventually exhaust your heap. During the concurrent marking cycle, you will see young collections continue as it is not a stop-the-world event.
--
You received this message because you are subscribed to the Google Groups "mechanical-sympathy" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mechanical-symp...@googlegroups.com.
Hence, considering what could slow down the marking time (or its cleaning), it's worth to check(as other have suggested):
- allocation rate
- what are the most frequently collected data structures during minor GCs (eg: linked-lists?)
- false sharing issues during card marking (i'm not sure of it)
Thanks all for the suggestions. I'll certainly check the safepoint
stuff. I suspect that a lot of EPA isn't happening where it could also
due to stuff being pushed through disruptor. Even if it is happening,
or I can make it happen, and also clear up all the low hanging fruit,
if I can't get below 100ms pauses on the 10G heap, then it would all
be for nothing.
Censum is interesting, I'll take a look. I have flight recordings
right now. Is it possible to find the time to safepoint in that?
> All that said, the copy cost and reference processing of G1 for a heap as
> busy / sized as yours is unlikely to get under 10ms, as Chris mentioned Gil
> will now be summoned ;-).
Yes, really what I'm looking for is someone to tell me "no, you're
nuts, not possible" so I can justify going down the rearchitecture
route. Unfortunately Zing isn't an option, since it would double the
cost of our product.
On Dec 14, 2016, at 5:02 AM, Gil Tene <g...@azul.com> wrote:Wow. I forgot I wrote that tool. Glad to see it helped you in your analysis Ivan.And Kirk, [most] of my GC related tools are not designed to break OpenJDK's GCs. The GC-realted tools I build are usually designed to exhibit normal GC behaviors more quickly in order to allow practical test-based observations (trying hard to not exacerbate the GC stall lengths, and only make them happen more frequently). This is true even for stressor tools like HeapFragger.
-Ivan