[BUG] Very slow compilation when lombok.val is combined with jdk 11

[rzukow]

Describe the bug
Code with some number of lombok.val compiles very slowly on jdk 11 (5s on jdk8 vs 2 minutes on jdk 11)

To Reproduce
Prepare a java project with hundreds of lombok.val and compile it on jdk11

Expected behavior
Compilation of code with lombok.val with jdk 11 should not be slower comparing to jdk 8

Version info (please complete the following information):

• Lombok 1.18.8
• openjdk version "11.0.3" 2019-04-16 LTS
• Gradle 5.4.1

** Workaround
As in jdk 11 you don't need val so much, I replaced few hundreds of vals with java 11 vars and this fixed the issue. It compiles in seconds instead of minutes.
But I think this is still a bug.

[Mr-DeWitt]

I've the same issue! The project compiles over 4 minutes instead of 24 seconds.
Switching back Java 1.8 solves the problem.

[Mr-DeWitt]

The problem occurs with openjdk 13 too.

[rspilker]

Would anybody be able to profile this, both on jdk8 and 11+ so we have an idea where the problem is?

[edudar]

Just a detail. I'm using val extensively for both main and test sources in one of my projects and only test is affected. main, however, compile a few seconds just fine but test takes over 2 minutes for 10 files. jdk11.0.6, gradle 6.+

[kossmoboleat]

I've also just found this problem in our code. It's the same for us that only in the test sources using val makes ":compileTestJava" take 75 seconds instead of 2 seconds with final var. As mentioned before compiling the main sources is fine with about 4 seconds even with val.

@rspilker I would be willing to profile it, but I'm not sure how. Would gradle-profiler work?

[kossmoboleat]

I think I got a profile successfully with JDK 13, which is attached. The flame graph seems to suggest to me that exceptions are thrown when running checkType().

~/P/c/d/c/registration » gradle-profiler --profile async-profiler --project-dir . clean compileTestJava                       remotes/origin/ecr-scanning~2 ✗

* Writing results to /Users/tim/Projects/cl/dad/ct/registration/profile-out-3

* Settings
Project dir: .
Output dir: profile-out-3
Profiler: async profiler
Benchmark: false
Versions: []
Gradle User Home: gradle-user-home
Targets: [clean, compileTestJava]

* Inspecting the build using its default Gradle version

* Stopping daemons

* Scenarios
Scenario: using Gradle 6.4
  Gradle 6.4 (/Users/tim/Projects/cl/dad/ct/registration/gradle-user-home/wrapper/dists/gradle-6.4-bin/aj6cyggqps6mdbpl6cfppfwqk/gradle-6.4)
  Run using: Tooling API
  Run: run tasks clean compileTestJava
  Cleanup: do nothing
  Gradle args: []
  Build changes: none
  Warm-ups: 2
  Builds: 1

* Running scenario using Gradle 6.4 (scenario 1/1)

* Stopping daemons

* Running warm-up build #1
Execution time 128065 ms

* Running warm-up build #2
Execution time 76858 ms

* Running measured build #1
Execution time 78839 ms

* Stopping daemons

* Results written to /Users/tim/Projects/cl/dad/ct/registration/profile-out-3
  /Users/tim/Projects/cl/dad/ct/registration/profile-out-3/6.4-flames.svg
  /Users/tim/Projects/cl/dad/ct/registration/profile-out-3/6.4-icicles.svg

profile-out-3.zip

[kossmoboleat]

Is the profile for JDK 13 enough or is one for JDK 8 or 11 necessary too? My code currently uses preview features, which I'd have to convert for those.

[kossmoboleat]

@rspilker Is a profile for JDK8 still necessary to debug this issue?

[kossmoboleat]

@rspilker @rzwitserloot what are the next steps here? Should I create another profile for JDK11? Can you give me a hint were to look for this problem?

[kossmoboleat]

@rspilker @rzwitserloot do you need more profiles to analyze this issue? I'd love to use val in my tests the same way I'm using it in the production code.

[Rawi01]

@kossmoboleat I checked out the flame graph and I agree that the exceptions are the problem. It is fascinating that it is only slow if you compile test code, that does not make sense 😕.

After some debugging I noticed that the method that throws the exception gets called a lot in some cases. It seems to be related to lambdas, maybe lombok calls the wrong method somewhere. Can you check if there is a common pattern you use in your test code and not/only sometimes in your normal project?

[kossmoboleat]

Hmm, I'll try to give it a shot. In the tests we're have a lot of heavily mocked unit tests with JUnit5 and Mockito. Mockito mocks automatically return default values for its methods. This auto-mocking or any calls to that might be the reason.

To check that, is there a minimal way I can trace or log the stacktrace when the exception is called? If I can debug lombok itself that would be interesting too, but maybe harder to get working for me.

[rzwitserloot]

This is the earlier report, but at this point I think #2652 is the better place to consolidate on this issue.

Duplicate of #2652