search

projectlombok / lombok

Very spicy additions to the Java programming language.
https://projectlombok.org/
Other
12.88k stars 2.39k forks source link

Unbounded memory use in eclipse #337

Closed lombokissues closed 9 years ago

lombokissues commented 9 years ago

Migrated from Google Code (issue 264)

lombokissues commented 9 years ago

:bust_in_silhouette: jwnimmer@jaybridge.com   :clock8: Aug 25, 2011 at 18:59 UTC

What steps will reproduce the problem?

  1. Open my project of ~20kloc Java with eclipse + lombok:
  2. Edit, run, save, etc. as usual.
  3. After 30-60 minutes, everything becomes unusually slow (3-15+ seconds to save, intelli-sense, compile, ...) due to GC pauses. The 1GB heap size of the eclipse JVM is full and a force-GC only reclaims a couple percent, soon to be used up again.

What is the expected output? What do you see instead?

No performance degradation over time, memory use scales with the size of the project, not how long my IDE is open.

What version of the product are you using? On what operating system?

Please provide any additional information below.

Unfortunately, I cannot share the source code for the project. I can post the eclipse settings and preferences if that is helpful. I have several save actions enabled, including auto-formatting.

FindBugs is also set to run incrementally on every save.

I've taken a heap dump and used eclipse MemoryAnalyzer. The Leak Suspects report says: The classloader "lombok.patcher.equinox.EquinoxClassLoader @ 0x69f24ec0" occupies 741,208,216 (92.32%) bytes. Within that classloader, there are: 140 MiB of org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment 70 MiB of org.eclipse.jdt.internal.compiler.ClassFile 67 MiB of org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding 65 MiB of org.eclipse.jdt.internal.compiler.lookup.SourceTypeBinding 61 MiB of org.eclipse.jdt.internal.compiler.ast.CompilationUnitDeclaration ... etc ...

This is fairly straightforward to reproduce for me (happens regularly) but does need at least 15 minutes of use to see a substantial increase in live heap use. I'm going to bisect across my plug-ins and settings to find the minimum sufficient setup to reproduce this, but it will take me a little while.

If anyone has ideas on other diagnostic tools or settings to explore to help narrow this down, I'm open to suggestions.

lombokissues commented 9 years ago

:bust_in_silhouette: jwnimmer@jaybridge.com   :clock8: Aug 25, 2011 at 20:31 UTC

When I uninstall FindBugs, turn off Save Actions, and turn off Build Automatically, this still happens. The creep rate of live heap use seems subjectively less, I will try to make some measurements later to quantify the differences.

My current test methodology is

lombokissues commented 9 years ago

:bust_in_silhouette: pe.fips   :clock8: Aug 26, 2011 at 09:44 UTC

Did some profiling myself, the issue is a map in PatchDelegate that determines whether @ Delegate was already handled or not.

I attached a patch that should fix this issue, but before I commit the changes I would rather have Reinier, Roel or Robbert Jan look at it.

lombokissues commented 9 years ago

:bust_in_silhouette: pe.fips   :clock8: Aug 26, 2011 at 09:44 UTC

:link: fix_memleak_patchdelegate.patch View file

lombokissues commented 9 years ago

:bust_in_silhouette: pe.fips   :clock8: Aug 26, 2011 at 09:49 UTC

Ah I forgot to ask, do you use @ Delegate in your code, as PatchDelegate seems to be the culprit?

lombokissues commented 9 years ago

:bust_in_silhouette: jwnimmer@jaybridge.com   :clock8: Aug 26, 2011 at 11:40 UTC

My other bit of diagnosis last night was that delombok'ing the code, but still running eclipse + lombok.jar, makes the issue go away.

Yes, we do use @ Delegate. I'll try removing the few uses of @ Delegate we have and see if that stops the problem.

lombokissues commented 9 years ago

:bust_in_silhouette: jwnimmer@jaybridge.com   :clock8: Aug 26, 2011 at 15:41 UTC

Yes, removing use of @ Delegate throughout the codebase makes the symptoms disappear.

lombokissues commented 9 years ago

:bust_in_silhouette: jwnimmer@jaybridge.com   :clock8: Aug 26, 2011 at 21:39 UTC

Looking at the patch... if Eclipse.isGenerated won't suffice for some reason, another fix might be to use WeakHashMap instead of IdentityHashMap, because ASTNode is guaranteed to use identity equals already.

lombokissues commented 9 years ago

:bust_in_silhouette: reinierz   :clock8: Sep 20, 2011 at 18:51 UTC

Abusing the generatedBy mapping for this seems like a bad idea. I'm fairly sure when we wrote "IdentityHashMap", we actually meant "WeakHashMap" (which is like an IdentityHashMap). jwnimmer had it right, in other words ;)

git blame says its me. Punishment will be handed out for this baseless display of stupidity.

Fixed: https://github.com/rzwitserloot/lombok/commit/41abd976afe0be0e4c7c2dbd6aee576fa41e8c47

That's a pretty big one; I think we'll be rolling out an 0.10.1 pretty soon.

In the mean time, there's the edge build which I just updated:

https://projectlombok.org/download-edge.html

lombokissues commented 9 years ago

:bust_in_silhouette: jwnimmer@jaybridge.com   :clock8: Sep 29, 2011 at 15:28 UTC

FWIW, we grabbed "version: 0.10.1-EDGE 2011-09-20 18:50 UTC" a week ago, and the fix is working well so far, no more problems.

lombokissues commented 9 years ago

:bust_in_silhouette: david.novalis.turner   :clock8: Jul 10, 2012 at 23:23 UTC

I'm using lombok 0.11.2, and I'm experiencing exactly these symptoms. However, I'm not using @ Delegate -- only @ Data. My codebase is https://github.com/openplans/OpenTripPlanner . I also have m2e and WTP installed.

I've experienced this on both Eclipse Indigo and a fresh install of Juno. We just started using Lombok last week, which is when the Eclipse problem started happening. Further, VisualVM tells me that the two largest objects in terms of retained size are lombok.patcher.equinox.EquinoxClassLoader and class lombok.eclipse.handlers.EclipseHandlerUtil.

Since the symptoms are so similar, I thought I would comment on this bug. But if you prefer, I could open a new bug.

lombokissues commented 9 years ago

:bust_in_silhouette: jwnimmer@jaybridge.com   :clock8: Jul 10, 2012 at 23:42 UTC

The recent 0.11.2 had a regression with @ ExtentionMethods, could that be your issue? issue #463 https://groups.google.com/forum/?fromgroups﹟!topic/project-lombok/rXJJA5v3FjM

lombokissues commented 9 years ago

:bust_in_silhouette: david.novalis.turner   :clock8: Jul 11, 2012 at 01:10 UTC

No, we are not using @ ExtensionMethod. We're only using @ Data, and we're only using it on one class.

lombokissues commented 9 years ago

:bust_in_silhouette: reinierz   :clock8: Apr 08, 2013 at 09:03 UTC

Comments on verified issues tend to fly under the radar unnoticed. Which is why I'm responding to this almost a year late. If it's still happening, definitely open a new issue.

For what it's worth, EclipseHandlerUtil is a utility class that is never constructed (it has all static methods in it), so it is not possible that that's scoring high on the retained size chart. It should score a 0. Possibly VisualVM simply means that code inside it is the source of the allocations.

lombokissues commented 9 years ago

End of migration