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

[Dmitry Samersoff]

Volker,

under UNIX :

file /opt/jdk7/bin/java | grep 32-bit

give you an information about launcher

-Dmitry

On 2011-10-28 17:23, Volker Simonis wrote:
> 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 ...
>>


-- 
Dmitry Samersoff
Java Hotspot development team, SPB04
* There will come soft rains ...