Request for review (URGENT!!) 7033141: assert(has_cp_cache(i)) failed: oob
Karen Kinnear
karen.kinnear at oracle.com
Fri May 20 09:13:54 PDT 2011
Looks good to me also. Good catch earlier Tom.
thanks,
Karen
On May 20, 2011, at 11:08 AM, Tom Rodriguez wrote:
> Looks good.
>
> tom
>
> On May 19, 2011, at 3:01 PM, Coleen Phillimore wrote:
>
>>
>> Yes, these should be reversed. You are right and it makes a
>> difference on x86. Fixed and retested:
>>
>> open webrev at http://cr.openjdk.java.net/~coleenp/7033141_3/
>> bug link at http://bugs.sun.com/view_bug.do?bug_id=7033141_3
>>
>> I also fixed the null assert strings and comments that Dan and
>> Karen pointed out.
>>
>> Thank you!
>> Coleen
>>
>> On 5/19/2011 1:15 PM, Tom Rodriguez wrote:
>>> Shouldn't the reversed version of the code swap the get_native/
>>> get_Java calls?
>>>
>>> 144 // Rewrite a classfile-order CP index into a native-order CPC
>>> index.
>>> 145 void Rewriter::rewrite_member_reference(address bcp, int
>>> offset, bool reverse) {
>>> 146 address p = bcp + offset;
>>> 147 if (!reverse) {
>>> 148 int cp_index = Bytes::get_Java_u2(p);
>>> 149 int cache_index = cp_entry_to_cp_cache(cp_index);
>>> 150 Bytes::put_native_u2(p, cache_index);
>>> 151 } else {
>>> 152 int cache_index = Bytes::get_Java_u2(p);
>>> 153 int pool_index = cp_cache_entry_pool_index(cache_index);
>>> 154 Bytes::put_native_u2(p, pool_index);
>>> 155 }
>>> 156 }
>>>
>>>
>>> tom
>>>
>>> On May 18, 2011, at 1: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