Optimize config generation

[aloubyansky]

Description

After merging #30506 io.quarkus.maven.it.DevMojoIT.testThatTheApplicationIsReloadedMultiModule started to fail with the OOME. Although these dev mode tests are run with -Xmx128m, they do highlight an issue in the way our config classes are generated currently.

Implementation ideas

As an alternative to the current impl, @radcortez suggested to switch to the ConfigMapping approach instead in https://quarkusio.zulipchat.com/#narrow/stream/187038-dev/topic/OOME.20in.20main/near/343476381

[quarkus-bot]

You added a link to a Zulip discussion, please make sure the description of the issue is comprehensive and doesn't require accessing Zulip

This message is automatically generated by a bot.

[gsmet]

I will experiment with this soon and report back.

[geoand]

#32209 changes RESTEasy Reactive configuration to @ConfigMapping

[aloubyansky]

@geoand I think you meant #32224

[geoand]

Oops :)

[aloubyansky]

I don't think this is done yet on "full scale". I'll re-open it for further evaluation.

[yrodiere]

Thanks for catching this, yes GitHub auto-closed this when I merged the PR but that's wrong.

[radcortez]

It would be interesting to measure if the changes are showing any impact. I'm pretty sure they will, but nothing like confirming it :)

[aloubyansky]

One way of testing an impact would be re-running the test mentioned in the description with -Xmx128m.

[gsmet]

FWIW, I just tried to lower the memory for these tests again and things look worse than before as I can't even get to the point of starting Quarkus: the bootstrap itself requires more than 128 MB of heap space.

Failure is in:

Caused by: java.lang.OutOfMemoryError: Java heap space
	at org.apache.maven.model.Dependency.clone(Dependency.java:246)
	at org.apache.maven.model.DependencyManagement.clone(DependencyManagement.java:75)
	at org.apache.maven.model.building.ModelCacheTag$2.intoCache(ModelCacheTag.java:109)
	at org.apache.maven.model.building.ModelCacheTag$2.fromCache(ModelCacheTag.java:114)
	at org.apache.maven.model.building.ModelCacheTag$2.fromCache(ModelCacheTag.java:95)
	at org.apache.maven.model.building.DefaultModelBuilder.getCache(DefaultModelBuilder.java:1252)
	at org.apache.maven.model.building.DefaultModelBuilder.importDependencyManagement(DefaultModelBuilder.java:1151)
	at org.apache.maven.model.building.DefaultModelBuilder.build(DefaultModelBuilder.java:486)
	at org.apache.maven.model.building.DefaultModelBuilder.build(DefaultModelBuilder.java:410)
	at org.apache.maven.model.building.DefaultModelBuilder.build(DefaultModelBuilder.java:243)
	at io.quarkus.bootstrap.resolver.maven.MavenModelBuilder.build(MavenModelBuilder.java:63)
	at org.apache.maven.repository.internal.DefaultArtifactDescriptorReader.loadPom(DefaultArtifactDescriptorReader.java:281)
	at org.apache.maven.repository.internal.DefaultArtifactDescriptorReader.readArtifactDescriptor(DefaultArtifactDescriptorReader.java:172)
	at org.eclipse.aether.internal.impl.collect.df.DfDependencyCollector.resolveCachedArtifactDescriptor(DfDependencyCollector.java:382)
	at org.eclipse.aether.internal.impl.collect.df.DfDependencyCollector.getArtifactDescriptorResult(DfDependencyCollector.java:368)
	at org.eclipse.aether.internal.impl.collect.df.DfDependencyCollector.processDependency(DfDependencyCollector.java:218)
	at org.eclipse.aether.internal.impl.collect.df.DfDependencyCollector.processDependency(DfDependencyCollector.java:156)
	at org.eclipse.aether.internal.impl.collect.df.DfDependencyCollector.process(DfDependencyCollector.java:138)
	at org.eclipse.aether.internal.impl.collect.df.DfDependencyCollector.doRecurse(DfDependencyCollector.java:343)
	at org.eclipse.aether.internal.impl.collect.df.DfDependencyCollector.processDependency(DfDependencyCollector.java:277)
	at org.eclipse.aether.internal.impl.collect.df.DfDependencyCollector.processDependency(DfDependencyCollector.java:156)
	at org.eclipse.aether.internal.impl.collect.df.DfDependencyCollector.process(DfDependencyCollector.java:138)
	at org.eclipse.aether.internal.impl.collect.df.DfDependencyCollector.doCollectDependencies(DfDependencyCollector.java:108)
	at org.eclipse.aether.internal.impl.collect.DependencyCollectorDelegate.collectDependencies(DependencyCollectorDelegate.java:222)
	at org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.collectDependencies(DefaultDependencyCollector.java:87)
	at org.eclipse.aether.internal.impl.DefaultRepositorySystem.collectDependencies(DefaultRepositorySystem.java:305)
	at io.quarkus.bootstrap.resolver.maven.MavenArtifactResolver.collectManagedDependencies(MavenArtifactResolver.java:307)
	at io.quarkus.bootstrap.resolver.maven.ApplicationDependencyTreeResolver.collectDependencies(ApplicationDependencyTreeResolver.java:592)
	at io.quarkus.bootstrap.resolver.maven.ApplicationDependencyTreeResolver.injectDeploymentDependencies(ApplicationDependencyTreeResolver.java:493)
	at io.quarkus.bootstrap.resolver.maven.ApplicationDependencyTreeResolver.resolve(ApplicationDependencyTreeResolver.java:197)
	at io.quarkus.bootstrap.resolver.BootstrapAppModelResolver.buildAppModel(BootstrapAppModelResolver.java:321)
	at io.quarkus.bootstrap.resolver.BootstrapAppModelResolver.doResolveModel(BootstrapAppModelResolver.java:286)

[gsmet]

/cc @aloubyansky ^

[gsmet]

Above stacktrace is testing:

[ERROR] TestMojoIT>LaunchMojoTestBase.testThatTheTestsAreReRunMultiModule:34 » ConditionTimeout Condition with lambda expression in io.quarkus.maven.it.continuoustesting.TestModeContinuousTestingMavenTestUtils was not fulfilled within 3 minutes.

[aloubyansky]

When it comes to TestMojoIT, there is only one test that loads only 4 workspace modules.

[gsmet]

From what I can see I have failure in the Failsafe tests also if I disable Surefire.

[aloubyansky]

@gsmet were you changing https://github.com/quarkusio/quarkus/blob/main/test-framework/maven/src/main/java/io/quarkus/maven/it/RunAndCheckMojoTestBase.java#L86 for testing?

[gsmet]

Yes. I reduced it to 64M first to see how it was doing, then raised it to 128M, which was our initial value, before we started having issues IIRC.

[aloubyansky]

I ran io.quarkus.maven.it.DevMojoIT.testThatTheApplicationIsReloadedMultiModule with 128M w/o failing.

[aloubyansky]

Ah, hold on, I'll re-test.

[aloubyansky]

Yes, still OOME.

[aloubyansky]

It doesn't look like it's the size of the workspace though, it loads only for modules. It must be something else.

[gsmet]

I haven't tried to dump the memory on OOME. Do you want me to do that?

[aloubyansky]

Sure, thanks.

[gsmet]

Related are:

• Zip filesystems consume a lot of memory on bootstrap #35280
• Avoid keeping references to BytecodeRecorderImpl #35282

[radcortez]

We did many optimizations in the last few releases with:

• Update SmallRye Config to 3.8.1 #40225
• Update SmallRye Config to 3.5.1 #37794
• Update SmallRye Config to 3.3.4 #35643

And many more... I think we can close this one.