When profiling a production application with JFR, we discovered that some allocation samples have abnormally large 'weight', e.g. an AtomicBoolean allocation was assigned the weight of 17.3 GiB. About 80 of total 26K ObjectAllocationSamples weighed more than 1 GiB each and those samples completely distorted the overall allocation profile.

It turns out that if JFR recording is enabled at runtime, the first sampled allocation in each thread "accumulates" all previous allocations happened in this thread before the recording.

I'm attaching WrongAllocationWeight.java that demonstrates the problem. The program allocates 2GB Java objects then starts JFR recording. The first allocation sample in that recording will have the weight more than 2GB.