On Thu, 8 Jun 2023 16:35:28 GMT, Brian Goetz <briango...@openjdk.org> wrote:
> I have a hard time imagining heavy parallel use here; concurrency against the > same cache would most likely come from accidental sharing. So this is not > necessarily a problem. Are you imagining differnet use cases? I think it is common practice for example in web services to pre-configure as much of the common parts as possible (and Classfile context logically falls into that category) and then register the service to the server, which use group of thread workers to handle individual requests. With (non-reusable) virtual threads and structured concurrency on the table makes internal use of thread locals even less sense. I can imagine a new virtual thread launched (and finished) for each individual transformation. Our `CorpusTest` relying on Junit parallelization is not so far from that scenario (I'm not sure if Junit already uses virtual threads or just a group of workers). It is technically irrelevant if user will share the context directly or through a `ClassModel` (for example an instrumentor class used to transform all incoming code - this BTW an idea of faster `j.l.r.ProxyGenerator` I'm thinking about). I think we should be sure that `Classfile` context (and also expansion of `ClassModel`) does not fail in parallel environments. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14180#issuecomment-1584034695
