We forgot to remove the Ricochet Frame code from the sA:
http://cr.openjdk.java.net/~twisti/7023639/
-- Chris
On Jul 19, 2012, at 11:28 AM, Christian Thalinger wrote:
> JDK testing found a small bug:
>
> diff --git a/src/share/vm/oops/cpCacheOop.cpp
> b/src/share/vm/oops/cpCacheOop.cpp
> --- a/src/share/vm/oops/cpCacheOop.cpp
> +++ b/src/share/vm/oops/cpCacheOop.cpp
> @@ -486,7 +486,8 @@
> // virtual and final so _f2 contains method ptr instead of vtable index
> if (f2_as_vfinal_method() == old_method) {
> // match old_method so need an update
> - set_f2_as_vfinal_method(new_method);
> + // NOTE: can't use set_f2_as_vfinal_method as it asserts on different
> values
> + _f2 = (intptr_t)new_method;
> if (RC_TRACE_IN_RANGE(0x00100000, 0x00400000)) {
> if (!(*trace_name_printed)) {
> // RC_TRACE_MESG macro has an embedded ResourceMark
>
> I will integrate this one.
>
> -- Chris
>
> On Jul 18, 2012, at 7:10 PM, John Rose wrote:
>
>> On Jul 17, 2012, at 4:04 PM, Christian Thalinger wrote:
>>
>>>>
>>>> I see in several files next code pattern. Should we call
>>>> throw_IncompatibleClassChangeError() as we do in other places?:
>>>>
>>>> + if (!EnableInvokeDynamic) {
>>>> + // rewriter does not generate this bytecode
>>>> + __ should_not_reach_here();
>>>> + return;
>>>> + }
>>>
>>> Hmm. This really should not happen and EnableInvokeDynamic is on by
>>> default anyway. I doubt someone turns it off.
>>
>> It's now a diagnostic switch. It can be used to verify that an app. is not
>> using 292, which is occasionally helpful.
>>
>>>> constantPoolOop.cpp:
>>>> Why not use guarantee() for bad operants?
>>>
>>> Not sure. John?
>>
>> The code in that file uses assert; I think I'm following the existing
>> practice there. The CP code operates after initial verification passes, so
>> assert is suitable, I think.
>>
>>>> Why you need separate scopes in resolve_bootstrap_specifier_at_impl()?
>>>
>>> To keep oops from being visible. Might result in bad crashes.
>>
>> Yes. An alternative is to have the x_oop variables visible at top level,
>> but to put in DEBUG_ONLY(x_oop = NULL). Having the temporary scoped seems
>> cleaner to me, but maybe my sense of style is off here.
>>
>>>
>>> I will refresh the review patch in mlvm. Thank you!
>>
>> Yes, thanks!
>>
>> — John
>> _______________________________________________
>> mlvm-dev mailing list
>> mlvm-dev@openjdk.java.net
>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev@openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
_______________________________________________
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
