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

Fri Oct 28 17:22:28 UTC 2011

I think 'file' is a good idea because we're in a Cygwin bash anyway.

The output for 64 and 32 bit executables is:

PE32+ executable (console) x86-64, for MS Windows
PE32 executable (console) Intel 80386, for MS Windows

That should be easy enough to parse.
I'll be on holiday and on the EclipsCon next week but after that I can
submit a patch if you want.
On the other side I'll be not offended if you fix it:)

Regards,
Volker

On Fri, Oct 28, 2011 at 4:48 PM, Dmitry Samersoff
<Dmitry.Samersoff at oracle.com> wrote:
> 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 ...
>