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