Details
-
Bug
-
Resolution: Fixed
-
P4
-
1.4.0
-
merlin
-
generic
-
generic
Description
Shashank Shekhar discovered a serious performance problem when the J2EE
RI loads stubs and ties.
The RI sets a Thread context class loader per application which has .jars
that aren't on the classpath.
Our Util.loadStub implementation, as described in the spec, first searched
the call stack for the latest user defined loader and tried it.
Unfortunately, the classes will only be found by the thread context loader, which is tried in the second step by the RMIClassLoader.
It turns out that there may wind up being multiple calls to
sun.misc.Launchers$AppClassLoader.loadClass, incuring quite a penalty
when the classpath is long.
Tests showed about 30 ms for the RI's classpath.
Attached are Shashank's slides detailing the call path, as well as a
stand alone test he wrote.
RI loads stubs and ties.
The RI sets a Thread context class loader per application which has .jars
that aren't on the classpath.
Our Util.loadStub implementation, as described in the spec, first searched
the call stack for the latest user defined loader and tried it.
Unfortunately, the classes will only be found by the thread context loader, which is tried in the second step by the RMIClassLoader.
It turns out that there may wind up being multiple calls to
sun.misc.Launchers$AppClassLoader.loadClass, incuring quite a penalty
when the classpath is long.
Tests showed about 30 ms for the RI's classpath.
Attached are Shashank's slides detailing the call path, as well as a
stand alone test he wrote.