some 32bit builds broken in icedtea 2.3.9

[Andrew Hughes]

[Taking zero off CC as this seems unrelated]

----- Original Message -----
> at least on some 32bit platforms, icedtea builds are broken:
> 
> see https://buildd.debian.org/status/package.php?p=openjdk-7
> the i386 and s390 build logs.
> 
> this is caused by the changes below:
> 
> --- build/openjdk/jdk/make/common/shared/Platform.gmk
> +++ build/openjdk/jdk/make/common/shared/Platform.gmk
> @@ -537,7 +537,7 @@
>        else \
>          echo "false"; \
>        fi)
> -    MAX_VM_MEMORY := 512
> +    MAX_VM_MEMORY := 1536
>      MIN_VM_MEMORY := $(MAX_VM_MEMORY)
>    else
>      MB_OF_MEMORY       := unknown
> --- build/openjdk/jdk/make/docs/Makefile        2013-04-29 21:06:38.450777732
> +0200
> +++ build/openjdk/jdk/make/docs/Makefile        2013-04-29 21:22:19.085051363
> +0200
> @@ -69,11 +69,11 @@
>  #    NOTE: javadoc will not complete without these larger settings.
>  #    WARNING: This could cause thrashing on low memory machines.
>  ifeq ($(ARCH_DATA_MODEL),64)
> -  MAX_VM_MEMORY = 1536
> +  MAX_VM_MEMORY = 1792
>  else ifeq ($(ARCH),universal)
> -  MAX_VM_MEMORY = 1536
> +  MAX_VM_MEMORY = 1792
>  else
> -  MAX_VM_MEMORY = $(shell if [ $(MIN_VM_MEMORY) -gt 768 ]; then echo
> $(MIN_VM_MEMORY); else echo 768; fi)
> +  MAX_VM_MEMORY = 768
>  endif
> 
>  # List of all possible directories for javadoc to look for sources
> 
> 
> building the docs on i386:
> 
> .../java ... -client -Xmx768m -Xms1536m ...
> Error occurred during initialization of VM
> Incompatible minimum and maximum heap sizes specified
> make[5]: ***
> [/build/buildd-openjdk-7_7u21-2.3.9-2-i386-pV_IFD/openjdk-7-7u21-2.3.9/build/openjdk.build/docs/api/index.html]
> Error 1
> 
> this is caused by re-setting MAX_VM_MEMORY without re-setting MIN_VM_MEMORY
> in
> openjdk/jdk/make/docs/Makefile.
> 
> proposed fix:
> 
>   MIN_VM_MEMORY := $(MAX_VM_MEMORY)
> 
> MIN_VM_MEMORY should not be a simply expanded variable in
> openjdk/jdk/make/common/shared/Platform.gmk, so that the re-set affects
> MIN_VM_MEMORY too.
> Just use:
> 
>   MIN_VM_MEMORY = $(MAX_VM_MEMORY)
> 
> This build failure did only show on Debian, not Ubuntu, however I couldn't
> yet
> find out why it did fail on the former, while it did succeed on the latter.
> 
> 
> the zero s390 build failure is caused by increasing MAX_VM_MEMORY by 1G,
> which
> is two high on s390. afaics the highest value the s390 vm does accept is
> about
> 768+128m. Can somebody else verify this on another s390 machine?
> 
> Setting this to 768 for the s390 build lets the  build succeed.  Why was this
> value changed in the first place?  which platform does require a 300% memory
> increase for the build?
> 

hg annotate is your friend in these situations.  This change comes from:

changeset:   2558:e6d81fc2c943
user:        Andrew John Hughes <gnu_andrew at member.fsf.org>
date:        Wed Jun 13 00:01:00 2012 +0100
summary:     PR986: Allow CACAO builds of IcedTea to be able to build IcedTea without bootstrap.

and has been in place for nearly a year.  It's not new to 2.3.9, but the 2.3.x series
as a whole.  As a workaround, you could use 2.2.8 which is about to be released
(going through tarball testing).  I presume these machines haven't been using 2.3.x
prior to this point?

I'm guessing your x86 build was using a larger maximum before.  It's not clear to me where

> -  MAX_VM_MEMORY = $(shell if [ $(MIN_VM_MEMORY) -gt 768 ]; then echo
> $(MIN_VM_MEMORY); else echo 768; fi)
> +  MAX_VM_MEMORY = 768

comes from. patches/cacao/memory.patch just shows:

diff -Nru openjdk.orig/jdk/make/docs/Makefile openjdk/jdk/make/docs/Makefile
--- openjdk.orig/jdk/make/docs/Makefile	2012-06-08 17:12:17.000000000 +0100
+++ openjdk/jdk/make/docs/Makefile	2012-06-12 11:09:31.616702981 +0100
@@ -69,9 +69,9 @@
 #    NOTE: javadoc will not complete without these larger settings.
 #    WARNING: This could cause thrashing on low memory machines.
 ifeq ($(ARCH_DATA_MODEL),64)
-  MAX_VM_MEMORY = 1536
+  MAX_VM_MEMORY = 1792
 else ifeq ($(ARCH),universal)
-  MAX_VM_MEMORY = 1536
+  MAX_VM_MEMORY = 1792
 else
   MAX_VM_MEMORY = 768
 endif

which only affects 64-bit builds.

The numbers were arrived at by repeated builds, increasing the value, until we got one that passed.
We could probably restrict the JDK one to 64-bit only, but this is a delicate issue
which varies per-arch.  Personally, I don't have the resources to build on x86 as well, especially
for a security update, and no means to build on s390, though I believe Red Hat does
both.

Hooking such builds up to the IcedTea builders would be great in catching this stuff.

>   Matthias
> 
> 

-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: 248BDC07 (https://keys.indymedia.org/)
Fingerprint = EC5A 1F5E C0AD 1D15 8F1F  8F91 3B96 A578 248B DC07