Compiling openjdk8 takes forever on RPI4.

Thu Mar 25 13:00:44 UTC 2021

I'm happy to extend that option to arm64, but I'm curious as to what
might be contributing here.

One thing is that the newly compiled code is hardly used at all in the
build, IIRC, so I have to wonder how enabling FPUHACK made the build
faster at all unless you built twice with it enabled.  But it doesn't
sound like that was the situation?  Another factor is that you're
building in a jail and that -CURRENT is involved somehow.  Did the
version of -CURRENT change at all across the different builds?

-- Greg

On 3/22/21 3:15 PM, Ronald Klop wrote:
>
> Van: Ronald Klop <ronald-lists at klop.ws>
> Datum: maandag, 22 maart 2021 18:11
> Aan: java at freebsd.org, arm at freebsd.org
> Onderwerp: Compiling openjdk8 takes forever on RPI4.
>>
>> Hi,
>>
>> I'm using poudriere to compile ports. It runs on an RPI4 8GB.
>> FreeBSD jail13 14.0-CURRENT #6 main-34d696110: Sat Feb 27 05:01:05
>> CET 2021
>>
>> Compilation is already going on for the second days. I have compiled
>> this port in the past in a couple of hours. NB: this compiles fine in
>> the official pkg builders.
>> http://www.ipv6proxy.net/go.php?u=http%3A%2F%2Fampere2.nyi.freebsd.org%2Fdata%2Fmain-arm64-default%2Fp568824_s7af04dff02%2Flogs%2Fopenjdk8-8.282.08.1.log&b=0&f=norefer
>>
>>
>> I used jstack to look at what it is doing. The main stack which keeps
>> showing up is this:
>>
>> "main" #1 prio=5 os_prio=15 tid=0x0000000041c41000 nid=0x3f560
>> runnable [0x0000ffffbfff8000]
>>    java.lang.Thread.State: RUNNABLE
>>     at sun.misc.FDBigInteger.rightInplaceSub(FDBigInteger.java:890)
>>     at
>> sun.misc.FloatingDecimal$ASCIIToBinaryBuffer.doubleValue(FloatingDecimal.java:1357)
>>     at sun.misc.FloatingDecimal.parseDouble(FloatingDecimal.java:110)
>>     at java.lang.Double.parseDouble(Double.java:538)
>>     at java.lang.Double.valueOf(Double.java:502)
>>     at
>> com.sun.tools.javac.parser.JavacParser.literal(JavacParser.java:720)
>>     at
>> com.sun.tools.javac.parser.JavacParser.literal(JavacParser.java:659)
>>     at
>> com.sun.tools.javac.parser.JavacParser.term3(JavacParser.java:1196)
>>     at
>> com.sun.tools.javac.parser.JavacParser.term2(JavacParser.java:909)
>>     at
>> com.sun.tools.javac.parser.JavacParser.term1(JavacParser.java:880)
>>     at com.sun.tools.javac.parser.JavacParser.term(JavacParser.java:836)
>>     at com.sun.tools.javac.parser.JavacParser.term(JavacParser.java:816)
>>     at
>> com.sun.tools.javac.parser.JavacParser.parseExpression(JavacParser.java:779)
>>     at
>> com.sun.tools.javac.parser.JavacParser.variableInitializer(JavacParser.java:2291)
>>     at
>> com.sun.tools.javac.parser.JavacParser.variableDeclaratorRest(JavacParser.java:3035)
>>     at
>> com.sun.tools.javac.parser.JavacParser.variableDeclaratorsRest(JavacParser.java:3006)
>>     at
>> com.sun.tools.javac.parser.JavacParser.classOrInterfaceBodyDeclaration(JavacParser.java:3537)
>>     at
>> com.sun.tools.javac.parser.JavacParser.classOrInterfaceBody(JavacParser.java:3436)
>>     at
>> com.sun.tools.javac.parser.JavacParser.classDeclaration(JavacParser.java:3285)
>>     at
>> com.sun.tools.javac.parser.JavacParser.classOrInterfaceOrEnumDeclaration(JavacParser.java:3226)
>>     at
>> com.sun.tools.javac.parser.JavacParser.typeDeclaration(JavacParser.java:3215)
>>     at
>> com.sun.tools.javac.parser.JavacParser.parseCompilationUnit(JavacParser.java:3155)
>>     at
>> com.sun.tools.javac.main.JavaCompiler.parse(JavaCompiler.java:628)
>>     at
>> com.sun.tools.javac.main.JavaCompiler.complete(JavaCompiler.java:772)
>>     at
>> com.sun.tools.javac.main.JavaCompiler$1.complete(JavaCompiler.java:312)
>>     at com.sun.tools.javac.jvm.ClassReader.fillIn(ClassReader.java:2535)
>> ... more lines skipped for brevity...
>>
>> The tail of the buildlog is:
>> ...
>> [01:02:41] ## Starting jdk
>> ...
>> [01:05:50] [Error] encoded value was greater than 3:
>> encode(15.029411, 1.0, 14.0, 15.0)
>> [01:05:50] [Error] encoded value was less than 0: encode(-0.05882353,
>> 1.0, 24.0, 25.0)
>> [01:05:50] [Error] encoded value was greater than 3:
>> encode(15.029411, 1.0, 14.0, 15.0)
>> [01:05:50] [Error] encoded value was less than 0: encode(-0.05882353,
>> 1.0, 24.0, 25.0)
>> [01:05:57] [Error] Encountered Infinity: encode(-0.00877193, 0.0,
>> 7.0, 7.0)
>> [01:13:57] Verifying
>> /wrkdirs/usr/ports/java/openjdk8/work/openjdk-jdk8u-jdk8u282-b08.1/build/bsd-aarch64-normal-zero-release/jdk/gensrc_x11wrappers/sizes.64.verification.tmp
>> to
>> /wrkdirs/usr/ports/java/openjdk8/work/openjdk-jdk8u-jdk8u282-b08.1/build/bsd-aarch64-normal-zero-release/jdk/gensrc_x11wrappers/sizes.64
>>
>>
>> And this is the last output for 32 hours already. I have no idea if
>> the last logline has anything todo with the current activity of the
>> compiling process.
>>
>> Any thoughts on how to fix or debug this? Would it be a Java, OS or
>> RPI4 problem?
>>
>> Regards,
>> Ronald.
>>  
>> _______________________________________________
>> freebsd-arm at freebsd.org mailing list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-arm
>> To unsubscribe, send any mail to "freebsd-arm-unsubscribe at freebsd.org"
>>
>>
>>
>
>
> Hi,
>
> I have no idea why, but it seams that enabling
> /usr/ports/java/openjdk8/files/fpuhack.patch on aarch64 fixes my build
> on 14.0/aarch64. Does this make sense? In the Makefile it was only
> enabled on armv6 and armv7.
>
> Regards,
> Ronald.
>
> _______________________________________________
> freebsd-java at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-java
> To unsubscribe, send any mail to "freebsd-java-unsubscribe at freebsd.org"