Use of internal APIs to protect against memory leaks
All, As you may know I am one of the Apache Tomcat committers. The Tomcat project was approached recently[1] to see what, if any, internal APIs Tomcat was using as part of the JDK 9 preparations. My response was that the only place Tomcat does this is in the memory leak prevention class [2]. I also commented that if the memory leaks could be addressed then we'd have no need to us the internal API. The response from Oracle was a suggestion to bring up these memory leaks on this list. 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. Mark [1] http://tomcat.markmail.org/thread/n3n6arf3j7f27zhb [2] http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/core/JreM...
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. -Alan
For the 2D disposer issue then 2d-dev is the place to start
The 2d disposer has a call to Thread.setContextClassLoader(null) It's been there since JDK6u21 ... and is in all later releases. https://bugs.openjdk.java.net/browse/JDK-6936389 So there is no need I see for accessing this in JDK 9 -phil. On 9/19/2014 9:19 AM, Alan Bateman wrote:
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.
-Alan
participants (3)
-
Alan Bateman
-
Mark Thomas
-
Phil Race