Fully featured low overhead profiler for Java EE and Java SE platforms.
Easy to use performance and memory profiler for .NET Framework.
Performance monitoring and profiling of Jenkins, Bamboo, TeamCity, Gradle, Maven, Ant and JUnit.

Memory allocation tracking

Moderators: Vladimir Kondratyev, Anton Katilin

Memory allocation tracking

Postby will.sargent » Tue Sep 08, 2020 6:04 pm

Hi there,

I'm interested in seeing what improvements there are in the JVM from 1.8 to 11. Running Yourkit, I can see that in 1.8 with the same application code the allocation rate is 2.6 M/sec, and running with JDK 11, it's only 350 K/sec. I'd like to find out what the difference is between JVMs, but when I turn on full memory allocation sampling, the allocation rate jumps from 350K to 900K, so something in the profiling disables some optimizations.

Here's the blog post with more details:

https://tersesystems.com/blog/2020/08/2 ... th-jdk-14/

and the application results:

https://github.com/wsargent/memalloctes ... er/results

is there a way to find what is causing the delta between JVMs?
will.sargent
 
Posts: 1
Joined: Tue Dec 25, 2018 9:28 pm

Re: Memory allocation tracking

Postby Anton Katilin » Wed Sep 09, 2020 6:57 am

Hello,

Exactly what object allocation mode did you use? If you are interested in the rate, I think the best option is object counting ("Count allocated objects" in the UI, startup option "alloc_object_counting" - see https://www.yourkit.com/docs/java/help/allocations.jsp ).

Also, could you please try to specify the startup option "disable_heap_sampling" when running on Java 11+. Does the rate change?

How to specify: https://www.yourkit.com/docs/java/help/ ... ptions.jsp

Best regards,
Anton
Anton Katilin
 
Posts: 6009
Joined: Wed Aug 11, 2004 8:37 am

Re: Memory allocation tracking

Postby Anton Katilin » Wed Sep 09, 2020 3:18 pm

Update:

If you are interested in the rate, I think the best option is object counting


Perhaps even better mode for your purpose is the "Record thread and stack" mode with sampled stacks and very large size limit and record-each value e.g. 10000000 both. This should reduce object creation callback workload and hence the allocation recording overhead to minimum. Please note that the size limit and record-each parameters do not affect the object creation rate shown in the telemetry, it always accounts all created objects.

The suggestion to try "disable_heap_sampling" for Java 11+ is still relevant.
Anton Katilin
 
Posts: 6009
Joined: Wed Aug 11, 2004 8:37 am


Return to Java Profiler

Who is online

Users browsing this forum: No registered users and 1 guest

YourKit uses cookies and other tracking technologies to improve your browsing experience on our website, to show you personalized content and targeted ads, to analyze our website traffic, and to understand where our visitors are coming from.

By browsing our website, you consent to our use of cookies and other tracking technologies in accordance with the Privacy Policy.