mx does not like .hotspot_compiler

Gilles Duboscq duboscq at ssw.jku.at
Tue Jul 15 08:03:41 UTC 2014


I've already hit that one and went the CompileCommandFile= way. We
could detect the .hotspot_compiler file in mx and pass in some fake
CompileCommandFile when doing version detection.

-Gilles

On Mon, Jul 14, 2014 at 11:08 PM, Tom Rodriguez
<tom.rodriguez at oracle.com> 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.
>


More information about the graal-dev mailing list