Build fails with "Method too large" exception

[fedinskiy]

Describe the bug

I have an application, which uses a lot (94) of different extensions. When I am trying to build it using the current SNAPSHOT, it fails with an exception during the build phase. If I use Quarkus 3.16.3, the apps works without any problems, same happens if I remove quarkus-redis-client extension

Expected behavior

Application either compiles or fails with a more telling error

Actual behavior

[error]: Build step io.quarkus.deployment.steps.ConfigGenerationBuildStep#generateConfigClass threw an exception: org.objectweb.asm.MethodTooLargeException: Method too large: io/quarkus/runtime/generated/Config.generateMappedProperties ()Ljava/util/Set;
[ERROR]     at org.objectweb.asm.MethodWriter.computeMethodInfoSize(MethodWriter.java:2088)
[ERROR]     at org.objectweb.asm.ClassWriter.toByteArray(ClassWriter.java:506)
[ERROR]     at io.quarkus.gizmo.ClassCreator.writeTo(ClassCreator.java:246)
[ERROR]     at io.quarkus.gizmo.ClassCreator.close(ClassCreator.java:257)
[ERROR]     at io.quarkus.deployment.configuration.RunTimeConfigurationGenerator$GenerateOperation.run(RunTimeConfigurationGenerator.java:519)
[ERROR]     at io.quarkus.deployment.steps.ConfigGenerationBuildStep.generateConfigClass(ConfigGenerationBuildStep.java:318)
[ERROR]     at java.base/java.lang.invoke.MethodHandle.invokeWithArguments(MethodHandle.java:733)
[ERROR]     at io.quarkus.deployment.ExtensionLoader$3.execute(ExtensionLoader.java:856)
[ERROR]     at io.quarkus.builder.BuildContext.run(BuildContext.java:256)
[ERROR]     at org.jboss.threads.ContextHandler$1.runWith(ContextHandler.java:18)
[ERROR]     at org.jboss.threads.EnhancedQueueExecutor$Task.doRunWith(EnhancedQueueExecutor.java:2675)
[ERROR]     at org.jboss.threads.EnhancedQueueExecutor$Task.run(EnhancedQueueExecutor.java:2654)
[ERROR]     at org.jboss.threads.EnhancedQueueExecutor.runThreadBody(EnhancedQueueExecutor.java:1627)
[ERROR]     at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1594)
[ERROR]     at java.base/java.lang.Thread.run(Thread.java:1583)
[ERROR]     at org.jboss.threads.JBossThread.run(JBossThread.java:499)

How to Reproduce?

1. git clone git@github.com:quarkus-qe/beefy-scenarios.git && cd beefy-scenarios/002-quarkus-all-extensions
2. mvn clean verify # or mvn clean install -DskipTests

Output of uname -a or ver

6.11.7-300.fc41.x86_64

Output of java -version

21.0.1, vendor: Eclipse Adoptium

Quarkus version or git rev

26db59d0b672053df63fd5c058b0778ffaac4739

Build tool (ie. output of mvnw --version or gradlew --version)

3.9.6 (bc0240f3c744dd6b6ec2920b3cd08dcc295161ae)

Additional information

No response

[fedinskiy]

I checked 3.16.4 and it is not affected

[gsmet]

I think it's due to us moving more and more extensions to @ConfigMapping.

@radcortez could you prepare a decompiled version of io/quarkus/runtime/generated/Config with a bunch of extensions? I'd like to discuss it with you with some actual data.

[fedinskiy]

3.17.0.CR1 is not affected either

[gsmet]

Yeah the migration of the core extension might not help.

But in the end, I suspect all the versions are affected if you add enough extensions that are using @ConfigMapping.

[radcortez]

I think it's due to us moving more and more extensions to @ConfigMapping.

@radcortez could you prepare a decompiled version of io/quarkus/runtime/generated/Config with a bunch of extensions? I'd like to discuss it with you with some actual data.

Well, yes, that method generates an entry for each configuration name. With more mappings, you get more entries. The method looks like this:

   private static Set generateMappedProperties() {
      HashSet var0 = new HashSet();
      PropertyName var1 = new PropertyName("quarkus.locales[*]");
      var0.add(var1);
      PropertyName var2 = new PropertyName("quarkus.profile[*]");
      var0.add(var2);
      PropertyName var3 = new PropertyName("quarkus.args");
      var0.add(var3);
      PropertyName var4 = new PropertyName("quarkus.profile");
      ...
  }

I have been thinking of a way to avoid having to rely on this, but I haven't found a way yet. Maybe others can help.

As you know, we report unknown properties in the configuration coming from the quarkus namespace. Each config instance, (build, static, runtime), only contains the valid names of each phase, but we also need to check that names from other phases are matched so they are not reported as positive. Example:

#build time
quarkus.native.enabled=
# runtime 
quarkus.thread-pool.core-threads=

When we read a configuration source like application.properties, we may find both build time and runtime values. Let's say we are initializing the runtime config. Obviously, we can't have the object for quarkus.native.enabled in the config runtime, because it is only for build time, but we still need to have some information somewhere that quarkus.native.enabled must not be reported as unknown. That is the purpose of that method, to build such list.

The previous implementation made the same checks, but because they also populated the object, it used a different method for each. We could quickly fix this by splitting the generation as well, but I'm looking forward to hearing other ideas.

[gsmet]

For now, I think I would start by splitting the method. It shouldn't be too hard if that's all it does.

@radcortez could we have a call to talk about this? I'd like to run some (probably stupid) ideas by you.

[radcortez]

@radcortez could we have a call to talk about this? I'd like to run some (probably stupid) ideas by you.

Sure, but I disagree with the stupid ideas. There are no stupid ideas :P

[fedinskiy]

Doing a bisecting and e44e07e68702db6f51f87ea4c5117488002c6f36 is affected

UPD: same goes for cb009c93a8a9841068b5ff8bd7e7edc4c3ed37e8

[geoand]

For now, I think I would start by splitting the method. It shouldn't be too hard if that's all it does.

Right, it's the easiest way to go over these sorts of problems. They have occurred in the past as well, and given how low the probability is of real applications being affected, it's a perfectly acceptable fix.