|
Quick Lists
|
|
Bug ID:
|
6502317
|
|
Votes
|
0
|
|
Synopsis
|
Deoptimization code of Java 1.5.x looks leaking memory.
|
|
Category
|
hotspot:compiler2
|
|
Reported Against
|
b03
, b10
, s10
|
|
Release Fixed
|
5.0u12(b02),
hs10(b07) (Bug ID:2145723)
, 6u2(b01) (Bug ID:2147601)
, 7(b07) (Bug ID:2176835)
|
|
State
|
10-Fix Delivered,
bug
|
|
Priority:
|
1-Very High
|
|
Related Bugs
|
6522848
,
6718313
|
|
Submit Date
|
08-DEC-2006
|
|
Description
|
Deoptimization code of JIT compiler in JVM 1.5 seems to be leaking memory under some situation.
Posted Date : 2006-12-08 08:05:36.0
|
|
Work Around
|
Use -client optoin.
|
|
Evaluation
|
When lazy deopt was added and the vframeArray code was rewritten this leak was introduced.
After going through the C2 code, found that these get deallocated in unpack_on_stack() which calls deallocate_monitor_chunks().
void vframeArray::deallocate_monitor_chunks() {
JavaThread* jt = JavaThread::current();
for (int index = 0; index < frames(); index++ ) {
MonitorChunk* chunk = element(index)->monitors();
if (chunk != NULL) {
jt->remove_monitor_chunk(chunk);
}
}
}
void JavaThread::remove_monitor_chunk(MonitorChunk* chunk) {
guarantee(monitor_chunks() != NULL, "must be non empty");
if (monitor_chunks() == chunk) {
set_monitor_chunks(chunk->next());
} else {
MonitorChunk* prev = monitor_chunks();
while (prev->next() != chunk) prev = prev->next();
prev->set_next(chunk->next());
}
}
In remove_monitor_chunk, we just set the pointer of the list to next chunk and don't actually delete the passed chunk.
Thanks to Poonam for finding this.
Posted Date : 2007-01-10 14:58:59.0
|
|
Comments
|
PLEASE NOTE: JDK6 is formerly known as Project Mustang
|
|
|
 |