Re: ClassValue perf?

> On May 6, 2016, at 4:48 AM, Michael Haupt wrote: > > Hi Peter, > > thank you. I've run the full benchmark in my setup and uploaded the updated > cumulative results to http://cr.openjdk.java.net/~mhaupt/8031043/ > . > >

Re: JFokus VM Tech Day 2016

> On Nov 11, 2015, at 3:37 PM, John Rose wrote: > > On Nov 11, 2015, at 12:35 AM, Marcus Lagergren > wrote: >> >> bare silicone magic > > That extra E moves the venue from Santa Clara to Las Vegas. LOL! Too good.

Re: ClassValue perf?

On Apr 24, 2015, at 2:17 PM, John Rose john.r.r...@oracle.com 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 Java 7+ only, so

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 head...@headius.com wrote: This could explain performance regressions we've seen on the

Re: Invokedynamic and recursive method call

On Jan 29, 2015, at 4:48 PM, John Rose john.r.r...@oracle.com wrote: On Jan 7, 2015, at 8:13 AM, Remi Forax fo...@univ-mlv.fr mailto:fo...@univ-mlv.fr wrote: But if fibo is called through an invokedynamic, instead of emitting a direct call to fibo, the JIT generates a code that push

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

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 long pauses (sometime very long pauses of over a minute) due to

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

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, MacGregor, Duncan (GE Energy Management) duncan.macgre...@ge.com wrote

Re: Loopy CallSite

On Jul 16, 2014, at 11:40 AM, Remi Forax fo...@univ-mlv.fr wrote: On 07/16/2014 07:38 PM, Vladimir Ivanov wrote: Remi, The problem is that for every iteration you create new call site for(int i=0; i100_000; i++) { new LoopyCS().getTarget().invokeExact(1_000); }

Re: FORK

On Apr 23, 2014, at 9:44 PM, Charles Oliver Nutter head...@headius.com wrote: What would it take to make Hotspot forkable? Obviously we'd need to pause all VM threads and restarting them on the other side (or perhaps a prefork mode that doesn't spin up threads?) but I know there's challenges

Re: RFR (L) 8037210: Get rid of char-based descriptions 'J' of basic types

On Apr 3, 2014, at 9:44 PM, John Rose john.r.r...@oracle.com wrote: On Apr 3, 2014, at 6:33 PM, Christian Thalinger christian.thalin...@oracle.com wrote: Of course they are popular because these are the type names. There is no type L; it’s an object. I don’t understand why we have

Re: RFR (L) 8037210: Get rid of char-based descriptions 'J' of basic types

regards, Vladimir Ivanov On 3/26/14 12:24 AM, Christian Thalinger wrote: + enum BasicType { + L_TYPE('L', Object.class, Wrapper.OBJECT), // all reference types + I_TYPE('I', int.class,Wrapper.INT), + J_TYPE('J', long.class, Wrapper.LONG), + F_TYPE('F

Re: RFR(S) : 8038186 : [TESTBUG] improvements of test j.l.i.MethodHandles

On Mar 24, 2014, at 1:33 PM, Igor Ignatyev igor.ignat...@oracle.com wrote: Hi all, Please review the patch: Problems: - MethodHandlesTest::testCatchException() doesn't provide enough testing of j.l.i.MethodHandles::catchException(). - MethodHandlesTest contains more than 3k lines, an

Re: RFR (L) 8037210: Get rid of char-based descriptions 'J' of basic types

On Mar 14, 2014, at 4:28 AM, Vladimir Ivanov vladimir.x.iva...@oracle.com wrote: http://cr.openjdk.java.net/~vlivanov/8037210/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8037210 953 lines changed: 425 ins; 217 del; 311 mod This is a massive cleanup of JSR292 code to replace

Re: RFR (L) 8037210: Get rid of char-based descriptions 'J' of basic types

On Mar 18, 2014, at 2:35 PM, John Rose john.r.r...@oracle.com wrote: On Mar 18, 2014, at 1:36 PM, Christian Thalinger christian.thalin...@oracle.com wrote: Why are we not using an Enum instead of an untyped byte? Byte is moderately typed, in the sense (which I rely on during development

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

, Vladimir Ivanov On 3/8/14 4:51 AM, Christian Thalinger wrote: Seems good to me. I’d like to have another name for this method: + private static Object invokeCustom(MethodHandle target, Object... args) throws Throwable { On Mar 4, 2014, at 12:00 PM, Vladimir Ivanov vladimir.x.iva

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

Seems good to me. I’d like to have another name for this method: + private static Object invokeCustom(MethodHandle target, Object... args) throws Throwable { On Mar 4, 2014, at 12:00 PM, Vladimir Ivanov vladimir.x.iva...@oracle.com wrote:

Re: [9] RFR (M): 8027827: Improve performance of catchException combinator

On Feb 20, 2014, at 9:57 AM, Vladimir Ivanov vladimir.x.iva...@oracle.com wrote: Paul, Thanks for the feedback! See my answers inline. Updated webrev: http://cr.openjdk.java.net/~vlivanov/8027827/final/webrev.01/ I finally figured out how to make caching work. This webrev contains

Re: Groovy bugs on JIRA

Thanks for the information. I agree that it is annoying that people without an OpenJDK username cannot log into JBS and add comments. I hope this will change some day. Maybe this is a missing backport of a fix in 8. Will start to dig... On Feb 7, 2014, at 6:01 AM, Cédric Champeau

Re: [8] RFR (S): 8033278: Missed access checks for Lookup.unreflect* after 8032585

Looks good. On Jan 30, 2014, at 4:58 PM, Vladimir Ivanov vladimir.x.iva...@oracle.com wrote: http://cr.openjdk.java.net/~vlivanov/8033278/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8033278 The fix for 8032585 [1] introduced a regression: in some cases access check on a reference

Re: [JDK8] RFR (XS): JSR292: IncompatibleClassChangeError in LambdaForm for CharSequence.toString() method handle type converter

[I’m resending something I sent earlier today to Vladimir directly.] On Jan 15, 2014, at 7:31 AM, Vladimir Ivanov vladimir.x.iva...@oracle.com wrote: http://cr.openjdk.java.net/~vlivanov/8031502/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8031502 InvokeBytecodeGenerator can produce

Re: [JDK8] RFR (XS): JSR292: IncompatibleClassChangeError in LambdaForm for CharSequence.toString() method handle type converter

On Jan 15, 2014, at 11:41 AM, Vladimir Ivanov vladimir.x.iva...@oracle.com wrote: Chris, Thanks for looking into this. See my answers inline. Best regards, Vladimir Ivanov On 1/15/14 9:51 PM, Christian Thalinger wrote: [I’m resending something I sent earlier today to Vladimir

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

On Jan 9, 2014, at 2:46 AM, Jochen Theodorou blackd...@gmx.org wrote: Am 08.01.2014 21:45, schrieb Christian Thalinger: [...] If we’d go with an initial value of 1 would it be a performance problem for you if it grows automatically? that means the map will have to grow for hundreds

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

would definitely be a good for us. Thanks! From: Christian Thalinger christian.thalin...@oracle.commailto:christian.thalin...@oracle.com Reply-To: Da Vinci Machine Project mlvm-dev@openjdk.java.netmailto:mlvm-dev@openjdk.java.net Date: Tuesday, 7 January 2014 22:54 To: Da Vinci Machine

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

On Jan 8, 2014, at 12:21 AM, Remi Forax fo...@univ-mlv.fr wrote: On 01/07/2014 11:54 PM, Christian Thalinger wrote: Can I get some comments on this bug from people who are using ClassValue? [#JDK-8031043] ClassValue's backing map should have a smaller initial size - Java Bug System https

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

On Jan 8, 2014, at 6:43 AM, Jochen Theodorou blackd...@gmx.org wrote: Am 07.01.2014 23:54, schrieb Christian Thalinger: Can I get some comments on this bug from people who are using ClassValue? [#JDK-8031043] ClassValue's backing map should have a smaller initial size - Java Bug System

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

Can I get some comments on this bug from people who are using ClassValue? [#JDK-8031043] ClassValue's backing map should have a smaller initial size - Java Bug System Is my assumption correct that most language runtimes only attach a small number of values (maybe only one) or that it wouldn’t

Re: Changes to method handles between jdk8 b103 and 114? more data

On Dec 11, 2013, at 12:17 AM, Mark Roos mr...@roos.com wrote: So I updated to b119 and changed some callsite signatures from using Object[] to Object... // public static RtCallSite bootStrapSelf(MethodHandles.Lookup callerLookup, String name, MethodType type, Object[] arg) {

Re: RFR (M) 8001110: method handles should have a collectArguments transform, generalizing asCollector

src/share/classes/java/lang/invoke/MethodHandles.java: You have renamed coll to filter but the documentation still references coll in multiple places, e.g.: + * If the filter method handle {@code coll} consumes one argument and produces + * a non-void result, then {@code

Re: RFR (M) 8024438: JSR 292 API specification maintenance for JDK 8

On Oct 2, 2013, at 2:31 PM, John Rose john.r.r...@oracle.com wrote: On Oct 2, 2013, at 12:14 PM, Christian Thalinger christian.thalin...@oracle.com wrote: src/share/classes/java/lang/invoke/MethodHandles.java: + * tha name=equiv/alookup expression/th Apparently the name

Re: RFR (S) 8024599: JSR 292 direct method handles need to respect initialization rules for static members

Looks good. On Oct 2, 2013, at 12:33 PM, John Rose john.r.r...@oracle.com wrote: Push-button webrev generator to the rescue: http://cr.openjdk.java.net/~jrose/8024599/webrev.01 — John On Oct 2, 2013, at 11:23 AM, Christian Thalinger christian.thalin...@oracle.com wrote: Since

Re: RFR (S) 8024599: JSR 292 direct method handles need to respect initialization rules for static members

Since there is no new webrev I assume you incorporated all the stuff below. If that's the case then it looks good. On Sep 20, 2013, at 6:18 PM, John Rose john.r.r...@oracle.com wrote: On Sep 20, 2013, at 8:29 AM, Vladimir Ivanov vladimir.x.iva...@oracle.com wrote: John, I don't see

Re: RFR (S) 8001105: findVirtual of Object[].clone produces internal error

Looks good. On Oct 1, 2013, at 2:29 PM, John Rose john.r.r...@oracle.com wrote: Second call for reviews. I need two official Reviewers for this change. — John P.S. Thanks for your comments Morris; I enhanced the comment: +// The JVM does this hack also. ++ // (See

Re: RFR (M) 8024438: JSR 292 API specification maintenance for JDK 8

src/share/classes/java/lang/invoke/MethodHandles.java: + * tha name=equiv/alookup expression/th Apparently the name attribute is obsolete for a/ in HTML5: http://dev.w3.org/html5/markup/a.html I think they want you to use th id=equiv. + * p style=font-size:smaller; + * a

Re: RFR (S) 8025112: JSR 292 spec updates for security manager and caller sensitivity

Thank you for doing this; it is much clearer now. Looks good. On Oct 1, 2013, at 10:19 PM, John Rose john.r.r...@oracle.com wrote: Chris Thalinger suggested removing the new booleans from the changed getDirectMethod call sites and instead put the intended usage into the method names, e.g.,

Re: RFR (M) 8001110: method handles should have a collectArguments transform, generalizing asCollector

On Sep 20, 2013, at 5:09 PM, John Rose john.r.r...@oracle.com wrote: On Sep 20, 2013, at 3:07 PM, Vladimir Ivanov vladimir.x.iva...@oracle.com wrote: I cleaned javadoc a little [1], so it is more readable in the browser now. Thanks; I applied those edits. I fixed the problem of a

Re: RFR (L) 8024761: JSR 292 improve performance of generic invocation

On Sep 18, 2013, at 6:43 PM, John Rose john.r.r...@oracle.com wrote: On Sep 18, 2013, at 2:11 PM, Christian Thalinger christian.thalin...@oracle.com wrote: src/share/classes/java/lang/invoke/CallSite.java: +if (3 + argv.length MethodType.MAX_MH_ARITY

Re: RFR(S+M) / 8022701 Accessibility checking: InvocationTargetException is thrown instead of IllegalAccessError

necessary to get the error, so it is not only shell-free, it can also be run outside jtreg. On 2013-09-12, at 2:34 PM, Christian Thalinger christian.thalin...@oracle.com wrote: On Sep 12, 2013, at 11:28 AM, David Chase david.r.ch...@oracle.com wrote: New webrev, commented line removed

Re: RFR (S) 8001108: an attempt to use init as a method name should elicit NoSuchMethodException

On Sep 19, 2013, at 2:31 PM, John Rose john.r.r...@oracle.com wrote: On Sep 18, 2013, at 5:05 PM, Christian Thalinger christian.thalin...@oracle.com wrote: src/share/classes/java/lang/invoke/MethodHandles.java: + * methods as if they were normal methods, but the JVM verifier

Re: jdk8 metaspace problem with indy

On Sep 26, 2013, at 7:20 AM, Jochen Theodorou blackd...@gmx.org wrote: Hi all, probably not such a good time to ask, since many of those, that could answer this might be on JavaOne... but still On the user list we got an interesting program that makes quite some problems to the jvm as

Re: JDK7u, hotspot, CC_INTERP, and COBOL

On Sep 25, 2013, at 10:52 AM, Francis ANDRE francis.andre.kampb...@orange.fr wrote: Hi On WXP with VS2010 and the http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/ repository, I successfully build and ran the debug version of hotspot in compiler1 directory. fine Next, I tried to get

Re: Reproducible InternalError in lambda stuff

On Sep 16, 2013, at 2:59 AM, Charles Oliver Nutter head...@headius.com wrote: On Mon, Sep 16, 2013 at 2:36 AM, John Rose john.r.r...@oracle.com wrote: I have refreshed mlvm-dev and pushed some patches to it which may address this problem. I'll get a build put together and see if I can get

Re: RFR (L) 8024761: JSR 292 improve performance of generic invocation

src/share/classes/java/lang/invoke/CallSite.java: +if (3 + argv.length MethodType.MAX_MH_ARITY) +MethodType invocationType = MethodType.genericMethodType(3 + argv.length); +MethodHandle spreader =

Re: RFR (S) 8001108: an attempt to use init as a method name should elicit NoSuchMethodException

src/share/classes/java/lang/invoke/MethodHandles.java: + * methods as if they were normal methods, but the JVM verifier rejects them. I think you should say JVM byte code verifier here. + * em(Note: JVM internal methods named {@code init} not visible to this API, + * even

Re: Interpreting Mission Control numbers for indy

On Sep 18, 2013, at 1:39 AM, Charles Oliver Nutter head...@headius.com wrote: I've been playing with JMC a bit tonight, running a user's application that's about 2x slower using indy than using trivial monomorphic caches (and no indy call sites). I'm trying to understand how to interpret

Re: RFR(S+M) / 8022701 Accessibility checking: InvocationTargetException is thrown instead of IllegalAccessError

+ // err.initCause(ex); Why is this commented? -- Chris On Sep 6, 2013, at 4:59 PM, David Chase david.r.ch...@oracle.com wrote: new, improved webrev: http://cr.openjdk.java.net/~drchase/8022701/webrev.02/ Same small changes to the sources, plus a test. bug: wrong exception was

Re: RFR(S+M) / 8022701 Accessibility checking: InvocationTargetException is thrown instead of IllegalAccessError

exceptions that lead to the defined exception being thrown. The commented line should have just been removed (I think). On 2013-09-12, at 1:24 PM, Christian Thalinger christian.thalin...@oracle.com wrote: + // err.initCause(ex); Why is this commented? -- Chris

Re: RFR (S) 8019417: JSR 292 javadoc should clarify method handle arity limits

On Sep 12, 2013, at 4:34 PM, John Rose john.r.r...@oracle.com wrote: Please review this change for a change to the JSR 292 implementation: http://cr.openjdk.java.net/~jrose/8019417/webrev.00 The change is to javadoc and unit tests, documenting and testing some corner cases of JSR 292

Re: Reproducible InternalError in lambda stuff

On Sep 6, 2013, at 11:11 PM, Charles Oliver Nutter head...@headius.com wrote: I can reproduce this by running a fairly normalish command in JRuby: (Java::JavaLang::InternalError) guard=Lambda(a0:L,a1:L,a2:L,a3:L,a4:L)={

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

On Jul 30, 2013, at 4:11 PM, Nick Williams nicholas+open...@nicholaswilliams.net wrote: Quick question for those of you that know anything about @CallerSensitive... After looking at the code and experimenting some, I've discovered that getCallerClass() doesn't actually keep going until it

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

On Jul 11, 2013, at 12:35 AM, Cédric Champeau cedric.champ...@gmail.com wrote: Le 11/07/2013 06:09, Charles Oliver Nutter a écrit : 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: sun.reflect.Reflection.getCallerClass(int) is going to be removed... how to replace?

On Jul 11, 2013, at 10:30 AM, Christian Thalinger christian.thalin...@oracle.com wrote: On Jul 11, 2013, at 12:35 AM, Cédric Champeau cedric.champ...@gmail.com wrote: Le 11/07/2013 06:09, Charles Oliver Nutter a écrit : Maybe a solution could be an annotation to mark calls

Re: RFR(L): 8008688: Make MethodHandleInfo public

Couldn't find any obvious problems. Looks good. -- Chris On Jul 2, 2013, at 6:26 PM, John Rose john.r.r...@oracle.com wrote: Thanks for the helpful review, Vladimir. I have incorporated all your comments and updated the webrev here: http://cr.openjdk.java.net/~jrose/8008688/webrev.05

Re: speed of invokeExact

On May 10, 2013, at 1:37 AM, Jochen Theodorou blackd...@gmx.org wrote: Am 10.05.2013 02:40, schrieb Christian Thalinger: [...] That's because your method handle is not constant and so the compiler cannot inline the call. And you tell me that in the first case the call was inlined

Re: speed of invokeExact

On May 9, 2013, at 2:26 AM, Jochen Theodorou blackd...@gmx.org wrote: Am 08.05.2013 23:12, schrieb John Rose: On May 8, 2013, at 5:33 AM, Jochen Theodorou blackd...@gmx.org wrote: Am 07.05.2013 19:31, schrieb Christian Thalinger: [...] Do you have any numbers?The problem is that if the MH

Re: speed of invokeExact

On May 7, 2013, at 8:04 AM, Jochen Theodorou blackd...@gmx.org wrote: Hi, I am currently investigating here some performance issues and I may have found a culprint here - invokeExact. My case is one where method caching fails and I will have to do an invokeExact from Java - meaning

Re: method handle cracking API

On Apr 25, 2013, at 8:58 AM, MacGregor, Duncan (GE Energy Management) duncan.macgre...@ge.com wrote: 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

Re: Update 12 build 3 - performance report question

On Dec 4, 2012, at 12:54 AM, George Marrows george.marr...@googlemail.com wrote: [resend after getting stuck in moderation first time] I was just checking out update 12 b3 with our Magik implementation on 64 bit Windows. Does b3 contain the backport of the Java 8 invokedynamic impl

Re: Perf regression since b72

On Mar 30, 2013, at 1:56 AM, Charles Oliver Nutter head...@headius.com wrote: I've been fiddling about with performance a bit again recently, and have noticed a perf degradation since b72. I mentioned this to the Nashorn guys and Marcus discovered that InlineSmallCode=2000 helped them get

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

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 round the problem. Although our

Re: Studying LF performance

[Back from vacation; catching up with emails.] On Dec 23, 2012, at 9:56 PM, Charles Oliver Nutter head...@headius.com wrote: Ok, things are definitely looking up with Roland's and Christian's patches! Good! :-) Numbers for red/black get as low as 0.74s with the new logic instead of the

Re: Studying LF performance

On Dec 23, 2012, at 10:11 PM, Charles Oliver Nutter head...@headius.com wrote: Oh, there's also this peculiar effect...shouldn't -TieredCompilation just give me C2 alone? Yes, it should. system ~/projects/jruby $ jruby -v -J-XX:-TieredCompilation

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

@openjdk.java.netmailto:mlvm-dev@openjdk.java.net Subject: Re: Java 7 update 12 issue with MethodHandles.catchException. On Dec 12, 2012, at 11:33 AM, Christian Thalinger wrote: That helps. I can't recall code that has a 8 argument limitation and does something else with 9+. Maybe John has

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

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...@ge.com wrote: Finally got time to try running our full application under 7u12 and I've hit a problem with our

Re: unreflectGetter and static class initialization

On Oct 24, 2012, at 3:32 PM, John Rose john.r.r...@oracle.com wrote: On Oct 24, 2012, at 1:08 PM, Jochen Theodorou wrote: what do you suggest as workaround? You could force the class to be initialized when the MH is created. This can be done with Class.forName. It would not exactly

Re: Latest experiments...happiness and sadness

On Oct 17, 2012, at 8:33 AM, David Chase david.r.ch...@oracle.com wrote: On 2012-10-16, at 8:53 PM, Charles Oliver Nutter head...@headius.com wrote: So *almost* everything is inlining, but one path (I believe it's the failure path from GWT after talking with Christian) is not reached.

Re: Reflection vs MethodHandle performance in Oracle JDK 7u7

Could you rerun the test with a recent JDK 8 build? -- Chris On Oct 10, 2012, at 3:02 PM, Ashwin Jayaprakash ashwin.jayaprak...@gmail.com wrote: Hi, I was looking at the Java 7 InvokeDynamic/MethodHandle feature set and I was curious to know how it performed compared to good old Reflection.

Re: Bug report: failing to call overridden method

On Oct 9, 2012, at 5:27 PM, Charles Oliver Nutter head...@headius.com wrote: I reported this to Christian, but thought I'd toss it here in case someone else runs into it. It appears that C1 (tier 1) is failing to compile a indy + MH virtual target into a proper overridden call. In other

Re: Back to work...JDK8

On Sep 15, 2012, at 3:15 PM, Charles Oliver Nutter head...@headius.com wrote: Things like this worry me a bit too, but there's only a couple of them :) We need to find out why these guys deoptimize. Either add -XX:+TraceDeoptimization or -XX:+LogCompilation (for the latter the output is

Re: Diagnosing performance cliffs on JDK7.

On Aug 21, 2012, at 2:00 AM, MacGregor, Duncan (GE Energy) duncan.macgre...@ge.com wrote: On 20/08/2012 20:47, Christian Thalinger christian.thalin...@oracle.com wrote: On Aug 20, 2012, at 12:02 PM, MacGregor, Duncan (GE Energy) duncan.macgre...@ge.com wrote: While trying to do some

Re: Missing invokehandle handling in bytecodeInterpreter.cpp

On Aug 7, 2012, at 3:19 PM, Roman Kennke wrote: Am Donnerstag, den 02.08.2012, 12:55 +0200 schrieb Roman Kennke: Am Dienstag, den 31.07.2012, 17:28 -0700 schrieb Christian Thalinger: On Jul 31, 2012, at 8:24 AM, Roman Kennke wrote: Am Dienstag, den 31.07.2012, 14:19 +0200 schrieb Roman

Re: Missing invokehandle handling in bytecodeInterpreter.cpp

On Jul 31, 2012, at 8:24 AM, Roman Kennke wrote: Am Dienstag, den 31.07.2012, 14:19 +0200 schrieb Roman Kennke: Hi there, I am currently (trying to) get the Hotspot-Zero port in shape for MLVM. I am running into a road block here: # Internal Error

hg: mlvm/mlvm/hotspot: meth-lazy: last minute fixes

Changeset: 6ca8164f788f Author:twisti Date: 2012-07-25 15:19 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/6ca8164f788f meth-lazy: last minute fixes ! meth-lazy-7023639.patch ___ mlvm-dev mailing list

Re: review request (L): JDK changes for 7023639: JSR 292 method handle invocation needs a fast path for compiled code

On Jul 24, 2012, at 2:55 AM, Aleksey Shipilev aleksey.shipi...@oracle.com wrote: On 07/23/2012 10:31 PM, John Rose wrote: On Jul 23, 2012, at 2:27 AM, Aleksey Shipilev wrote: The code does not need to be scalable, because the number of entries in the cache is small (order of 10-100) and

hg: mlvm/mlvm/hotspot: meth-lazy: fixed 32-bit SPARC C1 problem

Changeset: a8cb0e14256a Author:twisti Date: 2012-07-23 10:12 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/a8cb0e14256a meth-lazy: fixed 32-bit SPARC C1 problem ! meth-lazy-7023639.review.patch ___ mlvm-dev mailing list

hg: mlvm/mlvm/hotspot: meth-lazy: undo changes that caused a problem

Changeset: 8680e3b4be3b Author:twisti Date: 2012-07-20 14:39 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/8680e3b4be3b meth-lazy: undo changes that caused a problem ! meth-lazy-7023639.review.patch ___ mlvm-dev mailing

Re: review request (XXXL): 7023639: JSR 292 method handle invocation needs a fast path for compiled code

)) { if (!(*trace_name_printed)) { // RC_TRACE_MESG macro has an embedded ResourceMark I will integrate this one. -- Chris On Jul 18, 2012, at 7:10 PM, John Rose wrote: On Jul 17, 2012, at 4:04 PM, Christian Thalinger wrote: I see in several files next code pattern

hg: mlvm/mlvm/hotspot: meth-lazy: small bugfix

Changeset: cc59efc75960 Author:twisti Date: 2012-07-19 13:56 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/cc59efc75960 meth-lazy: small bugfix ! meth-lazy-7023639.review.patch ___ mlvm-dev mailing list

Re: review request (XXXL): 7023639: JSR 292 method handle invocation needs a fast path for compiled code

We forgot to remove the Ricochet Frame code from the sA: http://cr.openjdk.java.net/~twisti/7023639/ -- Chris On Jul 19, 2012, at 11:28 AM, Christian Thalinger wrote: JDK testing found a small bug: diff --git a/src/share/vm/oops/cpCacheOop.cpp b/src/share/vm/oops/cpCacheOop.cpp

hg: mlvm/mlvm/hotspot: meth-lazy: removed Ricochet frame code from SA

Changeset: f8ac1c76761f Author:twisti Date: 2012-07-19 15:15 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/f8ac1c76761f meth-lazy: removed Ricochet frame code from SA ! meth-lazy-7023639.review.patch ___ mlvm-dev mailing

Re: review request (XXXL): 7023639: JSR 292 method handle invocation needs a fast path for compiled code

. Done. -- Chris bytecodeInfo.cpp: Don't add spaces into conditions, looks strange. You REALLY want me to remove it? ;-) No, you can leave it as it is. Vladimir Christian Thalinger wrote: On Jul 12, 2012, at 6:27 PM, Vladimir Kozlov wrote: John, sharedRuntime_sparc.cpp: Why

hg: mlvm/mlvm/hotspot: meth-lazy: update for review comments

Changeset: 65906046e5fd Author:twisti Date: 2012-07-18 17:11 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/65906046e5fd meth-lazy: update for review comments ! meth-lazy-7023639.review.patch ___ mlvm-dev mailing list

hg: mlvm/mlvm/hotspot: rebase to current hsx/hotspot-comp

Changeset: 88f29874d717 Author:twisti Date: 2012-07-18 18:57 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/88f29874d717 rebase to current hsx/hotspot-comp ! meth-lazy-7023639.patch ! meth-lazy-7023639.review.patch ! series

hg: mlvm/mlvm/jdk: meth-lazy: added reinvokerTarget method to BMH species

Changeset: 72d2a3526502 Author:twisti Date: 2012-07-17 16:02 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/72d2a3526502 meth-lazy: added reinvokerTarget method to BMH species ! meth-lazy-7023639.bmh.patch ___ mlvm-dev mailing

Re: review request (XXXL): 7023639: JSR 292 method handle invocation needs a fast path for compiled code

On Jul 12, 2012, at 6:27 PM, Vladimir Kozlov wrote: John, sharedRuntime_sparc.cpp: Why casting to (int)? Also use pointer_delta(code_end, code_start,1): + __ set((int)(intptr_t)(code_end - code_start), temp2_reg); Done. You bound L_fail label twice, it should be local in

hg: mlvm/mlvm/hotspot: meth-lazy: update for review comments

Changeset: 9717ee54c9f5 Author:twisti Date: 2012-07-17 17:00 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/9717ee54c9f5 meth-lazy: update for review comments ! meth-lazy-7023639.review.patch ___ mlvm-dev mailing list

Re: hg: mlvm/mlvm/jdk: meth: performance work

On Jul 14, 2012, at 6:02 PM, john.r.r...@oracle.com wrote: Changeset: 56879e348afe Author:jrose Date: 2012-07-14 18:02 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/56879e348afe meth: performance work + meth-lazy-7023639.bmh.patch +

hg: mlvm/mlvm/jdk: meth-lazy: probably missed during last merge

Changeset: a436cf481411 Author:twisti Date: 2012-07-13 11:18 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/a436cf481411 meth-lazy: probably missed during last merge ! meth-lazy-7023639.patch ___ mlvm-dev mailing list

hg: mlvm/mlvm/hotspot: meth-lazy: misc. SPARC fixes

Changeset: f55844a06cc2 Author:twisti Date: 2012-07-12 18:47 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/f55844a06cc2 meth-lazy: misc. SPARC fixes ! meth-lazy-7023639.patch ___ mlvm-dev mailing list

Re: Testing out latest work

On Jul 11, 2012, at 2:17 PM, John Rose wrote: On Jul 11, 2012, at 2:12 PM, Charles Oliver Nutter wrote: OS X Lion, newish MBP, 4-core, 16GB memory. I have a 2009 MBP with 2 cores. We have a creeping suspicion that the crashing is more common on the 4-core machines. I just fixed a

hg: mlvm/mlvm/hotspot: meth-lazy: fix for intermittent exceptions of various kinds and crashes

Changeset: 22a0e2e50ec4 Author:twisti Date: 2012-07-11 15:32 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/22a0e2e50ec4 meth-lazy: fix for intermittent exceptions of various kinds and crashes ! meth-lazy-7023639.patch ___

Re: review request (M): 6711908: JVM needs direct access to some annotations

On Jul 11, 2012, at 3:47 PM, John Rose wrote: On Jul 11, 2012, at 12:01 AM, Michael Haupt wrote: @@ -1636,16 +1648,163 @@ The code for parsing @Retention deserves a comment highlighting that it is about parsing an annotation with payload (none of the annotations introduced by our work

hg: mlvm/mlvm/hotspot: meth-lazy: compiler snapshot

Changeset: 649f4375edec Author:twisti Date: 2012-07-06 17:06 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/649f4375edec meth-lazy: compiler snapshot ! meth-lazy-7023639.jit.patch ___ mlvm-dev mailing list

hg: mlvm/mlvm/jdk: meth-lazy: compiler snapshot

Changeset: fc8827d8a966 Author:twisti Date: 2012-07-06 17:06 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/fc8827d8a966 meth-lazy: compiler snapshot ! meth-lazy-7023639.patch ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net

hg: mlvm/mlvm/hotspot: meth-lazy: first cut of C1 support (some stuff works)

Changeset: 30e5e78c45d8 Author:twisti Date: 2012-06-25 12:26 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/30e5e78c45d8 meth-lazy: first cut of C1 support (some stuff works) ! meth-lazy-7023639.jit.patch ___ mlvm-dev

hg: mlvm/mlvm/hotspot: meth-lazy: forgot to add ciMemberName

Changeset: d3fc8dd38811 Author:twisti Date: 2012-06-25 12:50 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/d3fc8dd38811 meth-lazy: forgot to add ciMemberName ! meth-lazy-7023639.jit.patch ___ mlvm-dev mailing list

hg: mlvm/mlvm/jdk: meth-lazy: added DontInline annotation; small fix in makeGuardWithTest

Changeset: 207aa7731b26 Author:twisti Date: 2012-06-25 13:19 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/207aa7731b26 meth-lazy: added DontInline annotation; small fix in makeGuardWithTest ! meth-lazy-7023639.patch ___

hg: mlvm/mlvm/hotspot: meth-lazy: smaller fixes and changes

Changeset: 44ebe824251a Author:twisti Date: 2012-06-21 12:24 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/44ebe824251a meth-lazy: smaller fixes and changes ! meth-lazy-7023639.patch ___ mlvm-dev mailing list

Re: CFV: New Multi-Language VM Committer: Michael Haupt

voting: Eligible voters are current MLVM committers, who are John Rose, Christian Thalinger, and Lukas Stadler. Replies must be made publicly. The bylaws specify (as an optimization) that if all eligible voters vote Yes before the voting period ends then the action is approved at that time

Re: performance degeneration from jdk7u2 to jdk7u6?

On May 30, 2012, at 2:16 PM, Jochen Theodorou wrote: Am 24.05.2012 13:43, schrieb Rémi Forax: [...] if invokedynamic knows more, you can provide a path with less boxing so it's usually better. I changed Groovy to get rid of getCallSiteArray and added backpropagation of the return type

hg: mlvm/mlvm/jdk: meth-lazy: removed debug statements

Changeset: 989b69af27d3 Author:twisti Date: 2012-05-16 11:56 -0700 URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/989b69af27d3 meth-lazy: removed debug statements ! meth-lazy-7023639.patch ___ mlvm-dev mailing list

  1   2   3   4   5   >