ArC: performance optimizations related to client proxy invocations

[mkouba]

The first commit introduces the ContextInstances abstraction and generates the implementations for application and request contexts by default. The main goal is to avoid ConcurrentHashMap lookups in the hot path (i.e. for every client proxy invocation).

The generated implementation of an application context for config-quickstart looks like:
https://gist.github.com/mkouba/df6526fe8f3c76d4b773b814e1359555

Our benchmarks show that for application context the throughput has increased significantly: I've observed ~ 75% for 1 bean and ~ 25% for 200 beans. The size of the generated class is ~ 3KB for one bean and ~ 200KB for 200 beans. The numbers are lower for request context because in this case the container has to do much more (e.g. check if the context is active). This optimization can be disabled with quarkus.arc.optimize-contexts=false.

The second commit is similar to how we optimize the client proxy delegate access for the application context. However for the request context, we can only do this optimization if a single request context implementation is registered. I've observed ~ 20% improvement in the RequestScopedProxyInvocationBenchmark.

[Ladicek]

Just my ordinary nitpicking, nothing unusual.

The 2nd commit I believe we could apply to all normal scopes for which only 1 context is registered. It makes sense to keep ClientProxies.getApplicationScopedDelegate() separate, because we know that the application context is always active (and so the implementation is more performant); for other contexts, where we either don't know at all or we know that the context may be inactive, the getRequestScopedDelegate() implementation would be appropriate.

[manovotn]

I tried to give my feedback mostly over Zulip so just a few bits here.
Overall, I am not a big fan of replacing a nice API such as Map with this generated class, but I understand the motivation and the results seem to support it, so +1.

The 2nd commit I believe we could apply to all normal scopes for which only 1 context is registered. It makes sense to keep ClientProxies.getApplicationScopedDelegate() separate, because we know that the application context is always active (and so the implementation is more performant); for other contexts, where we either don't know at all or we know that the context may be inactive, the getRequestScopedDelegate() implementation would be appropriate.

I also agree with Ladislav in this point - we can apply the same logic to any normal scope and the optimization will be applicable in majority of cases as having multiple scope implementations is rare.

[mkouba]

The 2nd commit I believe we could apply to all normal scopes for which only 1 context is registered.

I also agree with Ladislav in this point - we can apply the same logic to any normal scope and the optimization will be applicable in majority of cases as having multiple scope implementations is rare.

@Ladicek @manovotn Done.

[gsmet]

@Ladicek @manovotn you all good with Martin's latest changes? If so, we can merge!

[manovotn]

@Ladicek @manovotn you all good with Martin's latest changes? If so, we can merge!

Yea, all good 👍

[Ladicek]

LGTM, my only comment is nitpicking :-)

[quarkus-bot]

Failing Jobs - Building d6c9f73

Status	Name	Step	Failures	Logs	Raw logs	Build scan
✔️	JVM Tests - JDK 11
✖	JVM Tests - JDK 17	Build	⚠️ Check →	Logs	Raw logs
✖	JVM Tests - JDK 21	Build	Failures	Logs	Raw logs
✖	Native Tests - Windows - RESTEasy Jackson	Setup GraalVM	⚠️ Check →	Logs	Raw logs

Full information is available in the Build summary check run.

Failures

⚙️ JVM Tests - JDK 21 #

- Failing: integration-tests/virtual-threads/mailer-virtual-threads 

📦 integration-tests/virtual-threads/mailer-virtual-threads

✖ io.quarkus.virtual.mail.RunOnVirtualThreadTest.test line 25 - More details - Source on GitHub

java.net.SocketTimeoutException: Read timed out
	at java.base/sun.nio.ch.NioSocketImpl.timedRead(NioSocketImpl.java:278)
	at java.base/sun.nio.ch.NioSocketImpl.implRead(NioSocketImpl.java:304)