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