Re: Smalltalk and tiered compile data
Hi Rémi Just a clarification on the switchpoint usage to invalidate sites. The switch path would still do a setTarget correct? So I am still sending lots of setTargets just based on switch point state? It also seems that if the switch point is in series with the target that the callsite will not invalidate until its next use. Seems like this could spread the invalidations out over time giving hotspot even more to do. Or am I not clear on how to do this? thanks mark___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: Smalltalk and tiered compile data
>From Rémi Mark, you should use a SwitchPoint I was thinking of that. I'll move it up on the list of things to try. My current approach gives me the option to filter the callsites and only invalidate the ones for a given signature. This would only matter if I have issues with hotspot as I would prefer to invalidate them all. This keeps the GWT depth under control. by sweeping them all out every so often. thanks mark ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: Fast long overflow detection?
On 02/07/2012 03:04 PM, Vitaly Davidovich wrote: > Can't the overflow test be (value ^ result) & (otherValue ^ result) < 0? > I think that's what hacker's delight suggests and you don't need the > negation and the sign bit mask in that case. In gnu.math the "fixnums" are int, so I do long addition like this: long r = (long) value + (long) otherValue; int ri = (int) r; if ((int) ri == r) return makeFix(ri); else return makeBig(r); This is probably slower on older 32-bit CPUs. But with modern CPUs I doubt it matters what computation you do: what really matters are cache misses. -- --Per Bothner p...@bothner.com http://per.bothner.com/ ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: Fast long overflow detection?
Can't the overflow test be (value ^ result) & (otherValue ^ result) < 0? I
think that's what hacker's delight suggests and you don't need the negation
and the sign bit mask in that case.
Sent from my phone
On Feb 7, 2012 3:31 PM, "Charles Oliver Nutter" wrote:
> The JRuby logic mimics what I think others are doing:
>
>private IRubyObject addFixnum(ThreadContext context, RubyFixnum other) {
>long otherValue = other.value;
>long result = value + otherValue;
>if (additionOverflowed(value, otherValue, result)) {
>return addAsBignum(context, other);
>}
>return newFixnum(context.getRuntime(), result);
>}
>
>private static boolean additionOverflowed(long original, long
> other, long result) {
>return (~(original ^ other) & (original ^ result) & SIGN_BIT) != 0;
>}
>
> JRuby's invokedynamic paths have special casing for a few small fixnum
> operations by comparing with Long.MAX_VALUE and MIN_VALUE (e.g. a + 1
> overflowed if it's now == Long.MIN_VALUE).
>
> - Charlie
>
> On Tue, Feb 7, 2012 at 7:28 PM, Mark Roos wrote:
> > So I thought I could get away with 64bit ints and not implement the
> > Smalltalk automatic conversion
> > to BigIntegers. Bad plan.
> >
> > So I went ahead and did it while I waited for the super bowl to start.
> Not
> > too difficult. Just wrappered
> > java BigInteger and added some simple overflow detection.
> >
> > But I am concerned about the impact on integer ops by adding a pretty
> > complex precalc overflow detection.
> > To help I decided to limit small ints to 62 bits and defer some checking
> > until after the op and cache lookup.
> >
> > Any suggestions on approaches that offer superior techniques?
> >
> > Seems like a methodHandle of guardOverflow would be handy someday.
> >
> > regards
> > mark
> > ___
> > mlvm-dev mailing list
> > mlvm-dev@openjdk.java.net
> > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
> >
> ___
> mlvm-dev mailing list
> mlvm-dev@openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>
___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: Fast long overflow detection?
The JRuby logic mimics what I think others are doing:
private IRubyObject addFixnum(ThreadContext context, RubyFixnum other) {
long otherValue = other.value;
long result = value + otherValue;
if (additionOverflowed(value, otherValue, result)) {
return addAsBignum(context, other);
}
return newFixnum(context.getRuntime(), result);
}
private static boolean additionOverflowed(long original, long
other, long result) {
return (~(original ^ other) & (original ^ result) & SIGN_BIT) != 0;
}
JRuby's invokedynamic paths have special casing for a few small fixnum
operations by comparing with Long.MAX_VALUE and MIN_VALUE (e.g. a + 1
overflowed if it's now == Long.MIN_VALUE).
- Charlie
On Tue, Feb 7, 2012 at 7:28 PM, Mark Roos wrote:
> So I thought I could get away with 64bit ints and not implement the
> Smalltalk automatic conversion
> to BigIntegers. Bad plan.
>
> So I went ahead and did it while I waited for the super bowl to start. Not
> too difficult. Just wrappered
> java BigInteger and added some simple overflow detection.
>
> But I am concerned about the impact on integer ops by adding a pretty
> complex precalc overflow detection.
> To help I decided to limit small ints to 62 bits and defer some checking
> until after the op and cache lookup.
>
> Any suggestions on approaches that offer superior techniques?
>
> Seems like a methodHandle of guardOverflow would be handy someday.
>
> regards
> mark
> ___
> mlvm-dev mailing list
> mlvm-dev@openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>
___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: problem with vargs method
As soon as you mh = mh.asType(target); it is no longer vararg, so it is treating new Class[0] as the second argument cast to Object. If you are trying to type as (Object , Object[]). I think you are going to run into difficulties validating (Class[]) Object[]. You may have to add a wrapper to get what you want, but you could also try using asCollector. Cheers, -- Jim On 2012-02-07, at 12:14 PM, Jochen Theodorou wrote: > The problem can be easily reproduced using this: >>MethodType type = MethodType.methodType(Constructor.class, >> Class[].class); >>MethodHandle mh = MethodHandles.lookup().findVirtual(Class.class, >> "getDeclaredConstructor", type); >>MethodType target = MethodType.methodType(Object.class, Object.class, >> Object.class); >>mh = mh.asType(target); >>mh.invokeWithArguments(Class.class,new Class[0]); > > can someone tell me the mistake? > > bye Jochen > > Am 07.02.2012 17:04, schrieb Jochen Theodorou: >> Hi all, >> >> maybe someone can explain to me why method handles behave this way in my >> case. >> >> Bascially I have a handle for Class#getDeclaredConstructor(Class...) I >> created via unreflect. >> >> http://docs.oracle.com/javase/7/docs/api/java/lang/Class.html#getDeclaredConstructor%28java.lang.Class...%29 >> >> this handle is then created as a AdapterMethodHandle$AsVargsCollector. >> My targetType is Object(Object,Object) and the arguments to the call are >> the Class, and an empty Class[]. So the next steps are asType with the >> target type, adding a guard with catch, then my guards for the arguments >> and last I do an invokeWithArguments. >> >> What I get now is a ClassCastException with the message required class >> java.lang.Class but encountered class [Ljava.lang.Class; >> >> The guards are unrelated to the problem, since it happens without them >> as well. >> >> Now can anyone explain me why I get that exception? It doesn't really >> make sense to me atm. >> >> bye Jochen >> > > > -- > Jochen "blackdrag" Theodorou - Groovy Project Tech Lead > blog: http://blackdragsview.blogspot.com/ > german groovy discussion newsgroup: de.comp.lang.misc > For Groovy programming sources visit http://groovy-lang.org > > ___ > mlvm-dev mailing list > mlvm-dev@openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: Smalltalk and tiered compile data
On 02/07/2012 08:28 PM, Mark Roos wrote: > Christian asked: > > What exactly do you mean by "invalidate call sites before the > benchmark"? > Are you using MutableCallSites and call setTarget on them? > > Exactly. I am using setTarget to set each call site to its initial > fallback method. This should drop the > GWT lookup chain forcing each call site to rebuild the chain. The > method handles for the code still exist but > the GWTs that reference them are gone. This is my current way to > force the call sites to get new versions > of the method code. > > thanks Mark, you should use a SwitchPoint instead of calling a lot of setTarget() because each setTarget() may require all threads of the VM to go to a safepoint so you may create a 'safepoint storm' (as coined by Dan Heidinga). > > mark Rémi ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Fast long overflow detection?
So I thought I could get away with 64bit ints and not implement the Smalltalk automatic conversion to BigIntegers. Bad plan. So I went ahead and did it while I waited for the super bowl to start. Not too difficult. Just wrappered java BigInteger and added some simple overflow detection. But I am concerned about the impact on integer ops by adding a pretty complex precalc overflow detection. To help I decided to limit small ints to 62 bits and defer some checking until after the op and cache lookup. Any suggestions on approaches that offer superior techniques? Seems like a methodHandle of guardOverflow would be handy someday. regards mark___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: Smalltalk and tiered compile data
Christian asked: What exactly do you mean by "invalidate call sites before the benchmark"? Are you using MutableCallSites and call setTarget on them? Exactly. I am using setTarget to set each call site to its initial fallback method. This should drop the GWT lookup chain forcing each call site to rebuild the chain. The method handles for the code still exist but the GWTs that reference them are gone. This is my current way to force the call sites to get new versions of the method code. thanks mark ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: problem with vargs method
Am 07.02.2012 18:29, schrieb Jim Laskey: > Worked okay for me. So must be addressed in a later release. :-/ later than jdk7u2? oh boy. I would feel better if I could find a bug report that shows the problem and that is resolved. Then I would at least have something for the release notes. But I didn't find anything that looks fitting. The only one that seems to be slightly fitting was fixed a year ago and surely that fix is part of jdk7u2 already. You said for > MethodType type = MethodType.methodType(Constructor.class, Class[].class); > MethodHandle mh = MethodHandles.lookup().findVirtual(Class.class, > "getDeclaredConstructor", type); > MethodType target = MethodType.methodType(Object.class, Object.class, > Object.class); > mh = mh.asType(target); > mh.invokeWithArguments(Class.class,new Class[0]); I probably have to wrap something... can you explain what you mean? bye Jochen -- Jochen "blackdrag" Theodorou - Groovy Project Tech Lead blog: http://blackdragsview.blogspot.com/ german groovy discussion newsgroup: de.comp.lang.misc For Groovy programming sources visit http://groovy-lang.org ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: problem with vargs method
Worked okay for me. So must be addressed in a later release. :-/ On 2012-02-07, at 1:17 PM, Jochen Theodorou wrote: > > That will produce a > > java.lang.invoke.WrongMethodTypeException: > (Ljava/lang/Object;[Ljava/lang/Object;)V cannot be called without a receiver > argument as ([Ljava/lang/Object;)Ljava/lang/Object; > > imho casting to Object and Object[] in > > mh.invokeExact((Object)Class.class, (Object[])new Class[0]); > > is without effect, since invokeExact is a vargs method an everything will > just be put into an Object[] anyway. We had not a compiler change for this > kind of thing, had we? > > bye Jochen > > Am 07.02.2012 17:52, schrieb Jim Laskey: >> Try >> >>MethodType type = MethodType.methodType(Constructor.class, >> Class[].class); >>MethodHandle mh = MethodHandles.lookup().findVirtual(Class.class, >> "getDeclaredConstructor", type); >>MethodType target = MethodType.methodType(void.class, Object.class, >> Object[].class); >>mh = MethodHandles.explicitCastArguments(mh, target); >>mh.invokeExact((Object)Class.class, (Object[])new Class[0]); >> >> Cheers, >> >> -- Jim >> >> On 2012-02-07, at 12:37 PM, Jochen Theodorou wrote: >> >>> Am 07.02.2012 17:29, schrieb Jim Laskey: >>>MethodType type = MethodType.methodType(Constructor.class, >>> Class[].class); >>>MethodHandle mh = >>> MethodHandles.lookup().findVirtual(Class.class, >>> "getDeclaredConstructor", type); >>>MethodType target = MethodType.methodType(Object.class, >>> Object.class, Object.class); >>>mh = mh.asType(target); >>>mh.invokeWithArguments(Class.class,new Class[0]); As soon as you mh = mh.asType(target); it is no longer vararg, so it is treating new Class[0] as the second argument cast to Object. If you are trying to type as (Object , Object[]). I think you are going to run into difficulties validating (Class[]) Object[]. You may have to add a wrapper to get what you want, but you could also try using asCollector. >>> >>> or in other words: I should not use invokeWithArguments for this. >>> >>> If I wanted to use the same target type... since that is what my call site >>> gives me... and I wanted to use invokeExact instead, how would I have to >>> change the program? >>> >>> bye blackdrag >>> >>> -- >>> Jochen "blackdrag" Theodorou - Groovy Project Tech Lead >>> blog: http://blackdragsview.blogspot.com/ >>> german groovy discussion newsgroup: de.comp.lang.misc >>> For Groovy programming sources visit http://groovy-lang.org >>> >> > > > -- > Jochen "blackdrag" Theodorou - Groovy Project Tech Lead > blog: http://blackdragsview.blogspot.com/ > german groovy discussion newsgroup: de.comp.lang.misc > For Groovy programming sources visit http://groovy-lang.org > ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: problem with vargs method
That will produce a java.lang.invoke.WrongMethodTypeException: (Ljava/lang/Object;[Ljava/lang/Object;)V cannot be called without a receiver argument as ([Ljava/lang/Object;)Ljava/lang/Object; imho casting to Object and Object[] in mh.invokeExact((Object)Class.class, (Object[])new Class[0]); is without effect, since invokeExact is a vargs method an everything will just be put into an Object[] anyway. We had not a compiler change for this kind of thing, had we? bye Jochen Am 07.02.2012 17:52, schrieb Jim Laskey: > Try > > MethodType type = MethodType.methodType(Constructor.class, > Class[].class); > MethodHandle mh = MethodHandles.lookup().findVirtual(Class.class, > "getDeclaredConstructor", type); > MethodType target = MethodType.methodType(void.class, Object.class, > Object[].class); > mh = MethodHandles.explicitCastArguments(mh, target); > mh.invokeExact((Object)Class.class, (Object[])new Class[0]); > > Cheers, > > -- Jim > > On 2012-02-07, at 12:37 PM, Jochen Theodorou wrote: > >> Am 07.02.2012 17:29, schrieb Jim Laskey: >> MethodType type = MethodType.methodType(Constructor.class, >> Class[].class); >> MethodHandle mh = >> MethodHandles.lookup().findVirtual(Class.class, >> "getDeclaredConstructor", type); >> MethodType target = MethodType.methodType(Object.class, >> Object.class, Object.class); >> mh = mh.asType(target); >> mh.invokeWithArguments(Class.class,new Class[0]); >>> >>> As soon as you mh = mh.asType(target); it is no longer vararg, so it >>> is treating new Class[0] as the second argument cast to Object. If >>> you are trying to type as (Object , Object[]). I think you are going >>> to run into difficulties validating (Class[]) Object[]. You may have >>> to add a wrapper to get what you want, but you could also try using >>> asCollector. >> >> or in other words: I should not use invokeWithArguments for this. >> >> If I wanted to use the same target type... since that is what my call site >> gives me... and I wanted to use invokeExact instead, how would I have to >> change the program? >> >> bye blackdrag >> >> -- >> Jochen "blackdrag" Theodorou - Groovy Project Tech Lead >> blog: http://blackdragsview.blogspot.com/ >> german groovy discussion newsgroup: de.comp.lang.misc >> For Groovy programming sources visit http://groovy-lang.org >> > -- Jochen "blackdrag" Theodorou - Groovy Project Tech Lead blog: http://blackdragsview.blogspot.com/ german groovy discussion newsgroup: de.comp.lang.misc For Groovy programming sources visit http://groovy-lang.org ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: problem with vargs method
Try MethodType type = MethodType.methodType(Constructor.class, Class[].class); MethodHandle mh = MethodHandles.lookup().findVirtual(Class.class, "getDeclaredConstructor", type); MethodType target = MethodType.methodType(void.class, Object.class, Object[].class); mh = MethodHandles.explicitCastArguments(mh, target); mh.invokeExact((Object)Class.class, (Object[])new Class[0]); Cheers, -- Jim On 2012-02-07, at 12:37 PM, Jochen Theodorou wrote: > Am 07.02.2012 17:29, schrieb Jim Laskey: >MethodType type = MethodType.methodType(Constructor.class, > Class[].class); >MethodHandle mh = MethodHandles.lookup().findVirtual(Class.class, > "getDeclaredConstructor", type); >MethodType target = MethodType.methodType(Object.class, > Object.class, Object.class); >mh = mh.asType(target); >mh.invokeWithArguments(Class.class,new Class[0]); >> >> As soon as you mh = mh.asType(target); it is no longer vararg, so it >> is treating new Class[0] as the second argument cast to Object. If >> you are trying to type as (Object , Object[]). I think you are going >> to run into difficulties validating (Class[]) Object[]. You may have >> to add a wrapper to get what you want, but you could also try using >> asCollector. > > or in other words: I should not use invokeWithArguments for this. > > If I wanted to use the same target type... since that is what my call site > gives me... and I wanted to use invokeExact instead, how would I have to > change the program? > > bye blackdrag > > -- > Jochen "blackdrag" Theodorou - Groovy Project Tech Lead > blog: http://blackdragsview.blogspot.com/ > german groovy discussion newsgroup: de.comp.lang.misc > For Groovy programming sources visit http://groovy-lang.org > ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: problem with vargs method
Am 07.02.2012 17:29, schrieb Jim Laskey: MethodType type = MethodType.methodType(Constructor.class, Class[].class); MethodHandle mh = MethodHandles.lookup().findVirtual(Class.class, "getDeclaredConstructor", type); MethodType target = MethodType.methodType(Object.class, Object.class, Object.class); mh = mh.asType(target); mh.invokeWithArguments(Class.class,new Class[0]); > > As soon as you mh = mh.asType(target); it is no longer vararg, so it > is treating new Class[0] as the second argument cast to Object. If > you are trying to type as (Object , Object[]). I think you are going > to run into difficulties validating (Class[]) Object[]. You may have > to add a wrapper to get what you want, but you could also try using > asCollector. or in other words: I should not use invokeWithArguments for this. If I wanted to use the same target type... since that is what my call site gives me... and I wanted to use invokeExact instead, how would I have to change the program? bye blackdrag -- Jochen "blackdrag" Theodorou - Groovy Project Tech Lead blog: http://blackdragsview.blogspot.com/ german groovy discussion newsgroup: de.comp.lang.misc For Groovy programming sources visit http://groovy-lang.org ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: problem with vargs method
As soon as you mh = mh.asType(target); it is no longer vararg, so it is treating new Class[0] as the second argument cast to Object. If you are trying to type as (Object , Object[]). I think you are going to run into difficulties validating (Class[]) Object[]. You may have to add a wrapper to get what you want, but you could also try using asCollector. Cheers, -- Jim On 2012-02-07, at 12:14 PM, Jochen Theodorou wrote: > The problem can be easily reproduced using this: >>MethodType type = MethodType.methodType(Constructor.class, >> Class[].class); >>MethodHandle mh = MethodHandles.lookup().findVirtual(Class.class, >> "getDeclaredConstructor", type); >>MethodType target = MethodType.methodType(Object.class, Object.class, >> Object.class); >>mh = mh.asType(target); >>mh.invokeWithArguments(Class.class,new Class[0]); > > can someone tell me the mistake? > > bye Jochen > > Am 07.02.2012 17:04, schrieb Jochen Theodorou: >> Hi all, >> >> maybe someone can explain to me why method handles behave this way in my >> case. >> >> Bascially I have a handle for Class#getDeclaredConstructor(Class...) I >> created via unreflect. >> >> http://docs.oracle.com/javase/7/docs/api/java/lang/Class.html#getDeclaredConstructor%28java.lang.Class...%29 >> >> this handle is then created as a AdapterMethodHandle$AsVargsCollector. >> My targetType is Object(Object,Object) and the arguments to the call are >> the Class, and an empty Class[]. So the next steps are asType with the >> target type, adding a guard with catch, then my guards for the arguments >> and last I do an invokeWithArguments. >> >> What I get now is a ClassCastException with the message required class >> java.lang.Class but encountered class [Ljava.lang.Class; >> >> The guards are unrelated to the problem, since it happens without them >> as well. >> >> Now can anyone explain me why I get that exception? It doesn't really >> make sense to me atm. >> >> bye Jochen >> > > > -- > Jochen "blackdrag" Theodorou - Groovy Project Tech Lead > blog: http://blackdragsview.blogspot.com/ > german groovy discussion newsgroup: de.comp.lang.misc > For Groovy programming sources visit http://groovy-lang.org > > ___ > mlvm-dev mailing list > mlvm-dev@openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: problem with vargs method
As soon as you mh = mh.asType(target); it is no longer vararg, so it is treating new Class[0] as the second argument cast to Object. If you are trying to type as (Object , Object[]). I think you are going to run into difficulties validating (Class[]) Object[]. You may have to add a wrapper to get what you want, but you could also try using asCollector. Cheers, -- Jim On 2012-02-07, at 12:14 PM, Jochen Theodorou wrote: > The problem can be easily reproduced using this: >>MethodType type = MethodType.methodType(Constructor.class, >> Class[].class); >>MethodHandle mh = MethodHandles.lookup().findVirtual(Class.class, >> "getDeclaredConstructor", type); >>MethodType target = MethodType.methodType(Object.class, Object.class, >> Object.class); >>mh = mh.asType(target); >>mh.invokeWithArguments(Class.class,new Class[0]); > > can someone tell me the mistake? > > bye Jochen > > Am 07.02.2012 17:04, schrieb Jochen Theodorou: >> Hi all, >> >> maybe someone can explain to me why method handles behave this way in my >> case. >> >> Bascially I have a handle for Class#getDeclaredConstructor(Class...) I >> created via unreflect. >> >> http://docs.oracle.com/javase/7/docs/api/java/lang/Class.html#getDeclaredConstructor%28java.lang.Class...%29 >> >> this handle is then created as a AdapterMethodHandle$AsVargsCollector. >> My targetType is Object(Object,Object) and the arguments to the call are >> the Class, and an empty Class[]. So the next steps are asType with the >> target type, adding a guard with catch, then my guards for the arguments >> and last I do an invokeWithArguments. >> >> What I get now is a ClassCastException with the message required class >> java.lang.Class but encountered class [Ljava.lang.Class; >> >> The guards are unrelated to the problem, since it happens without them >> as well. >> >> Now can anyone explain me why I get that exception? It doesn't really >> make sense to me atm. >> >> bye Jochen >> > > > -- > Jochen "blackdrag" Theodorou - Groovy Project Tech Lead > blog: http://blackdragsview.blogspot.com/ > german groovy discussion newsgroup: de.comp.lang.misc > For Groovy programming sources visit http://groovy-lang.org > > ___ > mlvm-dev mailing list > mlvm-dev@openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: problem with vargs method
The problem can be easily reproduced using this: > MethodType type = MethodType.methodType(Constructor.class, > Class[].class); > MethodHandle mh = MethodHandles.lookup().findVirtual(Class.class, > "getDeclaredConstructor", type); > MethodType target = MethodType.methodType(Object.class, Object.class, > Object.class); > mh = mh.asType(target); > mh.invokeWithArguments(Class.class,new Class[0]); can someone tell me the mistake? bye Jochen Am 07.02.2012 17:04, schrieb Jochen Theodorou: > Hi all, > > maybe someone can explain to me why method handles behave this way in my > case. > > Bascially I have a handle for Class#getDeclaredConstructor(Class...) I > created via unreflect. > > http://docs.oracle.com/javase/7/docs/api/java/lang/Class.html#getDeclaredConstructor%28java.lang.Class...%29 > > this handle is then created as a AdapterMethodHandle$AsVargsCollector. > My targetType is Object(Object,Object) and the arguments to the call are > the Class, and an empty Class[]. So the next steps are asType with the > target type, adding a guard with catch, then my guards for the arguments > and last I do an invokeWithArguments. > > What I get now is a ClassCastException with the message required class > java.lang.Class but encountered class [Ljava.lang.Class; > > The guards are unrelated to the problem, since it happens without them > as well. > > Now can anyone explain me why I get that exception? It doesn't really > make sense to me atm. > > bye Jochen > -- Jochen "blackdrag" Theodorou - Groovy Project Tech Lead blog: http://blackdragsview.blogspot.com/ german groovy discussion newsgroup: de.comp.lang.misc For Groovy programming sources visit http://groovy-lang.org ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
problem with vargs method
Hi all, maybe someone can explain to me why method handles behave this way in my case. Bascially I have a handle for Class#getDeclaredConstructor(Class...) I created via unreflect. http://docs.oracle.com/javase/7/docs/api/java/lang/Class.html#getDeclaredConstructor%28java.lang.Class...%29 this handle is then created as a AdapterMethodHandle$AsVargsCollector. My targetType is Object(Object,Object) and the arguments to the call are the Class, and an empty Class[]. So the next steps are asType with the target type, adding a guard with catch, then my guards for the arguments and last I do an invokeWithArguments. What I get now is a ClassCastException with the message required class java.lang.Class but encountered class [Ljava.lang.Class; The guards are unrelated to the problem, since it happens without them as well. Now can anyone explain me why I get that exception? It doesn't really make sense to me atm. bye Jochen -- Jochen "blackdrag" Theodorou - Groovy Project Tech Lead blog: http://blackdragsview.blogspot.com/ german groovy discussion newsgroup: de.comp.lang.misc For Groovy programming sources visit http://groovy-lang.org ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: Smalltalk and tiered compile data
On Feb 3, 2012, at 1:25 AM, Mark Roos wrote: > So I ran some tests using a simple benchmark using the jdk8-b23 from the > Openjdk google code. > > Without tiered compile I get: ( times in nanoseconds ) > 52101000 > 53973000 > 20932000 > > with tiered on > 493788000 > 521448000 > 513287000 > 34293 > 15048000 > > But if I invalidate all call sites before the benchmark with tiered I see: > > 449127000 > 288584000 > 80717000 > 36255000 > > and without tiered > 4921 > 744625000 > 27179000 > 26377000 > 24514000 > > in all cases more runs after show no changes for 30 runs. > > So tiered starts very very very slow but ends better. Both seem to have a > hard time if call sites have their > targets reset. > > any thoughts on how I might get the best always? Especially for callsite > resets. What exactly do you mean by "invalidate call sites before the benchmark"? Are you using MutableCallSites and call setTarget on them? > > And why would the startup be 10x slower for tiered? Good question. The run times are long enough (around 0.5s) that a C2 compile should happen in the first runs. But maybe I'm wrong. Igor, do you have an idea? -- Chris > > By the way the data for jdk7u4 is similar but its best times are slower. > > regards > mark___ > mlvm-dev mailing list > mlvm-dev@openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
