RFR: 8173709: Fix VerifyLoopOptimizations - step 1 - minimal infrastructure
Emanuel Peter
epeter at openjdk.org
Tue Apr 4 06:32:46 UTC 2023
On Wed, 29 Mar 2023 16:38:41 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:
>>> I had testing run, for tier1-tier6 and stress testing.
>>> The non-verification run finished with 27d 3h machine time.
>>> The verification run is still running, with at least 27d 7h machine time.
>>
>> Thanks for the data! If the verification run does not take much longer (say <1% on top of what the non-verification run takes), it might be a good trade-off to have it enabled by default. Not just to prevent the verification code from rotting but to actually get more value from it (better chances to find bugs earlier).
>
>> > I had testing run, for tier1-tier6 and stress testing.
>> > The non-verification run finished with 27d 3h machine time.
>> > The verification run is still running, with at least 27d 7h machine time.
>>
>> Thanks for the data! If the verification run does not take much longer (say <1% on top of what the non-verification run takes), it might be a good trade-off to have it enabled by default. Not just to prevent the verification code from rotting but to actually get more value from it (better chances to find bugs earlier).
>
> I assume @eme64 tested it with current limited verification. With adding/restoring more code the time will increase.
> I suggest to enable it only for `stress` testing now so we always use it for pre-integration testing and later tiers.
> After enabling of all verification code we will check time again and can decide if we can enable it by default always.
> So after pushing this fix we should add it to stress testing - we need that for pre-integration testing.
Thanks @vnkozlov @chhagedorn @TobiHartmann for the reviews!
-------------
PR Comment: https://git.openjdk.org/jdk/pull/13207#issuecomment-1495418474
More information about the hotspot-compiler-dev
mailing list