Quels sont les meilleurs paramètres JVM que vous avez trouvés pour exécuter Eclipse?
C’est cette période de l’année: "Eclipse.ini take 3", les réglages sont rétablis!
alt text http://www.Eclipse.org/home/promotions/friends-helios/helios.png
Après les réglages pour Eclipse Ganymede 3.4.x et Eclipse Galileo 3.5.x , voici un aperçu détaillé d'un "optimisé" Eclipse.ini fichier de paramètres pour Eclipse Helios 3.6.x:
(par "optimisé", je veux dire être capable de faire tourner une Eclipse à part entière sur notre station de travail pourrie au travail, un vieux P4 de 2002 avec 2Go RAM et XPSp3. Mais j'ai aussi testé ces mêmes paramètres sur Windows7)
WARNING: pour les plateformes autres que Windows, utilisez l'option propriétaire Sun -XX:MaxPermSize
à la place de l'option propriétaire Eclipse --launcher.XXMaxPermSize
.
C'est-à-dire: Sauf si vous utilisez la dernière version jdk6u21 build 7 . 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 ceci SO réponse . 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 fichier Eclipse.ini
.
Andrew Niefer m'a alerté sur cette situation et a écrit un article de blog , à propos d'un argument vm non standard (-XX:MaxPermSize
) et peut empêcher les vms d’autres fournisseurs de démarrer du tout.
Mais la version Eclipse de cette option (--launcher.XXMaxPermSize
) ne fonctionne pas avec le nouveau JDK (6u21, sauf si vous utilisez la version 6u21 7, voir ci-dessous).
Le final la solution est sur le Eclipse Wiki , 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 ça. Pas de réglage pour Tweak ici (encore une fois, seulement pour Helios sous Windows avec un 6u21 pre build 7 ).
Pour les plateformes autres que Windows, vous devez revenir à l'option propriétaire de Sun, -XX:MaxPermSize
.
Le problème est basé sur une régression: l’identification de la JVM échoue à cause du changement de nom Oracle dans Java.exe , et déclenchée bug 319514 sur Eclipse.
Andrew s’est occupé de le bogue 320005 - [launcher] --launcher.XXMaxPermSize: isSunVM
devrait renvoyer true pour Oracle , mais ce ne sera que pour Helios 3.6.1.
Francis Upton , un autre committer Eclipse, réfléchit à la situation générale .
Mise à jour du 27 juillet au 21 juillet :
Oracle a régressé le changement pour la prochaine version Java 6 et ne l'implémentera plus avant JDK 7 .
Si vous utilisez jdk6u21 build 7, vous pouvez revenir à la --launcher.XXMaxPermSize
(option Eclipse) au lieu de -XX:MaxPermSize
(option non standard).
Le détection automatique se produisant dans le lanceur C: Eclipse.exe
recherchera toujours la chaîne "Sun Microsystems
", mais avec 6u21b7, cela fonctionnera à nouveau.
Pour l'instant, je conserve toujours la version -XX:MaxPermSize
(car je ne sais pas quand tout le monde lancera Eclipse le à droite 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 d'une version à l'autre d'Eclipse 3.6.x:
org.Eclipse.equinox.launcher
avec la version la plus récente.plugins
le fragment org.Eclipse.equinox.launcher.[platform]
correspondant à la version la plus récente et utilise la bibliothèque partagée nommée Eclipse_*
à l'intérieur.Le JDK6 est maintenant explicitement requis pour lancer Eclipse:
-Dosgi.requiredJavaVersion = 1.6
This SO question rapporte une incidence positive pour le développement sur Mac OS.
Les options suivantes font partie de certaines des options expérimentales de la machine virtuelle Sun.
-XX:+UnlockExperimentalVMOptions
-XX:+UseG1GC
-XX:+UseFastAccessorMethods
Ils ont été rapportés dans ce article de blog pour potentiellement accélérer Eclipse.
Voir tous les options JVM ici et aussi dans la version officielle page Options Java Hotspot .
Remarque: le liste détaillée de ces options indique que UseFastAccessorMethods
pourrait être actif par défaut.
Voir aussi "Update your JVM" :
Pour rappel, G1 est le nouveau ramasse-miettes en préparation du kit JDK 7, mais déjà utilisé dans la version 6 de u17.
Voir le article de blog de Andrew Niefer rapportant cette nouvelle option:
--launcher.defaultAction
openFile
Cela indique au programme de lancement que s'il est appelé avec une ligne de commande ne contenant que des arguments ne commençant pas par "
-
", 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 programme de lancement recevra sous 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 le répertoire de travail actuel et ensuite par le répertoire du programme Eclipse.
Voir bug 3010 pour référence. À l'origine bug 4922 (octobre 2001, corrigé 9 ans plus tard).
Si vous êtes fatigué de cette boîte de dialogue lors de l'installation de vos nombreux plugins:
, ajoutez dans votre Eclipse.ini
:
-Declipse.p2.unsignedPolicy=allow
Voir ceci article de blog de Chris Aniszczy , et le rapport de bogue 235526 .
Je tiens à dire que la recherche en matière de sécurité confirme le fait que moins d’invitations sont meilleures.
Les gens ignorent les choses qui apparaissent dans le flux de quelque chose qu’ils veulent faire.Pour la version 3.6, nous ne devrions pas afficher d’avertissements au milieu du flux - peu importe la mesure dans laquelle nous simplifions, les gens les ignoreront tout simplement.
Au lieu de cela, nous devrions collecter tous les problèmes, ne pas ne pas installer ces ensembles, et au lieu de cela ramener l'utilisateur à un point du flux de travail où il peut corriger - Ajoutez de la confiance, configurez la politique de sécurité de manière plus souple, etc. Cela s'appelle "stockage sécurisé".
---------- http://www.Eclipse.org/home/categories/images/wiki.giftexte alt http: //www.Eclipse. org/home/categories/images/wiki.giftexte alternatif http://www.Eclipse.org/home/categories/images/wiki.gif
Ces options ne figurent pas directement dans le Eclipse.ini
ci-dessus, mais peuvent s'avérer utiles si nécessaire.
Lorsque Eclipse démarre, il lit son fichier de clés (où sont conservés les mots de passe), un fichier situé dans user.home
.
Si pour une raison quelconque, user.home
ne se résolvait pas correctement en un chemin à part entière, Eclipse ne démarre pas.
Initialement soulevée dans this SO question , si vous rencontrez ce problème, vous devez redéfinir le fichier de stockage de clés en un chemin explicite (aucun autre user.home à résoudre à le début)
Ajoutez dans votre Eclipse.ini
:
-Eclipse.keyring
C:\Eclipse\keyring.txt
Cela a été suivi par bug 300577 , il a été résolu dans cette autre question SO .
Attendez, il y a plus d'un fichier de réglage dans Eclipse.
si vous ajoutez à votre Eclipse.ini
l'option:
-debug
, vous activez le mode débogage et Eclipse recherchera un autre fichier de paramètres : un fichier .options
dans lequel vous pouvez 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 ce article de blog " Diagnostic de Dropins " :
org.Eclipse.equinox.p2.core/debug=true
org.Eclipse.equinox.p2.core/reconciler=true
P2 vous indiquera quels ensembles ont été trouvés dans le dossier
dropins/
, 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 a mal tourné, mais cela devrait vous donner des informations précises sur le point de départ:
- votre paquet était dans le plan?
- Était-ce un problème d'installation (erreur P2)
- ou peut-être n'est-il pas optimal d'inclure votre fonctionnalité?
Cela vient de Bogue 264924 - [réconciliateur] Pas de diagnostic de problème de perte de temps , 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
Cette configuration pose problème car OCL dépend de EMF qui est manquant.
3.5M5 ne fournit aucun diagnostic de ce problème.Lancez Eclipse.
Pas de problèmes évidents. Rien dans le journal des erreurs.
Help / About / Plugin
details afficheorg.Eclipse.ocl.doc
, mais pasorg.Eclipse.ocl
.Help / About / Configuration
details n'a pas de (diagnostic) mention deorg.Eclipse.ocl
.Help / Installation / Information Installed Software
n'a aucune mention deorg.Eclipse.ocl
.Où sont les marqueurs d'erreur de Nice?
Voir ceci blog post :
- Dans Galileo (également appelé Eclipse 3.5), JDT a commencé à résoudre le classpath 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 celle 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 31389 pour les références.
Cette SO question mentionne un correctif potentiel lorsque vous n’avez pas accès aux sites de mise à jour du plugin:
-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 banc de test avec la JVM 1.7 x64 n Windows sont les suivantes:
-Xincgc
-XX:-DontCompileHugeMethods
-XX:MaxInlineSize=1024
-XX:FreqInlineSize=1024
Mais je travaille encore dessus ...
Actuellement (novembre 2009), je teste avec jdk6 mise à jour 17 les options de configuration suivantes (avec Galileo - Eclipse 3.5.x, voir ci-dessous pour 3.4 ou ci-dessus pour Helios 3.6.x ):
(bien sûr, adaptez les chemins relatifs présents dans cet Eclipse.ini aux chemins appropriés pour votre configuration)
Remarque: pour Eclipse3.5 , remplacez les lignes startup
et launcher.library
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 mon réponse originale ci-dessus pour plus d'informations.
org.Eclipse.equinox.p2.reconciler.dropins.directory
.Il y avait un bogue avec points d'arrêt ignorés réellement liés au JDK.
Utilisez JDK6u16 ou une version plus récente pour lancer Eclipse (vous pouvez ensuite définir autant de JDK que vous souhaitez compiler dans Eclipse: ce n’est pas parce que vous lancez un Eclipse avec JDK6 que vous devrez compiler avec le même JDK).
Notez l'utilisation de:
--launcher.XXMaxPermSize
384m
-vmargs
-XX:MaxPermSize=128m
Comme documenté dans le Eclipse Wiki ,
Eclipse 3.3 prend en charge un nouvel argument pour le programme de lancement:
--launcher.XXMaxPermSize
.
Si le VM utilisé est un Sun VM et qu’il n’existe pas déjà un argument-XX:MaxPermSize=
VM, le lanceur lancera ajouter automatiquement-XX:MaxPermSize=256m
à la liste des arguments VM utilisés.
Le lanceur 3.3 ne peut identifier que les machines virtuelles Sun sur Windows.
Comme détaillé dans cette entrée :
Tous les vms n'acceptent pas l'argument
-XX:MaxPermSize
, raison pour laquelle il est passé de cette manière. Il peut exister (ou non) des problèmes d’identification de Sun vms.
Remarque: Eclipse 3.3.1 contient n bogue où le programme de lancement ne peut pas détecter une machine virtuelle Sun et n'utilise donc pas la taille PermGen correcte. Il semble que cela ait peut-être été n bogue connu sous Mac OS X pour 3.3. également.
Si vous utilisez l'une de ces combinaisons de plateformes, ajoutez l'indicateur-XX
auEclipse.ini
comme décrit ci-dessus.Remarques:
- la ligne "
384m
" correspond à la partie "=384m
" de l'argument VM, si la VM est sensible à la casse sur la "m
", alors tel est le cas de cet argument.- le préfixe "
--launcher.
", spécifie que l'argument est utilisé par le programme de lancement et qu'il a été ajouté aux arguments spécifiques du programme de lancement pour éviter les conflits de noms avec les arguments de l'application. (D'autres exemples sont--launcher.library
,--launcher.suppressErrors
)La partie
-vmargs -XX:MaxPermSize=384m
est l'argument transmis directement à la VM, contournant complètement le programme de lancement et n'utilisant pas de contrôle du fournisseur VM.
Pour les paramètres plus récents, voir Eclipse Galileo 3.5 paramètres ci-dessus .
Le meilleur réglage de la JVM toujours , à mon avis, inclut le dernier JDK que 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 insuffisante, je peux exécuter de gros 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 réponse de SO de GKelly et 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 un 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 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 n'utilise que 200 Mo pour le tas et 150 Mo pour le non-tas. Si vous utilisez d'énormes plugins, vous pouvez augmenter les limites "-Xmx200m" et "-XX: MaxPermSize = 150m".
La cible d'optimisation principale pour ces indicateurs était minimiser la latence dans tous les cas et, en tant que cible d'optimisation secondaire, réduire l'utilisation de la mémoire.
-showlocation
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 la Workspace name (shown in window title)
qui fonctionne beaucoup mieux que -showlocation
pour trois raisons:
Si vous utilisez Linux + Sun JDK/JRE 2bits, remplacez le "-vm" par:
-vm
[your_jdk_folder]/jre/lib/i386/client/libjvm.so
Si vous utilisez Linux + Sun JDK/JRE 64bits, remplacez le "-vm" par:
-vm
[your_jdk_folder]/jre/lib/AMD64/server/libjvm.so
Cela fonctionne très bien pour moi sur Ubuntu 8.10 et 9.04
Si vous utilisez jdk6 update 14, nous vous suggérons d'utiliser le récupérateur de place G1, ce qui semble améliorer les performances.
Pour ce faire, supprimez ces paramètres:
-XX: + UseConcMarkSweepGC
- XX: + CMSIncrementalMode
- XX: + CMSIncrementalPacing
et les remplacer par ceux-ci:
-XX: + UnlockExperimentalVMOptions
- XX: + UseG1GC
Vous pouvez également essayer de courir avec JRockit . C'est une machine virtuelle optimisée pour les serveurs, mais de nombreuses applications clientes, telles que les IDE, fonctionnent très bien sur JRockit. Eclipse ne fait pas exception. JRockit n'a pas de perm-space, vous n'avez donc pas besoin de le configurer.
Il est possible de définir une cible de temps de pause (ms) pour éviter les 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
D'habitude, je ne me soucie pas de régler -Xmx et -Xms et de laisser JRockit faire croître le tas comme il le juge nécessaire. Si vous lancez votre application Eclipse avec JRockit, vous pouvez également surveiller, profiler et rechercher les fuites de mémoire dans votre application à l'aide de la suite d'outils JRockit Mission Control. Vous téléchargez les plugins à partir de ceci site de mise à jour . Remarque, ne fonctionne que pour Eclipse 3.3 et Eclipse 3.4
Voici mon propre paramètre pour mon ordinateur Eclipse fonctionnant sur un ordinateur portable i7 2630M 16 Go 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 réglages ont fonctionné à merveille pour moi. Je suis sous 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
Eclipse aime beaucoup de RAM. Utilisez au moins -Xmx512M. Plus si disponible.
XX: + UseParallelGC c'est l'option la plus géniale de tous les temps !!!
-vm
C:\Program Files\Java\jdk1.6.0_07\jre\bin\client\jvm.dll
Pour spécifier la version de Java que vous utilisez et utiliser la DLL au lieu de lancer un processus javaw
Voici ce que j'utilise (bien que je les ai dans le raccourci au lieu du fichier de paramètres):
Eclipse.exe -showlocation -vm "C:\Java\jdk1.6.0_07\bin\javaw.exe" -vmargs -Xms256M -Xmx768M -XX: + UseParallelGC -XX: MaxPermSize = 128M