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