I'm chasing a weird JVM pause regarding the access of a fairly large (5000x5000) array. It certainly is not big in the scheme of things these days however. The contents are primitives (booleans), so it should be ~25MB or so.
It's not a thread lockout either, because if I remove any and all synchronization from the code, it still happens the same as before. All threads, stopped.
1. If I replace the array reads/writes with a burner loop (not a sleep (on purpose), but a simple loop + check for current time) for 5 seconds, the problem never occurs.
2. ^^^^So I'm assuming it's either a GC or a heap shuffling thing.
But before I go and torment anyone with a scaled down version of the offending code, I could use an answer first:
Do I have to run the JVM with the -verbosegc (or similar) argument in order for VisualVM to get GC and/or allocation events?
posted 1 year ago
Ok, it's almost a safepoint problem: The JVM is reporting a massive pause (4+ seconds), but with a blank vmop. Huh? Still chasing this down.
I think you'll have to write an example we can run for us to help you with this.
posted 1 year ago
Stephan van Hulst wrote:I think you'll have to write an example we can run for us to help you with this.
Yes: Planning on it. Have to get all my ducks in a row first.
The changes in jdk9 and 10 regarding how the safepoints work will be part of what I need to fault-isolate this thing, and that takes some time.
I'm really not alone in this either. There are a lot of folks wandering directly into a crazy non-GC safepoint pause. Looking to the Java bug database, I can see a few related and hard to trace down bug entries.
But I need to know if the issue is mine or not before further questioning the JVM.
I came across a tool named GCeasy, Universal GC Log analyser that has in-built intelligence to auto-detect problems in the JVM & Android GC logs and recommend solutions to it.You can quickly detect memory leaks, long GC pauses, premature object promotions plus many other performance impacting problems.
In this modern world, Garbage collection logs are still analyzed in a tedious & manual mode. i.e. you have to get hold of Operations engineer, then he will mail you the application's GC logs, then you will upload the logs to GC analysis tool, then you have to apply your intelligence to anlayze it. There is no programmatic way to analyze Garbage Collection logs in a proactive manner. Given this tediousness, it's impossible to analyze hundreds of JVM's GC logs in one stroke. Thus to eliminate this hassle, we have developed RESTful API to analyze garbage collection logs. With one line of code you can get your all your GC logs analyzed instantly. Learn how to use GCeasy REST API
Here are some sample reports generated by GCeasy:
1. G1 GC Report 2. Memory Leak Report
I have always wanted to have a neighbor just like you - Fred Rogers. Tiny ad: