Sv: Re: Sv: OOME in javac when building on Windows 7

[Phil Race]

On 11/7/2011 1:54 PM, Fredrik Öhrström wrote:
> ----- philip.race at oracle.com skrev:
>> I can definitely switch it to 64 bit JRE. I didn't do that because
>> your original email
>> subject was "build-infra now builds on 32bit windows." So I tried to
>> avoid 64 bit thinking that was what wouldn't work.
> That was a reasonable assumption. :-) But the real reason it only
> builds a 32 bit jvm, is because config.guess returns i686-pc-cygwin
> instead of x86_64-pc-cygwin. I do not know why. Perhaps it is a
> bug in config.guess, perhaps it is a side effect of cygwin being 32 bit?
> Anyone out there who knows?
>

64 bit gets me past that problem. I've now got a new completely 
unrelated problem
in building hotspot running the linker
Compiling...
c1_ValueType.cpp
Generating Code...
         sh C:\build-infra\jdk7\hotspot/make/windows/build_vm_def.sh
         C:\BUILD-~1\jdk7\build\WINDOW~1\UNCYGD~1.EXE 
C:\vs2010\VC\BIN\link.exe @
C:\Users\prr\AppData\Local\Temp\nmC8DB.tmp
LINK : fatal error LNK1181: cannot open input file 'kernel32.lib'
NMAKE : fatal error U1077: 
'C:\BUILD-~1\jdk7\build\WINDOW~1\UNCYGD~1.EXE' : return code '0x49d'
Stop.
NMAKE : fatal error U1077: 'cd' : return code '0x2'
Stop.
NMAKE : fatal error U1077: 'C:\vs2010\VC\BIN\nmake.EXE' : return code '0x2'
Stop.
make[2]: *** [generic_build1] Error 2
make[1]: *** [product1] Error 2
make: *** [hotspot] Error 2

Another path problem I suppose which is strange as the SDK and so 
kernel32.lib
  is in the standard location:
sh-4.1$ pwd
/cygdrive/c/Program Files (x86)/Microsoft SDKs/Windows/v7.0A/lib
sh-4.1$ ls Kernel32.lib
Kernel32.lib

>> Should I now infer that the configure script would have been ok with
>> the client VM
>> on 32 bit windows because it would have set up all options for client
>> ?
> The settings -client -server does not affect the possible size of the heap.
> On a 32 bit machine, the available virtual memory is 2G on Windows, or 3G
> since the java launcher and jvm.dll are compiled with LARGEADDRESSAWARE.
> (I think they are?)
>
> Unfortunately, that memory is severly fragmented on Windows (dll:s are
> sprinkled around as salt and pepper), and Hotspot/OpenJDK
> cannot deal with split heaps (JRockit can). So the largest contiguous memory
> chunk that is possible to find on Windows 32 bit, is usually around 1.8G.
> Which is the maximum heap size.

Server can't affect the *possible* heap, but it does affect the default 
heap settings.
But it sounds like you are saying that this javac server requires so 
much heap, that it will
likely hit the fragmentation problem, if not the overall heap limit.
In the 32 bit JRE, graphics drivers, notably D3D drivers, are a notable 
cause of that.
I suspect that the D3D preload code for startup performance can hit you 
there.
But it may be worth experimenting with -Dsun.java2d.d3d=false, and 
-Djava.awt.headless=true
to minimise the likelihood of this and see what a 32 bit server JVM can 
handle.

>
>> Maybe you could try "javaw.exe" to run that server ? It shouldn't need
>> a console.
>> "-Djava.awt.headless=true" is worth a try but I suspect won't prevent
>> the console.
> Ah, of course. Thanks for the tip! I'll try that.
>
> You can try too. Simply change in the  spec.gmk file where it says
> SERVER_JAVA:=.... to use javaw instead of java.
>
Unfortunately it didn't help. Maybe the way its being launched is part of
the problem. ie if its launched indirectly via something which causes the
cmd.exe to be created already. I haven't yet found where the command is 
launched.

-phil.
> //Fredrik
>