JRockit 6 bug

Question

I have found a bug in the JRockit 5 and 6 #27 JVM's (Windows, 32 bit). It comes up as a nullpointerexception when I run my application; under Sun's Java 5 or 6 JVM there is no problem.
Unfortunately I cannot provide steps to reproduce the problem without running my entire application, but I will try to describe the problem as good as I can.
The module where the problem comes up configures itself at startup. During this configuration it replaces System.out with its own PrintStream, called 'InterceptingPrintStream'. This class contains a member object called 'handler' to which all of the print methods delegate. This 'handler' object cannot be null: It is set in the (only) constructor, which contains also an assert to make sure that the object is not null.
When my module terminates it sets the old Printstream back again.
Now to the nullpointerexception: After my module has terminated, I write something to System.out. This gives a nullpointerexception in the InterceptingPrintStream: Its 'handler' object is null. As I mentioned above this is impossible by contract for the handler object to be null. It cannot be caused by some kind of racing condition either, because my application is single threaded.
What's more, since my module has terminated, there should be no InterceptingPrintStream in System.out at all anymore; it should have been replaced by the original PrintStream.
I tried to debug, but then found out that when I run my app in the debugger, the problem does not occur, regardless if I set any breakpoints or not.
So then I just added many checks in my code to check the type of System.out.
It turns out that after my module finishes, System.out is properly set back to a PrintStream. However, a couple of method calls later, System.out is replaced with the InterceptingPrintStream which seems to be partially garbage collected already.
I hope this description is of any use for you. If there are any steps which I can take to clarify the problem for you, please let me know.

Answer 1

I have identified a two methods for which optimization goes wrong. Let's call them method A and B; method B is actually called from method A.
But optimization goes wrong for both of them independently; If I switch off optimization for method A and not for B, method A gives no problems but B does, and vice versa.
This is imo what happens:
I see from the optimization output, that early on during the running of my app, methods A and B become optimized. Both method A and B contain a call to System.out.println. At this moment, System.out is still redirected to another stream called 'InterceptingPrintStream'. All calls to System.out go ok, even when method A and B are called a couple of more times.
Then System.out becomes redirected to its original console printstream again.
It seems that the optimized methods A and B do not pick up this change: They still try to call the InterceptingPrintStream, which is then already halfway garbage collected, which results in a NPE.
Other methods higher up in the call-chain which also refer to System.out do not have this problem.
Also, when I comment out the System.out calls in methods A and B, no other problem seems to come up.
Please tell me if there are any further steps I could take to help you out.