-
Notifications
You must be signed in to change notification settings - Fork 4.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bazel HEAD OOMs during analysis phase when JavaPluginInfo provides Java outputs information #14287
Comments
@comius FYI I think you added this commit. |
I would need a reproducer for this, can you provide one? It seems though rules_kotlin are at fault, what version are you using? Does changing the rules_kotlin version make things better/worse? Is there something useful in the heapdump? You're looking for a large number of JavaPluginInfo/JavaOutputs. To get a heap dump increase memory using Ideally I would compare a heapdump before and after the commit f73e28c. |
We are using an up to date version of rules Kotlin that has the
I'll work on getting a heap dump. |
Heap for 5.0.0 RC2 jmapd-5.0.0-RC2.txt |
The stack trace is a bit off compared to rules_kotlin HEAD. The call at io_bazel_rules_kotlin/kotlin/internal/jvm/compile.bzl:780 is the call to |
Cc @Wyverald |
Comparison of heap dumps show insane increase in object arrays and some increase in integer arrays:
merge call using a list for javaOutputs looks to be at fault here: |
Can you check if #14288 fixes it? Perhaps provide new heapdump. |
The heap looks much better with that commit pulled in. jmapd-patched.txt The heap for a larger app jmapd-patched-larger-app.txt |
Comparing jmap reverted and patched, there is even 34MB improvement. |
Thanks for flagging @meisterT. Let's get the fix cherrypicked into the rc2 branch. |
JavaPluginInfo merging of java_outputs caused a significant regression when a large number of plugins is present. This value is not used by native code and it does not get exposed to Starlark. The only use case for java_outputs is IDE integrations, where the value is used from a single java_plugin target. Fixes #14287 Closes #14288. PiperOrigin-RevId: 410502716
Description of the problem / feature request:
Bazel HEAD runs out of memory during the analysis phase of a build.
I did a git bisect tracking the issue back to this commit f73e28c as the culprit.
The stacktrace that eventually comes out:
Bugs: what's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.
Create a large java project that has lots of java plugins attached to each target. I'm able to repro with one of our smaller apps which has about 583 java targets, most of which have annotation processors.
The text was updated successfully, but these errors were encountered: