The tests use statically specified Transforms and each transformation also held set of options. Now the transformations hold static instance of Classfile context instead. Junit execute them in parallel for each individual class file being transformed, so one context is used in parallel environment. If we fall back to store List<Option> and create new Classfile context for each invocation – we will degrade the performance significantly (starting always with an empty cache). Trying to stick Classfile context with thread locality is possible, however it requires to re-design our CorpusTest and Transforms and performance will be randomly dependent on Junit decision about threads assignment. Also Junit may silently move to virtual threads (unless it already did) and performance will be back to an empty cache for each invocation.
From: Brian Goetz <brian.go...@oracle.com> Date: Thursday, 8 June 2023 21:58 To: Adam Sotona <asot...@openjdk.org>, core-libs-dev@openjdk.org <core-libs-dev@openjdk.org>, kulla-...@openjdk.org <kulla-...@openjdk.org> Subject: Re: RFR: 8308899: Introduce Classfile.Context and improve Classfile.Option(s) [v9] I still don't understand this point. Why are separate tests sharing a context at all? On 6/8/2023 9:26 AM, Adam Sotona wrote: Unfortunately thread-unsafe context makes sharing of it in tests executed in parallel a nightmare. I can fix our Corpus tests and hope the race condition won't raise also somewhere else later. However how to explain this limitation to users?
