GC Bomb - CMS GC starves high priority system threads

trembovetski · August 4, 2005, 9:17pm

[quote](Would appreciate if you could escalate this for me Trembo/Jeff)
[/quote]
Please file a bug and include all this information…
I’ve asked vm folks to look at the thread, but a bug is always better.

Dmitri

kbr · August 5, 2005, 2:19am

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 · August 5, 2005, 11:37am

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 · August 8, 2005, 7:23am

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.

princec · August 8, 2005, 9:28am

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 · September 26, 2005, 1:19pm

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 · September 26, 2005, 3:34pm

Hurrah! Fixed in Mustang. And, apparently, 1.5.0_06.

Cas

swpalmer · September 27, 2005, 2:41am

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 · September 27, 2005, 9:50am

Rumours on teh intarweb.

Cas

trembovetski · October 4, 2005, 4:49am

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 · October 4, 2005, 12:17pm

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

Cas

ajiva · October 4, 2005, 3:34pm

It is fixed in 1.5.0_06

princec · October 4, 2005, 11:13pm

I reckon that counts as a “reliable rumour”

Cas

princec · March 18, 2008, 11:23am

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 · March 18, 2008, 11:35am

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 · March 18, 2008, 1:42pm

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 · March 18, 2008, 3:36pm

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 · March 18, 2008, 4:39pm

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

verkel · March 26, 2008, 6:21am

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 · March 26, 2008, 10:36am

And what an excellent first post Most welcome.

Cas