Request for review (URGENT!!) 7033141: assert(has_cp_cache(i)) failed: oob

Coleen Phillimore coleen.phillimore at oracle.com
Wed May 18 13:14:49 PDT 2011


The last code change I sent out was not complete, and would not work if 
there was an exception in the relocator.  The code was structured as:

    if klass->is_rewritten() flag {
        verify - exit if exception
        rewrite bytecodes to point to (to be created) cpCache rather 
than constant pool
        create constant pool cache  - (added restore_bytecodes and) exit 
if exception
        run relocator for jsr/ret    - exit if exception
        link method entry points  - exit if exception
        set rewritten flag
   }

Any exceptions will cause the whole block to be retried if the exception 
is handled and class loading is attempted again for this class.  This 
latest code effectively changes this ordering to:

    if klass->is_rewritten() flag {
      verify - exit if exception
      rewrite bytecodes to point to cpCache rather than constant pool 
entries
       create constant pool  {
           if exception restore bytecodes to point to constant pool
           exit }
       set rewritten flag
   }
   run relocator for jsr/ret - exit if exception
   link method entry points - exit if exception

If there's an exception in relocator and linking method stages, these 
two actions are restartable if the VM handles the exception and has to 
retry loading that class.   The actions under the rewritten flag are not 
restartable.

This is tested with invokedynamic tests, RedefineClasses tests and class 
data sharing.  There was special testing to throw OOM at each part and 
testing to rerun the relocator.

This didn't make the deadline, but please review (again) for the next 
stage of the jdk7 release.

open webrev at http://cr.openjdk.java.net/~coleenp/7033141_2/
bug link at http://bugs.sun.com/view_bug.do?bug_id=7033141_2

Thanks,
Coleen


On 5/17/2011 4:44 PM, Coleen Phillimore wrote:
> Summary: Unrewrite bytecodes for OOM error allocating the constant 
> pool cache.
>
> open webrev at http://cr.openjdk.java.net/~coleenp/7033141/
> bug link at http://bugs.sun.com/view_bug.do?bug_id=7033141
>
> This bug fix also moves linking methods outside of the rewriting code 
> so that when the code cache is full, the vm can attempt to link the 
> methods again.   (also fixes bug 6947901)
>
> Tested with oom errors inserted for random cpCache allocation and also 
> tested with invokedynamic test.
>
> This is somewhat urgent.  If acceptable, I would like to put it back 
> today for code freeze (if not, it'll wait).
>
> Thanks,
> Coleen



More information about the hotspot-runtime-dev mailing list