On Thu, May 31, 2012 at 3:10 PM, John Rose <john.r.rose at oracle.com> wrote:
> On May 30, 2012, at 7:55 PM, Krystal Mok wrote:
>> Yes, it's doable. I'll just take the same approach for
> clazz1.isAssignableFrom(clazz2).
>>> It's trickier, since you can't just repurpose the C1 InstanceOf node. It
> looks like you'll have to refactor machine-dependent code to cut in the new
> logic.
>> Yes, I have noticed that already. It's not the same as the
Class.isInstance(). The (quick-n-dirty) plan was to fold the case where
both clazz1 and clazz2 are constants, and emit a leaf runtime call for
non-constant cases. Since Class.isAssignableFrom() only throws NPE if any
of clazz1 or clazz2 is null, it should be okay to make a leaf call after
null-checking them.
The complete solution, as you suggested, would have to involve changes to
platform-dependent code.
> For a comparison, see inline_native_subtype_check in C2, versus the
> "_isInstance" cases of inline_native_Class_query. The intrinsic for
> Class.isAssignableFrom is surprisingly more complex and specialized than
> the intrinsic for Class.isInstance.
>> (For C2-ish reasons, the intrinsic logic in library_call.cpp is
> machine-independent, so it's easier to do than in C1.)
>> I did notice this from the start, too. It's so tempting to add finer-grain
IR to C1 so that it can do more optimizations; but that feels against the
theme of C1.
> Unless you find a simple way to manage the C1 changes, you might want to
> stick with isInstance only, this time around.
>> Yes, I agree. I wouldn't mind making a more complete solution for C1 Class
intrinsics in future changes.
> In any case, we'll try what you have done already; I am confident it will
> do good things for our dynamic language codes.
>> Thanks, really looking forward to the numbers :-)
Thanks,
Kris
> Thanks,
> — John
>-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20120531/6fee6e85/attachment-0001.html