[11] RTM tests fail

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>