Community
Participate
Working Groups
Build Identifier: I20100608-0911 There are OOM (PermGen space) when launching Eclipse with the new JVM 1.6 u21 d'Oracle. This is discussed here: http://www.eclipse.org/forums/index.php?t=msg&th=171585&start=0& In the log we can see that the VM arguments are not taken in account: !SESSION 2010-07-12 09:58:41.307 ----------------------------------------------- eclipse.buildId=I20100608-0911 java.version=1.6.0_21 java.vendor=Sun Microsystems Inc. BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=en Framework arguments: -product org.eclipse.epp.package.modeling.product Command-line arguments: -os win32 -ws win32 -arch x86 -product org.eclipse.epp.package.modeling.product Reproducible: Always
Please copy in your eclipse.ini file. PW
Created attachment 174008 [details] patch Please find attached a quick patch. I simply added a test in "isSunVm" method to check if company name matches "Oracle". This is probably not the only check to do, as Oracle may have released other wm (JRockit JVM for instance) with the same info. For Mac and *nix, the isSunVm method implementation seems to not rely on "Sun Microsystems" name. I did not test the patch.
(In reply to comment #1) > Please copy in your eclipse.ini file. > > PW Paul, I can't get to my eclipse.ini file at the moment, but the problem surfaces when using the stock eclipse.ini that comes with the helios JEE distribution for Win32. Regards, Nathan
Seems like we should not wait until September to fix the fact that the current version of Eclipse does not work with the current version of Java on the most popular platform.
(In reply to comment #4) > Seems like we should not wait until September to fix the fact that the current > version of Eclipse does not work with the current version of Java on the most > popular platform. There is a workaround for those stuck right now: pass the -vmargs <arguments> in on the command line (for windows users, a shortcut can have the arguments added). PW
(In reply to comment #5) > (In reply to comment #4) > > Seems like we should not wait until September to fix the fact that the current > > version of Eclipse does not work with the current version of Java on the most > > popular platform. > > There is a workaround for those stuck right now: pass the -vmargs <arguments> > in on the command line (for windows users, a shortcut can have the arguments > added). I'm just really concerned about the user experience here. This is the worst possible problem to hit, basically a hang, and then people are going to have to look around for the workaround. At the very least we should put a very prominent warning in that spot before the download (like where we warn about the 64-bit VM versions) that if they are using Java u21 with Eclipse that they have to do the workaround. But I still thing we should consider a respin so that it just works. This sort of thing can drive people from Eclipse.
On *nix, the isSunVM is checking for the strings "Java HotSpot(TM)" or "OpenJDK" when running "java -version"
This also brings up a larger issue of the versions to certify against. I know we are very clear about which versions we certify against, but we should take pains to make sure this is the current version of Java (as well as popular OS platforms). Another alternative is to defer the distribution of Eclipse to another distributor (like Yoxos or someone) that does have something out of the box that works on the current version of everything (assuming they will actually make this work being unencumbered by the Eclipse release schedule). We could say that our stuff works on reference platforms, but for the *current* platforms go to (and give some list of links like we do now).
I've added details of this issue in the wiki, because more and more users are going to have PermGem problem with this new JDK release. http://wiki.eclipse.org/FAQ_How_do_I_increase_the_permgen_size_available_to_Eclipse%3F
(In reply to comment #2) > Oracle may have released other wm (JRockit JVM for instance) with the same > info. We need to check this, does anyone have access to the JRockit vm? Does it support the -XX:MaxPermSize vm arg?
Is this really a breakage since u21 or does it surface just now i.e. the ini was never read correctly? It sounds strange that such a fundamental thing like reading the ini gets broken from u20 to u21.
>It sounds strange that such a fundamental thing like >reading the ini gets broken from u20 to u21. Ah, I see it looks like the launcher code internally uses the vendor flag, which changed in u21.
(In reply to comment #10) > (In reply to comment #2) > > Oracle may have released other wm (JRockit JVM for instance) with the same > > info. > > We need to check this, does anyone have access to the JRockit vm? Does it > support the -XX:MaxPermSize vm arg? It seems not: http://download.oracle.com/docs/cd/E15289_01/doc.40/e15062/toc.htm
(In reply to comment #6) > (In reply to comment #5) > > (In reply to comment #4) > > > Seems like we should not wait until September to fix the fact that the current > > > version of Eclipse does not work with the current version of Java on the most > > > popular platform. > > > > There is a workaround for those stuck right now: pass the -vmargs <arguments> > > in on the command line (for windows users, a shortcut can have the arguments > > added). > I'm just really concerned about the user experience here. This is the worst > possible problem to hit, basically a hang, and then people are going to have to > look around for the workaround. At the very least we should put a very > prominent warning in that spot before the download (like where we warn about > the 64-bit VM versions) that if they are using Java u21 with Eclipse that they > have to do the workaround. But I still thing we should consider a respin so > that it just works. This sort of thing can drive people from Eclipse. I could not agree more; to assume that a majority of users will know how to find the workaround and apply it without problems is foolish, in my opinion. To say that Eclipse just doesn't work with the latest version of the JVM is a PR nightmare. To make this worse, a standard installation of Java on Windows will automatically update to the latest, so many users will encounter this problem "out of the blue." I'm pretty sure that there is precedence for doing an "a" release (as in 3.6a) and I think the option should be seriously considered by the PMC in this case.
> I'm pretty sure that there is precedence for doing an "a" release (as in 3.6a) > and I think the option should be seriously considered by the PMC in this case. I agree. All the more that, on a famous French forum, there is already such a question asked.(http://www.developpez.net/forums/d951167/environnements-developpement/eclipse/eclipse-java/pb-lors-lutilisation-declipse/) I also suggest,as Francis Upton did, to spot before the download to warn the user (Until the 3.6a release or the 3.6.1)
Tom, do you have access to the JRockit VM? If so, could you try the following (or substitute a different version of the launcher JAR if you have one) so we can see how the JRockit VM handles the MaxPermSize arg? Thanks. java -XX:MaxPermSize=256m -jar eclipse/plugins/org.eclipse.equinox.launcher_1.1.00.v20100507.jar
I can also reproduce the issue on Galileo, using jdk 1.6.0_21 on a Windows XP 32-bit PC. I suspect it will happen on previous releases as well. I suggest backporting the fix for at least Galileo, since it's likely many users will not adopt Helios right away.
*** Bug 319752 has been marked as a duplicate of this bug. ***
Tried what DJ Houghton had requested on Oracle JRockit Real Time 4.0.1 C:\Program Files\JRockit Real Time\jrrt-4.0.1-1.6.0\bin>java -fullversion java full version "1.6.0_20-b02" C:\Program Files\JRockit Real Time\jrrt-4.0.1-1.6.0\bin>java.exe -XX:MaxPermSize=256m -jar C:\OEPE\Mission\Galileo\all\R C2\eclipse\plugins\org.eclipse.equinox.launcher_1.0.201.R35x_v20090715.jar [WARN ][jrockit] MaxPermSize=256m ignored: Not a valid option for JRockit
*** Bug 319515 has been marked as a duplicate of this bug. ***
*** Bug 318297 has been marked as a duplicate of this bug. ***
Has anybody filed a bug against Oracle yet? If yes, could you paste the bug number here? Making such a change in a Service Release, that breaks clients like Eclipse (and probably others) seems like a no-no. Perhaps THEY could take it back and release a jre 6u21a with the original vendor string. I claim that this can be filed as a "critical" issue. For now, we have discussed on the Eclipse PMC that we'd change the README and put information into prominent places. It's unfortunate that this happens on the most popular Platform - but then it's not entirely unexpected given that we cannot control the JVM we are running on. For most products on top of Eclipse, this should be a non-issue since they ship their own JVM. From my point of view, the information in README / download clickthrough should (a) recommend not using 6u21, and (b) point people to the workaround adding -vmargs -XX:MaxPermSize=256m onto their commandline or eclipse.ini file (probably via the Wiki FAQ) (c) reference the related Sun bug number once we have it. BTW, there are other (less known) workarounds possible: - setenv _JAVA_OPTIONS -XX:MaxPermSize=256m - setenv JAVA_TOOL_OPTIONS -XX:MaxPermSize=256m - put a ".hotspotrc" file into the current directory, which contains the -XX:MaxPermSize=256m flag
The two most important workarounds have been added to: http://wiki.eclipse.org/FAQ_How_do_I_run_Eclipse%3F
Added the same entry to the 3.6 release notes.
I raised bug 319868 and bug 319871 about displaying a warning message for windows downloads.
(In reply to comment #19) > Tried what DJ Houghton had requested on Oracle JRockit Real Time 4.0.1 > > C:\Program Files\JRockit Real Time\jrrt-4.0.1-1.6.0\bin>java -fullversion > java full version "1.6.0_20-b02" > > C:\Program Files\JRockit Real Time\jrrt-4.0.1-1.6.0\bin>java.exe > -XX:MaxPermSize=256m -jar C:\OEPE\Mission\Galileo\all\R > C2\eclipse\plugins\org.eclipse.equinox.launcher_1.0.201.R35x_v20090715.jar > [WARN ][jrockit] MaxPermSize=256m ignored: Not a valid option for JRockit So is that just a warning that would get printed to the console and the VM still launches eclipse successfully? What happens if you use jrocket to to launch eclipse with the exe AND you add the following line to the eclipse.ini after the -vmargs line: -XX:MaxPermSize=256m Does eclipse launch successfully?
When I add -vm parameter to eclipse.ini and point to java.exe under Jrockit and add -XX:MaxPermSize=256m after the -vmargs line, I notice that the following warning displayed in the eclipse console. But eclipse launches successfully. Eclipse installation details from About Eclipse - Configuration screen java.home=C:\Program Files\JRockit Real Time\jrrt-4.0.1-1.6.0\jre java.io.tmpdir=C:\DOCUME~1\RALAGU~1.ST-\LOCALS~1\Temp\ java.library.path=C:\Program Files\JRockit Real Time\jrrt-4.0.1-1.6.0\bin;.;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\WINDOWS\system32\WindowsPowerShell\v1.0;C:\apps\db\oracle102\bin;C:\Program Files\Perforce;D:\MyData\Misc\shortcut;C:\cygwin\bin java.runtime.name=Java(TM) SE Runtime Environment java.runtime.version=1.6.0_20-b02 java.specification.name=Java Platform API Specification java.specification.vendor=Sun Microsystems Inc. java.specification.version=1.6 java.vendor=Oracle Corporation java.vendor.url=http://www.oracle.com/ java.vendor.url.bug=http://download.oracle.com/docs/cd/E15289_01/go2troubleshooting.html java.version=1.6.0_20 java.vm.info=compiled mode java.vm.name=Oracle JRockit(R) java.vm.specification.name=Java Virtual Machine Specification java.vm.specification.vendor=Sun Microsystems Inc. java.vm.specification.version=1.0 java.vm.vendor=Oracle Corporation java.vm.vendor.url=http://www.oracle.com/ java.vm.vendor.url.bug=http://download.oracle.com/docs/cd/E15289_01/go2troubleshooting.html java.vm.version=R28.0.1-21-133393-1.6.0_20-20100512-2132-windows-ia32
*** Bug 319895 has been marked as a duplicate of this bug. ***
Created attachment 174342 [details] version changes Patch to increment versions as this will be the first change in the 36x branch.
The patch attached by Mariot is good, and I suggest we use it given that the jrockit vm accepts the XX:MaxPermSize with a warning. Attempting to distinguish between the hotspot and jrockit vms here would require more code and testing would be difficult since I do not have access to the jrockit vm.
Created attachment 174343 [details] win32.x86 eclipse_1308.dll containing patch binary eclipse_1308.dll containing the changes for testing. It goes in the plugins/org.eclipse.equinox.launcher_win32.win32.x86 folder, replacing the 1307 from helios.
Does anyone know how update 21 will get distributed? Do users have to go download it or does it get pushed out automatically? I tend to agree with others here that this seems like a pretty serious issue. We can add a message to the download page but if the bulk of the users are going to hit this problem it sounds like a support nightmare?
(In reply to comment #32) > Does anyone know how update 21 will get distributed? Do users have to go > download it or does it get pushed out automatically? > > I tend to agree with others here that this seems like a pretty serious issue. > We can add a message to the download page but if the bulk of the users are > going to hit this problem it sounds like a support nightmare? (In reply to comment #32) > Does anyone know how update 21 will get distributed? Do users have to go > download it or does it get pushed out automatically? > > I tend to agree with others here that this seems like a pretty serious issue. > We can add a message to the download page but if the bulk of the users are > going to hit this problem it sounds like a support nightmare? On Windows, a stock "out of the box" JRE/JDK install will automatically check for updates and prompt the user to install them. Users can "click to update" or ignore the notification bubble whenever it comes up. Users can go into the control panel applet and disable update checking altogether, but they have to know to look for that option.
Patch looks good to me. (In reply to comment #32) > Does anyone know how update 21 will get distributed? Do users have to go > download it or does it get pushed out automatically? > > I tend to agree with others here that this seems like a pretty serious issue. > We can add a message to the download page but if the bulk of the users are > going to hit this problem it sounds like a support nightmare? Adding David to the CC list for this discussion. I understand the concern, but there is a work around. A respin of Helios is quite disruptive in its own right. removing security flag.
Assigning back to Andrew, sorry for the spam.
FYI, I have reported the issue to Sun / Oracle. Their Bug tracker does not give a bug ID right away, but I will notify this spot once I have it. I did some experiments with Java 1.6.0_21 and noticed that in the System Properties, the JVM still identifies itself as java.vendor=Sun Microsystems Inc. java.vendor.url=http://java.sun.com/ java.vendor.url.bug=http://java.sun.com/cgi-bin/bugreport.cgi java.version=1.6.0_21 whereas the "Company" name in the java.exe / javaw.exe Version Properties has been changed to "Oracle". Given that this is not consistent, the change has been made without upfront warning, and its impact is severe, I have reported this as a severe regression to Oracle.
With Oracle/Sun, the issue will be tracked as Bug Id: 6969236. The bug is not yet externally visible (may take a couple days). Once the bug is visible, you will be able to - monitor this bug on the Java Bug Database at http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6969236. - Vote for the bug (if you are an SDN member, which is free of charge) Click http://bugs.sun.com/bugdatabase/addVote.do?bug_id=6969236. - Addi the report to your Bug Watch list. You will receive an email notification when this bug is updated. Click http://bugs.sun.com/bugdatabase/addBugWatch.do?bug_id=6969236. The Sun Developer Network (http://developers.sun.com) is a free service that Sun offers. To join, visit https://softwarereg.sun.com/registration/developer/en_US/new_user.
As someone not in any way involved with u21 change, but someone who has been through an Oracle acquisition, let me offer some background... When Oracle acquires a product, there is a corporate mandate to re-brand all products. The deadlines given are very tight and the mandate even applies to old releases. I would not be surprised to see a re-branded Java 5 update show up. Thus, we cannot realistically expect anything to happen with the bug that Martin has opened. I would suggest that we set aside the passions and realize that the only ones hurt by the current situation are Eclipse users. Wikis and notices are fine and I did my part (http://lt-rider.blogspot.com/2010/07/oracle-jvm-6u21-and-eclipse.html) to spread the knowledge, but I still see this generating a lot of havoc on the Eclipse community. With a good portion of the community in the process of switching from Galileo to Helios in the next few months while u21 is rolling out, we have an opportunity to shield many users from experiencing this problem in the first place. +1 for a Helios hotfix
Am I correct in believing that this bug will cause all third party RCPs to fail upon startup once the end-user updates Java? (Except those who bundled a JRE inside their RCP structure)? This is a complete nightmare for us if so - we are not in a position to inform users that they should edit their <appname>.ini file to fix this. And I also understand from previous comments that this will break RCPs based on Eclipse 3.4, not just 3.5?
(In reply to comment #22) > For most products on top of Eclipse, > this should be a non-issue since they ship their own JVM. > FWIW, our product, which is based on the 3.5 workbench and requires Java 1.6+, has several hundred users and we do not package a JVM with it.
*** Bug 319495 has been marked as a duplicate of this bug. ***
(In reply to comment #38) > Wikis and notices are fine and I did my part > (http://lt-rider.blogspot.com/2010/07/oracle-jvm-6u21-and-eclipse.html) to > spread the knowledge, but I still see this generating a lot of havoc on the > Eclipse community. Anyone who doubts the negative impact this will have, indeed already is having, in the user community should read the first couple of comments to Konstantin's blog. Yes, doing a "hotfix" release is no trivial matter, but neither is regaining the trust and mind-share of developers who will be burned by this problem. By not releasing the fix, we are saying that Eclipse is simply not going to work out of the box on the latest version of the BY FAR most common JRE on the BY FAR most common operating systems. To be honest, I'm astonished that anyone considers that to be an acceptable position to take.
(In reply to comment #42) > Yes, doing a "hotfix" release is no trivial matter, but neither is regaining > the trust and mind-share of developers who will be burned by this problem. By > not releasing the fix, we are saying that Eclipse is simply not going to work > out of the box on the latest version of the BY FAR most common JRE on the BY > FAR most common operating systems. To be honest, I'm astonished that anyone > considers that to be an acceptable position to take. +1 As I said before another option is to declare that Eclipse will not solve this problem and point to others who will (and I'm sure the others who distribute Eclispe will be happy to solve this). Either way, there needs to be a way for anyone to quickly and easily get a working distribution without doing a bunch of (or any) funny stuff. It does not matter who broke this, it's up to us to fix it, as the damage will be only to us. We make these great arguments that we ship on time every time, but we blew it this time, we shipped something that did not work and we have to fix it. It does not matter that it was actually broken by Oracle (and pointing the finger at them is just going to make us look like whiners), it's going to be (and I think rightly) perceived as our problem. We are a very big Java product, one of the leading IDEs, we should have had a relationship with Oracle so that we knew what they were going to do, this should not have been a surprise, and since it happened we need to quickly do the right thing by our users to make their experience as seamless as possible, even if it means spinning another release. Let's keep in mind why we are here and who our customer is, and let's do right by them.
+1 for a hotfix. The download warning does not help people who already downloaded. Personally, I think we don't want to leave the impression "eclipse crashes all the time" with our users. I already saw some people venting about eclipse crashes on twitter today.
I'm in favor of doing all we can to help our users, and keep reputation high! But keep in mind that creating the hotfix only solves part of the problem, the hotfix must also be deployed somehow (that is, how are we going to help those on Eclipse 3.3.x, 3.4.x, 3.5.x or who have downloaded Helios already). How would an existing Helios user get the download when he cannot launch the product for auto-update any more? When downloading a hotfix is just as complex as fixing an INI file we don't win much. Fact is, Oracle made the change without upfront warning, and we were not aware of it. I'm not sure how realistic it is to expect "we should have known". Fact is also, Oracle does have the auto-update infrastructure to deploy a fix (just like they deployed the breakage) which we don't. Others shall judge whether that is "whining", I think I'm just talking facts. And I'd love to see the word spread to Oracle too regarding how much of a problem this is for our Community.
Hi, this bug cost me about an hour to find. The problem is that Eclipse not always prints out the PermGen error but sometimes simply hangs. I've discovered the problem by running jvisualvm and only then realized that the permgen switch no longer works. I think this is a really serious problem. And I also think that Oracle has done nothing wrong. I understand the reasons why Eclipse is reading the file information for the jvm.dll but I do not consider a file metadata as a critical component which cannot be changed. So this problem lies with Eclipse. Sorry if this is harsh but until this bug report I didn't even consider the u21 to be the cause as I've updated to helios and u21 at roughly the same time.
My 2 cents: did Sun wrote in some contract/specification that java.exe/javaw.exe MUST show "Sun Microsystems" in its Company field metadata? If so, then I agree this is primarily a serious bug introduced by Oracle. If not, I don't see why this should be addressed as an Oracle's fault. Maybe Eclipse needs a more robust mechanism to determine the JRE type to pass the MaxPermSize VM argument at startup? Mauro.
(In reply to comment #45) > Others shall judge whether that is "whining", I think I'm just talking facts. Talking facts does not help people, so yes, I consider this "whining". Users are not interested in a detailed analysis of the issue, they are interested in Eclipse working again. Even spare time driven and hobby-like open source projects can typically deliver fixes for serious issues within a short amount of time. And the Eclipse foundation (with a lot of member companies and a serious commercial background) is still discussing, whether this is possible? The Helios release has been widely reported as "delivering several million lines of code at the promised date, the Nth year in a row". Have you ever thought about the contrast between that promise and having such a serious issue only fixed in a 3 months away service release instead of as fast as possible? Regards, Michael
(In reply to comment #45) > But keep in mind that creating the hotfix only solves part of the problem, the > hotfix must also be deployed somehow (that is, how are we going to help those > on Eclipse 3.3.x, 3.4.x, 3.5.x or who have downloaded Helios already). How > would an existing Helios user get the download when he cannot launch the > product for auto-update any more? > > When downloading a hotfix is just as complex as fixing an INI file we don't win > much. > I'm inclined to agree with these comments.
In my opinion, this is an _Eclipse_ problem. I do not see why Oracle would be bound to "naming rules" unless Sun had previously made some strange claim (as noted by comment 47, which I doubt). I do not however, necessarily buy the argument that the Eclipse team dropped the ball in testing as 6u21 only went GA on July 7th or something around there. Perhaps someone would've found this problem if the EA builds of 6u21 had the string change but let's be realistic here, if you notice you get permgen problems on 6u21 (EA or not) but not 6u20, you are likely going to blame the VM, and not Eclipse. I would like to take the time here to _commend_ the community for realizing the discrepancy between the two startup scenarios to notice that the missing VM argument was the cause behind this bug. Now, regarding the _severity_ of this problem, I realize and agree that a lot of people is going to be burned by this. But, on the other hand, do you all remember the last time a bajillion people got burned? Remember bug 214092, which affected _all_ platforms? Admittedly, that was a HotSpot JVM bug and not an Eclipse bug but a user isn't going to know or care, Eclipse crashed and they got mad at Eclipse. They then searched around, found a workaround for the problem (which oddly enough, is essentially identical to the workaround for this bug, that is, either manually modify your eclipse.ini file or downgrade your JVM), and moved on with their lives.
(In reply to comment #45) > But keep in mind that creating the hotfix only solves part of the problem, the > hotfix must also be deployed somehow (that is, how are we going to help those > on Eclipse 3.3.x, 3.4.x, 3.5.x or who have downloaded Helios already). How > would an existing Helios user get the download when he cannot launch the > product for auto-update any more? I agree this is an issue, and needs to be addressed and it not easy, but the thing that we should do as quickly as possible so that people who are updating to Helios get the right thing. > > When downloading a hotfix is just as complex as fixing an INI file we don't win > much. We should consider other alternatives as fixing it in code somehow. > > Fact is, Oracle made the change without upfront warning, and we were not aware > of it. I'm not sure how realistic it is to expect "we should have known". Here I really strongly feel that we should have known. If you consider many large software companies; they have a relationship with their suppliers so they get inside information; they have relationships at high levels in the supply chain for their products so that before *anything* is released they have an opportunity to test it. The fact that we are one of the leading IDEs and were taking by surprise by this is not excusable. We should have this relationship so that Oracle would not consider releasing anything unless they know it will work on the Eclipse platform. Of course this is a foundation issue.
(In reply to comment #46) > Hi, this bug cost me about an hour to find. The problem is that Eclipse not > always prints out the PermGen error but sometimes simply hangs. > > I've discovered the problem by running jvisualvm and only then realized that > the permgen switch no longer works. > > I think this is a really serious problem. And I also think that Oracle has done > nothing wrong. I understand the reasons why Eclipse is reading the file > information for the jvm.dll but I do not consider a file metadata as a critical > component which cannot be changed. So this problem lies with Eclipse. Sorry if > this is harsh but until this bug report I didn't even consider the u21 to be > the cause as I've updated to helios and u21 at roughly the same time. +1, we have no business depending on internals like this and then complaining if they break.
*** Bug 319471 has been marked as a duplicate of this bug. ***
(In reply to comment #50) > I do not however, necessarily buy the argument that the Eclipse team dropped > the ball in testing as 6u21 only went GA on July 7th or something around there. I don't know the Java release process, but you mentioning EAs and GAs indicates they have some sort of schedule and process. If it's the job of the Eclipse Foundation to provide working Eclipse distributions then we most certainly dropped the ball here as we failed to certify our distribution on a Java that was coming out a week after our build. One can argue if this is the job of Eclipse to do this (rather than some other third party), however if we accept that this is our job, then we failed, and we need to address the underlying defects in our processes that allowed this to happen (as we are typically very good at).
(In reply to comment #50) > In my opinion, this is an _Eclipse_ problem. I do not see why Oracle would be > bound to "naming rules" unless Sun had previously made some strange claim (as > noted by comment 47, which I doubt). I agree. This is an Eclipse problem, especially since it is our users that are effected. > > I do not however, necessarily buy the argument that the Eclipse team dropped > the ball in testing as 6u21 only went GA on July 7th or something around there. > Perhaps someone would've found this problem if the EA builds of 6u21 had the > string change but let's be realistic here, if you notice you get permgen > problems on 6u21 (EA or not) but not 6u20, you are likely going to blame the > VM, and not Eclipse. I would like to take the time here to _commend_ the > community for realizing the discrepancy between the two startup scenarios to > notice that the missing VM argument was the cause behind this bug. Yup, there is not way we could have tested for this. > > Now, regarding the _severity_ of this problem, I realize and agree that a lot > of people is going to be burned by this. But, on the other hand, do you all > remember the last time a bajillion people got burned? Remember bug 214092, > which affected _all_ platforms? Admittedly, that was a HotSpot JVM bug and not > an Eclipse bug but a user isn't going to know or care, Eclipse crashed and they > got mad at Eclipse. They then searched around, found a workaround for the > problem (which oddly enough, is essentially identical to the workaround for > this bug, that is, either manually modify your eclipse.ini file or downgrade > your JVM), and moved on with their lives. Sorry but here I disagree. First, I would hope that we as a community try to improve our responsiveness, not just have a 'it is good enough' attitude. Second, we are very early in the Helios deployment cycle, less that 3 weeks. I would estimate that less than 20% [1] of our community has installed Helios, of those even fewer have installed the update 21. Therefore, we have an opportunity to NOT introduce this problem to 80% of the community and provide a usable fix for a good portion who have already downloaded. I agree with a lot of comments here. The reputation of Eclipse is shipping quality software, so knowingly let 80% of our community suffer through this bug, seems to go against this reputation. +1 that we fix this problem sooner than later. [1] We typically estimate 4 million users of Eclipse. To date we have had 986630 downloads of Helios. I know for a fact people download multiple times, hence I am estimated less than 20%.
I've added a "sticky" announcement about the problem and workarounds to the Newcomers forum (http://www.eclipse.org/forums/index.php?t=thread&frm_id=89). Unfortunately, history shows that many people ignore those sticky notes that are intended to get their attention first. <shrug> If anyone has suggestions for other forum groups where a similar sticky post should appear, let me know. Is there already a bug asking for a prominent notice at the top of the Downloads page?
(In reply to comment #55) > +1 that we fix this problem sooner than later. I would regard this as close to an emergency to get the current Helios kits right as is possible.
(In reply to comment #31) FYI, I just verified that downloading Andrew's eclipse_1308.dll from attachment 174343 [details] and dropping it into the plugins/org.eclipse.equinox.launcher.win32.win32.x86_1.1.0.v20100503 folder also fixes the problem, even without renaming or deleting the old DLL, or editing / patching any file. So that's a very simple fix for Helios users who don't like editing eclipse.ini. Now if we could just deploy that DLL automatically, Helios would be good... although the Galileo, Ganymede and Europa users would still have to edit their eclipse.ini, add a commandline flag, set an environment variable, or downgrade to 6u20 as per the FAQ on http://wiki.eclipse.org/FAQ_How_do_I_run_Eclipse%3F (In reply to comment #54) > address the underlying defects in our processes that allowed this to happen Sure we could do automated testing on JVM pre-releases. But even then we might miss something. To me, the most interesting outcome of this discussion would be creating some infrastructure for "push-style" emgergency updates. Then deploying a hotfix for whatever issue would be easy. (In reply to comment #55) > those even fewer have installed the update 21. Therefore, we have an > opportunity to NOT introduce this problem to 80% of the community Thanks for these figures. If these are right, then I agree that these are a strong argument in favor of doing a Helios respin. Did your calculation take into account the many other Eclipse distribution channels? Regarding those people who will download Helios from now on, I am still wondering why a clickthrough warning message is so much worse than a respin. IMO the main problem with this issue is that people are not aware of the problem, so making them aware of the many simple workarounds should go a long way... IMO this is more a question of perception and reputation than a technical question, so I'll trust your assessment, Ian. In terms of a respin, I believe that Dave Williams would know best what this would involve?
(In reply to comment #58) > > Thanks for these figures. If these are right, then I agree that these are a > strong argument in favor of doing a Helios respin. Did your calculation take > into account the many other Eclipse distribution channels? No they don't take into account alternative channels. It is difficult to estimate this impact but I can't believe it would be more than 10%. The numbers also don't include Eclipse based products but the 4 million is IDE users, not Eclipse based products. > > Regarding those people who will download Helios from now on, I am still > wondering why a clickthrough warning message is so much worse than a respin. > IMO the main problem with this issue is that people are not aware of the > problem, so making them aware of the many simple workarounds should go a long > way... I think the key problem is that people don't read warnings. :-) > IMO this is more a question of perception and reputation than a > technical question, so I'll trust your assessment, Ian. I appreciate the vote of confidence but I also respect the people that do a lot of the support work in the newcomer news forum, ie Eric, Francis and Remy. They are the front-line guys that take a lot of the heat for stuff like this. > > In terms of a respin, I believe that Dave Williams would know best what this > would involve? David, what say you?
Given that the discussion here has moved well beyond the actual technical fix, I raised bug 320005 for the code changes. That bug will be marked fixed as soon as I release the code. This bug remains for the discussion around the distribution of that fix.
(In reply to comment #45) > I'm in favor of doing all we can to help our users, and keep reputation high! > > But keep in mind that creating the hotfix only solves part of the problem, the > hotfix must also be deployed somehow (that is, how are we going to help those > on Eclipse 3.3.x, 3.4.x, 3.5.x or who have downloaded Helios already). How > would an existing Helios user get the download when he cannot launch the > product for auto-update any more? My understanding is that Eclipse can launch, but it will eventually run out of PermGen space and either crash or hang. Isn't the default behavior of the packages to automatically check for updates? If so, we can't really say whether or not users will be able to get the fix automatically, can we?
What happens with the p2 install instructions that modify the eclipse.ini during the next update if the majority of users modified the eclipse.ini by hand in the meantime?
Is there a reason this bug is marked as "Restricted Group Visibility"? It does not seem like a security issue to me. If there is no reason, can we make it public?
(In reply to comment #63) > Is there a reason this bug is marked as "Restricted Group Visibility"? It does > not seem like a security issue to me. If there is no reason, can we make it > public? +1 for making it public. We need to make people aware of the issue.
(In reply to comment #64) > +1 for making it public. We need to make people aware of the issue. @Eric, looks like you put it there, ok if we make it public?
(In reply to comment #64) > (In reply to comment #63) > > Is there a reason this bug is marked as "Restricted Group Visibility"? It does > > not seem like a security issue to me. If there is no reason, can we make it > > public? > > +1 for making it public. We need to make people aware of the issue. Even more so since several locations actually refer to this bug for details (wiki, Java Bug Database and more).
I'm just going to do it. Someone spank me if it's a problem.
(In reply to comment #65) > (In reply to comment #64) > > > +1 for making it public. We need to make people aware of the issue. > @Eric, looks like you put it there, ok if we make it public? Please stop adding the security advisory. This is the second time we have removed the advisory!
(In reply to comment #68) > Please stop adding the security advisory. This is the second time we have > removed the advisory! It must be some browser/client/cookie problem or something. I have emailed Eric about it.
(In reply to comment #65) > (In reply to comment #64) > > > +1 for making it public. We need to make people aware of the issue. > @Eric, looks like you put it there, ok if we make it public? Hmm, I didn't do that knowingly. I think there's a software bug somewhere, either in Bugzilla or in in my browser, because those changes, according to Bugzilla history log, correspond by timestamp to me comments. But I didn't explicitly change any fields at any time.
I just checked the java vm related information reported in Eclipse About > Eclipse Installation Details > Configuration, which says java.runtime.name=Java(TM) SE Runtime Environment java.runtime.version=1.6.0_21-b06 java.specification.name=Java Platform API Specification java.specification.vendor=Sun Microsystems Inc. java.specification.version=1.6 java.vendor=Sun Microsystems Inc. java.vendor.url=http://java.sun.com/ java.vendor.url.bug=http://java.sun.com/cgi-bin/bugreport.cgi java.version=1.6.0_21 java.vm.info=mixed mode java.vm.name=Java HotSpot(TM) Client VM java.vm.specification.name=Java Virtual Machine Specification java.vm.specification.vendor=Sun Microsystems Inc. java.vm.specification.version=1.0 java.vm.vendor=Sun Microsystems Inc. java.vm.version=17.0-b16 This should be part of what System.getProperties() returns. Compared to the console output mentioned in Comment #27, I think we should read the property java.vm.name to identify the vm being used. For Sun/Oracle JVM, java.vm.name=Java HotSpot(TM) Client VM For BEA/Oracle JVM, java.vm.name=Oracle JRockit(R) And this should work for all OS'es. The option mentioned in Commment #7, by checking the output of 'java -version' is also eligible if it makes things easier. We're right now being told that checking the COMPANY_NAME tends out to be a fragile method as what we're being through, therefore IMHO we shouldn't follow the same old approach and fix the bug with Patch #174008 (From Comment #27) > java.runtime.name=Java(TM) SE Runtime Environment > java.runtime.version=1.6.0_20-b02 > java.specification.name=Java Platform API Specification > java.specification.vendor=Sun Microsystems Inc. > java.specification.version=1.6 > java.vendor=Oracle Corporation > java.vendor.url=http://www.oracle.com/ > java.vendor.url.bug=http://download.oracle.com/docs/cd/E15289_01/go2troubleshooting.html > java.version=1.6.0_20 > java.vm.info=compiled mode > java.vm.name=Oracle JRockit(R) > java.vm.specification.name=Java Virtual Machine Specification > java.vm.specification.vendor=Sun Microsystems Inc. > java.vm.specification.version=1.0 > java.vm.vendor=Oracle Corporation > java.vm.vendor.url=http://www.oracle.com/ > java.vm.vendor.url.bug=http://download.oracle.com/docs/cd/E15289_01/go2troubleshooting.html > java.vm.version=R28.0.1-21-133393-1.6.0_20-20100512-2132-windows-ia32
Will the bug fix be available as small and simple update via Help->Check for Updates or "Install new software"?!
(In reply to comment #37) FYI, The Sun/Oracle bug is online now and can be voted for: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6969236. (In reply to comment #62) > What happens with the p2 install instructions that modify the eclipse.ini > during the next update if the majority of users modified the eclipse.ini by > hand in the meantime? Good point. As per comment 58, I think that downloading the fixed eclipse_1308.dll from attachment 174343 [details] is the safest fix. The DLL must be placed into plugins/org.eclipse.equinox.launcher.win32.win32.x86_1.1.0.v20100503 this could probably be simplified by distributing the DLL as a ZIP which can be extracted into the Eclipse install root. (In reply to comment #71) > I think we should read the property java.vm.name to identify > the vm being used. Problem is, this is performance critical and launching the VM was perceived as slow in the past on Windows (though this may have changed over time and should be measured again). Also, from comment 30 I understand that the current fix (from bug 320005) is done for quick availability and may receive further polishing to improve it. For example, we could read the VM properties (slow) but cache the value, indexed by location of the VM. At this early startup stage, I'm not sure though where we could have a good disk location for caching this. I suggest filing a separate bug for discussing improvements of the current logic. (In reply to comment #72) > Will the bug fix be available as small and simple update via Help->Check > for Updates or "Install new software"?! Problem is, the bug may strike before you get to performing "Check for Updates", so this won't be the recommended way deploying the fix. But of course making the fix available via update as well would seem prudent.
FYI, I have updated the http://wiki.eclipse.org/FAQ_How_do_I_run_Eclipse%3F to include the "download eclipse_1308.dll" workaround and add a reference to the Oracle/Sun BugParade entry. Also slightly improved the styling.
(In reply to comment #59) > (In reply to comment #58) > > > > In terms of a respin, I believe that Dave Williams would know best what this > > would involve? > > David, what say you? I'll probably say more more than you intend :) ... but, I've given this some thought, since my first impression was that this was not anywhere close to a case needing an emergency fix, even if a quick fix would be relatively easy. I think our predicable, regularly occurring Eclipse schedules work because it allows some coordinated focus ... and deviating from that is pretty distruptive, and takes away from other important work that needs to get done. But, I'll admit, it also leads to me being "stuck in my ways" so I'm open to suggestions and would be glad to help if the rest of the Planning Council wanted to change schedules or discuss an exception. But ... here's my thoughts on some of the mechanics of how this might be accomplished ... none of them easy, for this particular case. This is not a good case for any of the normal "quick hot fix" methods, as has been noted by others, and we don't really have the ability to "respin Helios" (not in any normal sense of the word). Normally, a "patch feature" might be one way to solve this problem with a respin of only the effected EPP packages. Users can't really update to the patch feature in this case (as has been noted). But, instead, normally, for hot fixes, EPP could use the patch feature to respin the effected packages, with just the patch feature added. But, for this case, that is more complicated and risky than usual. This executable is part of a special fragment, that has many connections to many features and functions. Hence would require many patch features, and some functions would need extensive testing, to make sure they would still work with a patched version of these features/fragments. I briefly chatted with Andrew Niefer about this possibility, and he said "At the very least there is the org.eclipse.rcp feature, the org.eclipse.equinox.executable feature (the delta pack), there is an org.eclipse.rcp.configuration used by the platform products and there will be configuration IUs that set the --launcher.library properties. Pushing out a hotfix might fix people's running eclipses, but there will likely be issues around build/export of rcp products. For product builds to work well, there really needs to be new versions of the features." So, patch features are not feasible for this particular case, it appears. Given the nature of our common repo, one approach might be if the Platform did an "early service release" (such as, as soon as possible), but, instead of a normal service release, it would have only this one fix ... but it would be trickled and filtered through all their normal builds, comparisons, and versioning, etc. While lots of work for them, this isn't as bad for common repository and EPP as it might sound ... since the platform is a "trusted" repo, the common repo simply points to it. So, if the Platform had an early service release, the common repo could be "fixed" by updating one URL. Then EPP respun once this new common repo was in place. But this is still a risky approach if the effected fragment/bundle or features happen to be those that other other projects have "close ties" with (that is, very tight, or exact versioning in prereq equinox) -- and, not sure, ECF, Jetty, Reina used to have some very tight version ranges for some of these equinox bundles/features ... not sure if they still do, or if it involved these in question ... but, if they did, they'd also have to rebuild, and we'd be back to "respining the whole repo" case, which would be a lot of work. Essentially just moving SR1 date earlier. I'd also like to mention process. I think the first level decision of any sort of remedial action should be the Eclipse/Platform/Equinox and EPP teams. If they want to provide a quick fix or service, then after that would be the time for the Planning Council to get more involved. As much as we all like to boss them around :) we do need to respect project boundaries, and they, in fact, know best if a fix or patch is feasible at their level and with their committers workload. Though I'm sure they appreciate the advice and opinions expressed here. And, don't forget, while all the above Helios discussion is good and interesting ... it does nothing to help anyone with users with any 3.3, 3.4, 3.5 apps installed. Many of them might also "break" with too little memory, with this Sun VM, without users specifying their own vm argument value for this non-standard argument. I honestly can't imagine us systematically "patching" or rebuilding all those old versions ... so there will have to be some mass education regardless of what we do for Helios, unless Oracle reverts the change, or changes the default value for XX:MaxPermSize. And, remember, this eduction is really just education on how to use the Sun VM ... granted, we were previously hiding something from Eclipse users who use that VM and now we are not, and granted Eclipse needs this parameter more than many other "java apps", but there's hundreds if not thousands of blogs and forum notes about people needing to increase this value for other apps that use Sun's VM ... that is, needing to set the parameter is not entirely specific to Eclipse. Maybe others have more optimistic ideas for better, easier, quicker solutions? But from my point of view and limited knowledge, fixing Helios in SR1 and conducting mass education for older releases is the best we can do for this particular case.
(In reply to comment #75) I had an initial conversation with Oracle and should know more next week, so I suggest we defer until I hear back. He did confirm that update 21 has not auto-updated, so that is good news.
Can anyone provide a link to download 1.6.0_20 for Windows so we can include that on the wiki/forums/IRC etc?
@Eric Rizzo, JDK 6 Update 20 with JavaFX SDK http://java.sun.com/javase/downloads/widget/jdk_javafx.jsp The initial web page for downloads is: http://java.sun.com/javase/downloads/index.jsp Hope this help you!
Created attachment 174640 [details] win32.x86 eclipse_1308.dll containing patch (In reply to comment #74) > FYI, I have updated the > > http://wiki.eclipse.org/FAQ_How_do_I_run_Eclipse%3F > > to include the "download eclipse_1308.dll" workaround and add a reference to > the Oracle/Sun BugParade entry. Also slightly improved the styling. I have attached the real dll if people are being told to download this library. This is the library that was released to the 36x branch, the other library was just something I compiled for testing. Note that p2 will keep the user's modifications to the eclipse.ini, they will not be overwritten during an install/upate. I would not say that dropping this dll into the old fragment folder is a better fix than modifying the eclipse.ini: - it violates p2's fundamental assumption of 1 version == 1 set of bits. - the fragment in the install was signed by eclipse.org, dropping in the dll will break the signature. These could become issues when performing rcp product builds from the modified install.
I modified the wiki to point to the new binary, and to move downloading the dll down as the third option.
(In reply to comment #76) > (In reply to comment #75) > > I had an initial conversation with Oracle and should know more next week, so I > suggest we defer until I hear back. He did confirm that update 21 has not > auto-updated, so that is good news. Oracle has confirmed that they are going to re-spin update 21 to remove the change the breaks Eclipse. The respin should be available next week. Big thanks to Oracle for being very accommodating and supportive!!! It was their idea to do the respin, so I take no credit, I am just the messenger. Also to Konstantin for hooking me up with the right people. However, I would like to point out that we need to fix this issue in Eclipse. Oracle is now the vendor name so it is very reasonable that they will eventually want to make this change.
Try to add into the eclipse.ini a -vm parameter, pointing to the jvm.dll in Windows or to libjvm.so in Linux/UNIX.
(In reply to comment #82) > Try to add into the eclipse.ini a -vm parameter, pointing to the jvm.dll in > Windows or to libjvm.so in Linux/UNIX. Who is this comment directed at? It is unclear if this is pointing out an issue or suggesting a possible fix/workaround.
(In reply to comment #83) > (In reply to comment #82) > > Try to add into the eclipse.ini a -vm parameter, pointing to the jvm.dll in > > Windows or to libjvm.so in Linux/UNIX. > > Who is this comment directed at? It is unclear if this is pointing out an > issue or suggesting a possible fix/workaround. It's a workaround. I always add the -vm parameter and therefore didn't face this issue after updating to JDK 6u21.
(In reply to comment #52) > +1, we have no business depending on internals like this and then complaining > if they break. Unfortunately we can't avoid depending on internals here. The Sun/Oracle VM, out of the box, cannot run Eclipse. It crashes because has an artificial limit on its permanent generation memory space. To work around this VM bug, we must insert the internal, non-standard XXMaxPermSize command line argument. However, since this argument is not a specified Java command line argument, other VMs correctly fail when this argument is supplied. So, we must detect whether we are running on a VM that requires this argument, and those internal properties were the only sufficiently performant mechanism we found to do that on Windows. If you can point us to a standard, supported way we can determine whether the unspecified, unsupported XXMaxPermSize argument is needed, please chime in.
> Unfortunately we can't avoid depending on internals here. The Sun/Oracle VM, > out of the box, cannot run Eclipse. It crashes because has an artificial limit > on its permanent generation memory space. To work around this VM bug, we must > insert the internal, non-standard XXMaxPermSize command line argument. However, > since this argument is not a specified Java command line argument, other VMs > correctly fail when this argument is supplied. So, we must detect whether we > are running on a VM that requires this argument, and those internal properties > were the only sufficiently performant mechanism we found to do that on Windows. > If you can point us to a standard, supported way we can determine whether the > unspecified, unsupported XXMaxPermSize argument is needed, please chime in. A number of proposal have been tossed around that are less brittle. I personally favor going by the output of "java -version" as is done in the *nix launcher and then stashing the result of that lookup so that only the first startup incurs the performance hit.
(In reply to comment #86) > A number of proposal have been tossed around that are less brittle. I > personally favor going by the output of "java -version" as is done in the *nix > launcher and then stashing the result of that lookup so that only the first > startup incurs the performance hit. Before doing something like: - looking for some cached value and reading it - making sure the value actually corresponds to the java version we are about to launch (perform some checksum on the VM?) - then using the correct VM launching arguments Analysis should be done on the cost of running an extra "java -version". After all we have not seen any complaints on the *nix platforms about performance here. Running the java -version command on a cold start likely does have a performance hit. But this is likely the same cold start costs of running a VM for the first time if we directly launched it when starting eclipse from a cold start. That being said, I don't see any guarantees on the output of java -version staying the same for all future releases of the VM. That is still somewhat brittle in my opinion.
> That being said, I don't see any guarantees on the output of java -version > staying the same for all future releases of the VM. That is still somewhat > brittle in my opinion. It's not a perfect solution, but it is less brittle than the current approach for two reasons: 1. The output of "java -version" is generally recognized as "api" by jvm vendors. A lot of software uses this information. The same cannot be said about attributes on a dll file. 2. A lot more information is accessible via "java -version". In particular, we get the name of the JVM, not just the vendor. That would allow logic to look for "HotSpot" rather than "Oracle" or "Sun", which is arguably less brittle and it would also allow us to correctly differentiate between Oracle HotSpot and Oracle JRockit JVMs.
Currently the launcher is not guaranteed to know a java.exe to run. There are cases where we only know the jvm.dll to use through the JNI invocation API. On *nix when we don't have a java executable, we default to isSunVM == false. Also, on windows, when we start with a java.exe, if that executable is not located in a jre install (Like C:\Windows\system32\java.exe), we end up looking in the registry for the jvm.dll. There could be cases where the jvm.dll we select out of the registry may be different from the jvm.dll that would have been selected by the java.exe. This could result in "java -version" being a different jvm than the one we are actually running.
> Currently the launcher is not guaranteed to know a java.exe to run. There are > cases where we only know the jvm.dll to use through the JNI invocation API. > On *nix when we don't have a java executable, we default to isSunVM == false. > > Also, on windows, when we start with a java.exe, if that executable is not > located in a jre install (Like C:\Windows\system32\java.exe), we end up looking > in the registry for the jvm.dll. There could be cases where the jvm.dll we > select out of the registry may be different from the jvm.dll that would have > been selected by the java.exe. This could result in "java -version" being a > different jvm than the one we are actually running. I imagine there is something similar to "java -version" that can be done with jvm.dll. But actually the practice of using jvm.dll is in itself problematic. Due to how Windows pins DLLs to memory, on 32-bit systems, it relatively easily leads to situations where it is impossible to allocate amounts as small as 1.5 gb to java/eclipse out of 4 gb virtual address space.
(In reply to comment #90) > I imagine there is something similar to "java -version" that can be done with > jvm.dll. It would be great if there was. The java executable must have a way to get this information from the jvm without fully loading the vm. > > But actually the practice of using jvm.dll is in itself problematic. Due to how > Windows pins DLLs to memory, on 32-bit systems, it relatively easily leads to > situations where it is impossible to allocate amounts as small as 1.5 gb to > java/eclipse out of 4 gb virtual address space. This is basically bug 188968. Looking at my comment bug 188968 comment #34, it appears that java.exe will have the same problems wrt to the location of the jvm.dll in memory. Eclipse just has additional problems coming from user32.dll which gets loaded to show the splash screen. As well bug 188968 comment 40 indicates that the version.dll we use to read the vendor from the jvm may also interfere with the amount of memory we can allocate. I'm not sure why my patch there did not get released, but it is a significant change to the launcher.
+1 for comment #89. Also somewhat related to comment #90, instead of calling java -version and parsing the stdout, if Java is going to be invoked anyway, could the results of a few System.getProperty(...) calls be used instead? This would be portable, and as was mentioned previously, the results of this could still be cached for performance. Some discussion may be necessary as to which properties should be looked at, but here are some that should be relevant: java.runtime.name=Java(TM) SE Runtime Environment java.runtime.version=1.6.0_21-b06 java.specification.name=Java Platform API Specification java.specification.vendor=Sun Microsystems Inc. java.specification.version=1.6 java.vendor.url.bug=http://java.sun.com/cgi-bin/bugreport.cgi java.vendor.url=http://java.sun.com/ java.vendor=Sun Microsystems Inc. java.version=1.6.0_21 java.vm.info=mixed mode java.vm.name=Java HotSpot(TM) 64-Bit Server VM java.vm.specification.name=Java Virtual Machine Specification java.vm.specification.vendor=Sun Microsystems Inc. java.vm.specification.version=1.0 java.vm.vendor=Sun Microsystems Inc. java.vm.version=17.0-b16 Compare to the output of java -version : java version "1.6.0_21" Java(TM) SE Runtime Environment (build 1.6.0_21-b06) Java HotSpot(TM) 64-Bit Server VM (build 17.0-b16, mixed mode) Per the API specifications, these property keys are always included: http://download.oracle.com/docs/cd/E17409_01/javase/6/docs/api/java/lang/System.html#getProperties() I would think that reading from the System Properties would also be cleaner and more reliable than parsing the output. Granted, if no cached information exists, the launcher will have to run Java once to obtain this information, and then again to actually launch the platform with the necessary JVM settings - but I think this would be the best approach.
(In reply to comment #85) > (In reply to comment #52) > > +1, we have no business depending on internals like this and then complaining > > if they break. > > Unfortunately we can't avoid depending on internals here. The Sun/Oracle VM, > out of the box, cannot run Eclipse. It crashes because has an artificial limit > on its permanent generation memory space. To work around this VM bug, we must > insert the internal, non-standard XXMaxPermSize command line argument. Has someone from the Eclipse Platform team opened a bug with Oracle? At some point in time they will make the change from Sun to Oracle, so it needs to be addressed.
(In reply to comment #93) > (In reply to comment #85) > > (In reply to comment #52) > > > +1, we have no business depending on internals like this and then complaining > > > if they break. > > > > Unfortunately we can't avoid depending on internals here. The Sun/Oracle VM, > > out of the box, cannot run Eclipse. It crashes because has an artificial limit > > on its permanent generation memory space. To work around this VM bug, we must > > insert the internal, non-standard XXMaxPermSize command line argument. > > Has someone from the Eclipse Platform team opened a bug with Oracle? At some > point in time they will make the change from Sun to Oracle, so it needs to be > addressed. I have opened enhancement request: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6969945 to make the default value for maxPermSpace larger or smarter. Seems to me users should not have to specify it at all, unless they purposely want to change characteristics of garbage collection. But, it is still in an invisible "triage" state ... after a week ... perhaps because its an enhancement request, instead of a bug. Is this the only VM specific parameter that is set? If so, that'd sure be the best solution. Then, even, new VMs would work on old Eclipses, since even if launcher argument was not recognized as running on a "sun vm" it would no longer matter since it wouldn't be required.
(In reply to comment #93) > Has someone from the Eclipse Platform team opened a bug with Oracle? At some > point in time they will make the change from Sun to Oracle, so it needs to be > addressed. Also see comment 37 for the bug Martin opened.
(In reply to comment #85) > (In reply to comment #52) > > +1, we have no business depending on internals like this and then complaining > > if they break. > > Unfortunately we can't avoid depending on internals here. The Sun/Oracle VM, > out of the box, cannot run Eclipse. It crashes because has an artificial limit > on its permanent generation memory space. To work around this VM bug, we must > insert the internal, non-standard XXMaxPermSize command line argument. However, > since this argument is not a specified Java command line argument, other VMs > correctly fail when this argument is supplied. So, we must detect whether we > are running on a VM that requires this argument, and those internal properties > were the only sufficiently performant mechanism we found to do that on Windows. > If you can point us to a standard, supported way we can determine whether the > unspecified, unsupported XXMaxPermSize argument is needed, please chime in. If depending on internals is necessary based on limitations of the current jvm, then the proper solution is to get information from Oracle/Sun what to depend on and depend on that. It should obviously be based on feature, not by owner. You don't want to make the classic MSN mistake, in which the website failed to load under Opera, but then worked perfectly in Opera if you configured Opera to send a header string saying it was IE. However all that is beside the point. You don't need the correct solution now. You need the *immediate* solution. Your flagship product has been broken out of box since at least the 12th and at least new downloads (I downloaded today, thank you very much) should be fixed immediately, even if every bit in the fix is 100% throwaway. This is very public, and very visible.
I am very, very confused about all this (still). I'm still running into PermGen problems all the time (e.g. below) !ENTRY org.eclipse.ui 4 0 2010-07-26 12:57:05.742 !MESSAGE Unhandled event loop exception !ENTRY org.eclipse.ui 4 0 2010-07-26 12:57:06.602 !MESSAGE Unhandled event loop exception !STACK 0 org.eclipse.swt.SWTException: Failed to execute runnable (java.lang.OutOfMemoryError: PermGen space) at org.eclipse.swt.SWT.error(SWT.java:4083) at org.eclipse.swt.SWT.error(SWT.java:3998) at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:137) at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:4041) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3660) at null...(MANY TIMES OVER) Caused by: java.lang.OutOfMemoryError: PermGen space I tried setting -XX:MaxPermSize=512m in the eclipse.ini file after the vmargs. I tried setting it in the shortcut properties. It's still happening - what on earth is going on with this?
Quick summary of current status: - As per comment #76, the Oracle jre6u21 is not auto-updating, so only Windows users who manually downloaded the 6u21 JRE are affected. - As per comment #81, Oracle is going to re-spin jre6u21 (should be available this week), taking out the rebranding, so the immediate problem is going away - The Eclipse Platform team is working on multiple fronts on a longer-term solution for the problem: + comment 94: Enhancement Request with Oracle to make default MaxPermSize larger or faster + Work with Oracle to see what's the best "API" for determining whether any given VM is a HotSpot VM (ie needs MaxPermSize) or not. Depends also on performance measurement in the Launcher and what we can do in terms of caching a query result. + Consider an infrastructure for rolling out hotfixes to Eclipse in a controlled manner (eg comment 58) - The workarounds from http://wiki.eclipse.org/FAQ_How_do_I_run_Eclipse%3F have all been tested to work as expected, if anybody still sees issues they best downgrade to JRE 6u20 or earlier or see below (In reply to comment #97) > I tried setting -XX:MaxPermSize=512m in the eclipse.ini file after the vmargs. > I tried setting it in the shortcut properties. It's still happening - what on > earth is going on with this? This is very strange. I'd recommend doing Help > About Eclipse, Installation Details, Configuration and check the value of the "eclipse.vmargs" property to see whether (a) your setting doesn't pass in, or (b) your Eclipse needs > 512m MaxPermSize. Or just downgrade to JRE 6u20.
*** Bug 319551 has been marked as a duplicate of this bug. ***
PermGen strikes again, any ideas? I'm starting to wonder if this is a wider issue with 6_21 (but maybe I'm just not seeing the problem) :( !ENTRY org.python.pydev 1 1 2010-07-26 14:54:08.874 !MESSAGE Did not expect adapter request: interface org.eclipse.search.ui.ISearchPageScoreComputer !ENTRY org.eclipse.core.jobs 4 2 2010-07-26 15:54:30.429 !MESSAGE An internal error occurred during: "Initializing JavaScript Tooling". !STACK 0 java.lang.OutOfMemoryError: PermGen space at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClassCond(Unknown Source) at java.lang.ClassLoader.defineClass(Unknown Source) at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.defineClass(DefaultClassLoader.java:188) at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.defineClass(ClasspathManager.java:580) at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findClassImpl(ClasspathManager.java:550) at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClassImpl(ClasspathManager.java:481) at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClass_LockClassLoader(ClasspathManager.java:469) at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClass(ClasspathManager.java:449) at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.findLocalClass(DefaultClassLoader.java:216) at org.eclipse.osgi.internal.loader.BundleLoader.findLocalClass(BundleLoader.java:393) at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:469) at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:422) at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:410) at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:107) at java.lang.ClassLoader.loadClass(Unknown Source) at org.eclipse.wst.jsdt.core.search.SearchEngine.<init>(SearchEngine.java:53) at org.eclipse.wst.jsdt.core.JavaScriptCore.initializeAfterLoad(JavaScriptCore.java:2673) at org.eclipse.wst.jsdt.internal.ui.InitializeAfterLoadJob$RealJob.run(InitializeAfterLoadJob.java:32) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54) ---- From my configuration details in running eclipse: eclipse.vmargs=-XX:MaxPermSize1024m -XX:PermSize512m -Xms512m -Xmx1024m
(In reply to comment #100) You are not using correct syntax for this switch: -XX:MaxPermSize=256m Note the equal sign unlike the -Xms and -Xmx switches.
Gah! It was bound to be something like that. I've changed the switch and it seems to be behaving itself for the time being - I'll post if it happens again.
It would appear Oracle has reverted the company name back to Sun, so it looks like the problem is fixed, for now. Note they are going to make the change to 'Oracle' for Java 7.
(In reply to comment #103) > It would appear Oracle has reverted the company name back to Sun, so it looks > like the problem is fixed, for now. Note they are going to make the change to > 'Oracle' for Java 7. Sorry meant to include link to the Oracle bug http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6969236
(In reply to comment #103) > It would appear Oracle has reverted the company name back to Sun, so it looks > like the problem is fixed, for now. Note they are going to make the change to > 'Oracle' for Java 7. I've updated the wiki page (http://wiki.eclipse.org/FAQ_How_do_I_run_Eclipse%3F) and the "sticky" announcement on the Newcomers forum (http://www.eclipse.org/forums/index.php?t=msg&th=171988&start=0&) to reflect the JVM/JRE update.
*** Bug 319435 has been marked as a duplicate of this bug. ***
*** Bug 319915 has been marked as a duplicate of this bug. ***
*** Bug 319517 has been marked as a duplicate of this bug. ***
Just to let you know that on one of the PCs I've worked on in these days, yesterday the Java auto-update feature proposed me to install the update 21. So it seems that now Oracle is pushing update 21 with auto update, too.
Was the eclipse_1308.dll patch tested with x64 Helios? I ask because it is not working on Helios x64 atop Java v6 u21 (not respin) x64 and Win7 x64. Further, it appears the patch guidance [1] is tacitly x86-specific. To wit: "For Helios, download the fixed eclipse_1308.dll and place it into (eclipse_home)/plugins/org.eclipse.equinox.launcher.win32.win32.x86_1.1.0.v20100503 This appears x86-specific because this folder does not exist in Helios x64. What does exist is: org.eclipse.equinox.launcher.win32.win32.x86_64_1.1.0.v20100503 If my experience with this patch is idiomatic, I suggest adding an x64-flavored patch along with the appropriate guidance to prevent compounded frustration. Peace, /jeff [1] - http://wiki.eclipse.org/FAQ_How_do_I_run_Eclipse%3F#Oracle.2FSun_VM_1.6.0_21_on_Windows
Sorry about this guys, but what the hell is taking so long? Ileana: hI, GOOD AFTERNOON Ileana: no problem Achilles: Hello Sorry about the delay Ileana: what can I do for you today? Achilles: Is this true? http://it.slashdot.org/story/10/07/28/2121259/slashdot.sourceforge.net Ileana: let me check, pls Achilles: okay take your time Ileana: I can put you in touch with people from Java Ileana: would this be okay for you? Achilles: okay Ileana: give me a moment please Ileana: Has transferred you to:Neha Achilles: Neha? Neha: Hello Neha: this is Neha how cn i help you today? Achilles: Is this true? http://it.slashdot.org/story/10/07/28/2121259/slashdot.sourceforge.net Neha: please give a second and i will check the link Achilles: sure Neha: all these things usually come up but Oracle is well prepared because these things are usually discussed by the Technical team and the higher managment Achilles: Okay. That's cool. Is there someone I might contact about this specific issue? Neha: what is the issue that you are facing? Achilles: Well, the issue is that if I upgrade my 2,500+ network computers to Java_1.6.0_21, will my developers not be able to use the Eclipse IDE? Neha: Miller there will not be ny such issue that you will face although if for any reason you do Eclipse will take care of it Achilles: Alright then! I will do the upgrade. Thanks for your time. Neha: not a problem...thanks for reaching out to us
Achilles, I am not sure I understand the purpose of your post. The short term issue has been resolved. See Comment 104. The only version of u21 that is getting pushed out by the upgrade process is b07 which Eclipse will not have any problem with. The only people who will experience problems and will need a workaround are those who manually installed u21-b06, which was never pushed out via automatic update and is no longer available. At this point, this bug tracks longer-term work to improve Eclipse launcher JVM detection in preparation for Java 7 release, which will include the branding changes that caused problems in u21. That should not affect any users right now.
Perhaps this bug should be marked as fixed since short-term compatibility was resolved via a change in u21-b07 and the long-term launcher changes are tracked by Bug 320005.
(In reply to comment #113) > Perhaps this bug should be marked as fixed +1, and update http://wiki.eclipse.org/FAQ_How_do_I_run_Eclipse%3F#Oracle.2FSun_VM_1.6.0_21_on_Windows to reference reinstalling Java 6u21 as the one and only recommended workaround for now. We'll likely need a similar FAQ entry for old Eclipse installs when Java 7 ships though. Does anybody know when Java 7 is scheduled to ship?
(In reply to comment #114) > Does anybody know when Java 7 is scheduled to ship? From http://openjdk.java.net/projects/jdk7/milestones M10 2010/07/23 – 2010/09/09 (b110) 7 builds The last scheduled milestone cycle will be followed by a test and stabilization period of indeterminate length, after which the final release will be declared.
Guys Since I raised bug 319752, I've been following most of the posts here with interest since after years of programming in Delphi, I'm trying to move over to java. Eclipse came with high recommendations, but to be honest I'm a little disillusioned here! I have a machine running Vists Business, there's nothing weird installed (well other than Delphi of course!) just the usual mish-mash of corporate stuff. I've installed the latest Eclipse Helios, Java u21, Maven 2; there's also TFS Team Explorer and it's plug-in for Eclipse (Team Explorer Everywhere). All I need do is a couple of edits, or click on menus, or something similar and Eclipse grinds to a halt! Task Manager reveals that javaw.exe has 50% cpu usage (on a dual-core processor this is like 100% usage!). Wait a few seconds and then Eclipse rudely disappears! No warnings, error messages or anything, it just vanishes taking javaw with it. This is my command line (by reading through 319514 and related posts) <Eclipse Folder>\eclipse.exe --launcher.XXMaxPermSize 256m -vm "<java folder>\bin\javaw.exe" -vmargs -Xms40m -Xmx512m This is my Eclipse.ini: -startup plugins/org.eclipse.equinox.launcher_1.1.0.v20100507.jar --launcher.library plugins/org.eclipse.equinox.launcher.win32.win32.x86_1.1.0.v20100503 -product org.eclipse.epp.package.java.product --launcher.defaultAction openFile --launcher.XXMaxPermSize 256M -showsplash org.eclipse.platform --launcher.XXMaxPermSize 256m --launcher.defaultAction openFile -vmargs -Dosgi.requiredJavaVersion=1.5 -Xms40m -Xmx384m Regards Ali
(In reply to comment #116) > Guys > Since I raised bug 319752, I've been following most of the posts here with > interest since after years of programming in Delphi, I'm trying to move over to > java. Eclipse came with high recommendations, but to be honest I'm a little > disillusioned here! > I have a machine running Vists Business, there's nothing weird installed (well > other than Delphi of course!) just the usual mish-mash of corporate stuff. I've > installed the latest Eclipse Helios, Java u21, Maven 2; there's also TFS Team > Explorer and it's plug-in for Eclipse (Team Explorer Everywhere). > All I need do is a couple of edits, or click on menus, or something similar and > Eclipse grinds to a halt! Task Manager reveals that javaw.exe has 50% cpu usage > (on a dual-core processor this is like 100% usage!). Wait a few seconds and > then Eclipse rudely disappears! No warnings, error messages or anything, it > just vanishes taking javaw with it. > This is my command line (by reading through 319514 and related posts) > <Eclipse Folder>\eclipse.exe --launcher.XXMaxPermSize 256m -vm "<java > folder>\bin\javaw.exe" -vmargs -Xms40m -Xmx512m > This is my Eclipse.ini: > -startup > plugins/org.eclipse.equinox.launcher_1.1.0.v20100507.jar > --launcher.library > plugins/org.eclipse.equinox.launcher.win32.win32.x86_1.1.0.v20100503 > -product > org.eclipse.epp.package.java.product > --launcher.defaultAction > openFile > --launcher.XXMaxPermSize > 256M > -showsplash > org.eclipse.platform > --launcher.XXMaxPermSize > 256m > --launcher.defaultAction > openFile > -vmargs > -Dosgi.requiredJavaVersion=1.5 > -Xms40m > -Xmx384m > Regards > Ali If your JVM or JDK is JVM 1.6u21, try uninstalling the JDK or JRE, downloading the newest version of JDK 1.6u21, installing the JDK, and then trying again. I think that Oracle should have increased the version number for such a bug fix.
#it is a big problem . i doubt the aptana studio has a problem . Now i know it is caused by jre(sun/oracle) ... in windows 32bit
> > I have opened enhancement request: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6969945 > to make the default value for maxPermSpace larger or smarter. > Seems to me users should not have to specify it at all, unless they purposely > want to change characteristics of garbage collection. But, it is still in an > invisible "triage" state ... after a week ... perhaps because its an > enhancement request, instead of a bug. > It the process of cleaning up my mail inbox, I have noticed that the bug I opened http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6969945 never has become "visible". I guess that means still not triaged, not accepted ... or, that I did something wrong in the submission. I still think the only true fix for this issue is to fix it on the VM side, so that max permgen space is not needed to be specified up front, or at least the default it made larger. But, I'll let others pursue that, if they can. (Martin and Ian seem to have good luck, hint hint :) But seriously, just wanted to document that my earlier statement in comment #94 that a "bug has been submitted for future improvements" is not completely accurate. Thanks,
(In reply to comment #119) > It the process of cleaning up my mail inbox, I have noticed that the bug I > opened > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6969945 > never has become "visible". I guess that means still not triaged, not accepted > ... or, that I did something wrong in the submission. Hi David, it happened more than once to me that some bugs of mine where never made visible, although confirmed. They say that some bugs are kept hidden if they are security bugs, but I have experience of some non-security bugs never made visible. I really don't know what is their actual policy for this, IMHO it's annoying... Mauro.
hi all, I am fasing a freeze problem after sharing my projects to svn and cutting connection to network. Eclipse is helios java version : java version "1.6.0_11" if, i connect to network or i disconnect from svn, then everything becomes fine. Is it generic problem of Helios with svn ? tx
(In reply to comment #121) > I am fasing a freeze problem after sharing my projects to svn and cutting > connection to network. Serkan, please open a _new_ bug with the Subversive or Subclipse teams (whichever plug-in you happen to be using) as your problem does not appear to be related to this bug.
This bug still exists with Java 1.6.0_21-b07 and eclipse 3.5.2. Unfortunately, this is the only version of Eclipse we can use as it is the latest version Adobe supports (with the flash builder plugin). Is there any word on if this bug will be fixed?
(In reply to comment #123) > This bug still exists with Java 1.6.0_21-b07 and eclipse 3.5.2. Unfortunately, > this is the only version of Eclipse we can use as it is the latest version > Adobe supports (with the flash builder plugin). > > Is there any word on if this bug will be fixed? Then you probably see a different bug.
(In reply to comment #119) > ... just wanted to document that my earlier statement in comment #94 > that a "bug has been submitted for future improvements" is not completely > accurate. Just to give an update, the bug I opened was triaged and made publically visible: See http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6969945 Even a better sign (maybe) is it was listed as "related to" a bug that seems to imply some work is going on to fix this issue in Sun/Oracle VM at its root causes (changing some of the fundamental ways "permgen" memory works ... if I understand it at all). See http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6964458 (It also list several other related bugs). So, seems maybe there is some hope it won't be an issue in future versions of their VM and Eclipse will no longer need to work around the maxpermsize default values.
Just for closure ... I'm resolving this bug, since no more work is going on here from Eclipse side. But I'll remind interested readers to see the "depends on" bugs to see where work was done to minimize this issue, and hopefully work around it in the future (if still needed) such as bug 320005. Greatest thanks to everyone involved, in getting past this.
SPAM removed by droy 2014-02-02
