Request for review (M): 7171890: C1: add Class.isInstance intrinsic
rednaxelafx at gmail.com
Thu May 31 06:26:25 PDT 2012
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
> 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
> 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
The complete solution, as you suggested, would have to involve changes to
> 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 :-)
> — John
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the hotspot-compiler-dev