A customer has found out the different behavior between 1.3.1 and Tiger-b64
related to handling files.
REPRODUCE :
1) unfold the attached test.zip
2) go to the dir. where the above zip file was unfolded.
3) Launch "java -Xdebug FileLeak app1" in Tiger-b64
4) go to temp dir.
5) Try to delete the apps.jar by explore
==> You can not delete the file.
Then track the the above steps in 1.3.1_11.
==> You CAN delete the apps.jar file at the step5.
PROGRAM FLOW:
The test program, FileLeak works as follows.
1) Load the class specified in arg. of FileLeeak from temp\apps.jar.
2) Execute the loaded class.
3) Clear all the references
4) Invoke SystemGC
5) Goto Sleep
PROBLEM :
The type information stored in
PlaceholderEntry*@SystemDictionary::_placeholder_bucketsmn
(systemDictionary.cpp) has never been deleted even though all the
reference are cleared.
As a result, when users try to delete the file which type information are
stored they can not delete because of file busy.
MORE INFORMATION:
- Program flow in JVM
resolve_or_null() (in systemDictionary.cpp ) calls
resolve_array_class_or_null(), when target class is array type.
In resolve_array_class_or_null(),
1) resolve_instance_class_or_null(j is called
when the name of class is stored.
2) record_primitive_array_loading() is called
when the type is stored.
Both in above 1) and 2), class name and type are stored in
placeholder_bbucket[] by add_placeholder() respectively.
In the case 1), the stored class name is deleted from placeholder_bucket
by remove_placeholder() in update_dictionary().
However, in the case 2), remove_placeholder() does not seem called.
So, data can not be released and users can not delete the jar file.
- JRE/JDK versions
- 1.3.1_0X : apps.jar file can be deleted
- 1.4.2_0X : apps.jar file can NOT be deleted
- Tigerb64 : apps.jar file can NOT be deleted
NOTE:
Please try to launch
"java -Xdebug FileLeak app2"
in Tiger-b64. You can delete apps.jar.
Please check the diff. between app1.java and app2.java under temp dir.
related to handling files.
REPRODUCE :
1) unfold the attached test.zip
2) go to the dir. where the above zip file was unfolded.
3) Launch "java -Xdebug FileLeak app1" in Tiger-b64
4) go to temp dir.
5) Try to delete the apps.jar by explore
==> You can not delete the file.
Then track the the above steps in 1.3.1_11.
==> You CAN delete the apps.jar file at the step5.
PROGRAM FLOW:
The test program, FileLeak works as follows.
1) Load the class specified in arg. of FileLeeak from temp\apps.jar.
2) Execute the loaded class.
3) Clear all the references
4) Invoke SystemGC
5) Goto Sleep
PROBLEM :
The type information stored in
PlaceholderEntry*@SystemDictionary::_placeholder_bucketsmn
(systemDictionary.cpp) has never been deleted even though all the
reference are cleared.
As a result, when users try to delete the file which type information are
stored they can not delete because of file busy.
MORE INFORMATION:
- Program flow in JVM
resolve_or_null() (in systemDictionary.cpp ) calls
resolve_array_class_or_null(), when target class is array type.
In resolve_array_class_or_null(),
1) resolve_instance_class_or_null(j is called
when the name of class is stored.
2) record_primitive_array_loading() is called
when the type is stored.
Both in above 1) and 2), class name and type are stored in
placeholder_bbucket[] by add_placeholder() respectively.
In the case 1), the stored class name is deleted from placeholder_bucket
by remove_placeholder() in update_dictionary().
However, in the case 2), remove_placeholder() does not seem called.
So, data can not be released and users can not delete the jar file.
- JRE/JDK versions
- 1.3.1_0X : apps.jar file can be deleted
- 1.4.2_0X : apps.jar file can NOT be deleted
- Tigerb64 : apps.jar file can NOT be deleted
NOTE:
Please try to launch
"java -Xdebug FileLeak app2"
in Tiger-b64. You can delete apps.jar.
Please check the diff. between app1.java and app2.java under temp dir.
- relates to
-
JDK-5093520 objects being kept alive in perm gen and old gen when debugger attached
- Resolved