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):

...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:

...or:


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 as well. This appeared to have no effect.

Java reports:

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?

I feel like an idiot.

My editor of choice was hiding an "access denied" error, and automatically saving and restoring to C:\Users\...\AppData\Local\VirtualStore\Program Files (x86)\FlashDevelop\Tools\flexsdk\bin due to the vista/7 virtualization stuff.

I was convinced I had the change in under C:\Program Files (x86) when I really didn't -- opening in either VS or Notepad shows the -Xmx384m version. Finding External\Tools\FDBuild\FDBuild.sln and putting breakpoints in e.g. ConfigHelper::Parse showed the file for what it truly was. Edited using a "run as administrator" notepad, and all is well.

:wanders back to corner: