Use of internal APIs to protect against memory leaks
Alan.Bateman at oracle.com
Fri Sep 19 16:19:58 UTC 2014
On 19/09/2014 14:12, Mark Thomas wrote:
> The memory leaks stem from the generally more complex class loader
> structure present in a JavaEE container than is typically present in a
> standalone Java app.
> At this point, I have two questions.
> 1. Is this community interested in examining these memory leaks further
> to see what can be done in the JDK to avoid them?
> 2. If yes, would you prefer a discussion thread for each leak or one
> thread for all leaks? Personally, I think a thread per leak would be
> easier to manage but it might make sense just to look at one leak first
> as there may well be some common themes that emerge which would save us
> discussing them on each thread.
I agree with with your suggestion that a discussion per so-called leak
would be better than trying to discuss all of this in one thread. The
hard bit will be finding the right list to start the discussion. For the
AWT issues then awt-dev is the place to start. For the 2D disposer issue
then 2d-dev is the place to start. The security-dev list is the place
for the security library issues. The net-dev list for the URLConnection
issue. I think core-libs-dev is probably okay for the rest.
Just to set expectations, it's possible that the outcome of some of
these will be just a bug in the JIRA. In some cases then I expect you
might get a bit of push back as there are performance and compatibility
issues to take account. As an example, the system-wide/singleton ORB
returned by ORB.init should never be located via the TCCL. However
switching this to using the system class loader breaks a number of 3rd
party ORBs that freely cast between per-application ORBs of whatever ORB
is bundled with the application and the system-wide ORB that acts as the
type code factory. However in general then having the JDK cache anything
that is located via the TCCL is a bug and I think you will get support
for poking at those issues.
More information about the core-libs-dev