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