RFR(S) : 8029381 : assert(is_method_type()) failed: bad cast

Christian Thalinger christian.thalinger at oracle.com
Fri May 30 23:07:01 UTC 2014

On May 30, 2014, at 3:14 PM, David Chase <david.r.chase at oracle.com> wrote:

> On 2014-05-30, at 5:50 PM, John Rose <john.r.rose at oracle.com> wrote:
>> Wow, that hurts.  Thanks for tracking and fixing that bug, which I think was mine.
>> Safe publication is hard enough through a single pointer; it's nearly impossible when two or more words of racy state are involved.
>> Did you consider guarding more (or all) uses of _flags?  That would be a more disruptive change, of course.
>> I mean something like (but more complex than):
>> intx flags()                     { return is_f1_null() ? 0 : _flags; }
> Christian and Coleen seemed to think that this race was peculiar to invokedynamic and those two bits.
> Perhaps they will have something to say.

These are the flags we set in ConstantPoolCacheEntry::set_method_handle_common:

  // Write the flags.
                   ((has_appendix    ? 1 : 0) << has_appendix_shift   ) |
                   ((has_method_type ? 1 : 0) << has_method_type_shift) |
                   (                   1      << is_final_shift       ),

Only appendix and method_type have additional data stored somewhere else (the resolved references array) on which we have to wait to settle before we can read them.  With:


we make sure that’s the case.

I don’t think we can adopt a similar contract for other flags as well.  For example is_final is used for multiple different kinds of entries where either f1 or f2 are set (e.g. invokevirtual vs. invokestatic).  So it would be hard to formulate appropriate guards.

> David

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140530/b60d21d1/attachment.html>

More information about the hotspot-compiler-dev mailing list