United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-6502317 Deoptimization code of Java 1.5.x looks leaking memory.
JDK-6502317 : Deoptimization code of Java 1.5.x looks leaking memory.

Details
Type:
Bug
Submit Date:
2006-12-08
Status:
Resolved
Updated Date:
2011-02-16
Project Name:
JDK
Resolved Date:
2007-03-17
Component:
hotspot
OS:
linux_redhat_4.0,linux_redhat_3.0,solaris_10
Sub-Component:
compiler
CPU:
x86,sparc
Priority:
P1
Resolution:
Fixed
Affected Versions:
solaris_10,5.0u8,5.0u11
Fixed Versions:
5.0u12 (b02)

Related Reports
Backport:
Backport:
Backport:
Duplicate:

Sub Tasks

Description
Deoptimization code of JIT compiler in JVM 1.5 seems to be leaking memory under some situation.

                                    

Comments
WORK AROUND

Use -client optoin.
                                     
2006-12-08
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.
                                     
2007-01-10



Hardware and Software, Engineered to Work Together