On windows, when executing the attached testcase, the deletion of the particular jar
(when prompted to do so) would succeed for pre-mustang releases (and some early
mustang builds) and fail when using the more recent mustang builds (say b50).
This is observed when verifying the fix for a JCE bug (5098318) "Cached Jar file
should be released on appl. exit even that is opended by Cipher" against various
J2SE releases. After turning the caching off in JCE, the testcase for 5098318
passes for 1.4.2, 1.5.0 releases, and early mustang builds (say b04), and failed
for more recent mustang builds.
The attached testcase is based on the testcase for 5098318 but it stripped off the
dependency on JCE.
Lastly, one interesting observation from Brad Wetmore is that the jar deletion
often succeeded when class Hello is unloaded (by setting -XX:+TraceClassUnloading)
and failed otherwise.
A few more comments.
Here's one of the problems which made this difficult to analyze, but please note,
Valerie has isolated JCE from the problem, so it's not JCE.
This could be a ZIP/Jar file issue, but I'm not convinced because the test
passed with "n" of jar entries reads, but failed with "n+1". This seems to
be pointing more to GC.
In the JCE jar verification, a class file is verified by reading its contents
and comparing signed hash values. For a successful verification,
we take every class file in the jar and make sure every
signature is valid. If I stopped verification step after 8 jar elements,
the war class was unloaded and the jar file could be deleted. However,
if I stopped verification after 9 or more jar elements, the class was NOT unloaded
and the jar file could not be deleted.
I went through the hprof data, and could find no references to the Hello class
from the root set, and thus couldn't find any reason why this wasn't being
unloaded. I'm not an expert in this area by any means, so I may
have misread something.
This is concerning because there was an escalation filed against JCE for 1.4.2/1.5,
and will probably be the same problem under 1.6 if not fixed. We have put
back the JCE change to not hold the reference, but if the GC isn't working right,
we may be back to another escalation.
Brad
(when prompted to do so) would succeed for pre-mustang releases (and some early
mustang builds) and fail when using the more recent mustang builds (say b50).
This is observed when verifying the fix for a JCE bug (5098318) "Cached Jar file
should be released on appl. exit even that is opended by Cipher" against various
J2SE releases. After turning the caching off in JCE, the testcase for 5098318
passes for 1.4.2, 1.5.0 releases, and early mustang builds (say b04), and failed
for more recent mustang builds.
The attached testcase is based on the testcase for 5098318 but it stripped off the
dependency on JCE.
Lastly, one interesting observation from Brad Wetmore is that the jar deletion
often succeeded when class Hello is unloaded (by setting -XX:+TraceClassUnloading)
and failed otherwise.
A few more comments.
Here's one of the problems which made this difficult to analyze, but please note,
Valerie has isolated JCE from the problem, so it's not JCE.
This could be a ZIP/Jar file issue, but I'm not convinced because the test
passed with "n" of jar entries reads, but failed with "n+1". This seems to
be pointing more to GC.
In the JCE jar verification, a class file is verified by reading its contents
and comparing signed hash values. For a successful verification,
we take every class file in the jar and make sure every
signature is valid. If I stopped verification step after 8 jar elements,
the war class was unloaded and the jar file could be deleted. However,
if I stopped verification after 9 or more jar elements, the class was NOT unloaded
and the jar file could not be deleted.
I went through the hprof data, and could find no references to the Hello class
from the root set, and thus couldn't find any reason why this wasn't being
unloaded. I'm not an expert in this area by any means, so I may
have misread something.
This is concerning because there was an escalation filed against JCE for 1.4.2/1.5,
and will probably be the same problem under 1.6 if not fixed. We have put
back the JCE change to not hold the reference, but if the GC isn't working right,
we may be back to another escalation.
Brad
- relates to
-
JDK-5098318 Cached Jar file should be released on appl. exit even that is opended by Cipher
-
- Resolved
-
-
JDK-6320351 new register allocator for c1
-
- Resolved
-
-
JDK-5095053 Use C2's ExceptionHandlerTable for C1 exception dispatch
-
- Resolved
-