RFD: The Cost of Profiling in the HotSpot Virtual Machine

[Vladimir Kozlov]

It is known issue [1].  We could use randomized profiling counters update as suggested in RFE.
I think we had such implementation in our JAOTC work back in days. But it may not such simple on not x86 platforms.

And, as Andrew said, it will complicate code and slowdown one thread performance during startup.

Yes, Leyden can help with this. Especially with next JEP we are working on [2] "Ahead-of-Time Method Profiling".
It requires "training" run to collect profiling data and may not work for all cases. But I think we should go this way 
since we are already working on it.

Thanks,
Vladimir K

[1] https://bugs.openjdk.org/browse/JDK-8134940
[2] https://bugs.openjdk.org/browse/JDK-8325147

On 2/3/25 3:18 AM, Andrew Haley wrote:
> This paper is available at
> https://ckirsch.github.io/publications/proceedings/MPLR24.pdf#page=117
> 
> One thing that really stands out is the slowdown caused by multiple
> threads racing to increment profile counters. While this may seem like
> a theoretical concern, we have seen it in customers' real-world
> situations. When an application spins up worker threads which all
> start at the same time, the resulting memory traffic can substantially
> delay application startup.
> 
> It would not be very difficult to fix problem this by using a very
> simple implementation of distributed counters, but doing so would
> generate (even) more code and would be slower in the single-threaded
> case. I have created https://bugs.openjdk.org/browse/JDK-8348027 to
> track this possibility.
> 
> But is it worth doing anything about this at all? You could argue that
> any application that starts too many threads to soon is simply
> misconfigured, but it's hard for Java users to diagnose what's
> happening. Maybe Project Leyden will solve the problem in a better
> way by removing the emphasis on warmup.
> 
> What do you think?
> 
> Thanks,
>