ArC: speed up bean resolution at runtime

[mkouba]

Specifically, the invocation of BeanManaget#getBeans() and the first hit for any programmatic lookup.

We use a precomputed map of a raw type to the set of matching beans which reduces the number of beans we need to iterate over when we're looking for matching beans.

Note that BeanManaget#getBeans() does not use the computing cache of results so this optimizaton results in a significant speed-up. On the other hand, the precomputed map could be memory demanding for large applications.

[mkouba]

This PR is related to #33693.

[mkouba]

Note that this is a runtime optimization. I didn't find a reasonable build-time alternative. Reasonable in terms of performance gain and complexity.

CC @franz1981 @Sanne

[Ladicek]

LGTM. Memory overhead should be pretty low, because all the objects (except of the maps and lists) must exist anyway [1], but some measurements would be good.

[1] I'm actually not sure about the String keys in the map. I'd personally use the Class object as the key, because that must exist. Looking at JDK 11's java.lang.Class, the getName() method initializes the class name lazily, so that String probably doesn't need to exist, but it's entirely possible we force it into existence elsewhere.

[manovotn]

I like this solution, it's IMO a good middle ground between what we had and going bonkers on over optimizing this code :)

[mkouba]

I'm actually not sure about the String keys in the map. I'd personally use the Class object as the key, because that must exist. Looking at JDK 11's java.lang.Class, the getName() method initializes the class name lazily, so that String probably doesn't need to exist, but it's entirely possible we force it into existence elsewhere.

@Ladicek Let's keep it this way for now. We could change it later, once we measure the RSS and find out that there's too much overhead... WDYT?

[Ladicek]

I already approved, so I'm fine :-)

[Sanne]

Very nice, thanks for looking at this so quickly!

[quarkus-bot]

Failing Jobs - Building d582a45

Status	Name	Step	Failures	Logs	Raw logs
✖	Native Tests - Amazon	Build	Failures	Logs	Raw logs

Full information is available in the Build summary check run.

Failures

⚙️ Native Tests - Amazon #

- Failing: integration-tests/amazon-lambda integration-tests/amazon-lambda-http 

📦 integration-tests/amazon-lambda

✖ io.quarkus.it.amazon.lambda.AmazonLambdaSimpleIT.testSimpleLambdaSuccess - More details - Source on GitHub

java.lang.RuntimeException: 
java.lang.RuntimeException: io.quarkus.builder.BuildException: Build failure: Build failed due to errors
	[error]: Build step io.quarkus.amazon.lambda.deployment.DevServicesLambdaProcessor#startEventServer threw an exception: java.lang.RuntimeException: java.util.concurrent.ExecutionException: java.net.BindException: Address already in use

📦 integration-tests/amazon-lambda-http

✖ io.quarkus.it.amazon.lambda.AmazonLambdaSimpleIT.testJaxrsCognitoJWTSecurityContext - More details - Source on GitHub

java.lang.RuntimeException: 
java.lang.RuntimeException: io.quarkus.builder.BuildException: Build failure: Build failed due to errors
	[error]: Build step io.quarkus.amazon.lambda.deployment.DevServicesLambdaProcessor#startEventServer threw an exception: java.lang.RuntimeException: java.util.concurrent.ExecutionException: java.net.BindException: Address already in use

[mkouba]

The failures in the integration-tests/amazon-lambda-http are unrelated, i.e. it fails in other PRs as well.