United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-6911204 generated adapters with large signatures can fill up the code cache
JDK-6911204 : generated adapters with large signatures can fill up the code cache

Details
Type:
Bug
Submit Date:
2009-12-16
Status:
Closed
Updated Date:
2011-03-08
Project Name:
JDK
Resolved Date:
2011-03-08
Component:
hotspot
OS:
solaris_9
Sub-Component:
compiler
CPU:
sparc
Priority:
P3
Resolution:
Fixed
Affected Versions:
hs17
Fixed Versions:
hs17 (b09)

Related Reports
Backport:
Backport:
Relates:
Relates:
Relates:

Sub Tasks

Description
A customer reports that repeatedly loading and unloading their test class ultimately result in a OutOfMemory error.  I attached the test case which shows the problem as unload.java.

                                    

Comments
EVALUATION

We should accurately track the signatures for all the adapters instead of only tracking ones with small signatures.  We might also consider unloading unused signatures by computing reference counts on the AdapterHandlerEntrys during GC.
                                     
2009-12-16
EVALUATION

At a minimum we also want to add a detail message in methodOopDesc when this occurs explaining what went wrong.  I think we might want to change this to some other kind of exception since it's not a Java heap issue at all.  Maybe a LinkageError?
                                     
2009-12-16
EVALUATION

http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/cf0685d550f1
                                     
2010-01-21
EVALUATION

6911204: generated adapters with large signatures can fill up the code cache
Reviewed-by: kvn, jrose

The adapter generation logic relies on the uint64_t fingerprint in the
methodOop to keep track of adapters and to reuse them for multiple
methods.  Since the uint64_t can only hold a limited number of
arguments methods that don't fit aren't tracked.  This means that
loading classes with lots of methods which aren't tracked can
eventually fill up the code cache.  The fix is to acurately track all
signatures.  I chose to use the representation of the calling
convention as the tracked information, since this will allow sharing
of adapters that are treated the same even though their signature in
basic types if diferent.  For example, bytes, chars and shorts are all
passed as int so their calling convention is the same.  This results
in fewer adapters being generated.  Bootstrapping the JVM after this
changes takes about 1/4 as many adapters.  The signatures are based on
VMRegPairs which are somewhat large so I went to a little extra
trouble to compact them.
                                     
2010-01-21



Hardware and Software, Engineered to Work Together