JDK-6489540 : The Disposer thread could cause memory leaks in user applications
  • Type: Bug
  • Component: client-libs
  • Sub-Component: 2d
  • Affected Version: 1.4.2
  • Priority: P3
  • Status: Closed
  • Resolution: Won't Fix
  • OS: generic
  • CPU: generic
  • Submitted: 2006-11-02
  • Updated: 2016-01-14
  • Resolved: 2016-01-14
Related Reports
Relates :  
JDK-6501120 - (thread) Existing constructors lead to pinned copies of inheritable thread locals
Relates :  
JDK-4219095 - inheritable thread locals: need way to snapshot and recreate complete state
Relates :  
JDK-6936389 - FontManager.fileCloser may cause memory leak in applets
Description
To dispose of Java2D-related resources we
  (Java2D) create a Java2D-Disposer thread
  the first time any Java2D-related activity
  is encountered (it is started from static block
  of Disposer class). This thread then lives
  forever.

  There is a couple of problems: first, if the
  customer's thread has an InheritableThreadLocal,
  our thread inherits it and thus it never gets
  disposed of even if customer's thread went away.

  This is not specific to our Disposer
  thread - if, say, an EventDispatchThread is started
  from the customer's thread it could also run
  into this issue.

  Another issue is that the Disposer thread
  inherits the parent thread's contextClassLoader,
  and since our thread lives forever, any classes
  referenced by that loader are not being collected
  (and since those could be customer's classes, they
  could contain some large data, leading to huge
  memory leaks).

Here's a thread which started the discussion:
   http://forums.java.net/jive/thread.jspa?messageID=169608&#169608
Comments
No plans to resolve at this time - reopen if there is a concern.
14-01-2016
- this is an issue reported against 7(7u), - there are now affected version 9 filed for this issue - 7u issues are transferred to Sustaining Nevertheless if someone have a report against 9 - please reopen and add affectedVersion 9 or 7u specific escalations might be reopen to Sustaining
10-08-2014
These are all approved for deferral to JDK 9 so you can update the FixVersion to state JDK 9. Kind regards, Mathias
29-08-2013
These are all approved for deferral to JDK 9 so you can update the FixVersion to state JDK 9. Kind regards, Mathias
29-08-2013
These are all approved for deferral to JDK 9 so you can update the FixVersion to state JDK 9. Kind regards, Mathias
29-08-2013
Converted "8-client-defer-candidate" label to "8-defer-request" by SQE' OK.
15-08-2013
*This is anti-deferral criteria list*: - P2 -------------- Engineering's Criteria ------------------------------------- - tck-red labeled - conformance labeled - P3 regressions reported/labeled against jdk8 - findbugs, parfait, eht labeled bugs - CAP <1 year reported - netbeans <1 year reported Victor ----------------- SQE's OK --------------------------------- Yes, we are ok with that thanks, Mikhail
15-08-2013
EVALUATION While working on a regression test case I found at least one other place which could cause a leak: java.util.logging.LogManager's Cleaner thread doesn't reset context class loader. I actually saw it holding the reference to the loader, so it's not a potential but real issue.
03-11-2006
SUGGESTED FIX *** Disposer.java: 1.9 --- Disposer.java *************** *** 65,70 **** --- 65,71 ---- tg = tgn, tgn = tg.getParent()); Thread t = new Thread(tg, disposerInstance, "Java2D Disposer"); + t.setContextClassLoader(ClassLoader.getSystemClassLoader()); t.setDaemon(true); t.setPriority(Thread.MAX_PRIORITY); t.start();
02-11-2006
EVALUATION Unfortunately the first problem could not be addressed: there is no way not to inherit parent thread's local storage. See bug 4219095: inheritable thread locals: need way to snapshot and recreate complete state As for the second problem, it could be addressed by resetting the context class loader when the thread is created.
02-11-2006