Java heap conflict forces Intel drivers to fail

OpenGL Development JOGL Development
#1

Let others be forewarned:

My customer was complaining that they always got the Microsoft GDI (software-only) OpenGL driver when running my Jogl application.

After much investigation, I’ve found that in some circumstances, the Java heap conflicts with where the Intel OpenGL Device Driver for the various Intel chipsets (eg 82865G) wants to load (either to put itself, or to store its internal stuff).

By removing the -Xmx argument (or lowering the specified max heap size) they get the Intel driver to load and run.

My application is a stand-alone application (neither an applet nor a WebStart app), using Jogl 1.1.0-rc3, jdk1.4.2 or 1.5.0.

I believe this is related to the issue previously mentioned as only an applet/IE issue:
http://www.java-gaming.org/forums/index.php?topic=16324

My theory is that since the Intel chips store all their info in memory, they may have particular address spaces they want to use (or some particular alignment), and just bail out if they cant get it.

Has anyone else run into this issue?

Is this something that Java could avoid some day?

Attached find the trivial Jogl app I used to test this. Note that this app is also a generic “print out basic system info
and Jogl / OpenGL capabilities” application, useful for debugging client installs.

#2

Sorry for the trouble.

You should complain to Intel about this. I have never heard of another graphics vendor’s drivers failing to enable hardware acceleration due to an address space conflict. The JVM lets the base OS decide where to put the Java heap. Even if we had chunked (non-contiguous) Java heaps in the JVM there wouldn’t be a guarantee that one of those chunks wouldn’t be poorly placed so as to conflict with the address space region the Intel graphics drivers want.

This is an especially serious problem if this is happening with standalone Java processes. This issue has been recently raised in the context of running Java and JOGL applets in Internet Explorer, which is something of a special case which we can work around, but if it’s happening with normal Java applications then Intel needs to fix their broken drivers.

#3

I have submitted a query to Intel, though I’m not holding my breath.

I suspected it was a driver problem – one of many that these drivers seem to have.

Does anyone know of tools to let me see what address space the driver wants? And what space the JVM is using? Maybe a tool to force Java to load into spaces outside of the area that the driver wants?

I doubt I’ll go down that path though (what a pain), since for most purposes I can just restrict my heap size to something much smaller, and less likely to conflict.

#4

The jmap tool that comes with the JDK is capable of showing you this information, but it looks like the version that ships on Windows is unnecessarily restricted and doesn’t print it. There are tools for example from SysInternals like ProcessExplorer that will show you low-level information about address space mappings, but there’s no easy correlation to show you for example what portion is the Java heap.

I think this is unlikely.

The only way I can potentially think of to work around this issue would be to write your own Java launcher, manually reserve exactly the address space region the driver wants, start the JVM and let it allocate its heap elsewhere in the address space, and then unreserve the region and start the JOGL portion of the app which will hopefully cause the driver to load into the right place. This is highly unlikely to work.

If Intel isn’t responsive then if I were you I’d vote with my dollars the next time and get a machine with NVidia graphics, since their OpenGL driver support is generally the best, and encourage people via word-of-mouth to do the same.