Openj9: JDK11: Intermittent BootstrapMethodError building/testing
We are seeing intermittent build or test errors on our Jenkins builds of jdk11 head, is this an OpenJ9 MethodHandle issue?
See logs: https://hyc-rt-openjdk-jenkins.swg-devops.com/job/verify_ibmsdk_build/220/console
16:35:09 java.lang.reflect.InvocationTargetException
16:35:09 at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@11-internal/Native Method)
16:35:09 at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@11-internal/NativeMethodAccessorImpl.java:62)
16:35:09 at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@11-internal/DelegatingMethodAccessorImpl.java:43)
16:35:09 at java.lang.reflect.Method.invoke(java.base@11-internal/Method.java:564)
16:35:09 at com.sun.javatest.regtest.agent.RegressionCompileCommand.run(RegressionCompileCommand.java:190)
16:35:09 at com.sun.javatest.regtest.agent.CompileActionHelper.runCompile(CompileActionHelper.java:91)
16:35:09 at com.sun.javatest.regtest.agent.AgentServer.doCompile(AgentServer.java:210)
16:35:09 at com.sun.javatest.regtest.agent.AgentServer.run(AgentServer.java:180)
16:35:09 at com.sun.javatest.regtest.agent.AgentServer.main(AgentServer.java:59)
16:35:09 Caused by: java.lang.BootstrapMethodError: java.lang.IllegalArgumentException: Host class com/sun/tools/javac/util/JavacMessages and anonymous class com/sun/tools/javac/util/JavacMessages$$Lambda$/ are in different packages
16:35:09 at com.sun.tools.javac.util.JavacMessages.add(jdk.compiler@11-internal/JavacMessages.java:106)
16:35:09 at com.sun.tools.javac.util.JavacMessages.<init>(jdk.compiler@11-internal/JavacMessages.java:96)
16:35:09 at com.sun.tools.javac.util.JavacMessages.<init>(jdk.compiler@11-internal/JavacMessages.java:79)
16:35:09 at com.sun.tools.javac.util.JavacMessages.instance(jdk.compiler@11-internal/JavacMessages.java:53)
16:35:09 at com.sun.tools.javac.util.JCDiagnostic$Factory.<init>(jdk.compiler@11-internal/JCDiagnostic.java:71)
16:35:09 at com.sun.tools.javac.util.JCDiagnostic$Factory.instance(jdk.compiler@11-internal/JCDiagnostic.java:61)
16:35:09 at com.sun.tools.javac.util.Log.<init>(jdk.compiler@11-internal/Log.java:351)
16:35:09 at com.sun.tools.javac.util.Log.<init>(jdk.compiler@11-internal/Log.java:254)
16:35:09 at com.sun.tools.javac.util.Log.instance(jdk.compiler@11-internal/Log.java:234)
16:35:09 at com.sun.tools.javac.main.Main.compile(jdk.compiler@11-internal/Main.java:192)
16:35:09 at com.sun.tools.javac.main.Main.compile(jdk.compiler@11-internal/Main.java:165)
16:35:09 at com.sun.tools.javac.Main.compile(jdk.compiler@11-internal/Main.java:75)
16:35:09 ... 9 more
16:35:09 Caused by: java.lang.IllegalArgumentException: Host class com/sun/tools/javac/util/JavacMessages and anonymous class com/sun/tools/javac/util/JavacMessages$$Lambda$/ are in different packages
16:35:09 at jdk.internal.misc.Unsafe.defineAnonymousClass(java.base@11-internal/Unsafe.java:1529)
16:35:09 at java.lang.invoke.InnerClassLambdaMetafactory.spinInnerClass(java.base@11-internal/InnerClassLambdaMetafactory.java:320)
16:35:09 at java.lang.invoke.InnerClassLambdaMetafactory.buildCallSite(java.base@11-internal/InnerClassLambdaMetafactory.java:188)
16:35:09 at java.lang.invoke.LambdaMetafactory.metafactory(java.base@11-internal/LambdaMetafactory.java:323)
16:35:09 at java.lang.invoke.DirectHandle.invokeExact_thunkArchetype_L(java.base@11-internal/DirectHandle.java:302)
16:35:09 at java.lang.invoke.AsTypeHandle.invokeExact_thunkArchetype_X(java.base@11-internal/AsTypeHandle.java:49)
16:35:09 at java.lang.invoke.MethodHandle.resolveInvokeDynamic(java.base@11-internal/MethodHandle.java:916)
andrew-m-leonard
All 52 comments
This is likely an issue with our implementation of Unsafe.defineAnonymousClass. Likely missing setting the package correctly for the anonymous class.
DanHeidinga
on 23 Mar 2018
packageID gets assigned in internalCreateRAMClassFromROMClass from createramclass.cpp. We may need to do something special for anonymous classes there.
Might not be as straight forward as copying the hostClass->packageID as packageIDs can be looked up in a hashtable on the classloader....
DanHeidinga
on 23 Mar 2018
@pdbain-ibm If get a chance, can you take a look at this?
DanHeidinga
on 26 Mar 2018
Will do. How urgent is this?
@andrew-m-leonard do you have a standalone test case for this? Would HelloWorld cause the problem?
pdbain-ibm
on 26 Mar 2018
@pdbain-ibm Unfortunately not... it works fine on my personal VM, but when we run builds on our Jenkin build infrastructure which are huge 96 core 256GbRAM VMs it fails just about all the time and just occasionally works. Please see logs here: https://hyc-rt-openjdk-jenkins.swg-devops.com/view/OpenJDK%20Green%20Board/job/build_openj9_jdk_nightly/
andrew-m-leonard
on 27 Mar 2018
I encountered this yesterday with a more normal-size VM (8 core, 16GB). After removing images/jmods/jdk.internal.le.jmod, restarting make images succeeded. Then removing images/jmods/* lead to the same failure.
keithc-ca
on 5 Apr 2018
@DanHeidinga @pdbain-ibm Anymore debug we can do on this please? our jdk11 builds fail every night with this... we're going to have to get to the bottom of it some how. Any clues?
@pshipton
andrew-m-leonard
on 23 Apr 2018
I haven't been able to work on this due to other higher priority tasks and don't anticipate getting to this soon. I wasn't able to reproduce the issue locally.
pdbain-ibm
on 23 Apr 2018
@andrew-m-leonard Can you generate a core at the time of the exception by running with -Xdump:java+system:events=throw+systhrow,filter=java/lang/IllegalArgumentException#jdk/internal/misc/Unsafe.defineAnonymousClass
To make it easy for the VM to pick up this option without having to hack the build scripts, use the (misnamed) IBM_JAVA_OPTIONS environment variable.
ie:
export IBM_JAVA_OPTIONS="-Xdump:java+system:events=throw+systhrow,filter=java/lang/IllegalArgumentException#jdk/internal/misc/Unsafe.defineAnonymousClass"
DanHeidinga
on 23 Apr 2018
I think this error occurred before in my OpenJ9-jdk11 build, will have a look if this can be reproduced locally.
JasonFengJ9
on 23 Apr 2018
@DanHeidinga @pdbain-ibm @JasonFengJ9
I did a bit of digging from looking at the stack, and I think i've found the "instigating" situation, but not sure how it happens.
- defineclass.c method hasSamePackageName(J9ROMClass *anonROMClass, J9ROMClass *hostROMClass) gets called with anonROMClass set to => "jdk/tools/jmod/JmodTask$JmodFileWriter$$Lambda$//000000002049E2D0"
- in that method it calls pkgname.c packageNameLength(J9ROMClass* romClass) which works out the package name length incorrectly as 47 due to the anon class for some reason having a double "//" at the end...
How does it get the double "//" ....?
andrew-m-leonard
on 23 Apr 2018
Since it is intermittent, is there some multi-threading occuring where 2 threads check for the ending "/" and both add one or something if it does have it...!?!
andrew-m-leonard
on 23 Apr 2018
Yes, this hack in pkgname.c seems to fix it for me, just need to figure out why it's like that...??!
packageNameLength(J9ROMClass* romClass)
{
const J9UTF8* className = J9ROMCLASS_CLASSNAME(romClass);
const BOOLEAN isAnonClass = J9_ARE_ANY_BITS_SET(romClass->extraModifiers, J9AccClassAnonClass);
BOOLEAN foundFirstSlash = FALSE;
UDATA result = 0;
IDATA i = J9UTF8_LENGTH(className) - 1;
for (; i >= 0; i--) {
if (J9UTF8_DATA(className)[i] == '/') {
/* Lambda names contain a '/'. If romClass is an anonymous class, find the second last '/'. */
if (!isAnonClass || foundFirstSlash) {
result = (UDATA)i;
break;
}
if (i>0 && J9UTF8_DATA(className)[i-1] == '/') { //HACK
//HACK: If we have an erroneous anon class ending with a double // ...skip 2nd/ //HACK
i--; //HACK
} //HACK
foundFirstSlash = TRUE;
}
}
return result;
}
By adding a printf to ROMClassBuilder.cpp for the anonymous original classname, I can see when it goes wrong it has got the originalStringLength of the className wrong by 1 character too long, it then fails when by "chance" the extra character is a "/", hence why it is intermittent...
ROMCLASSNAME orig: java/util/stream/Collectors$$Lambda$12
ROMCLASSNAME orig: java/util/stream/Collectors$$Lambda$13
ROMCLASSNAME orig: java/util/stream/Collectors$$Lambda$14
ROMCLASSNAME orig: java/util/stream/Collectors$$Lambda$15
ROMCLASSNAME orig: jdk/internal/loader/BuiltinClassLoader$$Lambda$
ROMCLASSNAME orig: jdk/internal/module/SystemModuleFinders$1$$Lambda$
ROMCLASSNAME orig: jdk/internal/module/IllegalAccessMaps$$Lambda$
ROMCLASSNAME orig: jdk/internal/module/IllegalAccessMaps$$Lambda$
ROMCLASSNAME orig: jdk/internal/module/IllegalAccessMaps$$Lambda$
ROMCLASSNAME orig: jdk/internal/module/IllegalAccessMaps$$Lambda$
ROMCLASSNAME orig: jdk/internal/module/IllegalAccessMaps$$Lambda$
ROMCLASSNAME orig: jdk/internal/module/IllegalAccessMaps$$Lambda$
ROMCLASSNAME orig: java/util/stream/MatchOps$$Lambda$
ROMCLASSNAME orig: jdk/internal/module/IllegalAccessMaps$$Lambda$
ROMCLASSNAME orig: jdk/internal/module/IllegalAccessMaps$$Lambda$
ROMCLASSNAME orig: jdk/internal/module/IllegalAccessMaps$$Lambda$
ROMCLASSNAME orig: jdk/internal/loader/BuiltinClassLoader$$Lambda$
ROMCLASSNAME orig: java/lang/ClassLoader$$Lambda$
ROMCLASSNAME orig: java/util/ResourceBundle$$Lambda$
ROMCLASSNAME orig: java/util/ResourceBundle$ResourceBundleProviderHelper$$Lambda$
ROMCLASSNAME orig: java/util/ResourceBundle$ResourceBundleProviderHelper$$Lambda$
ROMCLASSNAME orig: java/util/ResourceBundle$ResourceBundleProviderHelper$$Lambda$!
ROMCLASSNAME orig: java/util/regex/Pattern$$Lambda$"
ROMCLASSNAME orig: java/util/regex/Pattern$BitClass$$Lambda$#
ROMCLASSNAME orig: java/util/regex/Pattern$$Lambda$$
ROMCLASSNAME orig: java/util/regex/Pattern$CharPredicate$$Lambda$%
ROMCLASSNAME orig: java/util/regex/Pattern$$Lambda$&
ROMCLASSNAME orig: jdk/tools/jmod/JmodTask$JmodFileWriter$$Lambda$'
ROMCLASSNAME orig: jdk/tools/jmod/JmodTask$JmodFileWriter$$Lambda$(
ROMCLASSNAME orig: jdk/tools/jmod/JmodTask$JmodFileWriter$$Lambda$)
ROMCLASSNAME orig: jdk/tools/jmod/JmodTask$JmodFileWriter$$Lambda$*
ROMCLASSNAME orig: jdk/tools/jmod/JmodTask$JmodFileWriter$$Lambda$+
ROMCLASSNAME orig: jdk/tools/jmod/JmodTask$JmodFileWriter$$Lambda$,
ROMCLASSNAME orig: jdk/tools/jmod/JmodTask$JmodFileWriter$$Lambda$-
ROMCLASSNAME orig: jdk/tools/jmod/JmodTask$JmodFileWriter$$Lambda$.
ROMCLASSNAME orig: jdk/tools/jmod/JmodTask$JmodFileWriter$$Lambda$/
make[3]: *** [/home/admin/mydocker/ccm/openj9-openjdk/build/linux-x86_64-normal-server-release/images/jmods/jdk.editpad.jmod] Error 1
It looks like something is cycling through the characters !"#$%&'()*+,-./ and / is a bad choice. Is OpenJ9 responsible for those lambda names?
keithc-ca
on 24 Apr 2018
@keithc-ca I'm just debugging java/lang/invoke/InnerClassLambdaMetafactory.java at the moment which generates the Lambda+\
The classname is constructed as:
String className = .... "Lambda$" + atomicInteger.incrementAndGet();
I don't understand how the \
andrew-m-leonard
on 24 Apr 2018
AtomicInteger uses U.objectFieldOffset(AtomicInteger.class, "value"),
J9 added a new implementation for this method in JDK10, could this be a problem?
andrew-m-leonard
on 24 Apr 2018
I think we've found the problem: that + operator should do string concatenation with the effect being equivalent to calling StringBuilder.append(int) (not StringBuilder.append(char)). What does the bytecode for InnerClassLambdaMetafactory look like?
keithc-ca
on 24 Apr 2018
Could the fact that an atomicInteger is being auto-boxed to a String be causing an issue?
String className = .... "Lambda$" + atomicInteger.incrementAndGet(); <== ?
andrew-m-leonard
on 24 Apr 2018
@DanHeidinga @keithc-ca @JasonFengJ9 @pshipton I think I need some pearls of wisdom help please?!
i'm puzzled!??!
andrew-m-leonard
on 24 Apr 2018
I think OpenJ9 adds / blindly even there is / at end of the Lambdaclass name.
JasonFengJ9
on 24 Apr 2018
I'd like to see the output of javap -c -private java.lang.invoke.InnerClassLambdaMetafactory - specifically the constructor.
keithc-ca
on 24 Apr 2018
@andrew-m-leonard any chance I can access the machine that reproduces the failure? If it is not possible, can you provide the complete folder build/linux-x86_64-normal-server-release such that I can examine the JVM in question?
JasonFengJ9
on 24 Apr 2018
@JasonFengJ9 Yes, adding '/' blindly is fine, the problem as @keithc-ca eludes to is the java code that constructs the name and appends an "int" String is going wrong and adding a random odd character at the end rather than the String converted "int" value...
andrew-m-leonard
on 25 Apr 2018
@keithc-ca I maybe wrong, but the byte code looks good?
78: new #21 // class java/lang/StringBuilder
81: dup
82: invokespecial #22 // Method java/lang/StringBuilder."<init>":()V
85: aload_0
86: getfield #23 // Field targetClass:Ljava/lang/Class;
89: invokevirtual #12 // Method java/lang/Class.getName:()Ljava/lang/String;
92: bipush 46
94: bipush 47
96: invokevirtual #13 // Method java/lang/String.replace:(CC)Ljava/lang/String;
99: invokevirtual #24 // Method java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/StringBuilder;
102: ldc #25 // String $$Lambda$
104: invokevirtual #24 // Method java/lang/StringBuilder.append:(Ljava/lang/String;)Ljava/lang/StringBuilder;
107: getstatic #26 // Field counter:Ljava/util/concurrent/atomic/AtomicInteger;
110: invokevirtual #27 // Method java/util/concurrent/atomic/AtomicInteger.incrementAndGet:()I
113: invokevirtual #28 // Method java/lang/StringBuilder.append:(I)Ljava/lang/StringBuilder;
116: invokevirtual #29 // Method java/lang/StringBuilder.toString:()Ljava/lang/String;
119: putfield #9 // Field lambdaClassName:Ljava/lang/String;
@keithc-ca @JasonFengJ9 Here's some of my debug output when it goes wrong, it looks as though the counter "string" which presumably should be Strings $105, $106, $107,... is getting added as a plain unicode value possibly:
ROMCLASSNAME orig: jdk/tools/jlink/builder/DefaultImageBuilder$$Lambda$\u0105
ROMCLASSNAME orig: jdk/tools/jlink/builder/DefaultImageBuilder$$Lambda$\u0106
ROMCLASSNAME orig: jdk/tools/jlink/builder/DefaultImageBuilder$$Lambda$\u0107
@keithc-ca @JasonFengJ9 Could this be a JIT optimization issue, since our StringBuffer.append(int) is optimized looking at the first comment:
public StringBuilder append(int value) {
/*[PR JAZZ103 69835] This implementation is optimized for the JIT */
andrew-m-leonard
on 25 Apr 2018
@andrew-m-leonard you might run the build with IBM_JAVA_OPTIONS set to -Xint to check if this is JIT related.
JasonFengJ9
on 25 Apr 2018
I would suspect String compression before I suspected the JIT in this case. There's an option (don't know it off the top of my head) to force the JVM to use non-compressed strings. I'd give that a try and see if makes a difference.
DanHeidinga
on 25 Apr 2018
@keithc-ca @JasonFengJ9 Some sort of good news, i've managed to create a standalone testcase, that fails every time for me. Note, it ONLY fails because we compile our source with "-XDstringConcat=inline"
TestJava.zip
- Compile NumStr.java and Thingy.java using a suitable bootjdk (eg.jdk10) using the following options:
javac -XDstringConcat=inline *.java - Run using an openjdk11 with OpenJ9 JDK. So if you've got a build of jdk11 use that jdk...
java -cp . NumStr
...
ERROR: NumStr$$Lambda$\ucc33
ERROR: NumStr$$Lambda$\ucc34
ERROR: NumStr$$Lambda$\uaf28
ERROR: NumStr$$Lambda$\ucc37
andrew-m-leonard
on 25 Apr 2018
Note, if I run it using JDK10 with OpenJ9, or JDK11 with HotSpot, it works fine...
andrew-m-leonard
on 25 Apr 2018
@JasonFengJ9 You're a star!, yes, i've just set IBM_JAVA_OPTIONS to -Xint, and it fixes the problem with my standalone testcase!
andrew-m-leonard
on 25 Apr 2018
@andrew-m-leonard could you try -XX:+CompactStrings or -XX:-CompactStrings respectively? This is to check if the string compression has a role in this failure as per Dan's comment earlier.
JasonFengJ9
on 25 Apr 2018
Just tried -XX:+CompactStrings or -XX:-CompactStrings, and they make no difference...
It seems only export IBM_JAVA_OPTIONS=-Xint fixes it
andrew-m-leonard
on 25 Apr 2018
@DanHeidinga Please can you assign this issue to the JIT team?
andrew-m-leonard
on 25 Apr 2018
@DanHeidinga @pshipton I am going to add a temporary workaround patch to the extensions makefile to export IBM_JAVA_OPTIONS=-Xint, there by we can at least get a good build...
andrew-m-leonard
on 25 Apr 2018
FYI @fjeremic @andrewcraik @mstoodle - Paging our JIT experts :) Can you offer some suggestions on tracking down this potential JIT bug?
We're seeing an issue that doesn't happen at -Xint in java/lang/StringBuilder.append:(I)Ljava/lang/StringBuilder; where the int value isn't being converted correctly to a string when appending it.
DanHeidinga
on 25 Apr 2018
How exactly does one get a build of JDK11 with OpenJ9? I would be glad to take a look but I don't have a build handy that I can use. It appears https://github.ibm.com/runtimes/openj9-openjdk-jdk11 does not exist (yet).
Can you offer some suggestions on tracking down this potential JIT bug?
As far as suggestions go does limiting to this method still make it fail? i.e. trying:
-Xjit:limit={java/lang/StringBuilder.append:(I)Ljava/lang/StringBuilder;}
fjeremic
on 25 Apr 2018
@fjeremic The repo you need is https://github.ibm.com/runtimes/openj9-openjdk clone branch "openj9-jdk".
andrew-m-leonard
on 25 Apr 2018
@fjeremic This is OpenJDK (head), which will become JDK11 sometime in June when the OpenJDK community branch off the JDK11 stream...
andrew-m-leonard
on 25 Apr 2018
@fjeremic You may hit the "bug" when trying to build this yourself... if you do simply re-try "make all" a few times until it works...! the "bug" is intermittent depending on whether the random int String conversion happens to be a '/' character during the build!!
andrew-m-leonard
on 25 Apr 2018
Ok, I'll kick off the JDK build locally and try to reproduce your unit test case, confirm that it is a JIT failure, and do an initial investigation.
fjeremic
on 25 Apr 2018
Thanks Filip
andrew-m-leonard
on 25 Apr 2018
This is a JIT bug. It can be reproduced via the following command:
java -cp . -Xjit:'limit={Thingy.<init>(ILjava/lang/Class;)V}(optlevel=cold,tracefull,log=log.trace,lastOptIndex=12,lastOptSubIndex=1)' NumStr
The issue is in the String Peepholes optimization. It attempts to transform the the following Java code:
s1 + s2 + i
where s1 and s2 and Strings and i is an integer into:
new String(s1, s2, i)
The former Java code will map to a StringBuilder.append sequence followed by a call to StringBuilder.toString(). This incurs quite a bit of path length, so a special private constructor was introduced to handle these cases:
Unfortunately there is no constructor to handle the above case of two strings and an integer. So there exists a bug in the optimization pass, as the trees get transformed from:
n18n NULLCHK on n15n
n17n call java/lang/StringBuilder.<init>(I)V
n15n ==>new
n86n iconst 29
n22n compressedRefs
n20n aloadi Thingy.targetClass Ljava/lang/Class;
n19n aload <'this' parm LThingy;>
n21n lconst 0
n24n NULLCHK on n20n
n23n acall java/lang/Class.getName()Ljava/lang/String;
n20n ==>aloadi
n28n NULLCHK on n23n
n27n acall java/lang/String.replace(CC)Ljava/lang/String;
n23n ==>acall
n25n iconst 46
n26n iconst 47
n30n NULLCHK on n15n [#30]
n29n acall java/lang/StringBuilder.append(Ljava/lang/String;)Ljava/lang/StringBuilder;
n27n ==>acall
n33n NULLCHK on n29n [#30]
n32n acall java/lang/StringBuilder.append(Ljava/lang/String;)Ljava/lang/StringBuilder;
n31n aload <string "$$Lambda$">
n38n NULLCHK on n32n
n37n acall java/lang/StringBuilder.append(I)Ljava/lang/StringBuilder;
n32n ==>acall
n35n ==>icall
n40n NULLCHK on n37n
n39n acall java/lang/StringBuilder.toString()Ljava/lang/String;
n37n ==>acall
to
n24n NULLCHK on n20n [#30]
n23n acall java/lang/Class.getName()Ljava/lang/String;
n20n ==>aloadi
n28n NULLCHK on n23n [#30]
n27n acall java/lang/String.replace(CC)Ljava/lang/String;
n25n iconst 46
n26n iconst 47
n30n treetop
n27n ==>acall
n33n treetop
n31n aload <string "$$Lambda$">
n36n NULLCHK on n34n [#30]
n35n icall java/util/concurrent/atomic/AtomicInteger.incrementAndGet()I
n34n aload Thingy.cc Ljava/util/concurrent/atomic/AtomicInteger;
n38n treetop
n35n ==>icall
n91n treetop
n90n acall java/lang/String.valueOfCodePoint(I)Ljava/lang/String;
n35n ==>icall
n40n treetop
n39n new jitNewObjec
n94n loadaddr java/lang/String[#653 Static]
n96n treetop
n95n call java/lang/String.<init>(Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;)V
n27n ==>acall
n31n ==>aload
n90n ==>acall
So it seems because there is no string string integer constructor, it tries to use a string string string constructor as the one referenced above. To achieve this though the transformation introduces n90n which attempts to transform an integer into a String. But clearly valueOfCodePoint is not the right method to do this. It should be just valueOf.
I'll see if I can muster up some time to take a look at the fix for this, however I will be unreachable after Friday so I may have to delegate. Subscribing some folks which work on the optimizer here as we will need a proper fix @jdmpapin @cathyzhyi @andrewcraik @vijaysun-omr.
Attaching JIT trace log for reference:
log.trace.txt
@andrew-m-leonard if you need a workaround -Xjit:disableStringPeepholes will alleviate the problem.
fjeremic
on 25 Apr 2018
This also explains why you would see weird Unicode characters. It is because the JIT incorrectly introduces a valueOfCodePoint call instead of a valueOf call. So an integer such as 47 would get incorrectly appended to the string as / (47 is the code point for the character /) instead of the actual integer 4 and 7 being appended.
fjeremic
on 25 Apr 2018
@fjeremic Oddly I tried "-Xjit:disableStringPeepholes" and it does seem to avoid the issue, but we seem to get "java/lang/OutOfMemoryError: Java heap space" errors instead now! If I use "-Xint" instead it all seems to work fine.
Is something being greedy with memory?!
andrew-m-leonard
on 26 Apr 2018
Ah, think i've found something that's not helping for the OutOfmemory, on our build machines it is incorrectly working out the 32/64bit of the bootJDK as 32bit and choosing a small heap size, i'll raise a separate issue for that.
andrew-m-leonard
on 26 Apr 2018
Is someone currently working the JIT fix for this?
andrew-m-leonard
on 1 May 2018
@cathyzhyi - in @andrewcraik's and @fjeremic 's absence can you have a look at it
irinarada
on 1 May 2018
ok, I will take a look.
cathyzhyi
on 1 May 2018
The problem is due to JCL change adding java/lang/String.valueOfCodePoint which confuses the logic in StringPeepHole looking for java/lang/String.valueOf
This should be fixed by https://github.com/eclipse/openj9/pull/1872
cathyzhyi
on 8 May 2018
This issue should be fixed now by #2011
mpirvu
on 30 May 2018
Related issues
zl-wang
路
94Comments
markehammons
路
63Comments
fjeremic
路
62Comments
pshipton
路
62Comments
pshipton
路
64Comments