Request for review (URGENT!!) 7033141: assert(has_cp_cache(i)) failed: oob
Daniel D. Daugherty
daniel.daugherty at oracle.com
Thu May 19 08:00:36 PDT 2011
Thumbs up! My comments are all editorial so feel free to accept
them or ignore them. Your call.
Dan
src/share/vm/interpreter/rewriter.cpp
line 70: spacing: 'len-1' -> 'len - 1'
And thanks for switching to the more traditional count-down style.
line 219, 223 - no text in the assert. Yes, I see that line 202 and
line 206 do that also, but I think "sanity check" would be better
than nothing.
line 403: spacing: 'len-1' -> 'len - 1'
line 419: "leaving the state bytecodes"
State bytecodes? As opposed to Federal bytecodes? :-)
Maybe drop "state".
line 432: spacing: 'len-1' -> 'len - 1'
src/share/vm/interpreter/rewriter.hpp
No comments.
src/share/vm/oops/instanceKlass.cpp
No comments.
src/share/vm/oops/instanceKlass.hpp
No comments.
src/share/vm/oops/methodOop.cpp
No comments.
src/share/vm/prims/jvmtiRedefineClasses.cpp
No comments.
src/share/vm/prims/methodHandleWalk.cpp
No comments.
On 5/18/2011 2:14 PM, Coleen Phillimore wrote:
>
> 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