On 23/12/2010 10:53, Roman Kennke wrote:
Hi Chris,
(Sorry for top-posting, my stupid email program cannot do proper quoting)
I don't understand why the CR is a 'request for enhancement' with 'very low'
priority. A memory leak should be a bug with at least high priority in my world
view.
I agree, it should be marked as a bug and a P3 (Medium Priority). I'll
see if I can locate the area (java.util.logging) owner and have the bug
updated.
I will see if I find time to implement a fix.
Thanks, that would be great.
-Chris.
**Roman
-----Original Message-----
From: Chris Hegarty [mailto:chris.hega...@oracle.com]
Sent: 22 December 2010 17:35
To: Roman Kennke
Cc: core-libs-dev@openjdk.java.net
Subject: Re: Potential memory leak in java.util.logging.Level
On 12/22/10 02:36 PM, Roman Kennke wrote:
Hello,
I believe java.util.logging.Level is potentially memory leaking. This can
happen if an application defines its own subclass of Level and is loaded by its
own classloader. Level's constructor adds a reference to the new instance of
the subclass to its 'known' ArrayList (which is a static field). This instance
is never removed from that list. And since this instance holds a reference to
its classloader, this means that no classes loaded by that classloader can be
unloaded. It could be argued that you should not do crazy stuff with
classloaders, but this happens invariably when you deal with applets. I guess
similar problems can arise on app servers as well.
I wonder why Level's constructors need to be protected though. If they were
public, and new Levels could be created simply by instantiating one, this whole
problem would not exist. Then the Level.known list would only reference
instances of its own class, which would be problematic, unless you create LOTS
of levels, which is unlikely. I don't like static collection fields anyway...
too prone to leaking.
Is this a known problem? Is there a solution to this, except not creating
custom log levels? How else could custom log levels be created under those
circumstances that would not trigger this problem?
This would appear to be a known issue, see CR 6992761 [1].
-Chris.
[1] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6992761
Thanks,
Roman
This communication is for informational purposes only. It is not
intended as an offer or solicitation for the purchase or sale of
any financial instrument or as an official confirmation of any
transaction. All market prices, data and other information are not
warranted as to completeness or accuracy and are subject to change
without notice. Any comments or statements made herein do not
necessarily reflect those of JPMorgan Chase& Co., its subsidiaries
and affiliates.
This transmission may contain information that is privileged,
confidential, legally privileged, and/or exempt from disclosure
under applicable law. If you are not the intended recipient, you
are hereby notified that any disclosure, copying, distribution, or
use of the information contained herein (including any reliance
thereon) is STRICTLY PROHIBITED. Although this transmission and any
attachments are believed to be free of any virus or other defect
that might affect any computer system into which it is received and
opened, it is the responsibility of the recipient to ensure that it
is virus free and no responsibility is accepted by JPMorgan Chase&
Co., its subsidiaries and affiliates, as applicable, for any loss
or damage arising in any way from its use. If you received this
transmission in error, please immediately contact the sender and
destroy the material in its entirety, whether in electronic or hard
copy format. Thank you.
Please refer to http://www.jpmorgan.com/pages/disclosures for
disclosures relating to European legal entities.
