Created attachment 741915 [details]
rebased size_t patch

Created attachment 741916 [details]
patch to recognize s390(x)

Created attachment 741917 [details]
update for spec file

Please let me know if you need access to a s390(x) Fedora machine.

(In reply to comment #4)
> Please let me know if you need access to a s390(x) Fedora machine.

I would like to submit these patches upstream, but upstream requires a contributor agreement. Have you (or your employer) signed the OCA [1] by any chance? It would be nice to have access to a s390(x) machine so I can test this patch before sending it upstream.

[1] http://www.oracle.com/technetwork/oca-405177.pdf

(In reply to comment #5)
> (In reply to comment #4)
> > Please let me know if you need access to a s390(x) Fedora machine.
> 
> I would like to submit these patches upstream, but upstream requires a
> contributor agreement. Have you (or your employer) signed the OCA [1] by any
> chance? It would be nice to have access to a s390(x) machine so I can test
> this patch before sending it upstream.

this is my Fedora identity, I'm a Red Hat employee (dhorak), so I guess the agreement doesn't make any problem. Please ping me (dhorak) tomorrow on internal IRC for the s390x machine access (I'm on the way to bed now :-) ). Thanks, Dan

You say the size_t patch is a rebasing.  Where is the original from and why did it need rebasing?

The other change is fairly trivial and is just what we had in IcedTea beforehand, so looks fine.

the changes are visible in
http://pkgs.fedoraproject.org/cgit/java-1.8.0-openjdk.git/commit/?id=337e4b1b973806a312e6b1169464e70351d8c982

IIRC the hunk for jdk8/hotspot/src/share/vm/memory/collectorPolicy.cpp failed, because the context (see the // comments) around the change is different

The size_t patch needs a verification on s390, where the size_t makes the problem. I'm not able to run the build there because it fails very early with the "Could not reserve enough space for object heap" error (see above).

Created attachment 743211 [details]
full build.log from s390

Hi
Its likely not able to reserve -Xmx1100 out of 2gb in jvm init. Try reducing that value (I'll try to find the place but not really familiar with new build yet...)

Chris

Created attachment 743258 [details]
rebased and refreshed size_t patch

This is a result of successful HotSpot build on s390.

Created attachment 743259 [details]
workaround the OOM error on s390

Created attachment 743260 [details]
workaround the OOM error on s390

s/endif/fi/

(In reply to comment #13)
> Created attachment 743259 [details]
> workaround the OOM error on s390

I'll also try a build on Fedora builders whose have more memory than my test machine, not sure if there will be a change when the limit is 2GB per process, but still worth trying IMHO.

This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

so I'm still struggling with this one ...

from build.log on s390 (32-bit)
...
+ /usr/bin/echo Generating stubs from JDK sources.
Generating stubs from JDK sources.
(/usr/lib/jvm/java-openjdk/bin/java -Xms64M -Xmx1100M -XX:PermSize=32m -XX:MaxPermSize=160m -XX:ThreadStackSize=1536 "-Xbootclasspath/p:/builddir/build/BUILD/java-1.8.0-openjdk/jdk8/build/jdk8.build/langtools/dist/bootstrap/lib/javac.jar" -classpath /builddir/build/BUILD/java-1.8.0-openjdk/jdk8/build/jdk8.build/langtools/btclasses genstubs.GenStubs -s /builddir/build/BUILD/java-1.8.0-openjdk/jdk8/build/jdk8.build/langtools/tmpstubs -sourcepath /builddir/build/BUILD/java-1.8.0-openjdk/jdk8/jdk/src/share/classes   java.util.function.Predicate && /usr/bin/echo STUBS_ARE_CREATED = yes > /builddir/build/BUILD/java-1.8.0-openjdk/jdk8/build/jdk8.build/langtools/genstubs/_the_stubs.d)
BuildLangtools.gmk:150: Building /builddir/build/BUILD/java-1.8.0-openjdk/jdk8/build/jdk8.build/langtools/genstubs/_the_stubs.d  (from /builddir/build/BUILD/java-1.8.0-openjdk/jdk8/jdk/src/share/classes/java/util/function/Predicate.java) (/builddir/build/BUILD/java-1.8.0-openjdk/jdk8/jdk/src/share/classes/java/util/function/Predicate.java /builddir/build/BUILD/java-1.8.0-openjdk/jdk8/build/jdk8.build/langtools/btclasses/_the.BUILD_TOOLS_batch /builddir/build/BUILD/java-1.8.0-openjdk/jdk8/build/jdk8.build/langtools/dist/bootstrap/lib/javac.jar /builddir/build/BUILD/java-1.8.0-openjdk/jdk8/build/jdk8.build/langtools/gensrc/_the_props.d  newer)
+ /usr/lib/jvm/java-openjdk/bin/java -Xms64M -Xmx1100M -XX:PermSize=32m -XX:MaxPermSize=160m -XX:ThreadStackSize=1536 -Xbootclasspath/p:/builddir/build/BUILD/java-1.8.0-openjdk/jdk8/build/jdk8.build/langtools/dist/bootstrap/lib/javac.jar -classpath /builddir/build/BUILD/java-1.8.0-openjdk/jdk8/build/jdk8.build/langtools/btclasses genstubs.GenStubs -s /builddir/build/BUILD/java-1.8.0-openjdk/jdk8/build/jdk8.build/langtools/tmpstubs -sourcepath /builddir/build/BUILD/java-1.8.0-openjdk/jdk8/jdk/src/share/classes java.util.function.Predicate
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.
Error occurred during initialization of VM
Could not reserve enough space for object heap
gmake[1]: Leaving directory `/builddir/build/BUILD/java-1.8.0-openjdk/jdk8/langtools/make'
gmake[1]: *** No rule to make target `all', needed by `default'.  Stop.
make: *** [langtools-only] Error 2

I have tried various -Xmx values, for 800 it fails with

#
# There is insufficient memory for the Java Runtime Environment to continue.
# pthread_getattr_np
# An error report file with more information is saved as:
# /tmp/jvm-24104/hs_error.log
gmake[1]: *** [/builddir/build/BUILD/java-1.8.0-openjdk/jdk8/build/jdk8.build/langtools/classes/_the.BUILD_FULL_JAVAC_batch] Error 1
gmake[1]: Leaving directory `/builddir/build/BUILD/java-1.8.0-openjdk/jdk8/langtools/make'
make: *** [langtools-only] Error 2

for 900, 1100, 1300 it fails with the error in comment #17

I've also tried setting ThreadStackSize to 768 (as used in 32 bit builds), but no change

resolved/workarounded by 

diff -up jdk8/common/autoconf/boot-jdk.m4.s390 jdk8/common/autoconf/boot-jdk.m4
--- jdk8/common/autoconf/boot-jdk.m4.s390	2014-03-11 16:01:27.000000000 -0400
+++ jdk8/common/autoconf/boot-jdk.m4	2014-05-21 11:50:36.507890197 -0400
@@ -315,12 +315,12 @@ AC_DEFUN_ONCE([BOOTJDK_SETUP_BOOT_JDK_AR
     fi
 
     # Minimum amount of heap memory.
-    ADD_JVM_ARG_IF_OK([-Xms64M],boot_jdk_jvmargs,[$JAVA])
+    ADD_JVM_ARG_IF_OK([-Xms256M],boot_jdk_jvmargs,[$JAVA])
     if test "x$OPENJDK_TARGET_OS" = "xmacosx"; then
       # Why does macosx need more heap? Its the huge JDK batch.
       ADD_JVM_ARG_IF_OK([-Xmx1600M],boot_jdk_jvmargs,[$JAVA])
     else
-      ADD_JVM_ARG_IF_OK([-Xmx1100M],boot_jdk_jvmargs,[$JAVA])
+      ADD_JVM_ARG_IF_OK([-Xmx512M],boot_jdk_jvmargs,[$JAVA])
     fi
     # When is adding -client something that speeds up the JVM?
     # ADD_JVM_ARG_IF_OK([-client],boot_jdk_jvmargs,[$JAVA])

as suggested by aph

I'll close this once I have a build in s390 koji.

built as http://s390.koji.fedoraproject.org/koji/buildinfo?buildID=242358