2

I have a question about ClassUnloadingWithConcurrentMark flag since I didn't find any useful help anywhere. If we use G1GC is set to true by default (-XX:+ClassUnloadingWithConcurrentMark). If I use -XX:-ClassUnloadingWithConcurrentMark flag to turn off class unloading after G1 concurrent mark where is class unloading executed then (which phase)? I read somewhere that it happens when full GC is activated by what if full GC is never triggered? I have problems with long remark phases - unloading in below example took more than 3 seconds:

2015-06-08T08:09:16.318+0200: 572818.729: [GC remark 572818.729: [Finalize Marking, 0.0002590 secs] 572818.729: [GC ref-proc, 0.4479462 secs] 572819.177: [Unloading, 3.2004912 secs], 3.6499382 secs]
 [Times: user=0.20 sys=0.08, real=3.64 secs] 

Would using -XX:-ClassUnloadingWithConcurrentMark be useful to me to reduce class unloading times? I'm afraid that If I'll use this option I'll have even more problems (for example outofmemory exceptions,...) if class unloading will never happen.

EDIT: if we are using -XX:+ClassUnloadingWithConcurrentMark (default option) is class unloading triggered every time GC remark phase occurs? In logs I have some GC with GC cause: Metadata GC Threshold, but others don't have this cause but Unloading still happens in remark phase. Why is that so?

user4341206
  • 647
  • 1
  • 7
  • 26
  • please do not make duplicate questions, you already asked the very same thing [here](http://stackoverflow.com/questions/30566779/jvm-gc-problems/30570649?noredirect=1#comment49471335_30570649), that just duplicates people's efforts. – the8472 Jun 08 '15 at 15:48
  • I've asked a new question because there is no question about ClassUnloadingWithConcurrentMark yet and I think almost nobody would notice that comment in question I asked before. – user4341206 Jun 08 '15 at 16:02
  • you could have deleted the comment then to avoid duplication – the8472 Jun 08 '15 at 16:12

2 Answers2

2

I'm afraid that If I'll use this option I'll have even more problems

Why don't you just setup a test environment for these kinds of things and test it yourself?

Anyway, as already answered over here, the VM will perform some last-ditch heroics (1-2 full GCs, complete soft reference clearing) to ensure that the situation is not recoverable before throwing an OOM.

Would using -XX:-ClassUnloadingWithConcurrentMark be useful to me to reduce class unloading times?

Whether it will reduce them, I don't know, probably not. That's what you will have to try yourself. But it may delay the inevitable for a long time.

if we are using -XX:+ClassUnloadingWithConcurrentMark (default option) is class unloading triggered every time GC remark phase occurs?

yes, this was added with JDK-8049421 and the flag to turn it off again with JDK-8051607.

All you have to do is to search for "class unloading" on the openjdk bugtracker and/or the hotspot-gc-dev mailing lists. This is all public information.


Another thing you could try instead is setting -XX:MinMetaspaceFreeRatio=20 -XX:MaxMetaspaceFreeRatio=30. This would trigger class unloading sooner and hopefully cause a shorter cycle.

Community
  • 1
  • 1
the8472
  • 40,999
  • 5
  • 70
  • 122
  • I have used -XX:-ClassUnloadingWithConcurrentMark but I'm stiil getting Unloading at GC remark phase: [GC remark 58.309: [Finalize Marking, 0.0004742 secs] 58.310: [GC ref-proc, 0.0007091 secs] 58.310: [Unloading, 0.0000030 secs], 0.0016268 secs]. I am wondering if this Unloading is meant for class unloading or this is something else (I checked metaspace size when this happened and it didn't change at all!)? I had problems with this Unloading (long pause times), I thought that flag -XX:-ClassUnloadingWithConcurrentMark won't trigger Unloading anymore but it still does. – user4341206 Jun 09 '15 at 11:30
  • *"0.0000030 secs"* where's the problem? – the8472 Jun 09 '15 at 19:06
  • Yes it was "0.0000030 secs" here but this is not important here (low unloading pauses were already before at first major GC but then unloading time was much higher in next major GC) - the question is why is still Unloading going on on remark phase if I used -XX:-ClassUnloadingWithConcurrentMark flag? If I understood you correctly Unloading was not supposed to trigger here but only when full gc in triggered? – user4341206 Jun 10 '15 at 04:32
  • *"but this is not important here"*, yes it is. your *original* problem were the high pause times. I gave you some things to experiment with. So just run your experiments. If you don't experience high pause times it's a success. – the8472 Jun 10 '15 at 05:39
  • Like I said: Unloading was fast in the original problems in first few Unloadings: [Unloading, 0.0055955 secs], [Unloading, 0.0074093 secs], [Unloading, 0.0133418 secs], [Unloading, 0.0150455 secs], [Unloading, 0.0290516 secs], [Unloading, 0.9739555 secs], [Unloading, 3.2004912 secs] - as you can see Unloading was getting slower and slower. So I want to have Unloading classes when full gc is triggered, but I still have it at remark phase (if this Unloading is same as class unloading at all). Can you please answer the edited part of question if you maybe know the answer. Thanks. – user4341206 Jun 10 '15 at 06:18
  • Thank you for your edited answer, so this option is not working yet, it will be available in JDK9. So -XX:-ClassUnloadingWithConcurrentMark is useless. – user4341206 Jun 10 '15 at 07:21
  • I'm confused now. In JDK-8051607 (Add flag to turn off class unloading after G1 concurrent mark) is said that this is pushed to JDK 9, so I'm assuming that this flag is not available yet. If I use o -XX:-ClassUnloadingWithConcurrentMark flag it doesn't work either (Unloading is still in remark phase). – user4341206 Jun 10 '15 at 07:42
  • You didn't look at the related bug. – the8472 Jun 10 '15 at 07:49
0

G1 does class unloading during the STW Remark phase, this is the default behavior. You cannot prevent class unloading, because doing so would eventually cause "Out of Memory" errors.

The only way to mitigate this issue is to modify your code to stop using dynamic classes generation.

Ayoross
  • 11
  • 1