Re: EXT: Re: InvokeDynamic PIC Slowdown (deopt issue?) need advice

;mlvm-dev" wrote on 07/29/2016 08:08:56 AM: > From: Remi Forax > To: Da Vinci Machine Project > Date: 07/29/2016 08:09 AM > Subject: Re: EXT: Re: InvokeDynamic PIC Slowdown (deopt issue?) need advice > Sent by: "mlvm-dev" > > In fact, you don

Re: EXT: Re: InvokeDynamic PIC Slowdown (deopt issue?) need advice

nly test() see a new receiver, test2 is not make non re-entrant by the VM. cheers, Rémi - Mail original - > De: "MacGregor, Duncan (GE Energy Connections)" > À: "Da Vinci Machine Project" > Envoyé: Mardi 26 Juillet 2016 12:29:59 > Objet: Re: EXT: Re: I

Re: EXT: Re: InvokeDynamic PIC Slowdown (deopt issue?) need advice

gt; >Rémi > >- Mail original - >> De: "MacGregor, Duncan (GE Energy Connections)" >> >> À: "Da Vinci Machine Project" >> Envoyé: Lundi 25 Juillet 2016 11:40:51 >> Objet: Re: EXT: Re: InvokeDynamic PIC Slowdown (deopt issue?) need >

Re: EXT: Re: InvokeDynamic PIC Slowdown (deopt issue?) need advice

In my perfect world a pic looks like this at the lowest level         mov  object field ==> eax         je eax=test1  to implementation1  " the special GWT you mention "         je eax=test2  to implementation2         ...         handle miss I would want to move the testN order to optimize,  rep

Re: EXT: Re: InvokeDynamic PIC Slowdown (deopt issue?) need advice

yes, an array of a special kind of GWT, which unlike a GWT doesn't have a fallback, only a test and a target. Rémi > De: "Mark Roos" > À: "Da Vinci Machine Project" > Envoyé: Lundi 25 Juillet 2016 18:12:25 > Objet: Re: EXT: Re: InvokeDynamic PIC Slow

Re: EXT: Re: InvokeDynamic PIC Slowdown (deopt issue?) need advice

; De: "MacGregor, Duncan (GE Energy Connections)" >> À: "Da Vinci Machine Project" >> Envoyé: Lundi 25 Juillet 2016 11:40:51 >> Objet: Re: EXT: Re: InvokeDynamic PIC Slowdown (deopt issue?) need advice > >> I like the idea of this, but I¹m not

Re: EXT: Re: InvokeDynamic PIC Slowdown (deopt issue?) need advice

e, it should be implemented with an array of couples instead with a couple of arrays. Rémi - Mail original - > De: "MacGregor, Duncan (GE Energy Connections)" > À: "Da Vinci Machine Project" > Envoyé: Lundi 25 Juillet 2016 11:40:51 > Objet: Re: EXT: Re: In

Re: EXT: Re: InvokeDynamic PIC Slowdown (deopt issue?) need advice

I like the idea of this, but I¹m not sure it can be applied to Magik due to the ability for methods to redefined and hence our PICs to be invalidated. I¹ll have a look though, there might be a couple of places I could try prototyping this. Duncan. On 23/07/2016, 00:25, "mlvm-dev on behalf of John

Re: InvokeDynamic PIC Slowdown (deopt issue?) need advice

On Jul 24, 2016, at 3:41 PM, Mark Roos wrote: > > A few questions on implementation. > > My old prototype looks like: > private RtObject[] _mDicts = new RtObject[8]; // array of > method dicts > private MethodHandle[] _methods = new MethodHandle[8]; // the >

Re: InvokeDynamic PIC Slowdown (deopt issue?) need advice

 A few questions on implementation. My old prototype looks like:                 private RtObject[] _mDicts = new RtObject[8]; // array of method dicts                 private MethodHandle[] _methods = new MethodHandle[8]; // the code MH                 MethodHandle lookupSelf(RtObject rcvr, RtCal

Re: InvokeDynamic PIC Slowdown (deopt issue?) need advice

0 - Mail original - > De: "Remi Forax" > À: "Da Vinci Machine Project" > Envoyé: Samedi 23 Juillet 2016 12:39:08 > Objet: Re: InvokeDynamic PIC Slowdown (deopt issue?) need advice > At least the PIC usual test seems to work :) > > https://gi

Re: InvokeDynamic PIC Slowdown (deopt issue?) need advice

e: "John Rose" > À: "Da Vinci Machine Project" > Envoyé: Samedi 23 Juillet 2016 01:25:32 > Objet: Re: InvokeDynamic PIC Slowdown (deopt issue?) need advice > On May 31, 2016, at 12:41 PM, Mark Roos wrote: >> >> It looks like, from some fine timing, tha

Re: InvokeDynamic PIC Slowdown (deopt issue?) need advice

On 23.07.2016 01:25, John Rose wrote: On May 31, 2016, at 12:41 PM, Mark Roos wrote: It looks like, from some fine timing, that each time the Smalltalk class changes there is a large amount of time added to the call. Which I would expect if there was a deopt whenever a different GWT trigger

Re: InvokeDynamic PIC Slowdown (deopt issue?) need advice

t; From: John Rose > To: Da Vinci Machine Project > Date: 07/22/2016 04:26 PM > Subject: Re: InvokeDynamic PIC Slowdown (deopt issue?) need advice > Sent by: "mlvm-dev" > > On May 31, 2016, at 12:41 PM, Mark Roos wrote: > > > > It looks like

Re: InvokeDynamic PIC Slowdown (deopt issue?) need advice

On May 31, 2016, at 12:41 PM, Mark Roos wrote: > > It looks like, from some fine timing, that each time the Smalltalk class > changes there is a large amount > of time added to the call. Which I would expect if there was a deopt > whenever a different GWT triggered. > There are 6 GWTs in thi

Re: InvokeDynamic PIC Slowdown (deopt issue?) need advice

Thx Vladimir Turns out this was self inflicted by the means I was using for PIC invalidation.  There is an interesting case when only one class returns false and all others true ( isNil).  Since this is often in a loop the impact is severe.  I see how to handle this corner case but it does reopen

Re: InvokeDynamic PIC Slowdown (deopt issue?) need advice

Never-taken GWT branches (on per-MH instance basis) are aggressively pruned during JIT-compilation. So, in the worst case, a MH chain containing 6 GWT can experience 6 recompilations. I don't know what Java version you use, but there were a number of bugs fixed in HotSpot, which manifested a

Re: invokedynamic and subclasses

I've gotten this working with a simplified version of the inlining cache in Remi's cookbook. Thanks guys. Performance is about twice as slow as invokevirtual, which I am really pleased with. On Wed, Jun 24, 2015 at 9:53 AM, Rémi Forax wrote: > Hi Mike, > i've compiled a small list of patterns,

Re: invokedynamic and subclasses

JRuby also chains the bootstraps, you might find inspiration here: https://github.com/jruby/jruby/blob/master/core/src/main/java/org/jruby/runtime/invokedynamic/InvokeDynamicSupport.java On Wed, Jun 24, 2015 at 11:25 AM, Mike Jarmy wrote: > Jochen -- that comes tantalizingly close to making sens

Re: invokedynamic and subclasses

Jochen -- that comes tantalizingly close to making sense to me :-). I don't quite follow all of the terminology yet, but the basic idea that you describe of chaining bootstrap calls is sort of like what I had vaguely designed in my head. Once I am doing learning how all this works I should be abl

Re: invokedynamic and subclasses

Hi Mike, First of all, the bootstrap method does not have to be in the same class. In Groovy we have for example one bootstrap method for all classes only. It is part of the runtime then you could say. We do it like this. We have two bootstrap methods in the Groovy runtime (you don't need t

Re: invokedynamic and subclasses

Thanks guys, the cookbook is just the kind of thing I was looking for. On Wed, Jun 24, 2015 at 9:53 AM, Rémi Forax wrote: > Hi Mike, > i've compiled a small list of patterns, > https://code.google.com/p/jsr292-cookbook/ > > take a look to the first inlining cache example. > > cheers, > Rémi >

Re: invokedynamic and subclasses

Hi Mike, i've compiled a small list of patterns, https://code.google.com/p/jsr292-cookbook/ take a look to the first inlining cache example. cheers, Rémi Le 24 juin 2015 14:19:32 CEST, Mike Jarmy a écrit : >I've been experimenting with invokedynamic in a compiler for a dynamic >language >th

Re: invokedynamic and subclasses

Okay, this is just the sort of thing invokeDynamic is designed for. Where you want to call get_foo() you should use an invokeDynaimc instruction that will create a MutableCallSite. You should set the target of this to be a lookup method that can find the appropriate get_foo() method, and possibl

Re: Invokedynamic and recursive method call

Thank you, Vladimir ! Rémi On 01/30/2015 04:07 PM, Vladimir Ivanov wrote: Remi, thanks for the report! Filed JDK-8072008 [1]. Best regards, Vladimir Ivanov [1] https://bugs.openjdk.java.net/browse/JDK-8072008 On 1/30/15 4:03 AM, Remi Forax wrote: On 01/30/2015 01:48 AM, John Rose wrote:

Re: Invokedynamic and recursive method call

Remi, thanks for the report! Filed JDK-8072008 [1]. Best regards, Vladimir Ivanov [1] https://bugs.openjdk.java.net/browse/JDK-8072008 On 1/30/15 4:03 AM, Remi Forax wrote: On 01/30/2015 01:48 AM, John Rose wrote: On Jan 7, 2015, at 8:13 AM, Remi Forax mailto:[email protected]>> wrote: Bu

Re: Invokedynamic and recursive method call

On 01/30/2015 01:48 AM, John Rose wrote: On Jan 7, 2015, at 8:13 AM, Remi Forax > wrote: But if fibo is called through an invokedynamic, instead of emitting a direct call to fibo, the JIT generates a code that push the method handle on stack and execute it like if t

Re: Invokedynamic and recursive method call

> On Jan 29, 2015, at 4:48 PM, John Rose wrote: > > On Jan 7, 2015, at 8:13 AM, Remi Forax > wrote: >> >> But if fibo is called through an invokedynamic, instead of emitting a direct >> call to fibo, >> the JIT generates a code that push the method handle on stack an

Re: Invokedynamic and recursive method call

On Jan 7, 2015, at 8:13 AM, Remi Forax wrote: > > But if fibo is called through an invokedynamic, instead of emitting a direct > call to fibo, > the JIT generates a code that push the method handle on stack and execute it > like if the metod handle was not constant > (the method handle is consta

Re: Invokedynamic and recursive method call

Trying to remember compiler implementation details this sounds reasonable and is a bug (or an enhancement, actually ;-). Can someone file a bug? > On Jan 7, 2015, at 10:07 AM, Charles Oliver Nutter > wrote: > > This could explain performance regressions we've seen on the > performance of heav

Re: Invokedynamic and recursive method call

This could explain performance regressions we've seen on the performance of heavily-recursive algorithms. I'll try to get an assembly dump for fib in JRuby later today. - Charlie On Wed, Jan 7, 2015 at 10:13 AM, Remi Forax wrote: > > On 01/07/2015 10:43 AM, Marcus Lagergren wrote: >> >> Remi, I

Re: Invokedynamic and recursive method call

7u40 is when the native invoke dynamic implementation was replaced with Lambda Forms :-/ /M > On 07 Jan 2015, at 17:13, Remi Forax wrote: > > > On 01/07/2015 10:43 AM, Marcus Lagergren wrote: >> Remi, I tried to reproduce your problem with jdk9 b44. It runs decently fast. > > yes, nashorn is

Re: Invokedynamic and recursive method call

On 01/07/2015 10:43 AM, Marcus Lagergren wrote: Remi, I tried to reproduce your problem with jdk9 b44. It runs decently fast. yes, nashorn is fast enough but it can be faster if the JIT was not doing something stupid. When the VM inline fibo, because fibo is recursive, the recursive call i

Re: Invokedynamic and recursive method call

Remi, I tried to reproduce your problem with jdk9 b44. It runs decently fast. When did it start to regress? Regards Marcus > On 30 Dec 2014, at 20:48, Remi Forax wrote: > > Hi guys, > I've found a bug in the interaction between the lambda form and inlining > algorithm, > basically if the inli

Re: Invokedynamic and recursive method call

ping ? Rémi On 12/30/2014 08:48 PM, Remi Forax wrote: Hi guys, I've found a bug in the interaction between the lambda form and inlining algorithm, basically if the inlining heuristic bailout because the method is recursive and already inlined once, instead to emit a code to do a direct call,

Re: invokedynamic and error messages

Am 06.01.2012 17:22, schrieb John Rose: > On Jan 6, 2012, at 4:57 AM, Jochen Theodorou wrote: > >> I see where it comes from, but "reusing" that instead of making a new if >> is not really needed, is it? >> >> Do people here agree this should be improved? > > The javadoc for this throw is: > * @thr

Re: invokedynamic and error messages

On Jan 6, 2012, at 4:57 AM, Jochen Theodorou wrote: > I see where it comes from, but "reusing" that instead of making a new if > is not really needed, is it? > > Do people here agree this should be improved? The javadoc for this throw is: * @throws IllegalArgumentException if the target do

Auto Reply: Re: Invokedynamic updates for JRuby

FYI, I'm on vacation till June, 28. If you have HotSpot-related question, please, contact Leonid Mesnik ([email protected]). Best regards, Vladimir Ivanov ___ mlvm-dev mailing list [email protected] http://mail.openjdk.java.net/mailman/

Re: Invokedynamic updates for JRuby

My hope is that if you have a special path for +1 for(x=0; i Ok, numbers for fib with special paths for +1 -1 +2 and -2...this is > passing a primitive through invokedynamic, assumes we're calling > Fixnum always, and does not type-guard anything...so it's faster than > it ought to be, but it s

Re: Invokedynamic updates for JRuby

Ok, numbers for fib with special paths for +1 -1 +2 and -2...this is passing a primitive through invokedynamic, assumes we're calling Fixnum always, and does not type-guard anything...so it's faster than it ought to be, but it shows what difference the simpler overflow guard has: Normal overflow g

Re: Invokedynamic updates for JRuby

I did take your advice and add paths for +- 1 and 2, but did not see an improvement in perf. That's not to say there wasn't one, but it may be lost in the Fixnum object creation... - Charlie (mobile) On Jun 14, 2011, at 18:33, Rémi Forax wrote: > On 06/14/2011 05:02 PM, Charles Oliver Nutter

Re: Invokedynamic updates for JRuby

On 06/14/2011 05:02 PM, Charles Oliver Nutter wrote: > Disabled (for perf or incompleteness): > * Math operator invocations with literal fixnum RHS (incomplete: no guards) I'm working on an example for the cookbook that allows integers to overflow to BigInteger and has special paths when a constan

Re: InvokeDynamic

I suggest a syntax for InvokeDynamic. Why ? motivations ? Because it seems that syntax for InvokeDynamic will not be available in JDK7 and I dislike generating bytecode. I have used ASM, some years ago, and have nothing against it, but now I do not like Java bytecode (stack machine) and the

Re: InvokeDynamic

Hi Daniel, On 04/30/2011 09:51 AM, Daniel Latrémolière wrote: I suggest a syntax for InvokeDynamic. Why ? motivations ? It is created like a field and has a name (for referencing and bootstrapping it), then i suggest to create a new modifier "dynamic" and define InvokeDynamic like a mix o

Re: InvokeDynamic

Sorry, I have forgotten the details of invoking the InvokeDynamic created by this syntax. This can be made by using a syntax like: |ClassName#indyName(...);| except if headers contains (like for "static" scope [1]): |import dynamic packageName.ClassName#indyName;| || where it can be

Re: Invokedynamic and inlining flags

On Feb 3, 2011, at 1:17 PM, Charles Oliver Nutter wrote: > I'm ready to update it once MLVM changes have settled down. Huff, puff... Soon! -- John ___ mlvm-dev mailing list [email protected] http://mail.openjdk.java.net/mailman/listinfo/mlvm-d

Re: Invokedynamic and inlining flags

On Thu, Feb 3, 2011 at 3:56 PM, Rémi Forax wrote: > Charles, do you use ASM 4 or ASM 3.3 ? I am still using ASM 3.3 and Linkage to bind indy call sites. - Charlie ___ mlvm-dev mailing list [email protected] http://mail.openjdk.java.net/mailman/

Re: Invokedynamic and inlining flags

On 02/03/2011 10:17 PM, Charles Oliver Nutter wrote: > On Thu, Feb 3, 2011 at 6:33 AM, Christian Thalinger > wrote: >> On Jan 31, 2011, at 8:39 PM, Charles Oliver Nutter wrote: >>> Hello friends! After months on "vacation" from indy, I managed to >>> spend some time this weekend updating JRuby's

Re: Invokedynamic and inlining flags

On Thu, Feb 3, 2011 at 6:33 AM, Christian Thalinger wrote: > On Jan 31, 2011, at 8:39 PM, Charles Oliver Nutter wrote: >> Hello friends! After months on "vacation" from indy, I managed to >> spend some time this weekend updating JRuby's indy support. But this >> email is to ask about the inlining

Re: Invokedynamic and inlining flags

On Jan 31, 2011, at 8:39 PM, Charles Oliver Nutter wrote: > Hello friends! After months on "vacation" from indy, I managed to > spend some time this weekend updating JRuby's indy support. But this > email is to ask about the inlining flag tweaks that still seem to be > required. Does this mean I c

Re: Invokedynamic and inlining flags

On Jan 31, 2011, at 8:39 PM, Charles Oliver Nutter wrote: > Hello friends! After months on "vacation" from indy, I managed to > spend some time this weekend updating JRuby's indy support. But this > email is to ask about the inlining flag tweaks that still seem to be > required. > > First, the goo

Re: Invokedynamic slower than reflection?

>Eric's test Hello.java works OK, but your test, Rémi, fails (Fib4.java). So >it is a second bug. > >Stephen, I left a comment: http://gist.github.com/500808 > >Gist of the gist is: -XX:+UnlockExperimentalVMOptions -XX:+EnableInvokeDynamic Thanks John, I figured it was something simple like th

Re: Invokedynamic slower than reflection?

Eric's test Hello.java works OK, but your test, Rémi, fails (Fib4.java). So it is a second bug. Stephen, I left a comment: http://gist.github.com/500808 Gist of the gist is: -XX:+UnlockExperimentalVMOptions -XX:+EnableInvokeDynamic -- John On Jul 30, 2010, at 8:30 AM, Rémi Forax wrote: > L

Re: Invokedynamic slower than reflection?

>Hi Rémi, > >I did freshly build mlvm and run Eric's test. >Here's my result: > >Duration invokedynamic: 103 >Duration reflection: 1463 > >The patch seems to be working for me as InvokeDynamic is clearly >faster than Reflection on my machine. Hmm ... on my latest mlvm I get this error: Exceptio

Re: Invokedynamic slower than reflection?

Le 30/07/2010 08:40, Chanwit Kaewkasi a écrit : Hi Rémi, I did freshly build mlvm and run Eric's test. Here's my result: Duration invokedynamic: 103 Duration reflection: 1463 The patch seems to be working for me as InvokeDynamic is clearly faster than Reflection on my machine. Cheers, Chanwi

Auto Reply: Re: Invokedynamic slower than reflection?

Hello, I'm out of the office between July 19 and August 13. Christian Törnqvist ([email protected]) will be substituting for me. Please make sure to include him in mail conversations and telephone conferences. Regards, Henrik Österdahl JRockit Codegen & Runtime Dev Lead __

Re: Invokedynamic slower than reflection?

Hi Rémi, I did freshly build mlvm and run Eric's test. Here's my result: Duration invokedynamic: 103 Duration reflection: 1463 The patch seems to be working for me as InvokeDynamic is clearly faster than Reflection on my machine. Cheers, Chanwit -- Dr Chanwit Kaewkasi, Lecturer School of Comp

Re: Invokedynamic slower than reflection?

Le 29/07/2010 01:26, John Rose a écrit : On Jul 28, 2010, at 4:26 PM, Rémi Forax wrote: My question was more, is it enable in mlvm if I use default guards. Yes. In the series file, you'll see that it has the same guards (-/meth +) as the other patches: http://hg.openjdk.java.net

Re: Invokedynamic slower than reflection?

On Jul 28, 2010, at 4:26 PM, Rémi Forax wrote: > So I think the patch doesn't fix the issue. Also, I'll retry Eric Bodden's original Hello.java. -- John ___ mlvm-dev mailing list [email protected] http://mail.openjdk.java.net/mailman/listinfo/m

Re: Invokedynamic slower than reflection?

On Jul 28, 2010, at 4:26 PM, Rémi Forax wrote: > My question was more, is it enable in mlvm if I use default guards. Yes. In the series file, you'll see that it has the same guards (-/meth +) as the other patches: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/file/tip/series > So I think the

Re: Invokedynamic slower than reflection?

Le 29/07/2010 01:12, John Rose a écrit : > On Jul 27, 2010, at 10:11 AM, Rémi Forax wrote: > > >> Le 16/07/2010 00:48, John Rose a écrit : >> >>> It was some sort of bitrot. >>> >>> I pushed a fix for this to mlvm/hotspot. >>> >>> Thanks for the reports! >>> >>> -- John >>> >>> >>

Re: Invokedynamic slower than reflection?

On Jul 27, 2010, at 10:11 AM, Rémi Forax wrote: > Le 16/07/2010 00:48, John Rose a écrit : >> It was some sort of bitrot. >> >> I pushed a fix for this to mlvm/hotspot. >> >> Thanks for the reports! >> >> -- John >> > > Is it enable by default, it doesn't seem to work ? The fix is titled thi

Auto Reply: Re: Invokedynamic slower than reflection?

Hello, I'm out of the office between July 19 and August 13. Christian Törnqvist ([email protected]) will be substituting for me. Please make sure to include him in mail conversations and telephone conferences. Regards, Henrik Österdahl JRockit Codegen & Runtime Dev Lead __

Re: Invokedynamic slower than reflection?

Le 16/07/2010 00:48, John Rose a écrit : > It was some sort of bitrot. > > I pushed a fix for this to mlvm/hotspot. > > Thanks for the reports! > > -- John > Is it enable by default, it doesn't seem to work ? Rémi ___ mlvm-dev mailing list mlvm-dev

Re: Invokedynamic slower than reflection?

It was some sort of bitrot. I pushed a fix for this to mlvm/hotspot. Thanks for the reports! -- John On Jun 5, 2010, at 10:58 AM, Rémi Forax wrote: > Le 05/06/2010 02:01, John Rose a écrit : >> Is the call site megamutable? (Is it linked many times instead of once?) >> -- John >> > > no !

Re: Invokedynamic slower than reflection?

On Sat, 2010-06-05 at 19:58 +0200, Rémi Forax wrote: > Le 05/06/2010 02:01, John Rose a écrit : > > Is the call site megamutable? (Is it linked many times instead of once?) > > -- John > > > > no ! > The callsite is linked only once. Yeah, that bug is around since: 6939134: JSR 292 adjust

Re: Invokedynamic slower than reflection?

Le 05/06/2010 02:01, John Rose a écrit : > Is the call site megamutable? (Is it linked many times instead of once?) -- > John > no ! The callsite is linked only once. Rémi > On Jun 4, 2010, at 4:40 AM, Rémi Forax wrote: > > >> It's funny, I've found the same error last night. >> >> Ye

Re: Invokedynamic slower than reflection?

Is the call site megamutable? (Is it linked many times instead of once?) -- John On Jun 4, 2010, at 4:40 AM, Rémi Forax wrote: > It's funny, I've found the same error last night. > > Yes, there is a problem, > if you run with -XX:+PrintCompilation, you will see > lot of "made not entrant" on

Re: Invokedynamic slower than reflection?

It's funny, I've found the same error last night. Yes, there is a problem, if you run with -XX:+PrintCompilation, you will see lot of "made not entrant" on the same bytecode location. 183% made not entrant (2) Hello::main @ -2 (145 bytes) 184% Hello::main @ 6 (145 bytes) It seems that i

Re: Invokedynamic and Multiple Dispatch

On Mar 6, 2010, at 5:21 PM, Larry Chester wrote: > Then to invoke on an Object x: > > lookup.get(x.getClass()).invokeGeneric(x); > > This is quite slow though (although I believe the bottleneck is in the > invokeGeneric call). I can certainly believe that: invokeGeneric is not fully implemente

Re: Invokedynamic and Multiple Dispatch

Thanks for your reply! My aim is to dispatch based on the dynamic type of the Object as described in: http://en.wikipedia.org/wiki/Multiple_dispatch Currently my implementation revolves around building a HashMap that maps a dynamic type to a MethodHandle and invoking that: HashMap lookup = new

Re: Invokedynamic and Multiple Dispatch

On Feb 28, 2010, at 3:48 PM, Larry Chester wrote: > So I've been playing around with invokedynamic (with build 84), > however I've stumbled on something I find quite strange! > > Consider two objects a and b that both reference a String. a is > declared as a String but b is only an Object. When I

Re: InvokeDynamic throws NoClassDefFoundError

Le 18/02/2010 10:44, Kirill Shirokov a écrit : > John, > > I don't know if it is a known issue, but I noticed that InvokeDynamic > throws NoClassDefFoundError in the following test: > > package test; > > import java.dyn.InvokeDynamic; > import java.dyn.InvokeDynamicBootstrapError; >

Re: invokedynamic question

On May 23, 2008, at 5:02 AM, Jeroen Frijters wrote: > I hope it is appropriate to ask a question here about the > invokedynamic EDR. Yes. There are three actually places where comments can be sent: 1. A JCP comments alias which is merely a one-way pipe to the EG. 2. This list mlvm-dev, which