RFR: 8253750: use build-stable default seed for Utils.RANDOM_GENERATOR
Igor Ignatyev
iignatyev at openjdk.java.net
Fri Oct 2 17:57:38 UTC 2020
On Fri, 2 Oct 2020 17:47:40 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:
>> Is this really a good idea? The purpose of using random numbers is to get broader coverage on multiple runs.
>> If the seed only changes once per version (6 months), that reduces test coverage.
>> At least for dev submitted runs, I would like to be different for every build (unless overridden).
>
> Hi Roger,
>
> it's exactly that you want it to be. It is different for every build (not every release, as we are using
> `java.vm.version` not `java.version`) unless overridden, each dev submitted run and each CI builds have different
> `java.vm.version` (e.g. the last two mach5 CI builds have `16-ea+19-938` and `16-ea+19-939` as their `java.vm.version`,
> one of my ad-hoc mach5 runs -- `16-internal+0-2020-10-01-2150482.igor.ignatyev.jdk`, my local build --
> `16-internal+0-2020-10-01-2252075.iignatye...`, ) and hence would get different seeds. all the test tasks for these
> builds, on the other hand, would use the same seed, so one could be more confident that if test `T` passed on all
> platforms but platform `P`, it's platform `P` specific problem, there before this fix, one would need to rerun test `T`
> on each platform with the _faling_ seed and on platform `P` with at least one _passing_ seed, this problem becomes even
> more acute when you start considering all build flavor, vm flags, host configurations we cover in our testing.
Hi Joe,
this change indeed reduces test coverage, but not drastically (one can even argue that it doesn't reduce coverage as
generally speaking you can merge coverage from runs with different configurations, e.g. run on different platforms),
due to that and the reasons I wrote in my response to Roger, I don't think the reducing coverage is an issue here, nor
do I think that possible impact on coverage overweights the benefits we get from comparable runs.
-------------
PR: https://git.openjdk.java.net/jdk/pull/391
More information about the core-libs-dev
mailing list