¿Hay algo más que pueda hacer para tratar con "Límite de sobrecarga de GC superado" ejecutando Ant (línea de comandos)?

Estoy tratando de compilar un proyecto muy grande, multi-proyecto de Android utilizando la línea de comando Ant. Originalmente estaba usando Ant 1.8.3, pero desde entonces he actualizado a 1.8.4 (en vano, resulta). Aunque tengo Eclipse instalado (Indigo, actualizado hoy), la naturaleza de este proyecto impide el uso de Ant desde Eclipse para esto.

El código parece generar muy bien, pero cuando llega a la fase "dex" de la operación obtiene uno de los dos errores, dependiendo de mi ANT_OPTS : "Límite de sobrecarga del GC excedido" o "Java Heap Espacio".

Busqué en Google y revisé Stack. Después de encontrar varios enlaces (cf aquí , aquí , esta pregunta de la pila , y esta pregunta de la pila también ), modifiqué mis opciones de la hormiga. (Muchos enlaces cubren lo que sucede cuando esto sucede ejecutando el código Java, mi problema es en realidad en el proceso de Ant que crea el APK de Android para la carga).

Mi variable de entorno ANT_OPTS es actualmente:

 -Xms4g -Xmx4g -Xmn256m -XX:PermSize=256m -XX:MaxPermSize=1024m -XX:+UseConcMarkSweepGC -XX:+CMSPermGenSweepingEnabled -XX:+CMSClassUnloadingEnabled -XX:ParallelGCThreads=8

He intentado desactivar el límite general de GC por medio de -XX:-UseGCOverheadLimit , pero todo lo que hace es darme un error Java Heap Space en lugar del error GC Overhead Limit. He preguntado a mis compañeros de trabajo sobre esto, pero también están sin ideas.

Oh, un "detalle" más: Puedo usar Eclipse para compilar y cargar el proyecto, y eso parece funcionar "muy bien"; Sin embargo, el gran número de proyectos requeridos para este "meta-proyecto" sugiere que trato de que el script de Ant funcione.

Información del sistema:

Sistema operativo: Windows 7 64 bit
Java: Sun, 1.6, 64 bits
Memoria física: 8Gb
Android: SDK Herramientas: R20; Herramientas de la plataforma: R12 (Actualizado hoy, 28 Jun)

¿Hay algo más que pueda hacer? ¿Otra palabra clave para buscar? ¿Algún otro sitio para mirar?

Esto suena como lo que sucede cuando una aplicación se ejecuta lentamente fuera del espacio de montón. Si tiene conjunto de límite de sobrecarga de GC, la JVM muere con bastante rapidez. Si no lo hace, la aplicación continúa un poco más, gastando más y más tiempo GC'ing … y finalmente muere.

Si esta es su aplicación, debe comprobar si hay fugas de almacenamiento. Pero ya que es un bien conocido y (presumiblemente) bien probado aplicación de terceros, lo más simple de intentar es … para aumentar el tamaño de montón.

La otra cosa que intentar es desactivar CMS. No hay ninguna razón para usar CMS para una compilación por lotes: Las pausas de GC son irrelevantes. Sólo utilice el colector de rendimiento. (Esto probablemente no solucionará el problema de tamaño de montón, pero debería hacer que tus compilaciones se ejecuten más rápido.)

Una respuesta parcial a esta. Gracias a los encuestados actuales, que me ayudaron a rastrear esto.

Hay, aparentemente, dos (posiblemente tres?) Diferentes lugares donde los Java VM opts necesidad de ser cambiado, dependiendo de exactamente dónde se produce el error. En este caso, los ANT_OPTS no se pasan a Dex.

Pude solucionar el error editando el archivo de hornada de DX, cambiando:

 set defaultXmx=-Xmx1024M

 set defaultXmx=-Xmx4096M

Lo obvio Sin embargo : Nunca debería cambiar el archivo de lote dx. ¿Alguien conoce la forma "correcta" de cambiar las Opciones de Java que pasan a Dex por Ant?

Creo que lo que buscas es: