JDK8 32-bit "docs" build fails on 64-bit Windows

[Volker Simonis]

Using

MAX_VM_MEMORY = max (MAX_VM_MEMORY, 1024)

as proposed by Ivan will always result in MAX_VM_MEMORY being 1024
because MAX_VM_MEMORY is only assigned in jdk/make/common/shared/Platform.gmk to
be either 384 or 512.

By the way, I think that logic is wrong as well, because it always
sets MAX_VM_MEMORY
to 512 if it only could figure out the amount of memory on the machine
(MB_OF_MEMORY) - no
difference if that amount is less than or bigger than 512mb. This has
probably only not been
detected until now because I assume there are few Windows build
machines with less than
512mb memory nowadays:)

So back to our problem: I think MAX_VM_MEMORY should be set depending
of the bootstrap JDK
(because that's the JDK actually used to compile the javadoc files).
If the bootstrap JDK is a 64-bit JDK, the value of MAX_VM_MEMORY
should be set to 1024
otherwise it should be set to 512 which is apparently enough for a 32-bit JDK.

I only don't know how to elegantly find out what kind of bootstrap JDK
we are using. I know that
we could query the (non-standard) system property
"sun.arch.data.model" or the standard system
property "os.arch" (which has a non-standardized output:). But this
requires the launch of the VM.

Does anybody know a smarter way to find out what kind of VM we are
bootstrapping with?
Or perhaps this information is already stored in one of the many make
variables which are floating around?

Regards,
Volker

On Thu, Oct 27, 2011 at 7:24 PM, Dmitry Samersoff
<Dmitry.Samersoff at oracle.com> wrote:
> Kelly,
>
> AFAIK, this problem was solved on win2k time so (IMHO) we should try.
>
> -Dmitry
>
> On 2011-10-27 21:13, Kelly O'Hair wrote:
>> As I recall, on Windows, if we change to 1024, it's possible the VM will not startup if the
>> machine doesn't have a hole that big in it's virtual memory. So if we change to 1024, we could
>> rule out people with a fragmented memory system, like running NetBeans and FireFox and 100's of
>> useless Windows services. :^(
>> So it's ok with me to say jdk8 requires a 2GB system to build, but even with 2GB, this 1024 could
>> block some people from building.
>>
>> My tendency is to make the default NO_DOCS=true, maybe just on Windows for now,
>> but that might mean missing javadoc errors.
>>
>> -kto
>>
>> On Oct 27, 2011, at 9:41 AM, Volker Simonis wrote:
>>
>>> I've just realized that building the JDK documentation for a 32-bit
>>> build of JDK8 on Windows (with JDK7 as bootstrap JDK) fails:
>>>
>>> C:/OpenJDK/jdk1.7.0_01/bin/java -XX:-PrintVMOptions
>>> -XX:+UnlockDiagnosticVMOptions -XX:-LogVMOutput -client -Xmx512m
>>> -Xms512m -XX:PermSize=32m -XX:MaxPermSize=160m
>>> "-Xbootclasspath/p:C:/OpenJDK/output_x86/langtools/dist/bootstrap/lib/javadoc.jar;C:/OpenJDK/output_x86/langtools/dist/bootstrap/lib/javac.jar;C:/OpenJDK/output_x86/langtools/dist/bootstrap/lib/doclets.jar"
>>> -jar C:/OpenJDK/output_x86/langtools/dist/bootstrap/lib/javadoc.jar
>>> -bootclasspath c:/OpenJDK/output_x86/classes  -d
>>> c:/OpenJDK/output_x86/docs/api \
>>> @c:/OpenJDK/output_x86/tmp/docs/doctmp/coredocs.options
>>> @c:/OpenJDK/output_x86/tmp/docs/doctmp/coredocs.packages
>>> ..\..\src\share\classes\java\lang\invoke\MethodHandle.java:392:
>>> warning - Tag @link: reference not found: Objects.equals
>>> java.util.Objects#equals
>>> c:\OpenJDK\output_x86\impsrc\javax\xml\bind\JAXBContext.java:262:
>>> warning - Tag @see: reference not found: S 7.4.1 "Named Packages" in
>>> Java Language Specification</a>
>>> javadoc: error - java.lang.OutOfMemoryError: Please increase memory.
>>> For example, on the JDK Classic or HotSpot VMs, add the option -J-Xmx
>>> such as -J-Xmx32m.
>>> 1 error
>>> 2 warnings
>>>
>>>> From the error it seems as if this can also happen on other platforms.
>>> The problem is caused by the following setting in jdk/make/docs/Makefile:
>>>
>>>       67 # We override whatever the max VM memory setting is here.
>>>       68 #    NOTE: javadoc will not complete without these larger settings.
>>>       69 #    WARNING: This could cause thrashing on low memory machines.
>>>       70 ifeq ($(ARCH_DATA_MODEL),64)
>>>       71   MAX_VM_MEMORY = 1024
>>>       72 else
>>>       73   MAX_VM_MEMORY = 512
>>>       74 endif
>>>
>>> The 64-bit build succeeded without a problem, so apparently 1024m
>>> seems to be big enough.
>>>
>>> I think the problem is that I'm trying to build a 32-bit VM on a
>>> 64-bit Windows OS, so I set ARCH_DATA_MODEL to '32'.
>>> I know that the README mentions that 32-bit compiles are not supported
>>> on 64-bit OSes, but besides this problem, everything else works fine,
>>> so I think this should be fixed.
>>>
>>> Regards,
>>> Volker
>>
>
>
> --
> Dmitry Samersoff
> Java Hotspot development team, SPB04
> * There will come soft rains ...
>