guardWithTest

[Arthur Peters]

I'm a lurker, but I have a question.

What makes guardWithTest better or faster than simply using a method handle
of a method with an if statement in it?

Like:
Object meth(...args...)  {
  if(pred)
    guard;
  else
    callTargetMethod;
}

Can the JVM optimize the guardWithTest version better? Does it handle
primitive types better?

-Arthur


On Sun, May 24, 2009 at 8:52 AM, Attila Szegedi <szegedia at gmail.com> wrote:

> On 2009.05.22., at 6:59, Charles Oliver Nutter wrote:
>
> > Hello Fabio!
> >
> > Fabio Kung wrote:
> >> I don't know if this is how guardWithTest is intended to be used,
> >> but I
> >> found your code very clever. Making dynamic calls fall to the
> >> fallback
> >> implementation in the first time and after that, always going to the
> >> target method until cache is invalidated. I'm impressed! (and just
> >> trying to understand all these mlvm new things better).
> >
> > I think this is the right way to use guardWithTest, or at least it
> > feels
> > right to me :)
>
> Definitely right - I've proposed this back in my JVM lang summit
> presentation, see <http://wiki.jvmlangsummit.com/pdf/
> 25_Szegedi_mop.pdf> and search for "guardWithTest". I remember running
> out of time then and not being able to present the ideas at the end of
> the presentation correctly though... It's good to see it's catching on.
>
> It's great to see all this progress folks. I have a half-completed
> framework for interop between method handle resolvers for multiple
> languages; I see I'll need to press on as both JRuby and Jython seem
> to be advancing in invokedynamic in strides (it's just that, as usual,
> I'm "losing" most of my time to my day job, but as I said, this
> progress is really inspiring...)
>
> Attila.
>
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20090524/19b62fca/attachment.html