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

Fri Oct 28 17:33:32 UTC 2011

Yes, checking for MKS is a good idea indeed - I forgot about that.
I hope it will work there as well..

On Fri, Oct 28, 2011 at 7:29 PM, Ivan Krylov <Ivan.Krylov at oracle.com> wrote:
> 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 ...
>>>
>