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

[Dmitry Samersoff]

Ivan,

On 2011-10-28 17:54, Ivan Krylov wrote:
> Dima,
> 
> But we're talking about Windows. Given that we use cygwin anyway we
> could use file.exe from Cygwin
> 
>> file java.exe
> java.exe: PE32 executable (console) Intel 80386, for MS Windows

Could you check the output of dumpbin.exe /SUMMARY ? If my memory is not
bogus it can do what we need.

-Dmitry



> 
> Ivan
> 
> On 2011-10-28 17:47, Dmitry Samersoff wrote:
>> 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 ...