Estou utilizando a versão 11.1.1.5.0 generic no Linux, mas para outras plataformas as configurações são similares. O arquivo principal de configuração (jdev.conf) do JDeveloper está localizados na pasta $MW_HOME/jdeveloper/jdev/bin.
A primeira linha desse arquivo indica onde temos outras configurações: IncludeConfFile ../../ide/bin/ide.conf. O primeiro passo é abrir esse arquivo (ide.conf) e alterar os parametros Xmx e Xms. O parâmetro Xms é referente à quantidade de memória heap inicial a ser utilizada e o Xmx é a quantidade máxima. Minha máquina possui 8GB de RAM. Para o meu JDeveloper, 2GB de máximo e 1GB de mínimo é suficiente. O recomendado é 1/4 do total de memória que a máquina possua, mas você deve levar em consideração que poderá subir outros servidores e outras aplicações que irão consumir memória. Então aumentar muito esse valor, pode fazer com que a sua máquina utilize swap e, ao invés de deixar o JDeveloper mais rápido, sua máquina irá acabar ficando mais lenta. Então eu alterei minha máquina para os seguintes valores: "AddVMOption -Xmx2048M" e "AddVMOption -Xms1024M".
Edite o arquivo jdev.conf e modifique a linha "AddVMOption -XX:MaxPermSize=256M" para 384M. Adicione a seguinte linha no final do arquivo: "IncludeConfFile tunning.conf". Crie um arquivo tunning.conf no diretório: $MW_HOME/jdeveloper/jdev/bin com o seguinte conteúdo:
AddVMOption -XX:+UseConcMarkSweepGC # Utilizado em máquinas que tem suporte #AddVMOption -XX:+UseLargePages AddVMOption -XX:+UseFastAccessorMethods AddVMOption -XX:+UseParNewGC AddVMOption -XX:+UseTLAB AddVMOption -XX:+AggressiveOpts AddVMOption -XX:+UseStringCache AddVMOption -XX:+UseCompressedStrings AddVMOption -XX:+OptimizeStringConcat
Você pode também descomentar a linha do "AddVMOption -XX:+UseLargePages" para verificar se o seu sistema tem suporte a esse tipo de otimização. Caso você obtenhar o seguinte erro: "Java HotSpot(TM) 64-Bit Server VM warning: Failed to reserve shared memory (errno = 22).", significa que não há suporte ao UseLargePages. É só remover ou comentar novamente a linha.
Para visualizar as informações de tunning e o que cada comando desse faz, eu sugiro acessar o seguinte documento: http://www.oracle.com/technetwork/java/javase/tech/vmoptions-jsp-140102.html.
No Ubuntu há uma outra alteração importante. No arquivo jdev.conf altere o parâmetro SetJavaHome. No meu caso está da seguinte forma: "SetJavaHome /usr/lib/jvm/java-6-sun-1.6.0.26". Utilize o link simbólico, pois ao atualizar o Java, você poderá ter problemas ao iniciar o JDeveloper. O resultado deve ser algo do tipo: "SetJavaHome /usr/lib/jvm/java-6-sun".
Pronto! JDeveloper rápido, na medida do possível 🙂
Atualização dia 21/06/2012: A opção UseCompressedStrings não existe mais na versão 7 do Java.
Google+
Bacana essa combinação! Algumas switches mais exóticas que tem o potencial de turbinar esses e outros IDES (fonte: http://performance.netbeans.org/howto/jvmswitches/).
-J-Xverify:none Deixa de verificar o bytecode, fazendo com que as classes abram mais rapidamente (isso diminui muito o tempo de loading do IDE).
-Dsun.java2d.opengl=true Com uma placa de video legal essa opção aumenta bastante a responsividade do IDE (é recomendável desativar compz).
-J-XX:CompileThreshold=100 Jaz a JVM compilar mais bytecode por padrão. Isso significa que o IDE vai demorar mais para abrir, porém, deve executar operações mais rapidamente (menos código interpretado).
-J-XX:+CMSClassUnloadingEnable -J-XX:+CMSPermGenSweepingEnabled. Quando a JVM está usando esses algoritmos de GC alternativos ela costuma desabilitar o Unloading de classes. Essas switches habilitam o GC no PermGen diminuindo a probabilidade de java.lang.OutOfMemoryError: PermGen space (eles ainda acontecem se a aplicação tiver algum Classloader Leak).
Show de bola! Só precisa tirar os -J da frente dos parâmetros
Por favor, pode me dizer se hoje desenvolvo com jdeveloper posso copilar no netbeans para rodar no cliente.
Desde já agradeço sua atenção. Para segurança.
Pode sim