RFR: 8205694: AArch64: Add test to validate volatile load, store and CAS code generation
Andrew Dinn
adinn at redhat.com
Wed Jun 27 15:03:13 UTC 2018
On 27/06/18 15:41, Dmitrij Pochepko wrote:
> On 27.06.2018 16:05, Andrew Dinn wrote:
>> On 27/06/18 13:29, Dmitrij Pochepko wrote:
>>> On 27.06.2018 13:54, Andrew Dinn wrote:
>>>> On 26/06/18 19:33, Dmitrij Pochepko wrote:
>>>>> 1. Most tests which spawn other precesses for testing purposes are
>>>>> launched as "@run driver ..." for optimization reasons.
>>>> I'm using the Process API so I can retrieve and analyze the output
>>>> written to the spawned JVM's stdout. Is it possible to do that using
>>>> "@run driver"?
>>> yes
>> Well, that's good to know ;-) but still could you explain how or point
>> at an example?
> it's the same as for @run main. External vm options are stored by jtreg
> in several vm properties: test.vm.opts and test.java.opts (for
> -vmoptions and -javaoptions respectively), so, process tools use it in
> case you call createJavaProcessBuilder with first parameter == true.
> Here is an example how this could be done:
> gc/arguments/TestUseNUMAInterleaving.java
I'm really not sure what you are recommending here. Are you simply
saying that I need to change the @run directives so that they say
@run driver compiler.c2.aarch64.TestVolatiles
instead of
@run main compiler.c2.aarch64.TestVolatiles
If so then I can easily do that but I would really like to understand
why that is better -- as you say -- 'for optimization reasons'.
Could you clarify if that is all you are suggesting and if so why it
improves the situation?
If, instead, you are suggesting I do something more (or something else)
then can you give a precise and clear explanation of what I would need
to change and why? For now it would be best to base that on the original
webrev just to avoid any further confusion.
regards,
Andrew Dinn
-----------
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander
More information about the hotspot-compiler-dev
mailing list