Re: Early Access builds of JDK 9 b113 & JDK 9 with Project Jigsaw b113 (#4848) are available on java.net

[Rory O'Donnell]

Hi Mark,

Thanks for the feedback, I think the best place to get help with this is 
on the jigsaw mailing list [1]


Rgds,Rory

[1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/

On 17/04/2016 21:30, Mark Thomas wrote:

On 15/04/2016 09:26, Rory O'Donnell wrote:

Hi Mark/Mladen,

Early Access b113  for JDK 9 is
available on java.net, summary of  changes are listed here
.

Early Access b113  (#4664) for JDK 9 with
Project Jigsaw is available on java.net.

  * The important change in this build is that root modules when
compiling code in the unnamed module, or when running and the main
class is loaded from the class path, do not include the EE modules.
More on this in JEP 261.
  * The other change in this build is that the -Xpatch option is now
aligned with what we have documented in JEP 261, support for the old
form has been removed.

We are very interested in hearing your experiences in testing any Early
Access builds. Have you have begun testing against
JDK 9 and or JDK 9 with Project Jigsaw EA builds, have you uncovered
showstopper issues that you would like to discuss?
We would really like to hear your findings so far, either reply to me or
via the mailing lists [1], [2].

Rory,

I've started testing Tomcat trunk with JDK 9 + Project Jigsaw and it
looks like we are going to hit a bunch of problems related to Tomcat's
memory leak protection.

The short version is there are lots of JDK calls that can result in a
reference being retained to the current class loader. If that class
loader is the web application class loader it often ends up being pinned
in memory. This triggers a memory leak when the web application is
reloaded since the web application class loader is not eligible for GC.

Tomcat generally uses reflection to find these problems. It then does
one of two things:
- If the JRE provides an API the application developer should have used
to clean up the reference, Tomcat does this for them and then logs a
very loud error message telling the developer they need to fix their app.
- If there is nothing the developer could have done to avoid the
problem, Tomcat cleans it up. Usually this is via reflection again.

Reporting this second class of issues as JRE bugs has been on my TODO
list for a long time. It looks like Java 9 is going to bump this to the
top of the list.

The first problem we have hit is related to RMI. The memory leak is
triggered by a call to:
java.rmi.registry.Registry.bind() or
java.rmi.registry.Registry.rebind()

The problem occurs when an object of a class loaded by the web
application class loader is bound to the RMI registry.

There is no standard API (that I have found) that completely removes all
references. In particular
java.rmi.registry.Registry.unbind()
doesn't help.

The code Tomcat uses to clean this up is at [1]. Essentially, we need to
remove any reference to the web application's class loader from the RMI
caches.

With JDK 9 this fails with:
java.lang.reflect.InaccessibleObjectException: Unable to make member of
class sun.rmi.transport.Target accessible:  module java.rmi does not
export sun.rmi.transport to unnamed module ...

I took a look at the JDK 9 API but I could not find a way to bypass
this.

Possible solutions include:
1. Some way that allows us to continue to use reflection as per the
current code.

2. A new method somewhere in the RMI API that clears all references
associated with a given class loader from the cache.

3. Modify Registry.unbind() so it removes all references.

4. Something else...

I do have a concern with 3 on its own that, while that would allow
applications to clear their own references, it would mean Tomcat would
have no way to check for the problem.

Ideally, I'd like to see the API extended so a) applications are able to
clean up after themselves and b) Tomcat can check for leaked references
and generate error messages for the ones they found.

Any and all suggestions gratefully received. I'm happy to take this to a
specific JRE list if you point me in the right direction.

Thanks,

Mark


[1]
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/loader/WebappClassLoaderBase.java?view=annotate#l2214



--
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland


-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Early Access builds of JDK 9 b113 & JDK 9 with Project Jigsaw b113 (#4848) are available on java.net

[Mark Thomas]

On 15/04/2016 09:26, Rory O'Donnell wrote:
> 
> Hi Mark/Mladen,
> 
> Early Access b113  for JDK 9 is
> available on java.net, summary of  changes are listed here
> .
> 
> Early Access b113  (#4664) for JDK 9 with
> Project Jigsaw is available on java.net.
> 
>  * The important change in this build is that root modules when
>compiling code in the unnamed module, or when running and the main
>class is loaded from the class path, do not include the EE modules.
>More on this in JEP 261.
>  * The other change in this build is that the -Xpatch option is now
>aligned with what we have documented in JEP 261, support for the old
>form has been removed.
> 
> We are very interested in hearing your experiences in testing any Early
> Access builds. Have you have begun testing against
> JDK 9 and or JDK 9 with Project Jigsaw EA builds, have you uncovered
> showstopper issues that you would like to discuss?
> We would really like to hear your findings so far, either reply to me or
> via the mailing lists [1], [2].

Rory,

I've started testing Tomcat trunk with JDK 9 + Project Jigsaw and it
looks like we are going to hit a bunch of problems related to Tomcat's
memory leak protection.

The short version is there are lots of JDK calls that can result in a
reference being retained to the current class loader. If that class
loader is the web application class loader it often ends up being pinned
in memory. This triggers a memory leak when the web application is
reloaded since the web application class loader is not eligible for GC.

Tomcat generally uses reflection to find these problems. It then does
one of two things:
- If the JRE provides an API the application developer should have used
to clean up the reference, Tomcat does this for them and then logs a
very loud error message telling the developer they need to fix their app.
- If there is nothing the developer could have done to avoid the
problem, Tomcat cleans it up. Usually this is via reflection again.

Reporting this second class of issues as JRE bugs has been on my TODO
list for a long time. It looks like Java 9 is going to bump this to the
top of the list.

The first problem we have hit is related to RMI. The memory leak is
triggered by a call to:
java.rmi.registry.Registry.bind() or
java.rmi.registry.Registry.rebind()

The problem occurs when an object of a class loaded by the web
application class loader is bound to the RMI registry.

There is no standard API (that I have found) that completely removes all
references. In particular
java.rmi.registry.Registry.unbind()
doesn't help.

The code Tomcat uses to clean this up is at [1]. Essentially, we need to
remove any reference to the web application's class loader from the RMI
caches.

With JDK 9 this fails with:
java.lang.reflect.InaccessibleObjectException: Unable to make member of
class sun.rmi.transport.Target accessible:  module java.rmi does not
export sun.rmi.transport to unnamed module ...

I took a look at the JDK 9 API but I could not find a way to bypass
this.

Possible solutions include:
1. Some way that allows us to continue to use reflection as per the
current code.

2. A new method somewhere in the RMI API that clears all references
associated with a given class loader from the cache.

3. Modify Registry.unbind() so it removes all references.

4. Something else...

I do have a concern with 3 on its own that, while that would allow
applications to clear their own references, it would mean Tomcat would
have no way to check for the problem.

Ideally, I'd like to see the API extended so a) applications are able to
clean up after themselves and b) Tomcat can check for leaked references
and generate error messages for the ones they found.

Any and all suggestions gratefully received. I'm happy to take this to a
specific JRE list if you point me in the right direction.

Thanks,

Mark


[1]
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/loader/WebappClassLoaderBase.java?view=annotate#l2214


-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Early Access builds of JDK 9 b113 & JDK 9 with Project Jigsaw b113 (#4848) are available on java.net

[Rory O'Donnell]

Hi Mark/Mladen,

Early Access b113  for JDK 9 is 
available on java.net, summary of  changes are listed here 
.


Early Access b113  (#4664) for JDK 9 with 
Project Jigsaw is available on java.net.


 * The important change in this build is that root modules when
   compiling code in the unnamed module, or when running and the main
   class is loaded from the class path, do not include the EE modules.
   More on this in JEP 261.
 * The other change in this build is that the -Xpatch option is now
   aligned with what we have documented in JEP 261, support for the old
   form has been removed.

We are very interested in hearing your experiences in testing any Early 
Access builds. Have you have begun testing against
JDK 9 and or JDK 9 with Project Jigsaw EA builds, have you uncovered 
showstopper issues that you would like to discuss?
We would really like to hear your findings so far, either reply to me or 
via the mailing lists [1], [2].


Rgds,Rory

[1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/
[2] http://mail.openjdk.java.net/pipermail/jdk9-dev/

--
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA, Dublin,Ireland