Re: [9] RFR (S): 7177745: JSR292: Many Callsite relinkages cause target method to always run in interpreter mode

I was going to say it is unlikely to matter in production cases but might well hit test code which does extensive meta-programming, but actually, since it¹s a question of invalidations across _all_ sites, rather than any single one I think it might make a difference. I¹ll need to take a look at

Re: Getting back into indy...need a better argument collector!

On 11/01/2016, 11:27, "mlvm-dev on behalf of MacGregor, Duncan (GE Energy Management)" <mlvm-dev-boun...@openjdk.java.net on behalf of duncan.macgre...@ge.com> wrote: >On 11/01/2016, 03:16, "mlvm-dev on behalf of Charles Oliver Nutter" ><mlvm-dev-boun...

Re: Getting back into indy...need a better argument collector!

On 11/01/2016, 03:16, "mlvm-dev on behalf of Charles Oliver Nutter" wrote: ... >With asCollector: 16-17s per iteration > >With hand-written array construction: 7-8s per iteration > >A sampling profile only shows my Ruby code as

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

Re: ClassValue perf?

On 25/04/2015 13:44, Remi Forax fo...@univ-mlv.fr wrote: On 04/24/2015 11:17 PM, John Rose wrote: On Apr 24, 2015, at 5:38 AM, Charles Oliver Nutter head...@headius.com wrote: Hey folks! I'm wondering how the performance of ClassValue looks on recent OpenJDK 7 and 8 builds. JRuby 9000 will be

Re: Implementing VarHandle

On 12/04/2015 15:54, Remi Forax fo...@univ-mlv.fr wrote: Hi guys, I was about to write a blog post explaining why i don't like the way VarHandle are currently implemented when it occurs to me that providing another implementation may be a more efficient to discuss about implementation. So my

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

Now I¹m back from my Easter break I¹ve run done some testing with our code. Hs-comp is looking good in general, and this code does appear to give a nice little extra boost. My results are showing a difference at peak performance, which I found slightly surprising so I¹ll need to take a look at

Re: A simple PIC api

We did have optional instrumentation to maintain the PIC counts, and used that to guide our choice of ordering, but we didn¹t use it on a per PIC level to do anything at run time, it was just a case of gathering a lot of data and printing out the stats. It did add some overhead, but I think Vlad¹s

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

MH.spreadArguments would certainly be useful from my point of view. We have many cases where we need to take a trailing argument array and turn it into some arguments, and array contain the remainder. This involves a depressing amount of shuffling at the moment, and should be better. On

Re: [9] RFR (M): 8063137: Never-taken branches should be pruned when GWT LambdaForms are shared

This version seems to have inconsistent removal of ignore profile in the hotspot patch. It’s no longer added to vmSymbols but is still referenced in classFileParser. On 19/01/2015 20:21, MacGregor, Duncan (GE Energy Management) duncan.macgre...@ge.com wrote: Okay, I¹ve done some tests

Re: [9] RFR (M): 8063137: Never-taken branches should be pruned when GWT LambdaForms are shared

/8068915/webrev.00 On 1/19/15 11:21 PM, MacGregor, Duncan (GE Energy Management) wrote: Okay, I¹ve done some tests of this with the micro benchmarks for our language runtime which show pretty much no change except for one test which is now almost 3x slower. It uses nested loops to iterate over

Re: [9] RFR (M): 8063137: Never-taken branches should be pruned when GWT LambdaForms are shared

not too unhappy. :-) On 20/01/2015 17:14, MacGregor, Duncan (GE Energy Management) duncan.macgre...@ge.com wrote: Hmm, 8068915 hasn’t fixed it, but running fewer benchmarks seems to make the problem go away, so it looks like there’s something going wrong fairly deep in our runtime. Trying the full

Re: [9] RFR (M): 8063137: Never-taken branches should be pruned when GWT LambdaForms are shared

Okay, I¹ve done some tests of this with the micro benchmarks for our language runtime which show pretty much no change except for one test which is now almost 3x slower. It uses nested loops to iterate over an array and concatenate the string-like objects it contains, and replaces elements with

That was the year that was.

Since it's now the new year I thought it was a good opportunity to look back on progress we've made in Magik on Java over the course of the last twelve months. In my JVMLS talk I mentioned LF memory usage and startup time as areas of concern, as did Marcus and others. Over the last couple of

Re: [9, 8u40] RFR (XXS): 8059880: Get rid of LambdaForm interpretation

On 18/11/2014 23:33, Aleksey Shipilev aleksey.shipi...@oracle.com wrote: On 11/19/2014 12:01 AM, Vladimir Ivanov wrote: http://cr.openjdk.java.net/~vlivanov/8059880/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8059880 Yes, for the love of God, GO FOR IT. Seconded. Startup of our stuff

Re: MemberName$Factory.resolve() and the Eclipse debugger.

https://bugs.eclipse.org/bugs/show_bug.cgi?id=449791 On 18/11/2014 14:06, Marcus Lagergren marcus.lagerg...@oracle.com wrote: Nicely done, Duncan. Do you have a link to the issue report? Regards Marcus On 03 Nov 2014, at 16:48, MacGregor, Duncan (GE Energy Management) duncan.macgre...@ge.com

Re: MemberName$Factory.resolve() and the Eclipse debugger.

, at 8:36 AM, MacGregor, Duncan (GE Energy Management) duncan.macgre...@ge.com wrote: Okay, I now know why the JVM is stuck for so long, just not why Eclipse is doing what it does. At certain points during the loading of our application Eclipse will make a large number (upto 1) jdwp

Re: MemberName$Factory.resolve() and the Eclipse debugger.

Okay, I now know why the JVM is stuck for so long, just not why Eclipse is doing what it does. At certain points during the loading of our application Eclipse will make a large number (upto 1) jdwp classesForSignature requests, each of which causes the jdwp lib to trawl over a large number of

MemberName$Factory.resolve() and the Eclipse debugger.

When we’ve tried to debug some of our Java core in the context of running a large application we’ve been seeing long pauses (sometime very long pauses of over a minute) due to java.lang.invoke.MemberName$Factory.resolve() apparently taking ages to complete. Testing with an openjdk build I see

Re: MemberName$Factory.resolve() and the Eclipse debugger.

On 29/10/2014 16:55, Christian Thalinger christian.thalin...@oracle.com wrote: On Oct 29, 2014, at 9:39 AM, MacGregor, Duncan (GE Energy Management) duncan.macgre...@ge.com wrote: When we¹ve tried to debug some of our Java core in the context of running a large application we¹ve been seeing

Re: MemberName$Factory.resolve() and the Eclipse debugger.

On 29/10/2014 17:13, Christian Thalinger christian.thalin...@oracle.com wrote: On Oct 29, 2014, at 10:06 AM, MacGregor, Duncan (GE Energy Management) duncan.macgre...@ge.com wrote: On 29/10/2014 16:55, Christian Thalinger christian.thalin...@oracle.com wrote: On Oct 29, 2014, at 9:39 AM

Re: How high are he memory costs of polymorphic inline caches?

The memory costs are highly dependent on what combinators are being used and and how many entries are in the cache, and whether you¹re caching and reusing any adaption needed to the base method handles. It¹s also going to change quite radically for the better in 8y40 when various patches have

Re: [9] RFR (M): 8050057: Improve caching of MethodHandle reinvokers

I may be slightly confused as to the order in which these patches are expected to be applied merged but there seems to be some considerable interaction. Which patch set is meant to remove the final attribute from BoundMethodHandle.internalProperties()? I can¹t find it in any of the ones you¹ve

Re: [9] RFR (M): 8050057: Improve caching of MethodHandle reinvokers

Scratch that, found it. http://cr.openjdk.java.net/~vlivanov/8050052/webrev.00 + http://cr.openjdk.java.net/~vlivanov/8050052/prepared_forms/ != http://cr.openjdk.java.net/~vlivanov/8050052//webrev.01/ Duncan. On 15/07/2014 10:58, MacGregor, Duncan (GE Energy Management) duncan.macgre...@ge.com

Re: Object arrays with no referrers.

commitments I doubt we¹ll be able to offer help in the development, but we can offer help in testing and should be able to provide sample heap dumps for analysis. On 22/05/2014 17:51, MacGregor, Duncan (GE Energy Management) duncan.macgre...@ge.com wrote: I¹ve been doing some work towards reducing

Object arrays with no referrers.

I’ve been doing some work towards reducing the memory footprint of our applications under Java 8 and while picking through heap dumps have come across a large number of java.lang.Object[] instances that have no referrers but are not getting collected. I assume these are something to do with

Re: sun.reflect.Reflection.getCallerClass(int) is going to be removed... how to replace?

On 11/07/2013 05:09, Charles Oliver Nutter head...@headius.com wrote: On Wed, Jul 10, 2013 at 4:40 AM, Noctarius m...@noctarius.com wrote: Maybe a solution could be an annotation to mark calls to not appear in any stacktrace? Personally, I'd love to see *any* way to teach JVM about

Re: speed of invokeExact

Which version of the jvm are you seeing this problem on, and are you adapting the method handle every time as well as exact invoking it? We avoided invoke and invokeExact calls from Java (because they were sometimes painful to get correct in the case of varargs methods) by having the fallbacks

Re: method handle cracking API

I would have thought one of the most common uses of breaking down a method handle like this would be to immediately turn it into a java.lang.reflect object and maybe examine annotations or exception information. So although I don't think it should extend Member I do think it should have a standard

Re: JVM Summit Wrokshop/talk request

On 08/04/2013 23:01, Remi Forax fo...@univ-mlv.fr wrote: yes, I'm in it too, and we have to discuss about how to improve the startup time too, the implementation in 8 is so slow to ramp up that for my current project the implementation of 7 is 30 to 50% faster (the whole script run less than 10s).

Re: JVM Summit Wrokshop/talk request

I would certainly be interested, though travel budgets do seem to be tight this year. We could probably host it here in Cambridge if you guys want to come over to the UK. On 09/04/2013 08:19, Julien Ponge julien.po...@gmail.com wrote: Just an idea: would some of you be interested in having a

Re: Looking for comments on paper draft DynaMate: Simplified and optimized invokedynamic dispatch

I'd certainly be interested in having a read of it. On 19/02/2013 13:37, Eric Bodden eric.bod...@ec-spride.de wrote: Hi all. Kamil Erhard, a student of mine, and myself have prepared a paper draft on a novel framework for invokedynamic dispatch that we call DynaMate. The framework is meant to

Performance under jdk8

Okay, I've been able to test our stuff (both micro-benchmarks and a full application) under jdk8, and the performance Is looking good in both cases, though still slower than 7 on initial bootstrap. What is still concerning is memory usage which has increased significantly with Lambda forms due

Re: hotspot-comp OS X builds

Can I just check whether all this stuff has made it into the 7u12 or 8 snapshot releases, and if not when it will? Alternatively I can do a Windows build myself from source if its all made it into the public repos. On 24/01/2013 22:47, John Rose john.r.r...@oracle.com wrote: Thanks, Charlie!

Re: java.lang.invoke vs java.lang.reflect, redundancy and security

The two APIs are different in that security checks are performed when looking up method handles but not when calling them, while security checks are performed at every invocation of a reflected method or field. I'm sure some security infrastructure can be shared by the two APIs, but I'm not sure

Re: Converting MethodHandle into reflective Method instance

There is no public API for such introspection, and I think there's strong desire not to introduce one (though a private one is used in the Java 8 lambda factory). However even if there is one I don't think it would solve your problem. The call site created by a bootstrap method will normally

Re: Converting MethodHandle into reflective Method instance

On 11/01/2013 14:16, Eric Bodden eric.bod...@ec-spride.de wrote: Thanks Duncan, for the fast response. To clarify, when you say... The call site created by a bootstrap method will normally change its own target during execution into a a guardWithTest chain which would dispatch to several

Re: Multi-value return?

Well, our language is very much at the dynamic end of things, so functions can return an object or tuple of objects and the caller may want an object or a tuple. When we create a call site we install a result filter that checks the required and returned types and (un)packs as necessary. Obviously

Re: Java 7 update 12 issue with MethodHandles.catchException.

have actually been flushed. On 20/12/2012 19:27, Christian Thalinger christian.thalin...@oracle.com wrote: On Dec 13, 2012, at 7:55 AM, MacGregor, Duncan (GE Energy Management) duncan.macgre...@ge.com wrote: Thanks. Meanwhile I've patched the two offending parts of the database library to work

Re: again on megamorphic problems

I've been thinking about this due to the extensive mixin hierarchy in our runtime presenting some potential problems with the number of types being seen by some areas of code in some applications. It's going to be hard to magic this problem away at the JVM level due to the restrictions stated in

Re: again on megamorphic problems

On 21/12/2012 11:42, Jochen Theodorou blackd...@gmx.org wrote: Am 21.12.2012 12:28, schrieb MacGregor, Duncan (GE Energy Management): For example, Charles, how do you handle the creation of literals / constants when building specialised methods? Are the literals instantiated by two specialised

Java 7 update 12 issue with MethodHandles.catchException.

Finally got time to try running our full application under 7u12 and I've hit a problem with our database library. In two cases where we are combining method handles to catch exceptions from a library method, process those exceptions to fill in our own error information and then fallback to the

Re: Java 7 update 12 issue with MethodHandles.catchException.

I do see the failure with 8 as well. On 12/12/2012 17:31, Christian Thalinger christian.thalin...@oracle.com wrote: Do you see the same failure with 8 (to rule out differences between 7u12 and 8)? -- Chris On Dec 12, 2012, at 7:12 AM, MacGregor, Duncan (GE Energy Management) duncan.macgre

Re: Instrumenting call sites.

-dev@openjdk.java.netmailto:mlvm-dev@openjdk.java.net Date: Friday, 30 November 2012 02:26 To: Da Vinci Machine Project mlvm-dev@openjdk.java.netmailto:mlvm-dev@openjdk.java.net Subject: Re: Instrumenting call sites. On Nov 29, 2012, at 11:15 AM, MacGregor, Duncan (GE Energy Management) wrote: 1

Re: Instrumenting call sites.

On 29/11/2012 19:34, Aleksey Shipilev aleksey.shipi...@oracle.com wrote: Probably unrelated, but can't you do the same thing by dumping the type profile from HotSpot? -XX:+TraceTypeProfile (I think it requires debug build at this point, but 7u12 onwards should have that available in production