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
wha
On 11/01/2016, 11:27, "mlvm-dev on behalf of MacGregor, Duncan (GE Energy
Management)" wrote:
>On 11/01/2016, 03:16, "mlvm-dev on behalf of Charles Oliver Nutter"
>
>wrote:
>...
>>With asCollector: 16-17s per iteration
>>
>>With hand-written arra
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 the top items, and an
>allocation trace shows Object[] as the number o
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
On 25/04/2015 13:44, "Remi Forax" wrote:
>On 04/24/2015 11:17 PM, John Rose wrote:
>> On Apr 24, 2015, at 5:38 AM, Charles Oliver Nutter
>> wrote:
>>> Hey folks!
>>>
>>> I'm wondering how the performance of ClassValue looks on recent
>>> OpenJDK 7 and 8 builds. JRuby 9000 will be Java 7+ only, so
On 12/04/2015 15:54, "Remi Forax" 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 implementatio
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 just
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
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 26/02/2015
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)"
wrote:
>Okay, I¹ve done some tests of this w
not too unhappy. :-)
On 20/01/2015 17:14, "MacGregor, Duncan (GE Energy Management)"
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
>
>[1] http://cr.openjdk.java.net/~vlivanov/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
on_log tag.
>
>Thanks again for the valuable feedback!
>
>Best regards,
>Vladimir Ivanov
>
>[1] http://cr.openjdk.java.net/~vlivanov/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 mi
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 t
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 mon
On 18/11/2014 23:33, "Aleksey Shipilev"
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 seems fine now with
https://bugs.eclipse.org/bugs/show_bug.cgi?id=449791
On 18/11/2014 14:06, "Marcus Lagergren"
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)
>> w
at 8:36 AM, MacGregor, Duncan (GE Energy Management)
>> 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
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
On 29/10/2014 17:13, "Christian Thalinger"
wrote:
>
>> On Oct 29, 2014, at 10:06 AM, MacGregor, Duncan (GE Energy Management)
>> wrote:
>>
>> On 29/10/2014 16:55, "Christian Thalinger"
>> wrote:
>>>
>>>> On Oct
On 29/10/2014 16:55, "Christian Thalinger"
wrote:
>
>> On Oct 29, 2014, at 9:39 AM, MacGregor, Duncan (GE Energy Management)
>> wrote:
>>
>> When we¹ve tried to debug some of our Java core in the context of
>>running a large application we¹ve been seei
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 th
I really should be posting some stuff to the startup thread, but I need some
time to read over it (especially John’s post) carefully first. However since
this list is being active again…
I had a cunning idea that we had almost enough information present on our
method objects to do proper class
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
lande
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)"
wrote:
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 s
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)"
wrote:
>I¹ve been doing some work towards reduci
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 sta
I’ve just checked Magik on Java’s implementation and we only use one ClassValue
(to connect our method table objects with their corresponding classes) so a
reduction in the initial map size would definitely be a good for us.
From: Christian Thalinger
mailto:christian.thalin...@oracle.com>>
Repl
I've been trying our app/language runtime on 7u40 and we're seeing a
similar increase needed in PermGen, and some increase needed to heap
memory. Seem to have taken about a 10% performance hit on large
application benchmarks as well, but I'd need to do some more runs to be
really sure of that.
On
On 30/07/2013 16:58, "Charles Oliver Nutter" wrote:
>On Tue, Jul 30, 2013 at 7:17 AM, Peter Levart
>wrote:
>>Now that is the question for mlvm-dev mailing list: Isn't preventing
>>almost
>> all Lookup objects obtained by Lookup.in(RequestedLookupClass.class)
>>from
>> obtaining MHs of @CallerS
On 11/07/2013 05:09, "Charles Oliver Nutter" wrote:
>On Wed, Jul 10, 2013 at 4:40 AM, Noctarius 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
>language-specific stack traces. Currentl
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 ret
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
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" wrote:
>Just an idea: would some of you be interested in having a meeting at some
>point
On 08/04/2013 23:01, "Remi Forax" 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).
Yeah, th
Maybe I'm misunderstanding your question, but whether
mh.invokeWithArguments(args) internally generates a mono, poly, or
megamorphic call site internally in the JVM is going to depend on the
implementation and just how many subclasses of MethodHandle there are.
If you're concerned about the implem
I'd certainly be interested in having a read of it.
On 19/02/2013 13:37, "Eric Bodden" 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 aid language develo
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
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" wrote:
>Thanks, Charlie!
>
>Yes, feedback makes
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 ho
On 11/01/2013 14:16, "Eric Bodden" 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 targets, and w
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
change
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 t
On 21/12/2012 11:42, "Jochen Theodorou" 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
>>ins
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
th
te when zombies have actually been flushed.
On 20/12/2012 19:27, "Christian Thalinger"
wrote:
>
>On Dec 13, 2012, at 7:55 AM, "MacGregor, Duncan (GE Energy Management)"
> wrote:
>
>> Thanks. Meanwhile I've patched the two offending parts of the
Thanks. Meanwhile I've patched the two offending parts of the database library
to work round the problem. Although our benchmarks run quite nicely on 7u12 and
8 (give or take a couple of slowdowns) full applications really aren't
performing well right now.
Startup time on 7u12 has increased by
I do see the failure with 8 as well.
On 12/12/2012 17:31, "Christian Thalinger"
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)"
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 p
mailto:mlvm-dev@openjdk.java.net>>
Date: Friday, 30 November 2012 02:26
To: Da Vinci Machine Project
mailto: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. What is the recommended maximum tr
On 29/11/2012 19:34, "Aleksey Shipilev"
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 builds).
It might well w
I've been doing a little project in my spare time to instrument our call sites
and check the number of receivers being seen by each site in a running system.
As expected most sites only see one or two classes and so go through the fast
path. There are however some sites which see slightly more r
53 matches
Mail list logo
