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/ > . > > The benchmark indeed shows

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 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 this is >> one place I'd like

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

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: MemberName$Factory.resolve() and the Eclipse debugger.

Interesting. Thanks for digging deep. > On Oct 31, 2014, 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

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

> 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 29, 2014, at 9:39 AM, MacGregor, Duncan (GE Energy Management) >>> wrote: >>>

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

> 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 seeing long pauses (sometime very long pauses of > over a minute) due to java.lang.invoke.MemberName$

Re: Loopy CallSite

On Jul 16, 2014, at 11:40 AM, Remi Forax 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; i<100_000; i++) { >> >new LoopyCS().getTarget().invokeExact(1_000); >> > } >>

Re: FORK

On Apr 23, 2014, at 9:44 PM, Charles Oliver Nutter 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 with signal han

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

On Apr 3, 2014, at 9:44 PM, John Rose wrote: > On Apr 3, 2014, at 6:33 PM, Christian Thalinger > 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 to use different >>

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

s. > > Best 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,Wrapp

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

On Mar 24, 2014, at 1:33 PM, Igor Ignatyev 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 auxiliary code to

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

+ 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', float.class, Wrapper.FLOAT), + D_TYPE('D', double.class, Wrapper.DO

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

On Mar 18, 2014, at 2:35 PM, John Rose wrote: > On Mar 18, 2014, at 1:36 PM, Christian Thalinger > 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) > th

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

On Mar 14, 2014, at 4:28 AM, Vladimir Ivanov 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 char-based description of > b

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 { >> >>

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 wrote: > http://cr.openjdk.java.net/~vlivanov/8036117/webrev.00/ > https://bugs.openj

Re: RFR (S): 8033666: Make sure @ForceInline is everywhere it needs to be in sun.misc and java.lang.invoke

Looks good. While touching the code some time ago John and I were playing around with the idea to call Class.cast in the failing case: + static T castReference(Class t, U x) { + // inlined Class.cast because we can't ForceInline it + if (x != null && !t.isInstance(x)) +

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

On Feb 20, 2014, at 9:57 AM, Vladimir Ivanov 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 > these changes. > >

Re: Groovy bugs on JIRA

Can you tell me where “handle” (the target) is coming from in org.codehaus.groovy.vmplugin.v7.Selector$MethodSelector.setGuards? It would also be helpful to figure out what the target type is in Java 8. On Feb 7, 2014, at 5:13 PM, Christian Thalinger wrote: > Thanks for the information.

Re: Groovy bugs on JIRA

On Feb 7, 2014, at 6:02 AM, Jochen Theodorou wrote: > Am 07.02.2014 09:49, schrieb Cédric Champeau: > [...] >> [3] https://bugs.openjdk.java.net/browse/JDK-8033669 > > I first thought that this bug might be the same as > http://bugs.java.com/bugdatabase/view_bug.do?bug_id=8019184, but obviousl

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 wrote: >

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 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 class is omitted. > >

Re: [8] RFR (XS): 8032585: JSR292: IllegalAccessError when attempting to invoke protected method from different package

Looks good. On Jan 27, 2014, at 8:05 AM, Vladimir Ivanov wrote: > http://cr.openjdk.java.net/~vlivanov/8032585/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8032585 > > JSR292 access verification logic refuses method handle lookup access to > methods which are defined on inaccessible

[9] RFR (XXS): 8031043: ClassValue's backing map should have a smaller initial size

https://bugs.openjdk.java.net/browse/JDK-8031043 http://cr.openjdk.java.net/~twisti/8031043/webrev.00 8031043: ClassValue's backing map should have a smaller initial size Reviewed-by: The current initial size for ClassValue's backing WeakHashMap (ClassValueMap) is: private static final

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 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 Vla

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 wrote: > http://cr.openjdk.java.net/~vlivanov/8031502/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8031502 > > InvokeBytecodeGenerator can produce incorrect bytecode for a

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

dividual app, and most folks don't deploy more than a few > apps in a given JVM. Interesting. Thanks for the information. > > - Charlie > > On Thu, Jan 9, 2014 at 1:16 PM, Christian Thalinger > wrote: >> >> On Jan 9, 2014, at 2:46 AM, Jochen Theodor

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

On Jan 9, 2014, at 2:46 AM, Jochen Theodorou 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 fo

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

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

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

On Jan 8, 2014, at 6:43 AM, Jochen Theodorou 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 >&g

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

On Jan 8, 2014, at 12:21 AM, Remi Forax 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 >&g

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 m

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

On Dec 11, 2013, at 12:17 AM, Mark Roos 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) { > public stat

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

ink it is intelligible as > posted. — John I'm fine with that. > > On Oct 4, 2013, at 11:34 AM, John Rose wrote: > >> Yikes; good catch. I used javac -Xdoclint to find a couple typos in @param >> also. — John >> >> On Oct 4, 2013, at 11:17 AM

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 collectAr

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 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 > wrote: > >> Since there

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

On Oct 2, 2013, at 2:31 PM, John Rose wrote: > On Oct 2, 2013, at 12:14 PM, Christian Thalinger > wrote: > >> src/share/classes/java/lang/invoke/MethodHandles.java: >> >> + * lookup expression >> >> Apparently the name attribute is obsolete

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

On Sep 20, 2013, at 5:09 PM, John Rose wrote: > On Sep 20, 2013, at 3:07 PM, Vladimir Ivanov > 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 missing in a few > other places too. > >> The

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 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., "getDirectMethodN

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

src/share/classes/java/lang/invoke/MethodHandles.java: + * lookup expression Apparently the name attribute is obsolete for in HTML5: http://dev.w3.org/html5/markup/a.html I think they want you to use . + * + * + * Discussion of private access: Same here. + * Securi

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

Looks good. On Oct 1, 2013, at 2:29 PM, John Rose 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 ClassVerifier::verify_invoke

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 wrote: > On Sep 20, 2013, at 8:29 AM, Vladimir Ivanov > wrote: > >> John, >> >> I don't see much value in documenting buggy behavior of

Re: JDK7u, hotspot, CC_INTERP, and COBOL

On Sep 25, 2013, at 10:52 AM, Francis ANDRE 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 working the bytecode cppInt

Re: jdk8 metaspace problem with indy

On Sep 26, 2013, at 7:20 AM, Jochen Theodorou 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 it seems.

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

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

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

ase wrote: >>>> >>>>> The test is adapted from the test in the bug report. >>>>> The headline on the bug report is wrong -- because it uses reflection in >>>>> the test to do the invocation, >>>>> the thrown exception is wrappe

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

On Sep 18, 2013, at 6:43 PM, John Rose wrote: > On Sep 18, 2013, at 2:11 PM, Christian Thalinger > wrote: > >> src/share/classes/java/lang/invoke/CallSite.java: >> >> +if (3 + argv.length > MethodType.MAX_MH_ARITY) >> +

Re: Interpreting Mission Control numbers for indy

On Sep 18, 2013, at 1:39 AM, Charles Oliver Nutter 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 what I see. > > In

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 = invocationType.invokers().spreadInvok

Re: RFR (S) 8001108: an attempt to use "" 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. + * (Note: JVM internal methods named {@code } not visible to this API, + * even thou

Re: RFR (S) 8001109: arity mismatch on a call to spreader method handle should elicit IllegalArgumentException

Looks good. On Sep 12, 2013, at 6:02 PM, John Rose wrote: > Please review this change for a change to the JSR 292 implementation: > > http://cr.openjdk.java.net/~jrose/8001109/webrev.00/ > > The change is mostly to javadoc and unit tests, documenting and testing some > corner cases of JSR 292

Re: Reproducible InternalError in lambda stuff

On Sep 16, 2013, at 2:59 AM, Charles Oliver Nutter wrote: > On Mon, Sep 16, 2013 at 2:36 AM, John Rose 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 users to test it. > >> If you have

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

On Sep 12, 2013, at 4:34 PM, John Rose 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 APIs. > > Since th

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

ceptions 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 >> wrote: >> >>> +

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 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 thrown in call of me

Re: Reproducible InternalError in lambda stuff

On Sep 6, 2013, at 11:11 PM, Charles Oliver Nutter 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)=>{ > > t5:I=MethodHandle(ThreadContext,IRubyObject,IRubyObject,IRubyObject)boolean

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 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 finds the first method > without

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

On Jul 11, 2013, at 10:30 AM, Christian Thalinger wrote: > > On Jul 11, 2013, at 12:35 AM, Cédric Champeau > 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

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 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 >> language-specific stack traces.

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 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 > > Detailed repli

Re: speed of invokeExact

On May 10, 2013, at 1:37 AM, Jochen Theodorou 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

Re: speed of invokeExact

On May 9, 2013, at 2:26 AM, Jochen Theodorou wrote: > Am 08.05.2013 23:12, schrieb John Rose: >> On May 8, 2013, at 5:33 AM, Jochen Theodorou wrote: >> >>> Am 07.05.2013 19:31, schrieb Christian Thalinger: >>> [...] >>>> Do you have any numbers?

Re: speed of invokeExact

On May 7, 2013, at 8:04 AM, Jochen Theodorou 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 without > the inv

Re: method handle cracking API

On Apr 25, 2013, at 8:58 AM, "MacGregor, Duncan (GE Energy Management)" 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 exception information

Re: Update 12 build 3 - performance report & question

On Apr 14, 2013, at 10:29 PM, Christian Thalinger wrote: > > On Dec 4, 2012, at 12:54 AM, George Marrows > wrote: > >> [resend after getting stuck in moderation first time] >> >> I was just checking out update 12 b3 with our Magik implementation on 64 b

Re: Update 12 build 3 - performance report & question

On Dec 4, 2012, at 12:54 AM, George Marrows 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 that I believe > was plann

Re: Perf regression since b72

On Mar 30, 2013, at 1:56 AM, Charles Oliver Nutter 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 back to b72 > per

Re: Studying LF performance

On Dec 23, 2012, at 10:11 PM, Charles Oliver Nutter 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 > ../rubybench/bench/time/bench_red_black.rb > jruby 1.7.2

Re: Studying LF performance

[Back from vacation; catching up with emails.] On Dec 23, 2012, at 9:56 PM, Charles Oliver Nutter 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 1.5s I get without

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

nything that prints flushed methods. -- Chris > > 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 p

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

java.net>> > Date: Wednesday, 12 December 2012 19:42 > To: Da Vinci Machine Project > mailto: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:

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

On Dec 12, 2012, at 9:35 AM, "MacGregor, Duncan (GE Energy Management)" wrote: > I do see the failure with 8 as well. That helps. I can't recall code that has a "8 argument limitation" and does something else with 9+. Maybe John has an idea. -- Chris > &g

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)" wrote: > Finally got time to try running our full application under 7u12 and I've hit > a problem with our database library. In two

Re: unreflectGetter and static class initialization

On Oct 29, 2012, at 9:29 AM, Remi Forax wrote: > On 10/29/2012 05:03 PM, Christian Thalinger wrote: >> >> On Oct 24, 2012, at 3:32 PM, John Rose > <mailto:john.r.r...@oracle.com>> wrote: >> >>> On Oct 24, 2012, at 1:08 PM, Jochen Theodorou wrote: &

Re: unreflectGetter and static class initialization

On Oct 24, 2012, at 3:32 PM, John Rose 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 give you the seman

Re: hg: jdk8/tl/jdk: 7197401: Add a subset of the org.objectweb.asm packages to jdk8

On Oct 21, 2012, at 3:09 AM, Remi Forax wrote: > I suppose that j.l.invoke will be retrofited to use this package instead of > using the one that comes from jax-ws. Yes, as soon as possible. -- Chris > > Rémi > > Original Message > Subject: hg: jdk8/tl/jdk: 7197401:

Re: OS X OpenJDK 8 hotspot-comp + perf patches

On Oct 17, 2012, at 10:08 AM, Charles Oliver Nutter wrote: > This is a product build. I can run a fastdebug build if you need it > (and really I need it too, since PrintAssembly is still broken with > OpenJDK8). This is very annoying and I've already filed a bug for it: 8000489: older builds o

Re: Latest experiments...happiness and sadness

On Oct 17, 2012, at 8:33 AM, David Chase wrote: > > On 2012-10-16, at 8:53 PM, Charles Oliver Nutter 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. >> Because Hotspot's EA can't do partia

Re: Bug report: failing to call overridden method

On Oct 9, 2012, at 5:27 PM, Charles Oliver Nutter 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 words, it doesn't

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 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. > > I had refrained from

Re: Back to work...JDK8

On Sep 15, 2012, at 3:15 PM, Charles Oliver Nutter 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 then in hotspot.log).

Re: Diagnosing performance cliffs on JDK7.

On Aug 21, 2012, at 2:00 AM, "MacGregor, Duncan (GE Energy)" wrote: > On 20/08/2012 20:47, "Christian Thalinger" > wrote: >> On Aug 20, 2012, at 12:02 PM, "MacGregor, Duncan (GE Energy)" >> wrote: >> >>> While trying to do som

Re: Diagnosing performance cliffs on JDK7.

On Aug 20, 2012, at 12:02 PM, "MacGregor, Duncan (GE Energy)" wrote: > While trying to do some minor performance tuning on how we handle multiple > return results I've finally managed to consistently provoke a performance > cliff in our benchmarks. Logging compilation I see that the method in

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: >>>>&g

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 >> (/home/rkennke/src/open

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 mlvm-dev@openjdk.java.

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 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 scales only with type sc

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 mlv

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 lis

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 li

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/cp

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 mlvm-dev@openjdk.jav

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

0)) { 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 s

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/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 mlvm-d

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

hod()); > +Handle appendix(THREAD, cpce->has_appendix() ? cpce->f1_appendix() : > (oop)NULL); > +result.set_handle(method, appendix, CHECK); > +return; > + } Much better. Done. -- Chris > > >> bytecodeInfo.cpp: > >> Don't add spaces into con

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 mlvm-d

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 range_

  1   2   3   4   5   6   7   >