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

[Ivan Krylov]

I'd check that MKS has the same output of the file utility. It can still be used, right?
And I have replied to Dmitry that dumpbin does not give output that we need (although linking deps might hint on architecture) as generally not a good 
way to go.
Ivan

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