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.samers...@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 ...
