Eclipse的最佳JVM设置是什么? [英] What are the best JVM settings for Eclipse?
问题描述
这是一年中的时间再次:eclipse.ini采取3的设置反击!
Eclipse Helios 3.6和3.6.x设置
。
这个想法是能够将独立于任何Eclipse安装的新插件放在一个目录中。
以下部分详细介绍了这个 eclipse.ini
文件。
可怕的Oracle JVM 1.6u21(预构建7)和Eclipse崩溃
的帖子以及错误报告235526 。
我想说的是,安全研究支持更少的提示更好的事实。
人们忽略了弹出一些他们想要完成的东西的流程。
对于3.6,我们不应该在流程的中间弹出警告 - 无论我们简化多少人们只会忽略它们。
相反,我们应该收集所有的问题,不要安装这些捆绑的问题,而是将用户带回工作流程他们可以修复 - 添加信任,更宽松地配置安全策略等。这被称为 安全分期 。
---------- http://www.eclipse.org/home/categories/images/wiki .gif alt text http://www.eclipse.org/home/categories/images/wiki.gif alt text http://www.eclipse.org/home/categories/ images / wiki.gif
附加选项
这些选项不是直接在 eclipse.ini
以上,但如果需要可以派上用场。
Windows7上的user.home问题
当eclipse启动时,它将读取其密钥库文件(密码保存在哪里),位于 user.home
。
如果由于某种原因, user.home
不能正确解析为全文, flave路径,Eclipse不会启动。
最初在这个SO问题,如果你体验到这个,你需要重新定义密钥库文件到一个明确的路径(没有更多的user.home在开始时解决)
添加到您的 eclipse.ini
:
-eclipse.keyring
C:\eclipse\keyring.txt
这已被 bug 300577 ,它已经在这个。
调试模式
等待Eclipse中有多个设置文件。
如果添加到您的 eclipse.ini
选项:
-debug
,您启用调试模式,Eclipse将寻找另一个设置文件:一个 .options
文件,您可以在其中指定一些OSGI选项。
这是非常好的,当你通过添加新的插件dropins文件夹。
在.options文件中添加以下设置,如 blog post Dropins diagnosis :
org.eclipse.equinox.p2.core / debug = true
org.eclipse.equinox.p2.core / reconciler = true
P2将通知您在
dropins /
文件夹中找到了什么包,生成了什么请求,以及什么安装计划也许这不是对实际发生的事情的详细解释,出了什么问题,但是应该给出关于从哪里开始的强有力的信息:
- 是你的计划中的捆绑?
- 是否安装问题(P2故障)
- 或者是否包含您的功能不是最佳的?
来自 Bug 264924 - [reconciler]没有诊断滴漏问题,最终解决了以下问题:
将$ eclipse-SDK-3.5M5-win32.zip解压到... / eclipse
将zip文件解压缩到... / eclipse / dropins / mdt-ocl-SDK-1.3.0M5
这是一个有问题的配置因为OCL依赖于缺少的EMF。
3.5M5不提供此问题的诊断。
启动eclipse。
没有明显的问题。
帮助/关于/插件
详细信息显示org.eclipse.ocl.doc
,但不是org.eclipse.ocl
。
帮助/关于/配置
详细信息没有(诊断)提及
org.eclipse.ocl
。 / li>
帮助/安装/信息安装软件
没有提到org.eclipse.ocl
。
哪里有漂亮的错误标记?
清单类路径
看到这个 blog post :
- 在Galileo(又名Eclipse 3.5)中,JDT开始在添加到项目构建路径的库中解析manifest类路径。无论库直接添加到项目的构建路径还是通过类路径容器(如JDT提供的用户库设施或由第三方实现的)
- 在Helios中,此行为已更改,以从清单类路径解析中排除类路径容器。
这意味着您的一些项目可能不再在Helios中编译。
如果要恢复为伽利略行为,请添加:
-DresolveReferencedLibrariesForContainers = true
请参阅 bug 305037 , bug 313965 和错误313890 ,供参考。
IPV4堆栈
这个 SO问题在不访问插件更新站点时提到了一个潜在的修复:
-Djava.net.preferIPv4Stack = true
在这里提到,以防万一可以吗您的配置中的lp。
JVM1.7x64潜在优化
本文报告:
对于记录来说,迄今为止,我使用1.7 x64 JVM n Windows进行的测试中发现的最快的选项是:
-Xincgc
-XX:-DontCompileHugeMethods
-XX :MaxInlineSize = 1024
-XX:FreqInlineSize = 1024
但我仍在努力...
What are the best JVM settings you have found for running Eclipse?
It is that time of year again: "eclipse.ini take 3" the settings strike back!
Eclipse Helios 3.6 and 3.6.x settings
alt text http://www.eclipse.org/home/promotions/friends-helios/helios.png
After settings for Eclipse Ganymede 3.4.x and Eclipse Galileo 3.5.x, here is an in-depth look at an "optimized" eclipse.ini settings file for Eclipse Helios 3.6.x:
- based on runtime options,
- and using the Sun-Oracle JVM 1.6u21 b7, released July, 27th (
some some Sun proprietary options may be involved).
(by "optimized", I mean able to run a full-fledge Eclipse on our crappy workstation at work, some old P4 from 2002 with 2Go RAM and XPSp3. But I have also tested those same settings on Windows7)
Eclipse.ini
WARNING: for non-windows platform, use the Sun proprietary option -XX:MaxPermSize
instead of the Eclipse proprietary option --launcher.XXMaxPermSize
.
That is: Unless you are using the latest jdk6u21 build 7.
See the Oracle section below.
-data
../../workspace
-showlocation
-showsplash
org.eclipse.platform
--launcher.defaultAction
openFile
-vm
C:/Prog/Java/jdk1.6.0_21/jre/bin/server/jvm.dll
-vmargs
-Dosgi.requiredJavaVersion=1.6
-Declipse.p2.unsignedPolicy=allow
-Xms128m
-Xmx384m
-Xss4m
-XX:PermSize=128m
-XX:MaxPermSize=384m
-XX:CompileThreshold=5
-XX:MaxGCPauseMillis=10
-XX:MaxHeapFreeRatio=70
-XX:+CMSIncrementalPacing
-XX:+UnlockExperimentalVMOptions
-XX:+UseG1GC
-XX:+UseFastAccessorMethods
-Dcom.sun.management.jmxremote
-Dorg.eclipse.equinox.p2.reconciler.dropins.directory=C:/Prog/Java/eclipse_addons
Note:
Adapt the p2.reconciler.dropins.directory
to an external directory of your choice.
See this SO answer.
The idea is to be able to drop new plugins in a directory independently from any Eclipse installation.
The following sections detail what are in this eclipse.ini
file.
The dreaded Oracle JVM 1.6u21 (pre build 7) and Eclipse crashes
Andrew Niefer did alert me to this situation, and wrote a blog post, about a non-standard vm argument (-XX:MaxPermSize
) and can cause vms from other vendors to not start at all.
But the eclipse version of that option (--launcher.XXMaxPermSize
) is not working with the new JDK (6u21, unless you are using the 6u21 build 7, see below).
The final solution is on the Eclipse Wiki, and for Helios on Windows with 6u21 pre build 7 only:
- downloading the fixed eclipse_1308.dll (July 16th, 2010)
- and place it into
(eclipse_home)/plugins/org.eclipse.equinox.launcher.win32.win32.x86_1.1.0.v20100503
That's it. No setting to tweak here (again, only for Helios on Windows with a 6u21 pre build 7).
For non-Windows platform, you need to revert to the Sun proprietary option -XX:MaxPermSize
.
The issue is based one a regression: JVM identification fails due to Oracle rebranding in java.exe, and triggered bug 319514 on Eclipse.
Andrew took care of Bug 320005 - [launcher] --launcher.XXMaxPermSize: isSunVM
should return true for Oracle, but that will be only for Helios 3.6.1.
Francis Upton, another Eclipse committer, reflects on the all situation.
Update u21b7, July, 27th:
Oracle have regressed the change for the next Java 6 release and won't implement it again until JDK 7.
If you use jdk6u21 build 7, you can revert to the --launcher.XXMaxPermSize
(eclipse option) instead of -XX:MaxPermSize
(the non-standard option).
The auto-detection happening in the C launcher shim eclipse.exe
will still look for the "Sun Microsystems
" string, but with 6u21b7, it will now work - again.
For now, I still keep the -XX:MaxPermSize
version (because I have no idea when everybody will launch eclipse the right JDK).
Implicit `-startup` and `--launcher.library`
Contrary to the previous settings, the exact path for those modules is not set anymore, which is convenient since it can vary between different Eclipse 3.6.x releases:
- startup: If not specified, the executable will look in the plugins directory for the
org.eclipse.equinox.launcher
bundle with the highest version. - launcher.library: If not specified, the executable looks in the
plugins
directory for the appropriateorg.eclipse.equinox.launcher.[platform]
fragment with the highest version and uses the shared library namedeclipse_*
inside.
Use JDK6
The JDK6 is now explicitly required to launch Eclipse:
-Dosgi.requiredJavaVersion = 1.6
This SO question reports a positive incidence for development on Mac OS.
+UnlockExperimentalVMOptions
The following options are part of some of the experimental options of the Sun JVM.
-XX:+UnlockExperimentalVMOptions
-XX:+UseG1GC
-XX:+UseFastAccessorMethods
They have been reported in this blog post to potentially speed up Eclipse.
See all the JVM options here and also in the official Java Hotspot options page.
Note: the detailed list of those options reports that UseFastAccessorMethods
might be active by default.
See also "Update your JVM":
As a reminder, G1 is the new garbage collector in preparation for the JDK 7, but already used in the version 6 release from u17.
Opening files in Eclipse from the command line
See the blog post from Andrew Niefer reporting this new option:
--launcher.defaultAction
openFile
This tells the launcher that if it is called with a command line that only contains arguments that don't start with "
-
", then those arguments should be treated as if they followed "--launcher.openFile
".
eclipse myFile.txt
This is the kind of command line the launcher will receive on windows when you double click a file that is associated with eclipse, or you select files and choose "
Open With
" or "Send To
" Eclipse.Relative paths will be resolved first against the current working directory, and second against the eclipse program directory.
See bug 301033 for reference. Originally bug 4922 (October 2001, fixed 9 years later).
p2 and the Unsigned Dialog Prompt
If you are tired of this dialog box during the installation of your many plugins:
, add in your eclipse.ini
:
-Declipse.p2.unsignedPolicy=allow
See this blog post from Chris Aniszczy, and the bug report 235526.
I do want to say that security research supports the fact that less prompts are better.
People ignore things that pop up in the flow of something they want to get done.For 3.6, we should not pop up warnings in the middle of the flow - no matter how much we simplify, people will just ignore them.
Instead, we should collect all the problems, do not install those bundles with problems, and instead bring the user back to a point in the workflow where they can fixup - add trust, configure security policy more loosely, etc. This is called 'safe staging'.
---------- http://www.eclipse.org/home/categories/images/wiki.gif alt text http://www.eclipse.org/home/categories/images/wiki.gif alt text http://www.eclipse.org/home/categories/images/wiki.gif
Additional options
Those options are not directly in the eclipse.ini
above, but can come in handy if needed.
The `user.home` issue on Windows7
When eclipse starts, it will read its keystore file (where passwords are kept), a file located in user.home
.
If for some reason that user.home
doesn't resolve itself properly to a full-fledge path, Eclipse won't start.
Initially raised in this SO question, if you experience this, you need to redefine the keystore file to an explicit path (no more user.home to resolve at the start)
Add in your eclipse.ini
:
-eclipse.keyring
C:\eclipse\keyring.txt
This has been tracked by bug 300577, it has been solve in this other SO question.
Debug mode
Wait, there's more than one setting file in Eclipse.
if you add to your eclipse.ini
the option:
-debug
, you enable the debug mode and Eclipse will look for another setting file: a .options
file where you can specify some OSGI options.
And that is great when you are adding new plugins through the dropins folder.
Add in your .options file the following settings, as described in this blog post "Dropins diagnosis":
org.eclipse.equinox.p2.core/debug=true
org.eclipse.equinox.p2.core/reconciler=true
P2 will inform you what bundles were found in
dropins/
folder, what request was generated, and what is the plan of installation. Maybe it is not detailed explanation of what actually happened, and what went wrong, but it should give you strong information about where to start:
- was your bundle in the plan?
- Was it installation problem (P2 fault)
- or maybe it is just not optimal to include your feature?
That comes from Bug 264924 - [reconciler] No diagnosis of dropins problems, which finally solves the following issue like:
Unzip eclipse-SDK-3.5M5-win32.zip to ..../eclipse
Unzip mdt-ocl-SDK-1.3.0M5.zip to ..../eclipse/dropins/mdt-ocl-SDK-1.3.0M5
This is a problematic configuration since OCL depends on EMF which is missing.
3.5M5 provides no diagnosis of this problem.Start eclipse.
No obvious problems. Nothing in Error Log.
Help / About / Plugin
details showsorg.eclipse.ocl.doc
, but notorg.eclipse.ocl
.Help / About / Configuration
details has no (diagnostic) mention oforg.eclipse.ocl
.Help / Installation / Information Installed Software
has no mention oforg.eclipse.ocl
.Where are the nice error markers?
Manifest Classpath
See this blog post:
- In Galileo (aka Eclipse 3.5), JDT started resolving manifest classpath in libraries added to project’s build path. This worked whether the library was added to project’s build path directly or via a classpath container, such as the user library facility provided by JDT or one implemented by a third party.
- In Helios, this behavior was changed to exclude classpath containers from manifest classpath resolution.
That means some of your projects might no longer compile in Helios.
If you want to revert to Galileo behavior, add:
-DresolveReferencedLibrariesForContainers=true
See bug 305037, bug 313965 and bug 313890 for references.
IPV4 stack
This SO question mentions a potential fix when not accessing to plugin update sites:
-Djava.net.preferIPv4Stack=true
Mentioned here just in case it could help in your configuration.
JVM1.7x64 potential optimizations
This article reports:
For the record, the very fastest options I have found so far for my bench test with the 1.7 x64 JVM n Windows are:
-Xincgc
-XX:-DontCompileHugeMethods
-XX:MaxInlineSize=1024
-XX:FreqInlineSize=1024
But I am still working on it...
这篇关于Eclipse的最佳JVM设置是什么?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!