RFR 8252249: nsk/stress/stack/stack016.java fails with "Error: TEST_BUG: trickyRecursion() must throw an error anyway!"
Igor Ignatyev
igor.ignatyev at oracle.com
Wed Sep 2 20:33:12 UTC 2020
Hi Harold,
currently, the configurations which a test is run defined by test execution configuration (which is tiers/tasks-definitions in Oracle's case, and I'd guess others their own configuration matrixes), not a test (tests are, however, responsible for filtering out incompatible/meaningless configurations). this particular test is included in runs w/ tens different flag combinations, w/ around a half of them having -Xcomp; and `vm.compMode != "Xcomp"` effectively removes the test from all these runs.
Thanks,
-- Igor
> On Sep 2, 2020, at 1:21 PM, Harold Seigel <harold.seigel at oracle.com> wrote:
>
> Hi Igor,
>
> I think that the test needs to only run twice, once with -Xcomp and once with -Xint. It does not need to run with multiple -Xcomp configurations. It needs only to run with consistent stack sizes, so that stack consumption doesn't vary because some threads run an interpreted method and others run a compiled method.
>
> My understanding is that "vm.compMode != "Xcomp" will cause the test to be run without -Xcomp. The test will then run using its internal -Xint flag and then its -Xcomp flags. Which I think is what we want.
>
> Thanks, Harold
>
> On 9/2/2020 10:45 AM, Igor Ignatyev wrote:
>> Hi Harold,
>>
>> vm.compMode != "Xcomp" will exclude all combinations which has Xcomp, e.g. '-Xcomp -XX:-TieredCompilation', so it would be waste iff all other flags from Xcomp configurations are also used w/o Xcomp, which I don't think is generally true.
>>
>> given vm flags from jtreg actions are appended to external flags, running this test w/ '-Xcomp -XX:-TieredCompilation' (assuming there is no @requires) will actually result in two different (and one might argue expected) runs:
>> -Xcomp -XX:-TieredCompilation -Xint -Xss448K nsk.stress.stack.stack016 -eager
>> -Xcomp -XX:-TieredCompilation -Xcomp -Xss448K nsk.stress.stack.stack016 -eager
>>
>> thus I don't think '@requires vm.compMode' is needed here.
>>
>> if you think that '-Xint' run should be excluded when one specifies -Xcomp externally, I'd suggest splitting the test into two
>>
>> /*
>> * @test id=Xint
>> * @requires vm.compMode == null | vm.compMode == "Xint"
>> * @requires (vm.opt.DeoptimizeALot != true)
>> * @library /vmTestbase
>> * @build nsk.share.Terminator
>> * @run main/othervm/timeout=900 -Xint -Xss448K nsk.stress.stack.stack016 -eager
>> */
>>
>> /*
>> * @test id=Xcomp
>> * @requires vm.compMode == null | vm.compMode == "Xcomp"
>> * @requires (vm.opt.DeoptimizeALot != true)
>> * @library /vmTestbase
>> * @build nsk.share.Terminator
>> * @run main/othervm/timeout=900 -Xcomp -Xss448K nsk.stress.stack.stack016 -eager
>> */
>>
>> in this case Xint run will be run only if there is no Xint/Xmixed/Xbatch/Xcomp specified externally or Xint is specified, and similarly for Xcomp.
>>
>> Thanks,
>> -- Igor
>>
>>
>>
>>> On Sep 1, 2020, at 11:26 PM, David Holmes <david.holmes at oracle.com <mailto:david.holmes at oracle.com>> wrote:
>>>
>>> I would suggest that you keep the required condition
>>>
>>> vm.compMode != "Xcomp"
>>>
>>> to minimise the runs of this test. When executed as part of an Xcomp run both @run's will behave exactly the same way (Xcomp) - and that is the same as the second @run in a non-Xcomp run. So no point running the Xcomp version three times.
>>
More information about the hotspot-runtime-dev
mailing list