GC Bomb - CMS GC starves high priority system threads

[Ken Russell]

HotSpot has a deliberate mapping of Java priorities to Windows thread priorities where Java's maximum priority maps to THREAD_PRIORITY_TIME_CRITICAL and its minimum priority maps to THREAD_PRIORITY_LOWEST. See src/os/win32/os_win32.cpp, java_to_os_priority, in the Mustang HotSpot sources if you're curious. It's a simple change to downgrade the maximum possible setting to THREAD_PRIORITY_HIGHEST, but is that the right thing to do for all applications? It seems to me that the application should simply not be using the maximum priority (or, in fact, adjusting thread priorities at all) unless it's absolutely necessary. -XX:-UseThreadPriorities is the "big hammer" switch added to HotSpot at one point because of problems like this.

Are most of the issues seen on this thread caused by exactly this problem (e.g., swpalmer)? As far as I understand it, this isn't the root cause behind the glitches in mouse pointer tracking that have been seen in other applications like Eclipse and NetBeans on some machines which I consider to be a more serious problem (i.e., possibly not an application-level problem).

[princec]

This is precisely the root cause of the problem. No Java threads should be able to run as a time-critical thread on Windows; it buggers the whole system up, and there's not even any security on it. It'll make a DoS attack trivial. So perhaps this issue should be escalated a bit

Cas

[abies]

No Java threads should be able to run as a time-critical thread on Windows; it buggers the whole system up, and there's not even any security on it. It'll make a DoS attack trivial.Cas

As far as I understand, you are not able to set priority higher on thread that it is on threadgroup and you cannot modify it at all without correct permissions - so it should be enough for avoiding DoS in applets.

Games published by our own members! Check 'em out!

[princec]

I dunno about anyone else but I've always wanted to attach some actual security to "trusted" code as well to prevent it monkeying around with my system and rendering it unusable by accident... there's already two great limiters in the JVM right now which limit its Java heap space and also C heap space, but there's no limits on creating any other OS resources. It seems a little disjointed.

Cas

[jouni]

This is the bug 5101898 in Sun's bug database. See:

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5101898

See also discussion in

http://forum.java.sun.com/thread.jspa?threadID=666691&tstart=0

[princec]

Hurrah! Fixed in Mustang. <edit>And, apparently, 1.5.0_06.

Cas

[swpalmer]

I saw that this was fixed in Mustang... but where did you get the info that an _06 build was coming with the fix for Java 5?  Heck, I just got 1.5.0_05!

[princec]

Rumours on teh intarweb.

Cas

[trembovetski]

Well, doesn't Alan Bateman mention that it's been fixed in _06 in the second posted thread?

http://forum.java.sun.com/thread.jspa?threadID=666691&tstart=0

see the last post.

Dmitri

[princec]

Until it's officially closed in Bug Parade, it's a rumour on teh intarweb

Cas

Games published by our own members! Check 'em out!

[Azeem Jiva]

It is fixed in 1.5.0_06

[princec]

I reckon that counts as a "reliable rumour"

Cas

[princec]

Necro!

This bug has returned with a vengeance in JRE6... and needs to be un-regressed! There are TIME_CRITICAL threads all over the place once more.

Cas

[princec]

No wait! I tell a lie. It's different this time.. here's the symptoms:

Run Ultratron in Eclipse (java6ea) - game runs smoothly.
Run Ultratron as standalone executable, no Eclipse running in background - game runs smoothly.
Run Ultratron as standalone executable, Eclipse minimised in background - occasional, regular, 1 second pauses. Grr.

Any ideas on this particularly odd interaction? I feel that it's something similar to what it was before.

Cas

[erikd]

I'm not sure if it's related, but I'm noticing some strange behaviour of java6 at work:
Sometimes the whole OS (still running Win2000 here) almost freezes completely! When that happens (sometimes 5 times a day, sometimes 2 times a week), trying to kill all java processes solves the problem (that is, if the OS isn't frozen too much).
The problem seems to be triggered by running java6 and a java 1.4.2 version at the same time, as axing Lotus Notes' JRE (1.4.2) and replacing it with a java6 JRE seems to make the problem almost go away (making all applications use the same java6). Weird but true  . There's still the occasional short, system-wide pauses though...

Cas, does Ultratron still have the same problem if you run Eclipse with the same JRE version as Ultratron?

[princec]

Yes.

The plot thickens... turns out all games are afflicted with 1-second pauses when Eclipse is running. It might just be a daft Eclipse thread doing it.

Cas

[erikd]

But then, are things any different between 1.4 and 1.6?

[verkel]

The plot thickens... turns out all games are afflicted with 1-second pauses when Eclipse is running. It might just be a daft Eclipse thread doing it.

Cas

This is probably due to the idle GC feature in Eclipse. When the IDE detects itself as "idle", it periodically runs System.GC() to reduce perceived memory footprint. This however causes its CPU usage to spike and pauses games and other CPU intensive apps.

It's discussed in this bug: https://bugs.eclipse.org/bugs/show_bug.cgi?id=118335

You can run eclipse with: eclipse -vmargs -Dide.gc=false, as described in the post #8. This disables the idle GC and fixes the pauses, at least for me.

And oh, hi. First post, long time lurker.

[princec]

And what an excellent first post Most welcome.

Cas