FTR, selectAlternative intrinsic is there from the very beginning.
Recent changes improved how intrinsics are represented on LF level +
added a bunch of new intrinsics.
Best regards,
Vladimir Ivanov
On 9/1/14, 2:49 PM, Paul Sandoz wrote:
On Sep 1, 2014, at 12:29 PM, Vladimir Ivanov
wrote:
On Sep 1, 2014, at 12:29 PM, Vladimir Ivanov
wrote:
> Thanks, Paul.
>
> There's no need to add @ForceInline on selectAlternative.
> It is used only during LF interpretation. There's an intrinsic for GWT
> combinator, which encodes it as a branch (see
> InvokerBytecodeGenerator.emitSelectAlte
4, 1:48 PM, Paul Sandoz wrote:
On Aug 29, 2014, at 7:20 PM, Vladimir Ivanov
wrote:
http://cr.openjdk.java.net/~vlivanov/8056926/webrev.00/
https://bugs.openjdk.java.net/browse/JDK-8056926
Cache GuardWithTest per erased to basic types signature.
GWT shape is made friendly to sharing:
*
On Aug 29, 2014, at 7:20 PM, Vladimir Ivanov
wrote:
> http://cr.openjdk.java.net/~vlivanov/8056926/webrev.00/
> https://bugs.openjdk.java.net/browse/JDK-8056926
>
> Cache GuardWithTest per erased to basic types signature.
>
> GWT shape is made friendly to sharing:
> *
http://cr.openjdk.java.net/~vlivanov/8056926/webrev.00/
https://bugs.openjdk.java.net/browse/JDK-8056926
Cache GuardWithTest per erased to basic types signature.
GWT shape is made friendly to sharing:
* GWT MH is implemented as BMH which stores 3 method handles
* LF loads them from the
Changeset: b3d741bcbbe5
Author:jrose
Date: 2011-05-24 22:11 -0700
URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/b3d741bcbbe5
meth: update spec; factor out deprecated methods; fix guardWithTest
! meth-argcount-6983728.patch
+ meth-deprecate.patch
! meth-review-7032323.patch
This is an automatic response. I am on vacation from 12/20 through 12/26, and
not generally reading or responding to emai during that period. For urgent
matters please contact my manager David Cox or Jon Masamitsu.
___
mlvm-dev mailing list
mlvm-dev@ope
John, there are two different bugs:
One throws a NPE when calling a guardWithTest, the other can't get the
exactInvoker when
calling invokeWithArguments() and is only reproductible with mlvm
workspace code.
Basically, lookup.findVirtual(MethodHandle.class, "invoke", methodType
This is an automatic response. I am on vacation from 12/20 through 12/26, and
not generally reading or responding to emai during that period. For urgent
matters please contact my manager David Cox or Jon Masamitsu.
___
mlvm-dev mailing list
mlvm-dev@ope
On Dec 20, 2010, at 2:58 AM, Christian Thalinger wrote:
> I can reproduce it on x86 and SPARC with -Xint. I'm not sure yet what causes
> this but can this be an API problem?
Could be a problem with a generic invoker, I suppose. Generic invocation is
relatively new code.
Remi, what's the type
On Dec 14, 2010, at 8:12 PM, Rémi Forax wrote:
> On 12/14/2010 06:10 PM, Christian Thalinger wrote:
>> On Dec 14, 2010, at 6:02 PM, Rémi Forax wrote:
>>> With the jdk7b121, sometimes when I call a MH created with guardWith, it
>>> get a NPE because the target is NULL :(
>>>
>>> groovy examples/mix
On 12/14/2010 06:10 PM, Christian Thalinger wrote:
> On Dec 14, 2010, at 6:02 PM, Rémi Forax wrote:
>> With the jdk7b121, sometimes when I call a MH created with guardWith, it
>> get a NPE because the target is NULL :(
>>
>> groovy examples/mixin.groovy
>>
>> java.lang.NullPointerException
>>
On Dec 14, 2010, at 6:02 PM, Rémi Forax wrote:
> With the jdk7b121, sometimes when I call a MH created with guardWith, it
> get a NPE because the target is NULL :(
>
> groovy examples/mixin.groovy
>
> java.lang.NullPointerException
> at
> sun.dyn.MethodHandleImpl$GuardWithTest.invoke_L1(Met
With the jdk7b121, sometimes when I call a MH created with guardWith, it
get a NPE because the target is NULL :(
groovy examples/mixin.groovy
java.lang.NullPointerException
at
sun.dyn.MethodHandleImpl$GuardWithTest.invoke_L1(MethodHandleImpl.java:963)
at java.dyn.MethodHandle.invokeVa
Changeset: 1d04dc517fb8
Author:jrose
Date: 2009-05-27 12:59 -0700
URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/1d04dc517fb8
meth: guardWithTest typing bug
! indy.patch
___
mlvm-dev mailing list
[email protected]
http
Changeset: d6e69f64cd3e
Author:jrose
Date: 2009-05-27 13:00 -0700
URL: http://hg.openjdk.java.net/mlvm/mlvm/rev/d6e69f64cd3e
meth: guardWithTest typing bug
! netbeans/meth/test/jdk/java/dyn/MethodHandlesTest.java
___
mlvm-dev mailing
Thanks, Remi; will do. -- John
On May 27, 2009, at 9:12 AM, Rémi Forax wrote:
>
> last line should be :
>
> return convertArguments(token, gguard, type, gtype, null);
>
___
mlvm-dev mailing list
[email protected]
http://mail.openjdk.java.net/m
Rémi Forax wrote:
> I think, I've found the bug, in MethodHandleImpl.makeGuardWithTest
...
> last line should be :
>
> return convertArguments(token, gguard, type, gtype, null);
Yeah, fits with what I eventually had to do to make it work. I'll
proceed with doing convertArguments myself for now.
1:in `__file__'
>
> I'm investigating, but wanted to toss it out there in case someone sees
> something obvious (or runs into the same thing).
Ok, I think I've gotten it to work by doing this:
MethodHandles.convertArguments(guardWithTest, site.type())
But I expected guard
) {
MethodType gtype = type.generic();
if (type == gtype)
return new GuardWithTest(test, target, fallback);
MethodHandle gtest = convertArguments(token, test,
gtype.changeReturnType(boolean.class), test.type(), null);
Ok, John got fixes in to get gWT working last night, so I gave my code
another try:
http://gist.github.com/118504
But I'm getting this, so I'm not wiring something correctly:
CallSite.java:166:in `checkTarget': java.dyn.WrongMethodTypeException:
Bound[invoke_L5(java.lang.Object,java.lang.Objec
Changeset: a48f8a111bbb
Author:jrose
Date: 2009-05-27 00:35 -0700
URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/a48f8a111bbb
meth: add more guardWithTest cases
! indy.patch
___
mlvm-dev mailing list
[email protected]
http
Changeset: 7eeba04e72fe
Author:jrose
Date: 2009-05-26 18:09 -0700
URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/7eeba04e72fe
indy: progress on guardWithTest, spread, collect; run with java -ea
! indy.patch
___
mlvm-dev mailing list
Nice blog entry, Fredrik. Neal Gafter was also asking me at Lang.NET
for a slow path like the one you suggest.
If the user has a specific signature in mind, guardWithTest is
interchangeable with a hand-written JMH containing the if/then/else
logic. But the general API needs to be
Also, IIRC (and I might be wrong about that, memory is sometimes
failing...), guardWithTest was introduced when there was no
JavaMethodHandle; John pretty much specified few general-purpose
method handle types creatable by static factory methods in the
MethodHandles utility class, and that
Arthur Peters skrev:
> 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
>
Arthur Peters wrote:
> 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
&
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 b
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
>>
On May 21, 2009, at 8:25 PM, Charles Oliver Nutter wrote:
> Seems to be a failure in the spread, no?
Yes. There is a bug in spread combinators in the JVM assembly code,
so the Java code does not emit them currently.
And guardWithTest should be using a polymorphic combinator, not a
coll
On May 21, 2009, at 8:19 PM, Charles Oliver Nutter wrote:
> Ok, I was too intrigued by guardWithTest to not give it a try. Here's
> the revised InvokeDynamicSupport I came up with. It seems like things
> are wired correctly, but it results in a crash:
>
> http://gist.gith
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 cac
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
RubyObject,org.jruby.runtime.builtin.IRubyObject,java.lang.String,org.jruby.runtime.builtin.IRubyObject)boolean
from MethodHandles.java:859:in `spreadArguments'
from MethodHandleImpl.java:312:in `makeGuardWithTest'
from MethodHandles.java:1031:in `guardWi
Ok, I was too intrigued by guardWithTest to not give it a try. Here's
the revised InvokeDynamicSupport I came up with. It seems like things
are wired correctly, but it results in a crash:
http://gist.github.com/115901
It crashes with a message like:
# A fatal error has been detected b
35 matches
Mail list logo
