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