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