Migrated from Google Code (issue 264)
👤 email@example.com 🕗 Aug 25, 2011 at 18:59 UTC
What steps will reproduce the problem?
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
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.
👤 firstname.lastname@example.org 🕗 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
👤 pe.fips 🕗 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.
👤 pe.fips 🕗 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?
👤 email@example.com 🕗 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.
👤 firstname.lastname@example.org 🕗 Aug 26, 2011 at 15:41 UTC
Yes, removing use of @ Delegate throughout the codebase makes the symptoms disappear.
👤 email@example.com 🕗 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.
👤 reinierz 🕗 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.
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:
👤 firstname.lastname@example.org 🕗 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.
👤 david.novalis.turner 🕗 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.
👤 email@example.com 🕗 Jul 10, 2012 at 23:42 UTC
The recent 0.11.2 had a regression with @ ExtentionMethods, could that be your issue?
👤 david.novalis.turner 🕗 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.
👤 reinierz 🕗 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.
End of migration