Details
Backports
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-2132717 | 5.0u7 | Dmitriy Samersoff | P2 | Resolved | Fixed | b01 |
JDK-2132221 | 1.4.2_12 | Dmitriy Samersoff | P2 | Resolved | Fixed | b01 |
Description
Name: dd4877 Date: 08/27/2004
###@###.### 2004-08-27
The following bug:
4979680 2/2 objects being kept alive in perm gen and old gen
was split into two phases. The first phase restored the Merlin (1.4)
behavior and I was supposed to file a bug for the second phase. I believe
I forgot to file the phase 2 bug so I'm doing so now.
Here is an e-mail that I sent on this issue on 2004.01.28:
Greetings,
I've added Jon since he filed the original bug and I've added Coleen
since she loves SystemDictionary issues
Here are my first pass mullings on this bug...
1) placeholders for primitive arrays are added in
SystemDictionary::resolve_array_class_or_null() via a
placeholders()->find_and_add() call. There are two other
calls to find_and_add(), but those are place holders for
regular classes and not array classes.
2) placeholders are removed by placeholders()->find_and_remove()
in the case of errors or placeholders()->remove_entry() for
non-error cases. The three find_and_remove() calls are in
cases of errors with regular classes and not array classes.
The one remove_entry() call is made from SystemDictionary::
update_dictionary() when it is going to replace the placeholder
with a real class entry. update_dictionary() is only called
for real classes and not array classes
3) from my observations in points 1 & 2 above, it certainly looks
like those placeholders for primitive arrays are not deleted
by either code path in class PlaceholderTable.
4) I found that the placeholders are properly GC'ed which isn't a
surprise since we would have some serious stability issues with
GCAlot during heavy class loading:
SystemDictionary::always_strong_oops_do()
always_strong_classes_do()
placeholders_do()
placeholders()->oops_do()
5) Dictionary::do_unloading() loops through the dictionary and removes
entries if the entry's loader is dead. It seems like we need similar
functionality for the placeholder table.
Dictionary::do_unloading() has the following comment:
// The placeholder array has been handled in always_strong_oops_do.
Before primitive arrays were added to the placeholder array, I
think the comment was correct. Now, always_strong_oops_do() only
handles oop relocation and not "unloading".
SystemDictionary::do_unloading() calls Dictionary::do_unloading()
and it seems like SystemDictionary::do_unloading() is the right
place to remove any stale placeholder entries.
I'm thinking that we need to add PlaceholderTable()::do_unloading()
that sort of mirrors what Dictionary::do_unloading() (no event
posting though). This new "unloading" routine should be called from
SystemDictionary::do_unloading()
So am I on the right track here?
Dan
======================================================================
###@###.### 10/13/04 04:14 GMT
###@###.### 2004-08-27
The following bug:
4979680 2/2 objects being kept alive in perm gen and old gen
was split into two phases. The first phase restored the Merlin (1.4)
behavior and I was supposed to file a bug for the second phase. I believe
I forgot to file the phase 2 bug so I'm doing so now.
Here is an e-mail that I sent on this issue on 2004.01.28:
Greetings,
I've added Jon since he filed the original bug and I've added Coleen
since she loves SystemDictionary issues
Here are my first pass mullings on this bug...
1) placeholders for primitive arrays are added in
SystemDictionary::resolve_array_class_or_null() via a
placeholders()->find_and_add() call. There are two other
calls to find_and_add(), but those are place holders for
regular classes and not array classes.
2) placeholders are removed by placeholders()->find_and_remove()
in the case of errors or placeholders()->remove_entry() for
non-error cases. The three find_and_remove() calls are in
cases of errors with regular classes and not array classes.
The one remove_entry() call is made from SystemDictionary::
update_dictionary() when it is going to replace the placeholder
with a real class entry. update_dictionary() is only called
for real classes and not array classes
3) from my observations in points 1 & 2 above, it certainly looks
like those placeholders for primitive arrays are not deleted
by either code path in class PlaceholderTable.
4) I found that the placeholders are properly GC'ed which isn't a
surprise since we would have some serious stability issues with
GCAlot during heavy class loading:
SystemDictionary::always_strong_oops_do()
always_strong_classes_do()
placeholders_do()
placeholders()->oops_do()
5) Dictionary::do_unloading() loops through the dictionary and removes
entries if the entry's loader is dead. It seems like we need similar
functionality for the placeholder table.
Dictionary::do_unloading() has the following comment:
// The placeholder array has been handled in always_strong_oops_do.
Before primitive arrays were added to the placeholder array, I
think the comment was correct. Now, always_strong_oops_do() only
handles oop relocation and not "unloading".
SystemDictionary::do_unloading() calls Dictionary::do_unloading()
and it seems like SystemDictionary::do_unloading() is the right
place to remove any stale placeholder entries.
I'm thinking that we need to add PlaceholderTable()::do_unloading()
that sort of mirrors what Dictionary::do_unloading() (no event
posting though). This new "unloading" routine should be called from
SystemDictionary::do_unloading()
So am I on the right track here?
Dan
======================================================================
###@###.### 10/13/04 04:14 GMT
Attachments
Issue Links
- backported by
-
JDK-2132221 objects being kept alive in perm gen and old gen when debugger attached
- Resolved
-
JDK-2132717 objects being kept alive in perm gen and old gen when debugger attached
- Resolved
- relates to
-
JDK-4450091 GetClassLoaderClasses does not return primitive arrays
- Closed
-
JDK-6325682 VM lockup with -XX:+UseConcMarkSweepGC while loading classes with custom classloader
- Closed
-
JDK-5103671 Different behaviors with -Xdebug between 1.3.1 and tiger-b64
- Closed