java heap space error and ignored jvm.config
For a few days now, we've been getting the following (FlashDevelop 4.0.1 RTM for Microsoft.NET 2.0 (R2198), various flavors of Windows including XP 32bit, XP 64bit, and 7 64bit):
Running process: C:\Program Files (x86)\FlashDevelop\Tools\fdbuild\fdbuild.exe "C:\projects\module4\Engineering\Module4.as3proj" -ipc a2032483-0e62-4d06-8675-124283dcd739 -version "4.6.0; 3.1" -compiler "C:\Program Files (x86)\FlashDevelop\Tools\flexsdk" -notrace -library "C:\Program Files (x86)\FlashDevelop\Library"
mxmlc -load-config+=obj\Module4Config.xml -incremental=true +configname=airmobile -o obj\Module4634729630044361966
Starting java as: java.exe
INITIALIZING: Adobe Flex Compiler SHell (fcsh)
Starting new compile.
Loading configuration file C:\Program Files (x86)\FlashDevelop\Tools\flexsdk\frameworks\airmobile-config.xml
Loading configuration file C:\projects\module4\Engineering\obj\Module4Config.xml
Error: Java heap space
Build halted with errors (fcsh).
...coincident with a significant increase in the number and size of .fla files, .png files, and other "assets" we're building into the project.
We've all descended into FlashDevelop\Tools\flexsdk\bin\jvm.config and set up something like:
On at least a few machines (mine included, which is a Windows 7 Pro 64-bit machine) it seems to completely ignore this. Setting Systinternals Procmon.exe on FlashDevelop shows FlashDevelop.exe still running C:\Windows\SYSWOW64\java.exe with the -Xmx384m arg. Procmon.exe also shows fdbuild.exe successfully reading jvm.config just a few pages of events before this, so in theory it saw the line at some point (not sure if it communicated back to FlashDevelop.exe about this).
Just to be safe, on my machine, I set
java.home=C:\Program Files (x86)\Java\jre6\bin
as well. This appeared to have no effect.
java version "1.6.0_31"
Java(TM) SE Runtime Environment (build 1.6.0_31-b05)
Java HotSpot(TM) Client VM (build 20.6-b01, mixed mode, sharing)
I checked out flashdevelop-read-only from the public svn repo and built locally (rev 2238) and slapped a selection of breakpoints on pretty much anything with jvm.config, java.exe, "jvmarg", or the like nearby (shotgun debugging!). I eventually land on FlexCompilerShell::Compile, with jvmarg already showing the "wrong" -Xmx384m, but I'm not sure where it's coming from -- it's not hitting e.g. JvmConfigHelper::ReadConfig any time before this, or any of the other places I might (naively) expect. I'm not (yet) familiar enough with the remoting stuff or the project structure to figure out what's triggering the FlexCompilerShell::Compile.
We are probably doing something wrong with our project structure in the first place to require this much java heap space. I've heard but not confirmed reports that "Clean Solution" makes the problem go away temporarily on some machines.
But I'm still curious where it's getting the -Xmx384m arg from in the first place...
Any suggestions? Am I missing something obvious?