Re: A pure Java example with reflective access behaving differently with invokeWithArguments() compared to core reflection's invoke() (Re: Strange observation: MethodHandle.invokeWithArguments() would

implementation would be able to adopt changes in the inner workings accordingly thereby insulating bridges from such details and problems. On 08.06.2018 18:23, Peter Levart wrote: I think what you found is a discrepancy between handling of varargs methods using reflection vs. method handle's

Re: A pure Java example with reflective access behaving differently with invokeWithArguments() compared to core reflection's invoke() (Re: Strange observation: MethodHandle.invokeWithArguments() would

Hi Rony, I think what you found is a discrepancy between handling of varargs methods using reflection vs. method handle's .invokeWithArguments(). Reflection basically ignores the fact that some methods are varargs methods. It treats them exactly the same as if they had an array parameter

Re: ClassValue rooting objects after it goes away?

Hi Charles, On 03/02/2018 09:22 PM, Charles Oliver Nutter wrote: Put it another way: does a static reference from a class to itself prevent that class from being garbage collected? Of course not. ClassValue is intended to be a way to inject pseudo-static data into either a class or a Class.

Re: Isolated Methods JEP

Hi Michael, On 08/09/2016 02:05 PM, Peter Levart wrote: In which case would lookup privileges be insufficient to define an isolated method? I would expect the privileges of the code in the isolated method to be checked when such method is executed and not when defining such method - lazily

Re: Isolated Methods JEP

Hi Michael, In the JEP's description you write: /"The loadCode method creates a method from the passed bytecode instructions and constants and returns a MethodHandle that can be used to call the method. The implementation of loadCode will take care of verification of the code to

Re: RFR: JDK-8031043 ClassValue's backing map should have a smaller initial size

of locality of reference inherent to open-addressing tables with minimal average number of false probes which is a property of linked-nodes tables. It seems that in practice, it beats other strategies tried here when lookup performance is in question. Regards, Peter On 06/13/2016 07:18 PM, Peter Levart

RFR: JDK-8031043 ClassValue's backing map should have a smaller initial size

Hi, The patch for this issue is a result of the following discussion on mlvm-dev list: http://mail.openjdk.java.net/pipermail/mlvm-dev/2016-May/006602.html I propose the following improvement to the implementation of ClassValue API:

Re: proxy an interface and call a default method

On 06/02/2016 06:34 PM, fo...@univ-mlv.fr wrote: So perhaps, instead of providing a Proxy::findSuper method that returns a pre-bound MH, there could simply be a method like the following in the Proxy class: public final Object invokeSuper(Class interfaze, String

Re: proxy an interface and call a default method

Hi Remi, Jochen, On 06/02/2016 11:15 AM, fo...@univ-mlv.fr wrote: >The solution could be for Proxy API to provide a MH that was already >bound to the Proxy instance. Such pre-bound MH could not be abused then. independently of any security issue, it may be a good idea but doing a partial

Re: proxy an interface and call a default method

. The solution could be for Proxy API to provide a MH that was already bound to the Proxy instance. Such pre-bound MH could not be abused then. Regards, Peter - Mail original - De: "Peter Levart" <peter.lev...@gmail.com> À: "Da Vinci Machine Project" <mlvm-d

Re: ClassValue perf?

On 05/30/2016 11:09 PM, Peter Levart wrote: Will revert that to volatile semantics... So, here it is. The latest incarnation - the same as webrev.04.1 but with volatile semantics: http://cr.openjdk.java.net/~plevart/misc/ClassValue.Alternative2/webrev.04.2/ Benchmarks show no change

Re: ClassValue perf?

On 05/30/2016 07:47 PM, Aleksey Shipilev wrote: On 05/30/2016 06:59 PM, Peter Levart wrote: I also employed get-acquire/put-release memory ordering semantics instead of SC (volatile) in hope that it might improve a bit the performance on platforms such as PowerPC or ARM, but this can

Re: ClassValue perf?

sue over to you. Thanks! Best, Michael Am 26.05.2016 um 14:42 schrieb Michael Haupt <michael.ha...@oracle.com <mailto:michael.ha...@oracle.com>>: Hi Peter, thank you for this wonderful piece of work. Am 26.05.2016 um 10:59 schrieb Peter Levart <peter.lev...@gmail.com

Re: proxy an interface and call a default method

Hi, I think the main problem here is that by providing the InvocationHandler with a Lookup that could provide "invokespecial" MHs for the proxy interface(s) could be abused. Anyone can create a Proxy for any public interface and supply its own InvocationHandler which could be used to "steal"

Re: ClassValue perf?

Hi Michael, On 05/23/2016 03:56 PM, Michael Haupt wrote: I've ran the unpatched version and Peter's two patches once more. The results are attached (results.txt). They confirm Aleksey's observation. Regarding the 03 patch (plevart3 column in the results), perfasm output (see

Re: Question in understanding ClassValue better

On 05/24/2016 01:41 PM, Peter Levart wrote: Hm, It seems that my example will not help much. It also seems that the only problem with plain: static final ClassValue META_CLASS_CV = new ClassValue() { @Override protected MetaClass computeValue(Class type

Re: Question in understanding ClassValue better

21:32, Peter Levart wrote: [...] a ClassValue instance can be thought of as a component of a compound key. Together with a Class, they form a tuple (aClass, aClassValue) that can be associated with an "associated value", AV. And yes, the AVs associated with tuple containing a partic

Re: Question in understanding ClassValue better

A small correction... On 05/19/2016 09:32 PM, Peter Levart wrote: // the public API public MetaClass getInstanceFor(Class type) { This should of course read: // the public API public *static* MetaClass getInstanceFor(Class type) { Regards, Peter

Re: Question in understanding ClassValue better

Hi Jochen, I'll try to answer your questions as profoundly as I can... On 05/19/2016 04:27 PM, Jochen Theodorou wrote: Hi, at the beginning of this year I had an exchange with Peter Lavart about JDK-8136353 (see http://mail.openjdk.java.net/pipermail/mlvm-dev/2016-January/006563.html),

Re: ClassValue perf?

ue has at least 2x overhead with cleanup compared to my designs (note that benchmark includes classloading time too). Regards, Peter Best, Michael Am 05.05.2016 um 17:21 schrieb Peter Levart <peter.lev...@gmail.com <mailto:peter.lev...@gmail.com>>: Hi Michael, On 05/04/2016

Re: ClassValue perf?

/~plevart/misc/ClassValue.Alternative2/webrev.02/ Regards, Peter Best, Michael Am 04.05.2016 um 17:50 schrieb Peter Levart <peter.lev...@gmail.com <mailto:peter.lev...@gmail.com>>: Hi, On 04/29/2016 10:28 AM, Michael Haupt wrote: All, see http://cr.openjdk.java.net/~mh

Re: ClassValue perf?

Hi, On 04/29/2016 10:28 AM, Michael Haupt wrote: All, see http://cr.openjdk.java.net/~mhaupt/8031043/ for a snapshot of what is currently available. We have three patches: * Christian's, which simply reduces the HashMap size, * Peter's,

Re: Questions about JDK-8136353 "ClassValue preventing class unloading"

On 01/07/2016 02:18 AM, William ML Leslie wrote: On 7 January 2016 at 07:34, Peter Levart <peter.lev...@gmail.com> wrote: ClassValue API could use a different strategy and reference the cached instance of type T from ClassValue instance instead, but then you would have a p

Re: Questions about JDK-8136353 "ClassValue preventing class unloading"

On 01/07/2016 03:05 PM, Jochen Theodorou wrote: Hi Peter, Am 06.01.2016 um 21:34 schrieb Peter Levart: [...] Currently the cached instance of type T is reachable from Class instance and you are using Integer.TYPE in your example. Which means that the cached instance of T is never going

Re: Questions about JDK-8136353 "ClassValue preventing class unloading"

Hi Craig, I think that what you are asking for is impossible to achieve in current Java. ClassValue API is basically a cache that maps a pair: (ClassValue, Class) -> cached instance of type T You would like the cached instance of type T to not be reachable from either ClassValue instance

Re: Questions about JDK-8136353 "ClassValue preventing class unloading"

On 01/06/2016 09:34 PM, Peter Levart wrote: Hi Craig, I think that what you are asking for is impossible to achieve in current Java. ClassValue API is basically a cache that maps a pair: (ClassValue, Class) -> cached instance of type T You would like the cached instance of typ

Re: RFR: JDK-8136893: Improve early java.lang.invoke infrastructure initialization

015 um 08:46 schrieb Peter Levart <peter.lev...@gmail.com>: I have run the tests in java.lang.invoke and only have a problem with 1 test which seems to be related to the test or jtreg itself and happens also without my patch applied: #Test Results (version 2) #Tue Sep 22 09:48:

Re: RFR: JDK-8136893: Improve early java.lang.invoke infrastructure initialization

loader in other public APIs as well (for example: Class.forName(String name, boolean initialize, ClassLoader loader); ) although passing null from user code is rarely needed if at all. This is usually just for internal use. Regards, Peter Am 25.09.2015 um 08:46 schrieb Peter Levart <peter.

RFR: JDK-8136893: Improve early java.lang.invoke infrastructure initialization

Hi, I propose a simple fix for two initialization issues described/linked in: https://bugs.openjdk.java.net/browse/JDK-8136893 The patch is here: http://cr.openjdk.java.net/~plevart/jdk9-dev/8136893_MethodType.fromDescriptor/webrev.01/ The 1st issue is the method:

Re: ClassLoader leak in MethodHandle.asType()

On 04/25/2015 02:12 AM, John Rose wrote: On Apr 24, 2015, at 3:24 PM, Peter Levart peter.lev...@gmail.com mailto:peter.lev...@gmail.com wrote: Anyway. The inexact invoke() always transforms a specific MH to a generic one (Object, Object, ...)Object, right? Yes. So using inexact invoke

Re: ClassLoader leak in MethodHandle.asType()

, Peter On Apr 24, 2015, at 9:14 AM, Peter Levart peter.lev...@gmail.com mailto:peter.lev...@gmail.com wrote: I think there is a Class(Loader) leak in MethodHandle.asType() implementation. If for example some MH (say mhX) is long lived (because it is a system cached MH) and a client generates

ClassLoader leak in MethodHandle.asType()

Hi, I think there is a Class(Loader) leak in MethodHandle.asType() implementation. If for example some MH (say mhX) is long lived (because it is a system cached MH) and a client generates variants from it by invoking mhX.asType(newType) and the newType contains a type (either return type or

Re: Implementing VarHandle

On 04/19/2015 02:06 PM, Brian Goetz wrote: Thanks Remi. I’d like to separate this discussion into two components: implementation and API. Let’s talk about API first. We did give a fair amount of thought to the sigpoly-vs-typesafe API question. VarHandles allow you to abstract data access

Re: [9] RFR (M): 8057967: CallSite dependency tracking scales devastatingly poorly

Hi Vladimir, Would it be possible for CallSite.context to hold the Cleaner instance itself (without indirection through DependencyContext)? DEFAULT_CONTEXT would then be a Cleaner instance that references some default Class object (for example DefaultContext.class that serves no other

Re: What can we improve in JSR292 for Java 9?

On 02/26/2015 01:02 AM, Charles Oliver Nutter wrote: After talking with folks at the Jfokus VM Summit, it seems like there's a number of nice-to-have and a few need-to-have features we'd like to see get into java.lang.invoke. Vladimir suggested I start a thread on these features. A few from me:

Re: What can we improve in JSR292 for Java 9?

On 03/08/2015 01:38 PM, Jochen Theodorou wrote: Am 08.03.2015 12:16, schrieb Remi Forax: [...] You need to restrict the set of method handles that are allowed to be installed inside a CallSite corresponding to such kind of invokedynamic. Something like: you can do any transformations you want

Re: What can we improve in JSR292 for Java 9?

On 03/07/2015 02:53 PM, Remi Forax wrote: On 03/07/2015 06:31 AM, John Rose wrote: [...] (I wish we had a similar candidate for invokespecial/super. That is badly twisted around the verifier.) One way to solve the problem is to consider that invokedynamic init is a special 'bytecode'

Re: What can we improve in JSR292 for Java 9?

On 03/05/2015 04:09 AM, Jochen Theodorou wrote: Am 04.03.2015 23:50, schrieb Charles Oliver Nutter: On Thu, Feb 26, 2015 at 4:27 AM, Jochen Theodorou blackd...@gmx.org wrote: my biggest request: allow the call of a super constructor (like super(foo,bar)) using MethodHandles an have it

Re: [9] RFR (M): 8069591: Customize LambdaForms which are invoked using MH.invoke/invokeExact

On 01/23/2015 12:30 AM, John Rose wrote: On Jan 22, 2015, at 9:56 AM, Vladimir Ivanov vladimir.x.iva...@oracle.com wrote: Remi, John, thanks for review! Updated webrev: http://cr.openjdk.java.net/~vlivanov/8069591/webrev.01/ This time I did additional testing (COMPILE_THRESHOLD 0) and

Re: [9] RFR (M): 8067344: Adjust java/lang/invoke/LFCaching/LFGarbageCollectedTest.java for recent changes in java.lang.invoke

Hi Vladimir, I just wanted to ask about the reason you used PhantomReference to detect that a referent is not softly reachable any more. You could use another SoftReference or a WeakReference for the same effect, since it is guaranteed that all SoftReferences for same referent are cleared

Re: [9, 8u40] RFR (M): 8057020: LambdaForm caches should support eviction

time, would be helpful. Regards, Peter On 12/06/2014 01:30 PM, Peter Levart wrote: (Sorry for a re-send, forgot to include core-libs-dev)... Hi Vladimir, First, just a nit. I think that in LambdaFormEditor: 289 private LambdaForm putInCache(Transform key, LambdaForm form) { 290

Re: [9, 8u40] RFR (M): 8057020: LambdaForm caches should support eviction

Hi Vladimir, First, just a nit. I think that in LambdaFormEditor: 289 private LambdaForm putInCache(Transform key, LambdaForm form) { 290 key = key.withResult(form); 291 for (int pass = 0; ; pass++) { 292 Object c = lambdaForm.transformCache; 293

Re: [9, 8u40] RFR (M): 8057020: LambdaForm caches should support eviction

(Sorry for a re-send, forgot to include core-libs-dev)... Hi Vladimir, First, just a nit. I think that in LambdaFormEditor: 289 private LambdaForm putInCache(Transform key, LambdaForm form) { 290 key = key.withResult(form); 291 for (int pass = 0; ; pass++) { 292

Re: [9, 8u40] RFR (M): 8057020: LambdaForm caches should support eviction

On 12/01/2014 05:58 PM, Vladimir Ivanov wrote: http://cr.openjdk.java.net/~vlivanov/8057020/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8057020 There are 2 major LambdaForm caches: LambdaFormEditor-based and MethodTypeForm. The former is per-LambdaForm and the latter is per method

Re: invoking a interface default method from within an InvocationHandler

that sun.misc.ProxyGenerator can be much faster at generating new class than ASM. But it's also more difficult to program/change. So it depend on what changes would be necessary... Regards, Peter 2014-10-20 11:19 GMT+02:00 Paul Sandoz paul.san...@oracle.com: On Oct 18, 2014, at 6:59 PM, Peter

Re: invoking a interface default method from within an InvocationHandler

On 10/17/2014 11:58 AM, Paul Sandoz wrote: On Oct 16, 2014, at 12:43 PM, Remi Forax fo...@univ-mlv.fr wrote: On 10/15/2014 06:54 PM, Paul Sandoz wrote: Hi Remi, I did some brief evaluation of this area. MethodHandleProxies.asInterfaceInstance currently does not support proxying to default

Re: [9] RFR (S): 8058892: FILL_ARRAYS and ARRAYS are eagely initialized in MethodHandleImpl

On 10/02/2014 06:55 PM, Vladimir Ivanov wrote: Small update: http://cr.openjdk.java.net/~vlivanov/8058892/webrev.01/ Need to reorder initialization sequence in MHI.Lazy. Initialized FILL_ARRAYS and ARRAYS are required for later MH lookups. Additional testing: * jck (api/java_lang/invoke)

Re: [9] RFR (S): 8058892: FILL_ARRAYS and ARRAYS are eagely initialized in MethodHandleImpl

phone On Oct 2, 2014 2:34 PM, Peter Levart peter.lev...@gmail.com mailto:peter.lev...@gmail.com wrote: On 10/02/2014 06:55 PM, Vladimir Ivanov wrote: Small update: http://cr.openjdk.java.net/~vlivanov/8058892/webrev.01/ http://cr.openjdk.java.net/%7Evlivanov/8058892

Re: [9] RFR (S): 8058892: FILL_ARRAYS and ARRAYS are eagely initialized in MethodHandleImpl

. 82395900.795 (+-2794747.540) I don't see a noticeable difference (there's a lot of jitter - didn't turn off tiered compilation). Regards, Peter On Thu, Oct 2, 2014 at 3:12 PM, Peter Levart peter.lev...@gmail.com mailto:peter.lev...@gmail.com wrote: Well, if I add the following

Re: [9] RFR (L): 8057042: LambdaFormEditor: derive new LFs from a base LF

On 09/03/2014 03:25 PM, Vladimir Ivanov wrote: Peter, Thanks for the feedback. In LambdaFormEditor, where Transform[] is promoted into ConcurrentHashMapTransform, Transform: 339 ConcurrentHashMapTransform, Transform m = new ConcurrentHashMap(MAX_CACHE_ARRAY_SIZE * 2);

Re: [9] RFR (L): 8057042: LambdaFormEditor: derive new LFs from a base LF

[1] https://bugs.openjdk.java.net/browse/JDK-8057020 On 9/3/14, 3:43 PM, Peter Levart wrote: Hi Vladimir, I'm sure you and John have thought about it through, but I'll ask anyway. Are cached LambdaForms going to stay around forever? What about using a WeakReferenceLambdaForm

Re: [9] RFR (L): 8057042: LambdaFormEditor: derive new LFs from a base LF

On 09/02/2014 03:59 PM, Vladimir Ivanov wrote: Webrev: http://cr.openjdk.java.net/~vlivanov/8057042/webrev.00 Best regards, Vladimir Ivanov Hi Vladimir, In LambdaFormEditor, where Transform[] is promoted into ConcurrentHashMapTransform, Transform: 339

Re: [9] RFR (L): 8057042: LambdaFormEditor: derive new LFs from a base LF

Hi Vladimir, I'm sure you and John have thought about it through, but I'll ask anyway. Are cached LambdaForms going to stay around forever? What about using a WeakReferenceLambdaForm (LambdaFormEditor.Transform could extend WeakReference). This way unused LambdaForms would get GCed.

Re: RFR: 8000975: (process) Merge UNIXProcess.java.bsd UNIXProcess.java.linux ( .solaris .aix)

/system class loader when initializing the LambdaForm class, but then i got distracted with other stuff and forgot about it.) Your one-liner fix seems to do the trick, but I think we need Vladimir to confirm this is OK. Paul. On Apr 17, 2014, at 11:49 PM, Peter Levart peter.lev...@gmail.com wrote

Re: RFR: 8000975: (process) Merge UNIXProcess.java.bsd UNIXProcess.java.linux ( .solaris .aix)

into an environment where it's the only invocation of the process api. On Thu, Apr 17, 2014 at 8:33 AM, Peter Levart peter.lev...@gmail.com mailto:peter.lev...@gmail.com wrote: Hi Martin, Since you are the author of the test/java/lang/ProcessBuilder/SecurityManagerClinit.java test

Re: [9] RFR (S): 8036117: MethodHandles.catchException doesn't handle VarargsCollector right (8034120 failed)

Regards, Peter There's not much value in it in this particular case, but I decided to reduce possible noise. Best regards, Vladimir Ivanov On 3/11/14 3:35 PM, Peter Levart wrote: Hi, Excuse my ignorant question: What is the purpose of @LambdaForm.Hidden annotation? I suspect it has to do

Re: [9] RFR (S): 8036117: MethodHandles.catchException doesn't handle VarargsCollector right (8034120 failed)

Hi, Excuse my ignorant question: What is the purpose of @LambdaForm.Hidden annotation? I suspect it has to do with hiding the call frames in stack traces that are part of LambdaForm invocation chain. In this case, method: private static Object[] prepend(Object elem, Object[] array)

Re: [9] RFR (S): 8036117: MethodHandles.catchException doesn't handle VarargsCollector right (8034120 failed)

to be thrown from the invocation of the MH... Regards, Peter Best regards, Vladimir Ivanov Regards, Peter There's not much value in it in this particular case, but I decided to reduce possible noise. Best regards, Vladimir Ivanov On 3/11/14 3:35 PM, Peter Levart wrote: Hi, Excuse my

MethodHandleInfo.getDeclaringClass()

Hi, The following code: public class Test { static class X { public void x() { } } static class Y extends X { } public static void main(String[] args) throws Exception { MethodHandles.Lookup lookup = MethodHandles.lookup(); MethodHandle mh =

Re: Signature of MethodHandleInfo.reflectAs is not specific enough

On 11/11/2013 08:14 AM, Peter Levart wrote: The method could simply be: public T extends Member T reflect(Lookup lookup); But if one needs to hint the compiler, explicit type parameters can be used as an escape hatch as always: Object o = info.Methodreflect(lookup); Well, well

Re: Signature of MethodHandleInfo.reflectAs is not specific enough

On 11/11/2013 02:24 AM, Ali Ebrahimi wrote: This is another workaround: public T extends MemberAnnotatedElement, R R reflectAs(Class? super T expected, Lookup lookup); info.reflectAs(Member.class, lookup);//works info.reflectAs(AnnotatedElement.class, lookup);//works

Re: Classes on the stack trace

, needed for implementation of MethodHandles. Regards, Peter Nick On Jul 31, 2013, at 2:36 AM, Peter Levart wrote: Hi Nick, The @CallerSensitive annotation is an annotation that prevents some other infrastructure, namely the MethodHandles, to spoof caller classes. Try

Re: Classes on the stack trace

@CallerSensitive (except for enforcing that frame 1 is @CallerSensitive, which really isn't necessary if you aren't using it in further frames). Thoughts? Nick On Jul 30, 2013, at 10:33 AM, Jochen Theodorou wrote: Am 30.07.2013 16:16, schrieb Peter Levart: On 07/30/2013 03:19 PM, Jochen Theodorou

Re: Classes on the stack trace (was: getElementClass/StackTraceElement, was: @CallerSensitive public API, was: sun.reflect.Reflection.getCallerClass)

On 07/27/2013 09:01 PM, Nick Williams wrote: All, In the last two months, there have been a number of discussions surrounding stack traces, Classes on the stack trace, and caller classes [1], [2], [3]. These are all related discussions and the solution to them is equally related, so I

Re: Classes on the stack trace (was: getElementClass/StackTraceElement, was: @CallerSensitive public API, was: sun.reflect.Reflection.getCallerClass)

must use reflection (sudo code: If Java 8, use new public caller-sensitive API), so it needs code that it can pass a number into. Nick On Jul 30, 2013, at 7:17 AM, Peter Levart wrote: On 07/27/2013 09:01 PM, Nick Williams wrote: All, In the last two months, there have been a number

Re: Classes on the stack trace (was: getElementClass/StackTraceElement, was: @CallerSensitive public API, was: sun.reflect.Reflection.getCallerClass)

On 07/30/2013 03:19 PM, Jochen Theodorou wrote: Am 30.07.2013 14:17, schrieb Peter Levart: [...] So what would give Groovy or other language runtimes headaches when all there was was a parameter-less getCallerClass() API? Aren't the intermediate frames inserted by those runtimes controlled

Re: Classes on the stack trace (was: getElementClass/StackTraceElement, was: @CallerSensitive public API, was: sun.reflect.Reflection.getCallerClass)

On 07/30/2013 06:46 PM, MacGregor, Duncan (GE Energy Management) wrote: I can understand the worry about exposing @CallerSensitive methods, at least for the case of lookup.in() as I'm sure it could be used to open an exciting can of worms, but the current limitation doesn't feel quite right. I

Re: method handle cracking API

Hi John, I peeked at the implementation of HMI.asMember method: 111 +// Helper for default MethodHandleInfo.asMember. 112 +static Member reflectMember(MethodHandleInfo self) throws ReflectiveOperationException { 113 +int mods = self.getModifiers();

Re: some thoughts on ClassValue

On 04/27/2013 11:54 PM, John Rose wrote: On Apr 27, 2013, at 2:34 PM, Jochen Theodorou blackd...@gmx.org mailto:blackd...@gmx.org wrote: Am 27.04.2013 23:26, schrieb John Rose: ... Each instance of the Groovy runtime will use a distinct ClassValue instance. If the ClassValue instance goes

Re: some thoughts on ClassValue

On 04/28/2013 12:31 AM, Peter Levart wrote: On 04/27/2013 11:54 PM, John Rose wrote: On Apr 27, 2013, at 2:34 PM, Jochen Theodorou blackd...@gmx.org mailto:blackd...@gmx.org wrote: Am 27.04.2013 23:26, schrieb John Rose: ... Each instance of the Groovy runtime will use a distinct

Re: some thoughts on ClassValue

On 04/26/2013 09:59 AM, Jochen Theodorou wrote: Hi all, basically ClassValue is there so that my runtime/framework or whatever can store information and bind it to a class. The information is then available as long as the class exists. In Groovy3 I am going to use this for meta classes.

Re: another question about megamorphic call sites in combination with MethodHandles

On 03/22/2013 11:50 AM, Remi Forax wrote: On 03/22/2013 11:12 AM, Jochen Theodorou wrote: Am 22.03.2013 10:35, schrieb Remi Forax: On 03/22/2013 10:24 AM, Jochen Theodorou wrote: Am 22.03.2013 10:11, schrieb Remi Forax: [...] I don't think it's a good idea to expose directly method handles