For those of you that continue to experience hangs and massive slowdowns running CFB on Windows 7 64bit, the one thing I found that made all the difference in the world is to have Eclipse use the jvm.dll rather than javaw.exe (the default). I’m using the CFB plugin into Eclipse, but I suspect this may also apply to CFB standalone on Win7 64bit as well.
No amount of configuration changes, switching between 32 and 64bit JVM/Eclipse or disabling of features made any difference to the significant performance problems I was continuing to experience UNTIL I explicitly had Eclipse start up using the dll (forcing the JVM to load within the Eclipse process).
I also found that simply adding the –vm argument to the eclipse.ini apparently doesn’t work when trying to specify a specific JRE to use (at least on my machine); regardless of the existence of this argument in the ini file, it will still always fire up C:\Windows\System32\javaw.exe, which is where the problems I was seeing are (high CPU utilization, memory consumption). Not sure why that argument is ignored, perhaps a path issue, but I found that the only way I could be certain that I could run Eclipse with a specific JRE was to invoke Eclipse with the –vm command line argument.
I removed all my old JRE installs and installed the most recent 64bit JRE to C:\Java\64bit\.
What didn’t work:
I first tried updating eclipse.ini with:
|
1 |
-vm C:\Java\64bit\jre6\bin\javaw.exe |
but found that Eclipse was still invoking the C:\Windows\System32\javaw.exe for some reason. Eclipse started of course, and the javaw.exe process started going bananas again every time I would try to edit a file and *change the value of an html input tag* of all things – as soon as I changed the input value by adding one letter (even before saving) the javaw.exe process would immediately start eating cpu and memory, and I could repeat this problem consistently across multiple files. Eclipse would hang, and I’d have to forcibly kill it as it would never recover.
I then tried invoking Eclipse with the command line –vm argument, like so:
|
1 |
D:\eclipse\eclipse.exe -vm C:\Java\64bit\jre6\bin\javaw.exe |
leaving all the other arguments alone in the ini file; now, I could see that it was definitely using this particular javaw.exe but had exactly the same behavior I described above, edit a file (local filesystem, not network just to clear that it isn’t network related) and javaw.exe freaked out and Eclipse hung until forcibly killed.
I then tried changing the –vm argument in the eclipse.ini file to:
|
1 |
-vm C:\Java\64bit\jre6\bin\server\jvm.dll |
When Eclipse started it still had fired up javaw.exe in the Windows system32 directory as above. Whatever.
What worked:
Finally, I invoked Eclipse using the command line –vm argument pointing to the JRE’s jvm.dll, like so:
|
1 |
D:\eclipse\eclipse.exe -vm C:\Java\64bit\jre6\bin\server\jvm.dll |
and holy crap, it runs great. Responsive, no appreciable sluggishness, I even turned a bunch of the code assist and insight features back on in light of how great it works now. Because javaw.exe isn’t running I have seen none of the problems I had when using the default invocation. I don’t understand why this option isn’t talked about more (I recall seeing only one reference to it in all the stuff I read), nor why it works better for me than the default javaw.exe but I’ve been running it all day now and it has been working terrific so far.
So, if you’re on Win7 (or maybe even Vista) 64bit, have a 64bit JVM and 64Bit Eclipse and are seeing crappy performance or stability, try this method and see if it doesn’t solve your problems. Off now to uninstall IntelliJ and Komodo trials ….