mx does not like .hotspot_compiler

[Gilles Duboscq]

I think Bernhard pushed a fix for mx anyway.

-Gilles
On 16 Jul 2014 20:19, "Tom Rodriguez" <tom.rodriguez at oracle.com> wrote:

> I think https://bugs.openjdk.java.net/browse/JDK-8029446 is the bug id it
> was fixed under.  Oddly I just hit it this morning while looking at
> something else.  I’ll see about getting it back ported.
>
> tom
>
> On Jul 14, 2014, at 3:21 PM, Eric Caspole <eric.caspole at amd.com> wrote:
>
> > Thanks Tom, using the command line versions is OK for us.
> >
> > Here is the actual assert we hit while compiling Graal parts in -server
> mode with debug builds. This doesn't happen every time but I can usually
> get it to happen at least once in about 10 minutes of running our tests in
> a loop.
> >
> > Looks like: https://bugs.openjdk.java.net/browse/JDK-8030654
> > I vote for fixing this in debug builds.
> > Thanks,
> > Eric
> >
> >
> >
> > #
> > # A fatal error has been detected by the Java Runtime Environment:
> > #
> > #  Internal Error
> (/home/ecaspole/views/graal-openjdk/graal/src/share/vm/opto/chaitin.cpp:282),
> pid=16931, tid=140031381886720
> > #  assert(_cfg.get_block_for_node(proj) == borig) failed: incorrect
> block for kill projections
> > #
> > # JRE version: OpenJDK Runtime Environment (8.0) (build
> 1.8.0-internal-ecaspole_2014_07_10_12_42-b00)
> > # Java VM: OpenJDK 64-Bit Server VM (25.0-b63-internal-graal-0.3-debug
> mixed mode linux-amd64 compressed oops)
> > # Core dump written. Default location:
> /home/ecaspole/views/graal-openjdk/graal/core or core.16931
> > #
> > # 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 (0x00007f5bb01a2000):  JavaThread "C2 CompilerThread0"
> daemon [_thread_in_native, id=16941,
> stack(0x00007f5b98b65000,0x00007f5b98c66000)]
> >
> > Stack: [0x00007f5b98b65000,0x00007f5b98c66000],  sp=0x00007f5b98c60440,
>  free space=1005k
> > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code,
> C=native code)
> > V  [libjvm.so+0xc7a096]  VMError::report(outputStream*)+0x1112
> > V  [libjvm.so+0xc7b583]  VMError::report_and_die()+0x427
> > V  [libjvm.so+0x611781]  report_vm_error(char const*, int, char const*,
> char const*)+0xa5
> > V  [libjvm.so+0x4fb4af]  PhaseChaitin::clone_projs(Block*, unsigned int,
> Node*, Node*, unsigned int&)+0x145
> > V  [libjvm.so+0xb53c2e]  PhaseChaitin::split_Rematerialize(Node*,
> Block*, unsigned int, unsigned int&, GrowableArray<unsigned int>, int,
> unsigned int*, Node**, bool)+0
> > x4f6
> > V  [libjvm.so+0xb57873]  PhaseChaitin::Split(unsigned int,
> ResourceArea*)+0x398f
> > V  [libjvm.so+0x4fbc07]  PhaseChaitin::Register_Allocate()+0x557
> > V  [libjvm.so+0x5a0b4e]  Compile::Code_Gen()+0x284
> > V  [libjvm.so+0x59aaa8]  Compile::Compile(ciEnv*, C2Compiler*,
> ciMethod*, int, bool, bool, bool)+0x1348
> > V  [libjvm.so+0x4d651b]  C2Compiler::compile_method(ciEnv*, ciMethod*,
> int)+0x109
> > V  [libjvm.so+0x5b103d]
> CompileBroker::invoke_compiler_on_method(CompileTask*)+0x4d1
> > V  [libjvm.so+0x5b042b]  CompileBroker::compiler_thread_loop()+0x3b3
> > V  [libjvm.so+0xc24316]  compiler_thread_entry(JavaThread*, Thread*)+0x57
> > V  [libjvm.so+0xc1f68e]  JavaThread::thread_main_inner()+0x124
> > V  [libjvm.so+0xc1f55b]  JavaThread::run()+0x163
> > V  [libjvm.so+0xabda91]  java_start(Thread*)+0x1bb
> >
> >
> > Current CompileTask:
> > C2: 296437 23955       4
> com.oracle.graal.phases.common.CanonicalizerPhase$Instance::performReplacement
> (552 bytes)
> >
> >
> >
> > On 07/14/2014 05:08 PM, Tom Rodriguez wrote:
> >> hotspot_compiler as an automatically read file is deprecated in the
> product since it’s a potential security hole.  If .hotspot_compiler exists
> it will emit a warning about the new behavior which screws up tools that
> parse VM output like mx.  You can use -XX:CompileCommandFile= instead, just
> don’t use the .hotspot_compiler name.
> >>
> >> tom
> >>
> >> On Jul 14, 2014, at 1:26 PM, Eric Caspole <eric.caspole at amd.com> wrote:
> >>
> >>> We are usually running Graal with -server so only the HSAIL part is
> built with Graal. We were hitting an assert in C2 code and eventually I
> tried using a .hotspot_compiler file, but it makes mx fail, for example:
> >>>
> >>>
> >>> $ cat .hotspot_compiler
> >>> exclude java/lang/String indexOf
> >>>
> >>>
> >>> $ ./mx.sh  --vm server --vmbuild fastdebug  unittest -server -ea -esa
> -XX:-TraceGPUInteraction  -Dcom.amd.sumatra.offload.immediate=true
> hsail.test.lambda
> >>> Traceback (most recent call last):
> >>>  File "/home/ecaspole/views/graal-default/graal/mxtool/mx.py", line
> 4912, in <module>
> >>>    main()
> >>>  File "/home/ecaspole/views/graal-default/graal/mxtool/mx.py", line
> 4849, in main
> >>>    defaultJdk = JavaConfig(opts.java_home, opts.java_dbg_port)
> >>>  File "/home/ecaspole/views/graal-default/graal/mxtool/mx.py", line
> 1740, in __init__
> >>>    assert output[1] == 'version'
> >>> AssertionError
> >>>
> >>>
> >>> Even a completely empty .hotspot_compiler file causes it to fail.
> >>> Eventually I found -XX:CompileCommand= worked OK.
> >>
>
>