Community
Participate
Working Groups
After about a half an hour, the Eclipse shows a dialog box with message "Save could not be completed". (Half an hour of using the Eclipse, that is...) I'm using same machine and same JVM I have been using with previous builds and I didn't have these problems. On my other machine, which is a SuSE Linux 8.2, I'm getting OutOfMemoryExceptions as well as "Save could not be completed".
Created attachment 5991 [details] This is an export of error log
This is a JIT bug. Please change your VM. If you disable the JIT, you won't have it again.
A few question more questions: 1. How to disable JIT ? (For IBM JRE 141 on Windows and Linux) 2. What is the impact of disabled JIT on Eclipse ? 3. If the same JVM was used with older builds of Eclipse 3, why didn't this probelm show up earlier ? 4. If this is a JIT bug, has anyone informed the Sun/IBM (Hursley) about this ?
IBM VM JIT has been well-known for randoms NPE. We got the exact same issue with a IBM JDK1.3.1 VM. To disable the JIT, use this VM arg -Djava.compiler=NONE. The consequence is that Eclipse will run more slowly. I would highly suggest to move to another 1.4 VM.
Reduce severity since this looks like a JIT bug. Please let us know if disabling the JIT fixed it.
Disabling the JIT seems to have fixed the problem, the Eclipse has been in use for over two hours now. I have been using the Eclipse 3 M3 on my SuSE 8.2 Linux machine with latest JVM from Sun as well as with IBM 141 JVM, and the Eclipse was still getting OutOfMemoryExceptions and NullPointerExceptions. I'm not sure what other JVM should I move to... The severity of this problem has to be at least "major", because having no information about this issue in the readme, and having Eclipse unable to save file or do a build after a while, would be a major problem for anyone... (its a development tool... )
VM bugs are always frustrating indeed, but Eclipse cannot be blamed for these. Please report directly to the IBM vendor. Closing this defect as a VM bug.
I don't agree with closing the bug, and here is why: 1. No explaination has been provided as to why the problem didn't manifest itself in earlier builds of Eclipse running with same JVM. 2. No eplaination has been provided as to how does Eclipse make use of the JIT and why the root cause is in JIT not in Eclipse's usage of JIT 3. No indication of how this issue will be communicated to the users, I don't think letting every one run into this issue is acceptable. IMO, this needs to be addressed in the readme. 4. From the comments in this defect it is clear that the Eclipse developers know about this issue, yet I have been asked to report the problem to JVM vendor. Because I can not provide good enough test scenario to the JVM vendor, I was expecting that Eclipse team would to contact the JVM vendor... 5. From my perspective, disabling JIT is a workaround not a resolution. If disabling the JIT is the only way to get pass this, then this bug should be closed in way indicating that it will be dealt with later.
The solution is to fix the JIT. This is clearly a VM issue. I don't see what we can do to fix the JIT. A JIT is not supposed to cause NPE.
Eclipse is just a Java application running on a Java VM. The JIT is the optimizer part of the VM. The VM you are using is known to have severe defficiencies in this area. We cannot workaround these in application code. Any code change is inducing different bytecodes, and some are breaking the VM. Does this mean we shouldn't change any code because some VM has some bug ? No, you simply need to contact the VM vendor and report this problem to them since the bug is in their land not in ours. Relying on us to track these down is just not an option, we don't have the resource to track VM defects. Remember that the runtime you are using is still in beta mode (I think). Disabling the JIT is indeed a workaround, the real solution is to upgrade/change the VM. The fact it worked fine with a previous Eclipse drop means you were lucky. Closing
Reopening the bug in order to get the Eclipse team to put the workaround into the readme(or somewhere, so that the users/testers would be informed about it). As to the reporting the issue to the vendor, it requires a test case, as simple as possible, demostrating the problem. If the Eclipse team is unable to come up with one, then no one probaby can.
Please report to VM vendor. This bug database is reserved to Eclipse bugs. If a testcase is needed, then you seem to have one reproducing it. Closing.
The reason for reopening was that the information about the workaround has to be communicated to the users/testers. Please indicate how this will be handled. As to the reporting the VM vendors, running Eclipse for an hour is not considered a test case and therefore I can not report this the VM vendors.
By the time we ship, better JREs will be available. We will conduct a full testpass, and provide documentation for known issues. If this one is still an issue, then it will be documented for sure.
