Community
Participate
Working Groups
See the original issue I blogged about: http://www.jroller.com/andyl/entry/switching_jvm_options_at_runtime and the excellent article about the root cause: http://blogs.atlassian.com/2012/05/codecache-is-full-compiler-has-been-disabled/ The point is, that 1.7 Java (starting with Java 1.7.0_4) Oracle based JVM's set ReservedCodeCacheSize option to the default value of 48MB, which is critical for big Eclipse installations containing lot of code. The Java 6 had 1024 MB and Java 8 has 240 MB default setting, so they aren't affected by the "optimization" made in Java 7. The major issue is that once the CodeCacheSize hits the upper limit, JVM almost *silently* switches *forever* hotspot compiler off to the "interpreted" mode, resulting in the immediate performance decrease for all not yet "compiled" code and gradual "slow" performance decrease for already "compiled" code which was "too long" time in the cache and is removed from cache later. Unfortunately there is no way back - once the JVM decides to switch to the interpreted mode, it never switches back even if the CodeCache memory is freed again. Also unfortunately that users may not notice that JVM runs in interpreted mode and just will blame Eclipse being so slow - as I did. I observed this behavior on my workstation with jconsole and the problem was that even the already compiled code was removed from the code cache with the time, so that more and more code runs not optimized and performance degrades more and more. On Java 7 VM the "typical" code cache size (with increased max limit) for my Eclipse 3.8 installation was around 55 MB after some hours of work, means starting Eclipse at morning I almost always was reaching "dangerous" limit from 48 MB at the evening. On Java 8 and Eclipse 4.5 I see that the CodeCache is around 140 MB, which is at least smaller then 256 MB limit. One proposal is to check if the current JVM java.vendor is Oracle Corporation and the java.runtime.version is in [1.7.04, 1.8.0) than add the -XX:ReservedCodeCacheSize=256M to the eclipse startup arguments. Because this can be done only before the VM is started, the change must be done in the native launcher. Another option would be to set the argument in eclipse.ini but this would mean the limit should fit for all JVM's. 256M should be OK for Java 7 and 8, but could be critical for Java 6 where UseCodeCacheFlushing was not enabled by default (and so the memory was never freed).
Created attachment 250592 [details] Working day ends with "slow" Eclipse Just for fun tried to run jconsole over the day - and got the limit hit at 16:45. Until then the code cache size was always growing, because hotspot compiled the code and saved it to the cache. BTW I had lot of meetings, so actual *work* was may be 2-3 hours only. At 16:45 the limit was hit, the hotspot compiler was switched off and now one can see only a decline of the cache size: "old" compiled code is removed with the time but the new one never added because compilation is off. From 16:45 I'm entering the "slow motion" mode in Eclipse.
Mars supports only Java 7 and upwards so this change should be finde for Mars.
(In reply to Lars Vogel from comment #2) > Mars supports only Java 7 and upwards so this change should be finde for > Mars. This is true for all RCP scenarios? I recall it is true for the EPPs but that is not the only consumer of RCP and I also don't think RCP is the only consumer of the launcher.
FWIW: I hit this issue with Java 8 (1.8.0_31-b13) when I use Eclipse with a lot of add-in features such as the SDK Tests. Admittedly few would want to run with the SDK Tests, but it's a good stress test. Manually specifying -XX:ReservedCodeCacheSize=1024M makes Eclipse usable again.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
