Unbounded memory use in eclipse #337

Closed
lombokissues opened this Issue Jul 14, 2015 · 15 comments

Projects

None yet

2 participants

@lombokissues
Collaborator

Migrated from Google Code (issue 264)

@lombokissues
Collaborator

πŸ‘€ jwnimmer@jaybridge.com Β  πŸ•— 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?

  • Running on Ubuntu 10.04.
  • Lombok v0.10.0 "Burning Emu" (August 19th, 2011).
  • Eclipse Version: 3.7.0, Build id: I20110613-1736
    • +FindBugs 1.3.9.20090821
    • +Subclipse 1.6.18 and related dependencies.

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
Collaborator

πŸ‘€ jwnimmer@jaybridge.com Β  πŸ•— 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

  • open the project,
  • open a large-ish (~1 kloc) file,
  • edit whitespace, save,
    • repeat many edit-saves
  • in jvisualvm: force gc, look at live heap use,
    • when heap is unexpectedly large, heap dump, look at MemoryAnalyzer
      and confirm that the EquinoxClassLoader is the hog
@lombokissues
Collaborator

πŸ‘€ 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.

@lombokissues
Collaborator

πŸ‘€ pe.fips Β  πŸ•— Aug 26, 2011 at 09:44 UTC

πŸ”— fix_memleak_patchdelegate.patch View file

@lombokissues
Collaborator

πŸ‘€ 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?

@lombokissues
Collaborator

πŸ‘€ jwnimmer@jaybridge.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.

@lombokissues
Collaborator

πŸ‘€ jwnimmer@jaybridge.com Β  πŸ•— Aug 26, 2011 at 15:41 UTC

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

@lombokissues
Collaborator

πŸ‘€ jwnimmer@jaybridge.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.

@lombokissues
Collaborator

πŸ‘€ 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.

Fixed: 41abd97

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 lombokissues removed the accepted label Jul 14, 2015
@lombokissues
Collaborator

πŸ‘€ jwnimmer@jaybridge.com Β  πŸ•— 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
Collaborator

πŸ‘€ 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.

@lombokissues
Collaborator

πŸ‘€ jwnimmer@jaybridge.com Β  πŸ•— 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
Collaborator

πŸ‘€ 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.

@lombokissues
Collaborator

πŸ‘€ 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.

@lombokissues
Collaborator

End of migration

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment