Allocations profiler

[Kirk Pepperdine]

On Feb 20, 2015, at 11:58 AM, Aleksey Shipilev <aleksey.shipilev at oracle.com> wrote:

> On 02/20/2015 01:31 PM, Dawid Weiss wrote:
>>> I am not sure how they are able to pull off low-overhead profiling like
>>> that.
>> 
>> Just guessing but I think these may be separate problems (and separate
>> benchmarks); if you're profiling memory allocations you don't care (or
>> shouldn't look at) performance numbers.
> 
> I would think so too.
> 
>> I'm not saying it's easy to do or derive clear conclusions from
>> numbers (considering TLABs, different GCs, local optimizations like
>> escape analysis, etc.), but in many cases it's easy to spot relatively
>> simple problems.
> 
> I agree. In the same way, you can "just" attach the sampling profiler
> (like JFR, VisualVM, YourKit, you name it) and piggyback on the law of
> large numbers. If there are allocations in the benchmark code, they will
> float up.

This is the correct answer IMHO.

> 
> What's a use case for allocation-accurate profiler?

Allocations are dictated by execution paths through the code. The only difference between “fast” and “slow” code is the rate. But all rates should be relative.

Regards,
Kirk