RFR: 7903754: jcstress should die asap - with report - on broken jvm/hw, instead of waiting on kill [v4]

[Jiří Vaněk]

On Fri, 21 Mar 2025 12:33:40 GMT, Jiří Vaněk <jvanek at openjdk.org> wrote:

>> Initial PoC
>> 
>> It currently show how to set up argument, and how the framework will be terminated. Feedback welcomed.  Should be finished soon
>
> Jiří Vaněk has updated the pull request incrementally with one additional commit since the last revision:
> 
>   replaced incorrect System.out by output

One more call before redoing it - I really think  the ratio will be heavily missed in future QA runs.  jcstress is not jmh. When jmh fails, it is usually deterministic and stable. With jcstress it is not the case. You **want to have failures**. The reason for this is to not waste cycles on machines, where it would lead to hundred, or even hundred of thousands ..well *all* tests failures.  We have it on some 10% so we usually have all results, including failures, but if we get borked hw or jvm, it will fail in hour, and not in two days. Similarly, if the VM is broken jsut a bit, there are again full results, with *all* failures.  That give us excelnt compromise. Simple fail on error will heavily downgrade the usability and usage of jcstress:(

As i suggested - I can introduce -foe, which will default to --failFAST=1, or I can make the number optional, and it will default eg to those moreover verified 10%. I can remove the %%, as it as proved itself, but at the end was not used by us. 

Similarly I can remove the  double failFAST/failFast.  The failFast have advantage that you always have a set finished, but is missing fine-tuning which failFAST have. We are using failFast.

wdyt?

-------------

PR Comment: https://git.openjdk.org/jcstress/pull/157#issuecomment-2956083041