Quels sont les meilleurs paramètres JVM que vous ayez trouvés pour exécuter Eclipse?
Quels sont les meilleurs paramètres JVM que vous ayez trouvés pour exécuter Eclipse?
Réponses:
C'est encore cette période de l'année: "eclipse.ini take 3" les paramètres sont de retour!
texte alternatif http://www.eclipse.org/home/promotions/friends-helios/helios.png
Une fois les paramètres pour Eclipse Ganymede 3.4.x et Eclipse Galileo 3.5.x , voici un regard en profondeur sur un « optimisé » eclipse.ini fichier de paramètres pour Eclipse Helios 3.6.x:
( par "optimisé", je veux dire capable d'exécuter une Eclipse à part entière sur notre station de travail de merde au travail, un vieux P4 de 2002 avec 2Go de RAM et XPSp3. Mais j'ai également testé ces mêmes paramètres sur Windows7 )
AVERTISSEMENT : pour les plates-formes non Windows, utilisez l'option propriétaire Sun -XX:MaxPermSize
au lieu de l'option propriétaire Eclipse --launcher.XXMaxPermSize
.
C'est-à-dire: à moins que vous n'utilisiez la dernière version 7 de jdk6u21 . Voir la section Oracle ci-dessous.
-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
Remarque:
adaptez le p2.reconciler.dropins.directory
à un répertoire externe de votre choix.
Voir cette réponse SO . L'idée est de pouvoir déposer de nouveaux plugins dans un répertoire indépendamment de toute installation Eclipse.
Les sections suivantes détaillent le contenu de ce eclipse.ini
fichier.
Andrew Niefer m'a alerté de cette situation et a écrit un article de blog sur un argument vm non standard ( -XX:MaxPermSize
) et peut empêcher les vms d'autres fournisseurs de démarrer.
Mais la version éclipse de cette option ( --launcher.XXMaxPermSize
) ne fonctionne pas avec le nouveau JDK (6u21, sauf si vous utilisez la version 7 de 6u21, voir ci-dessous).
le finalLa solution se trouve sur le wiki Eclipse , et pour Helios sur Windows avec 6u21 pre build 7 uniquement:
(eclipse_home) /plugins/org.eclipse.equinox.launcher.win32.win32.x86_1.1.0.v20100503
C'est tout. Aucun paramètre à modifier ici (encore une fois, uniquement pour Helios sur Windows avec une pré-version 6u21 7 ).
Pour la plate - forme non-Windows, vous devez revenir à l'option exclusive dim. -XX:MaxPermSize
.
Le problème est basé sur une régression: l' identification JVM échoue en raison du changement de marque Oracle dans java.exe et a déclenché le bogue 319514 sur Eclipse.
Andrew s'est occupé du bug 320005 - [lanceur] --launcher.XXMaxPermSize: isSunVM
devrait retourner vrai pour Oracle , mais ce ne sera que pour Helios 3.6.1.
Francis Upton , un autre committer d'Eclipse, réfléchit à la situation .
Mise à jour u21b7, 27 juillet :
Oracle a régressé la modification pour la prochaine version de Java 6 et ne l'implémentera plus avant JDK 7 .
Si vous utilisez jdk6u21 build 7 , vous pouvez revenir à --launcher.XXMaxPermSize
(option eclipse) au lieu de -XX:MaxPermSize
(option non standard).
La détection automatique qui se produit dans la cale du lanceur Ceclipse.exe
cherchera toujours la Sun Microsystems
chaîne " ", mais avec 6u21b7, cela fonctionnera à nouveau.
Pour l'instant, je garde toujours la -XX:MaxPermSize
version (car je ne sais pas quand tout le monde lancera eclipse le bon JDK).
Contrairement aux paramètres précédents, le chemin exact de ces modules n'est plus défini, ce qui est pratique car il peut varier entre les différentes versions d'Eclipse 3.6.x:
org.eclipse.equinox.launcher
bundle avec la version la plus élevée.plugins
répertoire le org.eclipse.equinox.launcher.[platform]
fragment approprié avec la version la plus élevée et utilise la bibliothèque partagée nommée à l' eclipse_*
intérieur.Le JDK6 est désormais explicitement requis pour lancer Eclipse:
-Dosgi.requiredJavaVersion = 1.6
Cette question SO rapporte une incidence positive pour le développement sur Mac OS.
Les options suivantes font partie de certaines des options expérimentales de la JVM Sun.
-XX:+UnlockExperimentalVMOptions
-XX:+UseG1GC
-XX:+UseFastAccessorMethods
Ils ont été signalés dans ce blog pour potentiellement accélérer Eclipse.
Voir toutes les options JVM ici et également sur la page d'options Java Hotspot officielle .
Remarque: la liste détaillée des rapports d' options qui UseFastAccessorMethods
peuvent être actifs par défaut.
Voir aussi "Mettre à jour votre JVM" :
Pour rappel, G1 est le nouveau garbage collector en préparation du JDK 7, mais déjà utilisé dans la version 6 de u17.
Voir le blog d'Andrew Niefer rapportant cette nouvelle option:
--launcher.defaultAction
openFile
Cela indique au lanceur que s'il est appelé avec une ligne de commande qui ne contient que des arguments qui ne commencent pas par "
-
", alors ces arguments doivent être traités comme s'ils suivaient "--launcher.openFile
".
eclipse myFile.txt
C'est le type de ligne de commande que le lanceur recevra sur Windows lorsque vous double-cliquez sur un fichier associé à eclipse, ou que vous sélectionnez des fichiers et choisissez "
Open With
" ou "Send To
" Eclipse.Les chemins relatifs seront d'abord résolus par rapport au répertoire de travail actuel et ensuite par rapport au répertoire du programme eclipse.
Voir bug 301033 pour référence. Initialement bug 4922 (octobre 2001, corrigé 9 ans plus tard).
Si vous en avez assez de cette boîte de dialogue lors de l'installation de vos nombreux plugins:
, ajoutez votre eclipse.ini
:
-Declipse.p2.unsignedPolicy=allow
Voir cet article de blog de Chris Aniszczy et le rapport de bogue 235526 .
Je tiens à dire que la recherche sur la sécurité confirme le fait que moins de messages sont meilleurs.
Les gens ignorent les choses qui surgissent dans le flux de quelque chose qu'ils veulent faire.Pour la 3.6, nous ne devrions pas afficher d'avertissements au milieu du flux - peu importe combien nous simplifions, les gens les ignoreront.
Au lieu de cela, nous devons collecter tous les problèmes, ne pas installer ces bundles avec des problèmes et ramener l'utilisateur à un point du flux de travail où il peut corriger - ajouter de la confiance, configurer la politique de sécurité de manière plus lâche, etc. Cela s'appelle `` sûr mise en scène » .
---------- http://www.eclipse.org/home/categories/images/wiki.gif texte alternatif http://www.eclipse.org/home/categories/images/wiki.gif texte alternatif http://www.eclipse.org/home/categories/images/wiki.gif
Ces options ne sont pas directement décrites eclipse.ini
ci - dessus, mais peuvent être utiles si nécessaire.
Lorsque eclipse démarre, il lit son fichier de clés (où les mots de passe sont conservés), un fichier situé dans user.home
.
Si pour une raison qui user.home
ne se résout pas correctement en un chemin complet, Eclipse ne démarre pas.
Initialement soulevé dans cette question SO , si vous rencontrez ce problème , vous devez redéfinir le fichier de clés sur un chemin explicite (plus de user.home à résoudre au début)
Ajoutez votre eclipse.ini
:
-eclipse.keyring
C:\eclipse\keyring.txt
Cela a été suivi par le bug 300577 , il a été résolu dans cette autre question SO .
Attendez, il y a plus d'un fichier de paramètres dans Eclipse.
si vous ajoutez à votre eclipse.ini
option:
-debug
, vous activez le mode de débogage et Eclipse recherchera un autre fichier de paramètres: un .options
fichier dans lequel vous pourrez spécifier certaines options OSGI.
Et c'est génial lorsque vous ajoutez de nouveaux plugins via le dossier dropins.
Ajoutez dans votre fichier .options les paramètres suivants, comme décrit dans cet article de blog " Diagnostic Dropins " :
org.eclipse.equinox.p2.core/debug=true
org.eclipse.equinox.p2.core/reconciler=true
P2 vous informera quels bundles ont été trouvés dans le
dropins/
dossier, quelle demande a été générée et quel est le plan d'installation. Ce n'est peut-être pas une explication détaillée de ce qui s'est réellement passé et de ce qui n'a pas fonctionné, mais cela devrait vous donner des informations solides sur le point de départ:
- était votre paquet dans le plan?
- Était-ce un problème d'installation (défaut P2)
- ou peut-être qu'il n'est tout simplement pas optimal d'inclure votre fonctionnalité?
Cela vient du bogue 264924 - [réconciliateur] Aucun diagnostic de problèmes de dropins , ce qui résout finalement le problème suivant comme:
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
Il s'agit d'une configuration problématique car OCL dépend d'EMF qui est manquant.
3.5M5 ne fournit aucun diagnostic de ce problème.Démarrez l'éclipse.
Pas de problèmes évidents. Rien dans le journal des erreurs.
Help / About / Plugin
les détails montrentorg.eclipse.ocl.doc
, mais pasorg.eclipse.ocl
.Help / About / Configuration
les détails n'ont aucune mention (diagnostique)org.eclipse.ocl
.Help / Installation / Information Installed Software
n'a aucune mention deorg.eclipse.ocl
.Où sont les jolis marqueurs d'erreur?
Voir cet article de blog :
- Dans Galileo (alias Eclipse 3.5), JDT a commencé à résoudre le chemin de classe manifeste dans les bibliothèques ajoutées au chemin de génération du projet. Cela a fonctionné que la bibliothèque ait été ajoutée au chemin de génération du projet directement ou via un conteneur de chemin de classe, tel que la bibliothèque utilisateur fournie par JDT ou implémentée par un tiers.
- Dans Helios, ce comportement a été modifié pour exclure les conteneurs de chemin de classe de la résolution du chemin de classe manifeste.
Cela signifie que certains de vos projets pourraient ne plus être compilés dans Helios.
Si vous souhaitez revenir au comportement de Galileo, ajoutez:
-DresolveReferencedLibrariesForContainers=true
Voir bug 305037 , bug 313965 et bug 313890 pour les références.
Cette question SO mentionne un correctif potentiel lorsque vous n'accédez pas aux sites de mise à jour des plugins:
-Djava.net.preferIPv4Stack=true
Mentionné ici juste au cas où cela pourrait aider dans votre configuration.
Cet article rapporte:
Pour mémoire, les options les plus rapides que j'ai trouvées jusqu'à présent pour mon test de banc avec la JVM 1.7 x64 n Windows sont:
-Xincgc
-XX:-DontCompileHugeMethods
-XX:MaxInlineSize=1024
-XX:FreqInlineSize=1024
Mais j'y travaille toujours ...
-XX:CompileThreshold=5
provoque des ralentissements HORRENDOUS pour moi. Se débarrasser de cette seule option a réduit mon temps de démarrage d'Eclipse à 17 secondes de> 1 min !! Sans parler de la lenteur de l'IDE en général. Voir ce lien
-XX:CompileThreshold=5
est une valeur très faible (par défaut = 10000). Cette valeur représente le nombre d'appels / branches de méthode avant de le compiler. Une valeur trop faible entraînera le remplissage prématuré de votre CodeCache et la console peut signaler: CodeCache is full. Compiler has been disabled
Une fois le compilateur désactivé, vous remarquerez une lenteur dans l'application. Il existe deux façons de résoudre ce problème: 1. Utilisez -XX:CompileThreshold=1000
(affinez ce nombre) ou 2. Essayez d'augmenter la taille du cache de code à l'aide de -XX:ReservedCodeCacheSize=64m
(doubler par rapport aux 32 m par défaut)
Actuellement (novembre 2009), je teste avec jdk6 update 17 le jeu d'options de configuration suivant (avec Galileo - eclipse 3.5.x, voir ci - dessous pour 3.4 ou supérieur pour Helios 3.6.x ):
(bien sûr, adaptez les chemins relatifs présent dans ce eclipse.ini aux chemins corrects pour votre configuration)
Remarque: pour eclipse3.5 , remplacez startup
et launcher.library
lignes par:
-startup
plugins/org.eclipse.equinox.launcher_1.0.200.v20090520.jar
--launcher.library
plugins/org.eclipse.equinox.launcher.win32.win32.x86_1.0.200.v20090519
-data
../../workspace
-showlocation
-showsplash
org.eclipse.platform
--launcher.XXMaxPermSize
384m
-startup
plugins/org.eclipse.equinox.launcher_1.0.201.R35x_v20090715.jar
--launcher.library
plugins/org.eclipse.equinox.launcher.win32.win32.x86_1.0.200.v20090519
-vm
../../../../program files/Java/jdk1.6.0_17/jre/bin/client/jvm.dll
-vmargs
-Dosgi.requiredJavaVersion=1.5
-Xms128m
-Xmx384m
-Xss4m
-XX:PermSize=128m
-XX:MaxPermSize=384m
-XX:CompileThreshold=5
-XX:MaxGCPauseMillis=10
-XX:MaxHeapFreeRatio=70
-XX:+UseConcMarkSweepGC
-XX:+CMSIncrementalMode
-XX:+CMSIncrementalPacing
-Dcom.sun.management.jmxremote
-Dorg.eclipse.equinox.p2.reconciler.dropins.directory=C:/jv/eclipse/mydropins
Voir aussi ma réponse originale ci-dessus pour plus d'informations.
org.eclipse.equinox.p2.reconciler.dropins.directory
option.Il y avait un bogue avec des points d'arrêt ignorés réellement liés au JDK.
Utilisez JDK6u16 ou plus récent pour lancer eclipse (Vous pouvez alors définir autant de JDK que vous souhaitez compiler dans eclipse: ce n'est pas parce que vous lancez une éclipse avec JDK6 que vous devrez compiler avec ce même JDK).
Notez l'utilisation de:
--launcher.XXMaxPermSize
384m
-vmargs
-XX:MaxPermSize=128m
Comme documenté dans le Wiki Eclipse ,
Eclipse 3.3 prend en charge un nouvel argument au lanceur:
--launcher.XXMaxPermSize
.
Si la machine virtuelle utilisée est une machine virtuelle Sun et qu'il n'y a pas déjà d'-XX:MaxPermSize=
argument de machine virtuelle, le lanceur s'ajoutera automatiquement-XX:MaxPermSize=256m
à la liste des arguments de machine virtuelle utilisés.
Le lanceur 3.3 est uniquement capable d'identifier les machines virtuelles Sun sous Windows.
Comme détaillé dans cette entrée :
Tous les vms n'acceptent pas l'
-XX:MaxPermSize
argument, c'est pourquoi il est transmis de cette manière. Il peut (ou non) exister des problèmes d'identification des rayons solaires.
Remarque: Eclipse 3.3.1 a un bogue dans lequel le lanceur ne peut pas détecter une machine virtuelle Sun et n'utilise donc pas la taille PermGen correcte. Il semble que cela ait également été un bogue connu sur Mac OS X pour 3.3.0 .
Si vous utilisez l'une de ces combinaisons de plates-formes, ajoutez l'-XX
indicateur aueclipse.ini
comme décrit ci-dessus.Remarques:
- la
384m
ligne " " se traduit par la "=384m
" partie de l'argument VM, si la VM est sensible à la casse sur "m
", alors cet argument l'est aussi.- le
--launcher.
préfixe " ", cela spécifie que l'argument est consommé par le lanceur lui-même et a été ajouté aux arguments spécifiques du lanceur pour éviter les collisions de noms avec les arguments d'application. (D'autres exemples sont--launcher.library
,--launcher.suppressErrors
)La
-vmargs -XX:MaxPermSize=384m
partie est l'argument transmis directement à la machine virtuelle, contournant entièrement le lanceur et aucun contrôle sur le fournisseur de la machine virtuelle n'est utilisé.
Pour les paramètres plus récents, voir Paramètres Eclipse Galileo 3.5 ci-dessus .
Le meilleur réglage JVM toujours , à mon avis, comprend la dernière JDK vous pouvez trouver (donc pour l' instant, jdk1.6.0_b07 jusqu'à B16, sauf B14 et B15 )
Même avec ces paramètres de mémoire assez bas, je peux exécuter de grands projets Java (avec un serveur Web) sur mon ancien bureau (2002) avec 2 Go de RAM.
-showlocation
-showsplash
org.eclipse.platform
--launcher.XXMaxPermSize
256M
-framework
plugins\org.eclipse.osgi_3.4.2.R34x_v20080826-1230.jar
-vm
jdk1.6.0_10\jre\bin\client\jvm.dll
-vmargs
-Dosgi.requiredJavaVersion=1.5
-Xms128m
-Xmx384m
-Xss2m
-XX:PermSize=128m
-XX:MaxPermSize=128m
-XX:MaxGCPauseMillis=10
-XX:MaxHeapFreeRatio=70
-XX:+UseConcMarkSweepGC
-XX:+CMSIncrementalMode
-XX:+CMSIncrementalPacing
-XX:CompileThreshold=5
-Dcom.sun.management.jmxremote
Voir la réponse SO de GKelly et l'entrée de blog de Piotr Gabryanczyk pour plus de détails sur les nouvelles options.
Vous pouvez également envisager de lancer:
C:\[jdk1.6.0_0x path]\bin\jconsole.exe
Comme indiqué dans une question précédente sur la consommation de mémoire .
Paramètres pour Sun / Oracle java version "1.6.0_31" et Eclipse 3.7 fonctionnant sous Linux x86-64:
-nosplash
-vmargs
-Xincgc
-Xss500k
-Dosgi.requiredJavaVersion=1.6
-Xms64m
-Xmx200m
-XX:NewSize=8m
-XX:PermSize=80m
-XX:MaxPermSize=150m
-XX:MaxPermHeapExpansion=10m
-XX:+UseConcMarkSweepGC
-XX:CMSInitiatingOccupancyFraction=70
-XX:+UseCMSInitiatingOccupancyOnly
-XX:+UseParNewGC
-XX:+CMSConcurrentMTEnabled
-XX:ConcGCThreads=2
-XX:ParallelGCThreads=2
-XX:+CMSIncrementalPacing
-XX:CMSIncrementalDutyCycleMin=0
-XX:CMSIncrementalDutyCycle=5
-XX:GCTimeRatio=49
-XX:MaxGCPauseMillis=20
-XX:GCPauseIntervalMillis=1000
-XX:+UseCMSCompactAtFullCollection
-XX:+CMSClassUnloadingEnabled
-XX:+DoEscapeAnalysis
-XX:+UseCompressedOops
-XX:+AggressiveOpts
-XX:+ExplicitGCInvokesConcurrentAndUnloadsClasses
Notez que cela utilise seulement 200 Mo pour le tas et 150 Mo pour le non-tas. Si vous utilisez d'énormes plugins, vous souhaiterez peut-être augmenter les limites "-Xmx200m" et "-XX: MaxPermSize = 150m".
La cible d'optimisation principale pour ces indicateurs a été de minimiser la latence dans tous les cas et, en tant que cible d'optimisation secondaire, de minimiser l'utilisation de la mémoire.
-location
Pour faciliter l'exécution d'Eclipse deux fois et savoir à quel espace de travail vous avez affaire
Eclipse 3.6 ajoute une option de préférences pour spécifier ce qu'il faut afficher pour ce Workspace name (shown in window title)
qui fonctionne beaucoup mieux que -showlocation
pour trois raisons:
Si vous optez pour la mise à jour 14 de jdk6, je vous suggère d'utiliser le garbage collector G1 qui semble améliorer les performances.
Pour ce faire, supprimez ces paramètres:
-XX: + UseConcMarkSweepGC
-XX: + CMSIncrementalMode
-XX: + CMSIncrementalPacing
et remplacez-les par ceux-ci:
-XX: + UnlockExperimentalVMOptions
-XX: + UseG1GC
Si vous utilisez Linux + Sun JDK / JRE 32bits , remplacez "-vm" par:
-vm
[your_jdk_folder]/jre/lib/i386/client/libjvm.so
Si vous utilisez Linux + Sun JDK / JRE 64bits , remplacez "-vm" par:
-vm
[your_jdk_folder]/jre/lib/amd64/server/libjvm.so
Cela fonctionne bien pour moi sur Ubuntu 8.10 et 9.04
Vous pouvez également essayer de courir avec JRockit . C'est une machine virtuelle Java optimisée pour les serveurs, mais de nombreuses applications clientes de longue durée, comme les IDE, fonctionnent très bien sur JRockit. Eclipse ne fait pas exception. JRockit n'a pas d'espace permanent, vous n'avez donc pas besoin de le configurer.
Il est possible de définir un objectif de temps de pause (ms) pour éviter de longues pauses gc bloquant l'interface utilisateur.
-showsplash
org.eclipse.platform
-vm
C:\jrmc-3.1.2-1.6.0\bin\javaw.exe
-vmargs
-XgcPrio:deterministic
-XpauseTarget:20
Je ne prends généralement pas la peine de définir -Xmx et -Xms et de laisser JRockit agrandir le tas comme il le juge nécessaire. Si vous lancez votre application Eclipse avec JRockit, vous pouvez également surveiller, profiler et trouver des fuites de mémoire dans votre application à l'aide de la suite d'outils JRockit Mission Control. Vous téléchargez les plugins depuis ce site de mise à jour . Remarque, ne fonctionne que pour Eclipse 3.3 et Eclipse 3.4
Voici mon propre paramètre pour mon Eclipse fonctionnant sur un ordinateur portable i7 2630M 16 Go de RAM, ce paramètre est utilisé depuis une semaine, sans un seul plantage, et Eclipse 3.7 fonctionne correctement.
-startup
plugins/org.eclipse.equinox.launcher_1.2.0.v20110502.jar
--launcher.library
plugins/org.eclipse.equinox.launcher.win32.win32.x86_64_1.1.100.v20110502
-product
org.eclipse.epp.package.jee.product
--launcher.defaultAction
openFile
--launcher.XXMaxPermSize
256M
-showsplash
org.eclipse.platform
--launcher.XXMaxPermSize
256m
--launcher.defaultAction
openFile
-vmargs
-Dosgi.requiredJavaVersion=1.5
-Xms1024m
-Xmx4096m
-XX:MaxPermSize=256m
Calculs: pour Win 7 x64
-startup
../../../plugins/org.eclipse.equinox.launcher_1.2.0.v20110502.jar
--launcher.library
../../../plugins/org.eclipse.equinox.launcher.cocoa.macosx_1.1.100.v20110502
-showsplash
org.eclipse.platform
--launcher.XXMaxPermSize
256m
--launcher.defaultAction
openFile
-vmargs
-Xms128m
-Xmx512m
-XX:MaxPermSize=256m
-Xdock:icon=../Resources/Eclipse.icns
-XstartOnFirstThread
-Dorg.eclipse.swt.internal.carbon.smallFonts
-Dcom.sun.management.jmxremote
-Declipse.p2.unsignedPolicy=allow
Et ces paramètres ont fonctionné comme un charme pour moi. J'utilise OS X10.6, Eclipse 3.7 Indigo, JDK1.6.0_24
Mes propres paramètres (Java 1.7, modifier pour 1.6):
-vm
C:/Program Files (x86)/Java/jdk1.7.0/bin
-startup
plugins/org.eclipse.equinox.launcher_1.1.0.v20100507.jar
--launcher.library
plugins/org.eclipse.equinox.launcher.win32.win32.x86_1.1.100.v20100628
-showsplash
org.eclipse.platform
--launcher.XXMaxPermSize
256m
--launcher.defaultAction
openFile
-vmargs
-server
-Dosgi.requiredJavaVersion=1.7
-Xmn100m
-Xss1m
-XgcPrio:deterministic
-XpauseTarget:20
-XX:PermSize=400M
-XX:MaxPermSize=500M
-XX:CompileThreshold=10
-XX:MaxGCPauseMillis=10
-XX:MaxHeapFreeRatio=70
-XX:+UnlockExperimentalVMOptions
-XX:+DoEscapeAnalysis
-XX:+UseG1GC
-XX:+UseFastAccessorMethods
-XX:+AggressiveOpts
-Xms512m
-Xmx512m
Si vous m'aimez et que vous rencontrez des problèmes avec la version Oracle actuelle de 1.6, vous souhaiterez peut-être mettre à jour votre JDK ou définir
-XX: MaxPermSize. Plus d'informations sont disponibles ici: http://java.dzone.com/articles/latest-java-update-fixes
XX: + UseParallelGC c'est l'option la plus impressionnante jamais !!!
-vm
C: \ Program Files \ Java \ jdk1.6.0_07 \ jre \ bin \ client \ jvm.dll
Pour spécifier la version java que vous utilisez et utiliser la DLL au lieu de lancer un processus javaw
eclipse.ini
paramètres améliorés pour Helios 3.6 sont ici (ci-dessous, dans une nouvelle réponse): stackoverflow.com/questions/142357/…