J3D+JOGL make a Win64 app freeze for 1 minute

I maintain a huge Windows-only application that was written mostly by my predecessors using Java 6, ANT, NSIS and Eclipse 3.7 Indigo. A tested JRE is bundled with the product. It does not run in a web browser and does not communicate through the Internet.

The most recent major release of the app runs on Windows 7 and XP in 32-bit mode.

Using Eclipse 4.2.2 Juno, I added features and fixed bugs with the goal of shipping 32- and 64-bit Java 7 builds that run on Windows 7. A logical next step would be to upgrade to Java 8 and Windows 10.

The only 3D-based feature of the app used a version of Java3D that was at least 5 or 10 years old. Recently, that feature stopped working. After studying possible solutions and trying a few, I settled on J3D+JOGL, more precisely:

        J3D pre12 + JOGL 2.3.2 + Gluegen 2.3.2

For testing purposes, I created an Eclipse project to contain OpenGL's Pyramid example (built as an application) and a project to contain J3D+JOGL (to be shared between Pyramid and my app).  

Unfortunately, that attempt failed. The presence in the stack trace of names like TempFileCache suggested that a not-unexpected culprit was to blame: a corporate security policy that caused Automated Native Library Loading to freeze.

Goodbye to automation. I got the Pyramid example working perfectly in 64-bit mode by adding:

        -Djogamp.gluegen.UseTempJarCache=false

and

        -Djava.library.path=C:\Users\myname\workspace\JOGL\jogamp-all-platforms\lib\windows-amd64

to VM args and by setting the native library locations of gluegen-rt and jogl-all to

        JOGL/jogamp-all-platforms/jar/atomic.

The 3d-based feature and everything else in the application now works as it should, with one huge exception: Some thread (seemingly the interactive event loop) blocks for 60 seconds soon after launch, even when the 3D-based feature has not been invoked by the user. The app can often be shaken out of its stupor in less than a minute by using Eclipse debug mode to pause and resume the main thread.

A 60-second freeze is, well, not a feature that customers will appreciate. Because the only changes I made to my application before the freeze appeared were ones necessary to get it working with the excellent JOGAMP technologies, I would like to rule the latter out as a cause of the pause.

Is there any activity that Gluegen or some other technology performs as an application starts up (before any OpenGL method is called) that might cause a thread to wait for 60 seconds?

Does JOGL or Java3D do anything with Security Manager that might be a factor?

Is anything in my installation suspect?

I ran more tests. The long pauses only occur the first time that I do certain things. After that, I presume, the objects that the app needs in order to redo those things are generally in caches. But that has always been true, and the app has not been nearly as slow before the working set coalesces. I am still trying to find out why.

EDIT to original post: Pyramid is a Java3D example, not an OpenGL example.

Larry,
I only know about the JAva3D side of things properly, but generally Java3D works very hard to do all of it's work on it's own threads (the J3d-Renderer thread mainly).

In order to help you out I'll really need a minimal reproduction of the issue (and generally more information about when it pauses).

Some information which might help you close in on this issue:

VirtualUniverse has some static code that calls MasterControl.loadLibraries and other work that could conceivably access disk and generally have a slow down.
So any line you have that does a new of VirtualUniverse or it's subclasses should be checked for problems.

Canvas3d.addNotify hands it's work off to the Renderer thread generally, might is a good candidate for problems.
This is called on the event thread automatically when you add the Canvas3D to a visible parent container, so try testing the addition of Canvas3D to it's parent for performance issues.


Finally Canvas3D methods often interact with teh renderer thread so thread synchronization issue might cause pauses, try cutting out or timing calls to
paint(Graphics g)
getGraphicsContext3D()
getGraphics2D()
waitForOffScreenRendering()
doSwap()

If in your code you subclass any of these methods, ensure you are not synchronizing with any other threads
preRender()
postRender()
postSwap()
renderField(int fieldDesc)

These are just some ideas for trying to cut down the code and give a reproducible example, which is where people on this forum will be able to help.

Thanks,
Phil.

Hi

Do you reproduce this bug when using a recent build of OpenJDK 1.7 or 1.8 under Windows? Please provide a SSCCE.

I kicked the vending machine in the right place:

Eclipse > Exit
"Start" menu > Restart
Eclipse > Launch

Unasked, Eclipse rebuilt the workspace. As soon as I saw that happening, I felt my odds were good.

Yes, it tested perfectly. Performance is back to normal.

I have theories about why it happened. I won't bore you with them. But yes, I had religiously Refreshed. However, I had not ensured that automatically triggered rebuilds were comprehensive.

Meanwhile, I had begun to look into Phil's and Julien's suggestions, so I learned a few things that should be of value in the future. Thanks for your time.

Larry

Larry,
Excellent news, very please to hear it wasn't another bug.

You'd probably get the same behavior if you use Project->Clean->Clean all.

I find I have to do that from time to time to get everything squared up again, refresh often just ignores you.

Thansk,
Phil.