Low-Overhead Heap Profiling
robbin.ehn at oracle.com
Tue Jul 4 07:53:42 UTC 2017
First I want to thank you for helping out with this!
On 07/03/2017 02:44 PM, Thomas Schatzl wrote:
> On Wed, 2017-06-28 at 09:51 +0200, Robbin Ehn wrote:
>> On 06/21/2017 10:45 PM, JC Beyler wrote:
>>> Hi all,
>>> First off: Thanks again to Robbin and Thomas for their reviews :)
>>> Next, I've uploaded a new webrev:
>>> Here is an update:
>>> - @Robbin, I forgot to say that yes I need to look at implementing
>>> this for the other architectures and testing it before it is all
>>> ready to go. Is it common to have it working on all possible
>>> combinations or is there a subset that I should be doing first and
>>> we can do the others later?
>> I will change my mind here and proposed a different approach.
>> Right now the only compiler platform change you have is for the
>> FastTLABRefill works for all gc except G1 (CMS is deprecated) but
>> only in C1 compiled code.
>> The performance angle of this is not really relevant, since then you
>> will have C2 compiled code.
> Afaik C2 compiled code also uses the stubs for TLAB refill/inline
> allocation too (I may remember wrongly).
The FastTLABRefill is only checked in e.g.:
>> So I suggested that we should remove FastTLABRefill completely, I
>> will try to makes this happen but most likely not before my long
>> That means you can avoid all platform specific code (as patch is
>> now), correct?
>> If so just keep the x86 support in there and we remove that if I
>> succeed, plus you can support all platforms when
>> Sounds good?
> Not sure about it is easy to remove FastTLABRefill, but that may be
> something to discuss in more detail. Just noting that while the runtime
> call can be negligible on large heaps (with large TLABs) it might not
> be on small ones (or you have many Java threads which causes your TLABs
> to get smallish due to how TLAB size is calculated iirc).
> E.g. Serial GC may still be used a lot on embedded platforms which tend
> to use smaller heaps and benefit the most from this optimization.
This was a worry I also had, I was told not to worry (by several folks).
> Now one can always automatically disable FastTLABRefill if you want
> this kind of heap monitoring (and it does not work with
That would be good.
When I get back I will start the CSR for removing FastTLABRefill.
The CSR can of course be 'denied', but I will give it a go.
More information about the hotspot-compiler-dev