[11] RTM tests fail
Christian Thalinger
cthalinger at twitter.com
Thu Aug 30 16:51:52 UTC 2018
> On Aug 30, 2018, at 12:27 AM, Gustavo Romero <gromero at linux.vnet.ibm.com> wrote:
>
> Hi Götz, Christian,
>
> Cristian, I don't know how easy it's to trigger an ad hoc test on your system to
> test the RTM suite against a Graal JVM, but I'm wondering if you could kindly test
> a fix for JDK-8209972:
>
> http://cr.openjdk.java.net/~gromero/misc/8209972_GRAAL_dont_run_RTM_tests_with_Graal.patch <http://cr.openjdk.java.net/~gromero/misc/8209972_GRAAL_dont_run_RTM_tests_with_Graal.patch>
Yes, that’s pretty easy. I’ll do it tomorrow and get back to you.
>
>
> Götz, I've tried to fix that in vm.rtm.cpu property but it got cumbersome around
> TestUseRTMLockingOptionOnUnsupportedCPU.java. There, vm.rtm.cpu would be false
> for Graal JVM and so the test runs and expects some failure message from the JVM
> regarding unsupported CPU or OS, however the problem is rather that the compiler
> itself doesn't support RTM. I could adapt that test but tweaking it locally
> seems odd to me. Also I think that the other tests (*Unsupported*.java) are
> irrelevant when the selected compiler does not support RTM (please see the commit
> message where I try to explain it with other words). What do you think?
>
> Thanks.
>
>
> Best regards,
> Gustavo
>
> On 08/29/2018 10:52 AM, Gustavo Romero wrote:
>> Hi Christian,
>> A quick question:
>> What's the way you recommend to run the compiler/rtm tests with Graal JVM?
>> I'm using something like that but I would like know if there is a better way to
>> do that. I don't want to run all the tests, only the RTM ones, so I would like
>> to avoid 'make hostpot-*':
>> JT_JAVA=/usr/lib/jvm/java-8-openjdk-amd64 /home/gromero/jtreg/bin/jtreg -javaoption:-XX:+UnlockExperimentalVMOptions -javaoption:-XX:+EnableJVMCI -javaoption:-XX:+UseJVMCICompiler -v1 -conc:6 -jdk:./build/linux-x86_64-normal-server-release/jdk/ ./test/hotspot/jtreg/compiler/rtm
>> Vladimir, thanks for filing JDK-8209972.
>> Thanks.
>> Regards,
>> Gustavo
>> On 08/24/2018 10:53 AM, Gustavo Romero wrote:
>>> Hi Goetz,
>>>
>>> On 08/24/2018 04:44 AM, Lindenmaier, Goetz wrote:
>>>> Hi Gustavo,
>>>>
>>>>> If it's possible would that be the best solution in this case?
>>>> Yes, I think so. It's the most local place to change this.
>>>>
>>>> But maybe VMProps works fine, too. Then this is the better place.
>>>> I just don't know whether all tests properly check that.
>>>>
>>>> In general, I think such information should go into the
>>>> test suite, not into the testee... kind of strange to adapt a testee
>>>> so that tests pass. There should be a single point in the test suite
>>>> where it is listed which VM configuration supports which features.
>>>> For a while such things were added to Platform.java, but now
>>>> there is VMProps ... and there are base classes in the test sub-suites
>>>> that try to do this ...
>>>> Some tests then again check for the platform themselves.
>>>>
>>>> But basically I thought the CPU feature string is there to
>>>> report about the actual CPU we are running on, not to
>>>> tell what the VM exploits of these features.
>>>
>>> Sure, that makes total sense. So much that the CPU feature string is
>>> determined very early in the JVM creation.
>>>
>>> Thanks.
>>>
>>> Best regards,
>>> Gustavo
>>>> Best regards,
>>>> Goetz.
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: Gustavo Romero <gromero at linux.vnet.ibm.com>
>>>>> Sent: Dienstag, 21. August 2018 15:04
>>>>> To: Christian Thalinger <cthalinger at twitter.com>; Lindenmaier, Goetz
>>>>> <goetz.lindenmaier at sap.com>
>>>>> Cc: hotspot compiler <hotspot-compiler-dev at openjdk.java.net>
>>>>> Subject: Re: [11] RTM tests fail
>>>>>
>>>>> Hi Christian, Goetz,
>>>>>
>>>>> On 08/21/2018 08:02 AM, Christian Thalinger wrote:
>>>>>>
>>>>>>
>>>>>>> On Aug 20, 2018, at 5:44 PM, Christian Thalinger <cthalinger at twitter.com>
>>>>> wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> On Aug 20, 2018, at 5:02 PM, Lindenmaier, Goetz
>>>>> <goetz.lindenmaier at sap.com> wrote:
>>>>>>>>
>>>>>>>> Hi
>>>>>>>>
>>>>>>>> I think it would make more sense to add this in VMProps.java when
>>>>>>>> vm.rtm.cpu is evaluated.
>>>>>>>> Or to adapt the CPU feature string not to report rtm. While I think
>>>>>>>> this is crude, I have seen (and then also done) this before.
>>>>>>>>
>>>>>>>> Adding !vm.graal.enabled to each test will require changing this
>>>>>>>> in all tests when, e.g., RTM support is implemented in graal x86, but
>>>>>>>> not in graal ppc …
>>>>>>>
>>>>>>> Good point regarding different architectures.
>>>>>>
>>>>>> Anyone want to pick this up? :-)
>>>>>
>>>>> Yes, I can, although not promptly. Is it ok to wait a week or so?
>>>>>
>>>>> Also it's been quite some time that I don't check the Graal code...
>>>>>
>>>>> Goetz, would it be reasonable to handle this at the JVM side? For instance,
>>>>> would it be possible (and correct) to keep separate RTM feature status for
>>>>> JVM + Hotspot and for JVM + Graal for each architecture so for a given arch it
>>>>> would be possible to advertise "rtm" for JVM + Hotspot but not for JVM +
>>>>> Graal?
>>>>>
>>>>> If it's possible would that be the best solution in this case?
>>>>>
>>>>> Thanks.
>>>>>
>>>>>
>>>>> Bbest regards,
>>>>> Gustavo
>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> Best regards,
>>>>>>>> Goetz.
>>>>>>>>
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: Christian Thalinger <cthalinger at twitter.com>
>>>>>>>>> Sent: Montag, 20. August 2018 14:55
>>>>>>>>> To: Gustavo Romero <gromero at linux.vnet.ibm.com>
>>>>>>>>> Cc: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; hotspot
>>>>> compiler
>>>>>>>>> <hotspot-compiler-dev at openjdk.java.net>
>>>>>>>>> Subject: Re: [11] RTM tests fail
>>>>>>>>>
>>>>>>>>> Quick additional question: Graal does not implement RTM (as far as I
>>>>> know)
>>>>>>>>> but the tests are always run and I don’t see a:
>>>>>>>>>
>>>>>>>>> @requires !vm.graal.enabled
>>>>>>>>>
>>>>>>>>> in the test files. Should we add that?
>>>>>>>>>
>>>>>>>>>> On Jul 11, 2018, at 4:17 PM, Gustavo Romero
>>>>>>>>> <gromero at linux.vnet.ibm.com> wrote:
>>>>>>>>>>
>>>>>>>>>> Hi Christian,
>>>>>>>>>>
>>>>>>>>>> On 07/11/2018 11:10 AM, Christian Thalinger wrote:
>>>>>>>>>>>> On Jun 29, 2018, at 11:23 AM, Gustavo Romero
>>>>>>>>> <gromero at linux.vnet.ibm.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> Hi Christian,
>>>>>>>>>>>>
>>>>>>>>>>>> On 06/29/2018 12:16 PM, Christian Thalinger wrote:
>>>>>>>>>>>>>> On Jun 25, 2018, at 5:32 PM, Gustavo Romero
>>>>>>>>> <gromero at linux.vnet.ibm.com
>>>>> <mailto:gromero at linux.vnet.ibm.com>>
>>>>>>>>> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hi Christian,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 06/25/2018 09:54 AM, Christian Thalinger wrote:
>>>>>>>>>>>>>>>> On Jun 25, 2018, at 8:49 AM, Gustavo Romero
>>>>>>>>> <gromero at linux.vnet.ibm.com
>>>>> <mailto:gromero at linux.vnet.ibm.com>>
>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 06/25/2018 09:46 AM, Lindenmaier, Goetz wrote:
>>>>>>>>>>>>>>>>>>> Did you check with or without these fixes?
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Without, unfortunately. Are all of the failures fixed now (in
>>>>> jdk-
>>>>>>>>> 11+19)?
>>>>>>>>>>>>>>>>> I don't know, our machines do not have RTM, only our
>>>>> Power
>>>>>>>>> ones do.
>>>>>>>>>>>>>>>>> But I think Gustavo Romero from IBM claimed so.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Yup, after the three fixes Goetz mentioned all RTM tests must
>>>>> pass
>>>>>>>>> on Intel.
>>>>>>>>>>>>>>> Ok, I’ll get back to you…
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Yes, please let me know if all went fine :)
>>>>>>>>>>>>> I did not forget but we can’t merge in jdk-11+19 because of
>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8205616
>>>>>>>>>>>>> We have to wait until jdk-11+20 is tagged.
>>>>>>>>>>>>
>>>>>>>>>>>> Sure!
>>>>>>>>>>> I’m happy to report that all RTM test failures are fixed. Thanks!
>>>>>>>>>> Thanks for testing & confirming it. :)
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Regards,
>>>>>>>>>> Gustavo
>>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20180830/fbcbc6bf/attachment-0001.html>
More information about the hotspot-compiler-dev
mailing list