JDK8 32-bit "docs" build fails on 64-bit Windows
Kelly O'Hair
kelly.ohair at oracle.com
Fri Oct 28 21:24:32 UTC 2011
The plan with jdk8 is to abandon MKS completely, it's a nasty complication.
But in general, I wish we could come up with a simpler solution here, like maybe
not having to set a maximum heap size at all.
-kto
On Oct 28, 2011, at 10:33 AM, Volker Simonis wrote:
> 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 ...
>>>>
>>
More information about the build-dev
mailing list