JDK-8028165 : assert(t->meet(t0) == t) failed: Not monotonic
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: hs25,9
  • Priority: P2
  • Status: Closed
  • Resolution: Duplicate
  • OS: linux
  • CPU: x86_64
  • Submitted: 2013-11-11
  • Updated: 2023-07-21
  • Resolved: 2023-07-21
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 9
9Resolved
Related Reports
Duplicate :  
JDK-8141551 - C2 can not handle returns with incompatible interface arrays
Relates :  
JDK-8141551 - C2 can not handle returns with incompatible interface arrays
Description
I ran into an assert when running lucene using a debug build of hotspot-comp. I do not get the crash every time, empirically I'd say it reproduces every 4th time or so.

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (lucene/src/share/vm/opto/phaseX.cpp:1428), pid=32214, tid=139795492837120
#  assert(t->meet(t0) == t) failed: Not monotonic
#
# JRE version: Java(TM) SE Runtime Environment (8.0-b114) (build 1.8.0-ea-b114)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (25.0-b58-internal-debug mixed mode linux-amd64 compressed oops)
# Core dump written. Default location: lucene/lucene/trunk/lucene/build/core/test/J0/core or core.32214
#
# If you would like to submit a bug report, please visit:
#   http://bugreport.sun.com/bugreport/crash.jsp
#

---------------  T H R E A D  ---------------

Current thread (0x00007f24c018a000):  JavaThread "C2 CompilerThread1" daemon [_thread_in_native, id=32230, stack(0x00007f24aca11000,0x00007f24acb12000)]

Stack: [0x00007f24aca11000,0x00007f24acb12000],  sp=0x00007f24acb0be70,  free space=1003k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0xce1ba6]  VMError::report(outputStream*)+0x10ea
V  [libjvm.so+0xce3066]  VMError::report_and_die()+0x42c
V  [libjvm.so+0x649230]  report_vm_error(char const*, int, char const*, char const*)+0x93
V  [libjvm.so+0xb6b7b4]  ccp_type_widens(Type const*, Type const*)+0x4e
V  [libjvm.so+0xb6b9cb]  PhaseCCP::analyze()+0x121
V  [libjvm.so+0xb6b716]  PhaseCCP::PhaseCCP(PhaseIterGVN*)+0x98
V  [libjvm.so+0x5d59e5]  Compile::Optimize()+0x8cd
V  [libjvm.so+0x5d00ac]  Compile::Compile(ciEnv*, C2Compiler*, ciMethod*, int, bool, bool, bool)+0x111a
V  [libjvm.so+0x506c71]  C2Compiler::compile_method(ciEnv*, ciMethod*, int)+0xf7
V  [libjvm.so+0x5e6e95]  CompileBroker::invoke_compiler_on_method(CompileTask*)+0x459
V  [libjvm.so+0x5e64fc]  CompileBroker::compiler_thread_loop()+0x334
V  [libjvm.so+0xc88c82]  compiler_thread_entry(JavaThread*, Thread*)+0x57
V  [libjvm.so+0xc842ab]  JavaThread::thread_main_inner()+0x14f
V  [libjvm.so+0xc8414d]  JavaThread::run()+0x163
V  [libjvm.so+0xb0f48e]  java_start(Thread*)+0x1c2


Current CompileTask:
C2: 453919 33602 %     4       com.carrotsearch.randomizedtesting.ClassModel$ModelBuilder::build @ 43 (245 bytes)
Comments
After JDK-8141551 has been pushed this bug is not reproducible any more. So I will close it as duplicate of JDK-8141551. If this problem should reappear, please reopen this bug and we can try to fix it as proposed in the previous comment.
26-11-2015
I agree with the analysis Mikael posted on 2013-11-27 03:54. I think this could be for example fixed by changing the code in TypeInstPtr::xmeet_helper() as follows: } else { // Does not implement, fall to Object // Oop does not implement interface, so mixing falls to Object // just like the verifier does (if both are above the // centerline fall to interface) k = above_centerline(ptr) ? tinst_klass : ciEnv::current()->Object_klass(); xk = above_centerline(ptr) ? tinst_xk : false; // Watch out for Constant vs. AnyNull interface. if (ptr == Constant) ptr = NotNull; // forget it was a constant - instance_id = InstanceBot; + instance_id = above_centerline(ptr) ? instance_id : InstanceBot; } i.e. only fall to bottom if we did fall to Object and use the previous value of the instance_id if we did fall to interface. I verified that the change indeed fixes this problem, but I'm not completely sure that it doesn't break anything else (I've only run the JCK vm and lang tests w/o -Xcomp and the solar testsuite so far). The problem with not fixing this is that this bug is related to "JDK-8141551 C2 can not handle returns with incompatible interface arrays" and once that one will be fixed as proposed in http://cr.openjdk.java.net/~simonis/webrevs/2015/8141551.v3/ it will also fix or at least shadow this bug (i.e. it will not be possible to reproduce it any more with the provided test case. Currently, the bug appears PhaseCCP::analyze() when we are working on a Phi node (node 4416 in this example): 3574 CallStaticJava === 3580 246 3572 8 1 ( 3587 3544 1 89 115 3444 1 1 1 1 1 1 1 1 1 1 1 1 1 ) [[ 3588 3589 3590 3592 ]] # Static java.lang.Class::getDeclaredFields narrowoop: java/lang/reflect/Field:exact *[int:>=0]:exact * ( java/lang/Class:NotNull:exact * ) ClassModel$4::members @ bci:1 ClassModel$4::members @ bci:2 ClassModel$ModelBuilder::build @ bci:30 !jvms: ClassModel$4::members @ bci:1 ClassModel$4::members @ bci:2 ClassModel$ModelBuilder::build @ bci:30 4100 CallStaticJava === 3689 3690 3691 8 1 ( 3693 3533 1 89 115 3444 1 1 1 1 1 1 1 1 1 1 1 1 1 1 ) [[ 4101 4102 4103 4105 ]] # Static java.lang.Class::copyMethods narrowoop: java/lang/reflect/Method:exact *[int:>=0]:exact * ( narrowoop: java/lang/reflect/Method:exact *[int:>=0]:exact * ) Class::getDeclaredMethods @ bci:14 ClassModel$3::members @ bci:1 ClassModel$3::members @ bci:2 ClassModel$ModelBuilder::build @ bci:30 !jvms: Class::getDeclaredMethods @ bci:14 ClassModel$3::members @ bci:1 ClassModel$3::members @ bci:2 ClassModel$ModelBuilder::build @ bci:-1 3592 Proj === 3574 [[ 4154 3604 3604 ]] #5 !jvms: ClassModel$4::members @ bci:1 ClassModel$4::members @ bci:2 ClassModel$ModelBuilder::build @ bci:30 4105 Proj === 4100 [[ 4154 4120 4120 ]] #5 !jvms: Class::getDeclaredMethods @ bci:14 ClassModel$3::members @ bci:1 ClassModel$3::members @ bci:2 ClassModel$ModelBuilder::build @ bci:-1 4154 Phi === 4149 4105 3592 [[ 4158 4170 ]] #narrowoop: java/lang/reflect/AccessibleObject *[int:>=0] * !jvms: ClassModel$ModelBuilder::build @ bci:-1 4170 CastPP === 4163 4154 [[ 4171 4171 4416 ]] #narrowoop: java/lang/reflect/AccessibleObject *[int:>=0]:NotNull * !jvms: ClassModel$ModelBuilder::build @ bci:37 4416 Phi === 4411 275 4170 [[ 250 ]] #narrowoop: java/lang/reflect/Member *[int:>=0]:NotNull * !orig=250 !jvms: ClassModel$ModelBuilder::build @ bci:43 As you can see, it depends on the two CallStaticJava nodes which return a Field[] and a Method[] array respectively and which are merged to a AccessibleObject[]. This will be met with a Member[] in the Phi node which leds to the problems already described in the comments before. Now with the proposed fix for JDK-8141551, the graph will change as follows: 3574 CallStaticJava === 3580 246 3572 8 1 ( 3587 3544 1 89 115 3444 1 1 1 1 1 1 1 1 1 1 1 1 1 ) [[ 3588 3589 3590 3592 ]] # Static java.lang.Class::getDeclaredFields narrowoop: java/lang/reflect/Field:exact *[int:>=0]:exact * ( java/lang/Class:NotNull:exact * ) ClassModel$4::members @ bci:1 ClassModel$4::members @ bci:2 ClassModel$ModelBuilder::build @ bci:30 !jvms: ClassModel$4::members @ bci:1 ClassModel$4::members @ bci:2 ClassModel$ModelBuilder::build @ bci:30 4100 CallStaticJava === 3689 3690 3691 8 1 ( 3693 3533 1 89 115 3444 1 1 1 1 1 1 1 1 1 1 1 1 1 1 ) [[ 4101 4102 4103 4105 ]] # Static java.lang.Class::copyMethods narrowoop: java/lang/reflect/Method:exact *[int:>=0]:exact * ( narrowoop: java/lang/reflect/Method:exact *[int:>=0]:exact * ) Class::getDeclaredMethods @ bci:14 ClassModel$3::members @ bci:1 ClassModel$3::members @ bci:2 ClassModel$ModelBuilder::build @ bci:30 !jvms: Class::getDeclaredMethods @ bci:14 ClassModel$3::members @ bci:1 ClassModel$3::members @ bci:2 ClassModel$ModelBuilder::build @ bci:-1 3592 Proj === 3574 [[ 3626 3604 3604 ]] #5 !jvms: ClassModel$4::members @ bci:1 ClassModel$4::members @ bci:2 ClassModel$ModelBuilder::build @ bci:30 4105 Proj === 4100 [[ 4142 4120 4120 ]] #5 !jvms: Class::getDeclaredMethods @ bci:14 ClassModel$3::members @ bci:1 ClassModel$3::members @ bci:2 ClassModel$ModelBuilder::build @ bci:-1 3626 CheckCastPP === _ 3592 [[ 4154 ]] #narrowoop: java/lang/reflect/Member *[int:>=0] * !jvms: ClassModel$4::members @ bci:5 ClassModel$ModelBuilder::build @ bci:30 4142 CheckCastPP === _ 4105 [[ 4154 ]] #narrowoop: java/lang/reflect/Member *[int:>=0] * !jvms: ClassModel$3::members @ bci:5 ClassModel$ModelBuilder::build @ bci:-1 4154 Phi === 4149 4142 3626 [[ 4158 4170 ]] #narrowoop: java/lang/reflect/Member *[int:>=0] * !jvms: ClassModel$ModelBuilder::build @ bci:-1 4170 CastPP === 4163 4154 [[ 4171 4171 4416 ]] #narrowoop: java/lang/reflect/Member *[int:>=0]:NotNull * !jvms: ClassModel$ModelBuilder::build @ bci:37 4416 Phi === 4411 275 4170 [[ 250 ]] #narrowoop: java/lang/reflect/Member *[int:>=0] * !orig=250 !jvms: ClassModel$ModelBuilder::build @ bci:43 because the fix for JDK-8141551 will add CheckCast nodes which cast instance-arrays to interface-arrays when they meet. This results in the Phi node 4154 having the type Member[] and this will nicely meet with Member[] of PhiNode 4416 which previously caused the problem. I'm only not sure if the fix for JDK-8141551 catches really all the incarnations of this bug or if a fix of TypeInstPtr::xmeet_helper() as proposed above is still necessary? I'd suggest to close this as duplicate of JDK-8141551 once that has been fixed. If we will still see this assertion after that fix, we can reopen this bug and try with the proposed fix. What do you think?
17-11-2015
I think in the "David's last comment" as posted by Christian above there's a typo in the third paragraph. In my opinion it only makes sense if it reads as "...consider combining ... a Method[] and a Field[]; both are (class) AccessibleObject and also (interface) Member, but AccessibleObject is not also a Member, so the class-oriented meet lands at AccessibleObject[] (because it's an array of these things and arrays subtype) but what the source code wanted (and how it behaves) is to obtain a Member[].
17-11-2015
David's last comment: Mikael Vidstedt got part way into this, and my understanding is about the same as his. I think that the symmetric lattice code is just plain overclever and buggy (clearly it is buggy, we have this bug). The problem comes from a combo of (at least) interface types not conforming quite to the Java type system, and Java's attempts to do array subtyping. Mikael says: "As part of computing Value for the PhiNode we are meeting the element types in dual space. The element types are Member and AccessibleObject respectively (an interface and a class, but the class does not implement the interface). The pointers are both TOP, as are the instance ids. The above code will however unconditionally make instance_id fall to bottom, and when the resulting type is later dualled instance id will be top and that does not blend." I attempted to reproduce this in a much smaller example, but so far have been unable to get it to fire. I suspect that it needs an unloaded class to appear in just the right place to make it go wrong. I've included the test case below. As an example of the problem, consider combining (I'm being vague about meet/join because there are two conventions for orientation and it was not even clear in the code which applied) a Member[] and a Field[]; both are (class) AccessibleObject and also (interface) Member, but AccessibleObject is not also a Member, so the class-oriented meet lands at AccessibleObject[] (because it's an array of these things and arrays subtype) but what the source code wanted (and how it behaves) is to obtain a Member[]. And this leads to heck. There is an alternate JVM type system, first described publicly around 15 years ago (by me, when I worked for NaturalBridge) and we sent it to the Java guys way back when, and they knew better than three guys in three garages. http://chasewoerner.org/verify_problem.html . I do not know offhand how to cast that type system into a symmetric lattice, though perhaps I could if I thought hard about it. To avoid the need to click the link, the short answer is that a "JVMtype" is a triple (class-type, interface-types, array-element-JVMtype), where class-type is a single Java class type, interface-types is a set of Java interface types, and array-element-JVMtype is the JVMtype of one of these elements or "null" if it is not an array, or (I think, depends on convention) bottom if the element types are unspeakable. So for example Float[] meet int[] gives you (Object, {Serializable, Cloneable}, TOP) because whatever is there is an array, thus Serializable and Cloneable, but the element type is unspeakable. In the case of this example, the JVMType would be (Object, {Cloneable, Serializable}, (AccessibleObject, {Member}, null)) This part of the IP is not owned by anyone; in theory Guy Steele may have a very old email in his mailbox informing him of this. We really thought this ought to be fixed, so we were prepared to give away the answer. There are some obvious improvements to the encoding -- no point including interfaces in the interface set that are implied by the Java class type, nor is there any point in including Cloneable and Serializable when the array-element-JVMtype is non-null. But, as I said, I was having a hard to convincing myself that replacing the JVM's type system was going to be a good idea, nor did I understand exactly what this means embedded into a symmetric lattice.
02-03-2015
Note -- if it fails, it fails on org.apache.lucene.search.TestBooleanScorer . If that executes successfully, kill it then and start over.
30-12-2014
Are these constraints imposed on the compiler, or constraints on the set of values that we may encounter? This stuff seems to be almost inherently ambiguous. (I think it is "constraints on the set of values" -- bottom means "the compiler/analysis does not know anything about what value the program may produce here, so it cannot optimize much at all", where "top" means that the compiler/analysis can assume whatever it wishes, so it is likely to be able optimize quite a bit.)
26-12-2014
[~jrose] has found a way of thinking about the direction of the lattice so it actually makes (some) sense: TOP is all constraints and BOTTOM is the set of empty constraints. I know it's not perfect but that's the way it is and the constraint way of thinking at least lets me wrap my head around it.
26-12-2014
I'd like to add, that the lattice code is woefully underdocumented, especially given that there are two conventions in lattice-based program analysis and they are vertically flipped from each other. "Data flow analysis" as I learned it assigned "TOP" to paths never taken, and "BOTTOM" to "don't know much" -- i.e., TOP = empty set and BOTTOM = all possible values. Based on Hecht, Davey/Priestley, and Nielson/Nielson/Hankin, the agreed-upon orientation is: SQ CUP = Join = LUB = Supremum = "towards most general" = "union" SQ CAP = Meet = GLB = Infimum = "towards most specific" = "intersection" TOP = 1 = "most general" = set of all BOTTOM = 0 = "most specific" = set of none x SUBTYPE y <=> x JOIN y = y <=> x = x MEET y This is upside down from what I learned originally. I think C2 uses the convention I learned, e.g., "fall to Object". Would be nice if the comments were a little more explicit about this. In particular, if the picture at line 3540 included placement of the node for "T is-subtype-or-equal Object", that would be helpful. And given the information I've been able to understand so far, and given that diagram, and despite claims, I don't believe that the lattice is symmetric -- I don't have a specific counter example, but from my understanding of what it means to be symmetric the pictures and the apparent operations lack nodes that I would expect to see -- and in particular, an analysis lattice that is symmetric would include some funny-looking nodes. For example, the dual of "is subtype or-equal-Foo AND is-not-null" is (I think) "null OR not-a-Foo", (these are the two arms of "instanceof Foo") and I don't see that in the diagram. I'd love to be proved wrong, and then I'd love to have that proof inserted into the code as a comment. I've had not much luck writing a regression test despite having the offending code in standalone form, and I am beginning to wonder if perhaps it depends on a more delicate interaction with not-null and/or speculated types.
25-12-2014
This looks more promising: https://github.com/carrotsearch/randomizedtesting/blob/master/randomized-runner/src/main/java/com/carrotsearch/randomizedtesting/ClassModel.java#L81
18-12-2014
And the resulting bytecodes make no sense for this bug (in particular, where is the method named build?) /Users/dr2chase/work/jdk9/build/macosx-x86_64-normal-server-fastdebug/jdk/bin/javap -classpath ./lucene/test-framework/lib/randomizedtesting-runner-2.1.9.jar -c -private 'com/carrotsearch/randomizedtesting/ClassModel$1' Compiled from "ClassModel.java" final class com.carrotsearch.randomizedtesting.ClassModel$1 implements java.util.Comparator<java.lang.reflect.Method> { com.carrotsearch.randomizedtesting.ClassModel$1(); Code: 0: aload_0 1: invokespecial #1 // Method java/lang/Object."<init>":()V 4: return public int compare(java.lang.reflect.Method, java.lang.reflect.Method); Code: 0: aload_1 1: invokevirtual #2 // Method java/lang/reflect/Method.toGenericString:()Ljava/lang/String; 4: aload_2 5: invokevirtual #2 // Method java/lang/reflect/Method.toGenericString:()Ljava/lang/String; 8: invokevirtual #3 // Method java/lang/String.compareTo:(Ljava/lang/String;)I 11: ireturn public int compare(java.lang.Object, java.lang.Object); Code: 0: aload_0 1: aload_1 2: checkcast #4 // class java/lang/reflect/Method 5: aload_2 6: checkcast #4 // class java/lang/reflect/Method 9: invokevirtual #5 // Method compare:(Ljava/lang/reflect/Method;Ljava/lang/reflect/Method;)I 12: ireturn }
18-12-2014
Method being compiled is "build", signature "(Ljava/lang/Class;)Ljava/util/LinkedHashMap;" In class com/carrotsearch/randomizedtesting/ClassModel$ModelBuilder In jar file ./lucene/test-framework/lib/randomizedtesting-runner-2.1.9.jar And also ./solr/test-framework/lib/randomizedtesting-runner-2.1.9.jar (perhaps they are the same?)
18-12-2014
Debugging tricks on MacOS Mavericks (and later), for future reference: - I've only been able to make the bug occur in a fastdebug image running the lucene ant script. - use _JAVA_OPTIONS environment variable. export _JAVA_OPTIONS=-XX:+ShowMessageBoxOnError - ant will eventually hang: ant test -Dtests.seed=43A1116E7F98BED4 -Dtests.jvms=1 -Dtests.dynamicAssignmentRatio=0 -Dargs="-XX:-UseSuperWord -XX:+ShowMessageBoxOnError -XX:CompileCommand=option,org.apache.lucene.util.packed.BlockPackedReaderIterator::next,UseSuperWord -XX:CompileCommand=option,org.apache.lucene.codecs.compressing.CompressingTermVectorsReader::readPositions,UseSuperWord" [junit4] HEARTBEAT J0 PID(66600@dr2chase.local): 2014-12-17T10:50:54, stalled for 47210s at: <unknown> [junit4] HEARTBEAT J0 PID(66600@dr2chase.local): 2014-12-17T10:51:54, stalled for 47270s at: <unknown> [junit4] HEARTBEAT J0 PID(66600@dr2chase.local): 2014-12-17T10:52:54, stalled for 47330s at: <unknown> [junit4] HEARTBEAT J0 PID(66600@dr2chase.local): 2014-12-17T10:53:54, stalled for 47390s at: <unknown> This is very useful for overnight debugging... - lldb cheat sheet: https://developer.apple.com/library/mac/documentation/IDEs/Conceptual/gdb_to_lldb_transition_guide/document/lldb-command-examples.html - Before you start lldb, get your current tty: dr2chase:bin dr2chase$ tty /dev/ttys000 dr2chase:bin dr2chase$ lldb ./java (lldb) target create "./java" Current executable set to './java' (x86_64). (lldb) attach -p 66600 Process 66600 stopped p Debugging=1 bt all // figure out which thread has the error thread select 13 // it was 13 for me, twice. p (int) open("/dev/ttys000", 131073) // it was 30 for me, twice. p tty=new fdStream(" /dev/null") // because the call you want is not there. p ((fdStream *) tty)->_fd=30 // Fix the file descriptor p tty->print_cr("A test") // Et voila!
17-12-2014
[~drchase], any updates on this bug?
15-12-2014
Unhandled nightly bug -> P1
15-12-2014
The problem is most likely in TypeInstPtr::xmeet_helper when meeting with another TypeInstPtr, and specifically when meeting an oop and an (unrelated) interface. The instance_id unconditionally falls to bottom on line 3364:, which is likely not correct: // Oop does not implement interface, so mixing falls to Object // just like the verifier does (if both are above the // centerline fall to interface) k = above_centerline(ptr) ? tinst_klass : ciEnv::current()->Object_klass(); xk = above_centerline(ptr) ? tinst_xk : false; // Watch out for Constant vs. AnyNull interface. if (ptr == Constant) ptr = NotNull; // forget it was a constant instance_id = InstanceBot; As part of computing Value for the PhiNode we are meeting the element types in dual space. The element types are Member and AccessibleObject respectively (an interface and a class, but the class does not implement the interface). The pointers are both TOP, as are the instance ids. The above code will however unconditionally make instance_id fall to bottom, and when the resulting type is later dualled instance id will be top and that does not blend. The theory is that instance_id should closely mimic what's applied to the pointer, meaning it should only fall to bottom if the pointer falls (so only if the pointer is Constant). Will ponder upon this.
27-11-2013
I think it is the same issue 8019959 Bharadwaj worked on and closed as not reproducible.
15-11-2013
I can reproduce this on both 1.8.0-b113 and 1.8.0-b107.
13-11-2013
The reason why they don't match appear to be because the array element instance_id's don't match: t->_ary._elem->isa_narrowoop()._ptrtype->isa_instptr()->_instance_id == -1 t0->_ary._elem->isa_narrowoop()._ptrtype->isa_instptr()->_instance_id == 0 ttmp->tary._elem->isa_narrowoop()._ptrtype->isa_instptr()->_instance_id == 0 -1 is also known as InstanceTop, 0 is InstanceBot.
13-11-2013
I instrumented the relevant function to keep the meet() return value in a variable called ttmp - and it turns out meet() returns a Member[]: (gdb) p (char*)(((TypeInstPtr*)((TypeNarrowPtr*)(((TypeAryPtr*)t0)._ary._elem))._ptrtype)._name._symbol._body) $3 = 0x7f87ba6435b0 "java/lang/reflect/Field\361\033" (gdb) p (char*)(((TypeInstPtr*)((TypeNarrowPtr*)(((TypeAryPtr*)t)._ary._elem))._ptrtype)._name._symbol._body) $4 = 0x7f87ba659530 "java/lang/reflect/Member\020" (gdb) p (char*)(((TypeInstPtr*)((TypeNarrowPtr*)(((TypeAryPtr*)ttmp)._ary._elem))._ptrtype)._name._symbol._body) $5 = 0x7f87ba659530 "java/lang/reflect/Member\020" But ttmp != t: (gdb) p t $8 = (const Type *) 0x7f878a9131f8 (gdb) p ttmp $9 = (const Type *) 0x7f87851e4e68 (gdb) p t0 $10 = (const Type *) 0x7f87861ce3d8
12-11-2013
It would be interesting to see what meet() returns. We could simple loose 'not_null' or 'exact' type's status.
12-11-2013
Without my new code in compile.cpp the CompileCommand=option flags will not work. So only -XX:-UseSuperWord is needed. the failed assert is assert(t->meet(t0) == t, "Not monotonic"). So based on Mikael output t is Member[] and t0 is Field[]. t0 is type(n) and it is propagated by phaseCCP type (more precise Field[]). t is original general Phi node's type. C2 type system should handle cases interface[].meet(instance[]).
12-11-2013
This is how I got lucene btw: svn co -r 1523179 https://svn.apache.org/repos/asf/lucene/dev/trunk trunk And the ivy version is ivy-2.3.0.jar. I cd to lucene/core before running the ant command
11-11-2013
An initial round of gdb examination together with vladmir tells us that we're processing a Phi node and have two array types: one of which is a java.lang.reflect.Member (an interface) and the other which is a java.lang.reflect.Field (a class): (gdb) p (char*)(((TypeInstPtr*)((TypeNarrowPtr*)(((TypeAryPtr*)t0)._ary._elem))._ptrtype)._name._symbol._body) $39 = 0x7f24aec765b0 "java/lang/reflect/Field\361\033" (gdb) p (char*)(((TypeInstPtr*)((TypeNarrowPtr*)(((TypeAryPtr*)t)._ary._elem))._ptrtype)._name._symbol._body) $40 = 0x7f24aec8c530 "java/lang/reflect/Member\020"
11-11-2013
I'm running lucene like so (I was actually trying to reproduce the other bug Vladimir was looking at): ant test -Dtests.seed=43A1116E7F98BED4 -Dtests.jvms=1 -Dtests.dynamicAssignmentRatio=0 -Dargs="-XX:-UseSuperWord -XX:CompileCommand=option,org.apache.lucene.util.packed.BlockPackedReaderIterator::next,UseSuperWord -XX:CompileCommand=option,org.apache.lucene.codecs.compressing.CompressingTermVectorsReader::readPositions,UseSuperWord" The crash happens a few minutes into the test.
11-11-2013
Mikael, assign hs_err file to the bug, please. How do you run it? Do you see crash when building lucene or running the tests?
11-11-2013