Re: ClassValue perf?

[Christian Thalinger]

> 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 that this latest addition to the group slows down 
> random and sequential access, especially for small numbers of values and 
> classes. The OpenJDK tests are fine; I'm running a batch of internal tests as 
> well.
> 
> Given that one concern with this issue, next to reducing footprint, was to 
> optimise for the single-value case, I'm still a bit hesitant even though the 
> sheer amount of code reduction is impressive. I'll evaluate further.

The main motivation to optimize for the single-value use case is Graal but it’s 
not super important.  Graal solved this issue in a different way and it’s 
questionable Graal would go back using ClassValue so don’t worry too much about 
it.

> 
> Best,
> 
> Michael
> 
>> Am 05.05.2016 um 17:21 schrieb Peter Levart > >:
>> 
>> Hi Michael,
>> 
>> 
>> On 05/04/2016 06:02 PM, Michael Haupt wrote:
>>> Hi Peter,
>>> 
>>> thank you for chiming in again! :-) I'll look at this in depth on Friday.
>> 
>> Good. Because I found bugs in expunging logic and a discrepancy of behavior 
>> when a value is installed concurrently by some other thread and then later 
>> removed while the 1st thread is still calculating the value. Current 
>> ClassValue re-tries the computation until it can make sure there were no 
>> concurrent changes to the entry during its computation. I fixed both things 
>> and verified that the behavior is now the same:
>> 
>> 
>> http://cr.openjdk.java.net/~plevart/misc/ClassValue.Alternative2/webrev.02/ 
>> 
>> 
>> Regards, Peter
> 
> 
> -- 
> 
>  
> Dr. Michael Haupt | Principal Member of Technical Staff
> Phone: +49 331 200 7277 | Fax: +49 331 200 7561
> Oracle Java Platform Group | LangTools Team | Nashorn
> Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, 
> Germany
> 
> ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstraße 25, D-80992 
> München
> Registergericht: Amtsgericht München, HRA 95603
> 
> Komplementärin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 
> 3543 AS Utrecht, Niederlande
> Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697
> Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher
>     Oracle is committed to developing 
> practices and products that help protect the environment
> 
> ___
> mlvm-dev mailing list
> mlvm-dev@openjdk.java.net 
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev 
> 
___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

Re: JFokus VM Tech Day 2016

[Christian Thalinger]

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

> ___
> mlvm-dev mailing list
> mlvm-dev@openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

Re: ClassValue perf?

[Christian Thalinger]

 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 this is
 one place I'd like to simplify our code a bit.
 
 I could measure myself, but I'm guessing some of you have already done
 a lot of exploration or have benchmarks handy. So, what say you?
 
 I'm listening too.  We don't have any special optimizations for CVs,
 and I'm hoping the generic code is a good-enough start.

A while ago (wow; it’s more than a year already) I was working on:

[#JDK-8031043] ClassValue's backing map should have a smaller initial size - 
Java Bug System https://bugs.openjdk.java.net/browse/JDK-8031043

and we had a conversation about it:

http://mail.openjdk.java.net/pipermail/mlvm-dev/2014-January/005597.html 
http://mail.openjdk.java.net/pipermail/mlvm-dev/2014-January/005597.html

It’s not about performance directly but it’s about memory usage and maybe the 
one-value-per-class optimization John suggests is in fact a performance 
improvement.  Someone should pick this one up.

 — John
 ___
 mlvm-dev mailing list
 mlvm-dev@openjdk.java.net
 http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

Re: Invokedynamic and recursive method call

[Christian Thalinger]

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
 performance of heavily-recursive algorithms. I'll try to get an
 assembly dump for fib in JRuby later today.
 
 - Charlie
 
 On Wed, Jan 7, 2015 at 10:13 AM, Remi Forax fo...@univ-mlv.fr wrote:
 
 On 01/07/2015 10:43 AM, Marcus Lagergren wrote:
 
 Remi, I tried to reproduce your problem with jdk9 b44. It runs decently
 fast.
 
 
 yes, nashorn is fast enough but it can be faster if the JIT was not doing
 something stupid.
 
 When the VM inline fibo, because fibo is recursive, the recursive call is
 inlined only once,
 so the call at depth=2 can not be inlined but should be a classical direct
 call.
 
 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 and execute it
 like if the metod handle was not constant
 (the method handle is constant because the call at depth=1 is inlined !).
 
 When did it start to regress?
 
 
 jdk7u40, i believe.
 
 I've created a jar containing some handwritten bytecodes with no dependency
 to reproduce the issue easily:
  https://github.com/forax/vmboiler/blob/master/test7/fibo7.jar
 
 [forax@localhost test7]$ time /usr/jdk/jdk1.9.0/bin/java -cp fibo7.jar
 FiboSample
 1836311903
 
 real0m6.653s
 user0m6.729s
 sys0m0.019s
 [forax@localhost test7]$ time /usr/jdk/jdk1.8.0_25/bin/java -cp fibo7.jar
 FiboSample
 1836311903
 
 real0m6.572s
 user0m6.591s
 sys0m0.019s
 [forax@localhost test7]$ time /usr/jdk/jdk1.7.0_71/bin/java -cp fibo7.jar
 FiboSample
 1836311903
 
 real0m6.373s
 user0m6.396s
 sys0m0.016s
 [forax@localhost test7]$ time /usr/jdk/jdk1.7.0_25/bin/java -cp fibo7.jar
 FiboSample
 1836311903
 
 real0m4.847s
 user0m4.832s
 sys0m0.019s
 
 as you can see, it was faster with a JDK before jdk7u40.
 
 
 Regards
 Marcus
 
 
 cheers,
 Rémi
 
 
 
 On 30 Dec 2014, at 20:48, Remi Forax fo...@univ-mlv.fr wrote:
 
 Hi guys,
 I've found a bug in the interaction between the lambda form and inlining
 algorithm,
 basically if the inlining heuristic bailout because the method is
 recursive and already inlined once,
 instead to emit a code to do a direct call, it revert to do call to
 linkStatic with the method
 as MemberName.
 
 I think it's a regression because before the introduction of lambda
 forms,
 I'm pretty sure that the JIT was emitting a direct call.
 
 Step to reproduce with nashorn, run this JavaScript code
 function fibo(n) {
  return (n  2)? 1: fibo(n - 1) + fibo(n - 2)
 }
 
 print(fibo(45))
 
 like this:
  /usr/jdk/jdk1.9.0/bin/jjs -J-XX:+UnlockDiagnosticVMOptions
 -J-XX:+PrintAssembly fibo.js  log.txt
 
 look for a method 'fibo' from the tail of the log, you will find
 something like this:
 
  0x7f97e4b4743f: mov$0x76d08f770,%r8   ;   {oop(a
 'java/lang/invoke/MemberName' = {method} {0x7f97dcff8e40} 'fibo'
 '(Ljdk/nashorn/internal/runtime/ScriptFunction;Ljava/lang/Object;I)I' in
 'jdk/nashorn/internal/scripts/Script$Recompilation$2$fibo')}
  0x7f97e4b47449: xchg   %ax,%ax
  0x7f97e4b4744b: callq  0x7f97dd0446e0
 
 I hope this can be fixed. My demonstration that I can have fibo written
 with a dynamic language
 that run as fast as written in Java doesn't work anymore :(
 
 cheers,
 Rémi
 
 ___
 mlvm-dev mailing list
 mlvm-dev@openjdk.java.net
 http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
 
 ___
 mlvm-dev mailing list
 mlvm-dev@openjdk.java.net
 http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
 
 
 ___
 mlvm-dev mailing list
 mlvm-dev@openjdk.java.net
 http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
 ___
 mlvm-dev mailing list
 mlvm-dev@openjdk.java.net
 http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

Re: Invokedynamic and recursive method call

[Christian Thalinger]

 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 the method handle on stack and execute it
 like if the metod handle was not constant
 (the method handle is constant because the call at depth=1 is inlined !).
 
 Invocation of non-constant MH's had a performance regression with the 
 LF-based implementation.
 As of JDK-8069591 they should be no slower and sometimes faster than the old 
 implementation.

Maybe but what Remi is saying that the MH is constant and we could emit a 
direct call.

 — John
 
 ___
 mlvm-dev mailing list
 mlvm-dev@openjdk.java.net
 http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

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

[Christian Thalinger]

 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 java.lang.invoke.MemberName$Factory.resolve() 
 apparently taking ages to complete.

Over a minute?!?  What is the JVM doing during this time?  Class loading?  
Garbage collection?

The only thing that comes to mind is that methods with breakpoints are not 
compiled but interpreted.  But even if you had a lot of breakpoints in core 
methods I don’t see how that would explain pauses of over a minute.

 Testing with an openjdk build I see the reported line number in thread dumps 
 is 962 of MemberName.java, which is where Factory.resolve() calls 
 MethodHandleNatives.resolve().
 
 Anybody else seen this, and is it even worth investigating further without 
 David’s change to intern MemberNames?
 
 Regards, Duncan.
 ___
 mlvm-dev mailing list
 mlvm-dev@openjdk.java.net
 http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

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

[Christian Thalinger]

 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:
 
 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.
 
 Over a minute?!?  What is the JVM doing during this time?  Class loading?
 Garbage collection?
 
 Doesnąt seem to be doing any GC, not doing much of anything that I can
 see. Iąve applied Daivdąs MemberName interning patches and will see if
 they change the behaviour at all, and then build a JDK with debug symbols
 and see if connecting a debugger to the process sheds any light on whatąs
 going on inside the JVM.
 
 The only thing that comes to mind is that methods with breakpoints are
 not compiled but interpreted.  But even if you had a lot of breakpoints
 in core methods I donąt see how that would explain pauses of over a
 minute.
 
 It happens even without breakpoints being set. Is it possibly due to the
 avalanche of anonymous classes Lambdaforms produce?

So you’re running in Eclipse’s debugger but without breakpoints set and no 
single-stepping?

 
 Testing with an openjdk build I see the reported line number in thread
 dumps is 962 of MemberName.java, which is where Factory.resolve() calls
 MethodHandleNatives.resolve().
 
 Anybody else seen this, and is it even worth investigating further
 without Davidąs change to intern MemberNames?
 
 Regards, Duncan.
 ___
 mlvm-dev mailing list
 mlvm-dev@openjdk.java.net
 http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
 
 ___
 mlvm-dev mailing list
 mlvm-dev@openjdk.java.net
 http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
 
 ___
 mlvm-dev mailing list
 mlvm-dev@openjdk.java.net
 http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

Re: Loopy CallSite

[Christian Thalinger]

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);
   }
 
 In LoopyCS constructor you instantiates 3 new MethodHandles:
 target = MethodHandles.filterArguments(target, 0, FOO);
 target = MethodHandles.guardWithTest(ZERO,
 target,
  MethodHandles.dropArguments(MethodHandles.constant(int.class,
  0).asType(MethodType.methodType(void.class)), 0, int.class));
 
 Since we don't cache LambdaForms yet for these combinators, 3 new 
 LambdaForms are created for each invocation. Then they are compiled to 
 bytecode and then JIT kicks in. That's why you see continuous JITing.
 
 If you reuse a call site object, it stabilizes very quickly.
 
 doh, sorry for this stupid code :(

Everyone makes mistakes once in a while.  Even you, Remi ;-)

 
 
 Best regards,
 Vladimir Ivanov
 
 Rémi
 
 
 On 7/12/14 6:05 PM, Remi Forax wrote:
 It seems that the JIT is lost with whe there is a loopy callsite and
 never stabilize (or the steady state is after the program ends).
 
 import java.lang.invoke.MethodHandle;
 import java.lang.invoke.MethodHandles;
 import java.lang.invoke.MethodType;
 import java.lang.invoke.MutableCallSite;
 
 public class Loop {
   static class LoopyCS extends MutableCallSite {
 public LoopyCS() {
   super(MethodType.methodType(void.class, int.class));
 
   MethodHandle target = dynamicInvoker();
   target = MethodHandles.filterArguments(target, 0, FOO);
   target = MethodHandles.guardWithTest(ZERO,
   target,
 MethodHandles.dropArguments(MethodHandles.constant(int.class,
 0).asType(MethodType.methodType(void.class)), 0, int.class));
   setTarget(target);
 }
   }
 
   static final MethodHandle FOO, ZERO;
   static {
 try {
   FOO = MethodHandles.lookup().findStatic(Loop.class, foo,
 MethodType.methodType(int.class, int.class));
   ZERO = MethodHandles.lookup().findStatic(Loop.class, zero,
 MethodType.methodType(boolean.class, int.class));
 } catch (NoSuchMethodException | IllegalAccessException e) {
   throw new AssertionError(e);
 }
   }
 
   private static boolean zero(int i) {
 return i != 0;
   }
 
   private static int foo(int i) {
 COUNTER++;
 return i - 1;
   }
 
   private static int COUNTER = 0;
 
   public static void main(String[] args) throws Throwable {
 for(int i=0; i100_000; i++) {
   new LoopyCS().getTarget().invokeExact(1_000);
 }
 System.out.println(COUNTER);
   }
 }
 
 cheers,
 Rémi
 
 
 ___
 mlvm-dev mailing list
 mlvm-dev@openjdk.java.net
 http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
 ___
 mlvm-dev mailing list
 mlvm-dev@openjdk.java.net
 http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
 
 ___
 mlvm-dev mailing list
 mlvm-dev@openjdk.java.net
 http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

Re: FORK

[Christian Thalinger]

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 with signal handlers etc.
 
 I ask for a few reasons...
 
 * Dalvik has shown what you can do with a larval preforking setup.
 This is a big reason why Android apps can run in such a small amount
 of memory and start up so quickly.
 * Startup time! If we could fork an already-hot JVM, we could hit the
 ground running with *every* command, *and* still have truly separate
 processes.
 * There's a lot of development and scaling patterns that depend on
 forking, and we get constant questions about forking on JRuby.
 * Rubinius -- a Ruby VM with partially-concurrent GC, a
 signal-handling thread, JIT threads, and real parallel Ruby threads --
 supports forking. They bring the threads to a safe point, fork, and
 restart them on the other side. Color me jealous.
 
 So...given that OpenJDK is rapidly expanding into smaller-profile
 devices and new languages and development patterns, perhaps it's time
 to make it fit into the UNIX philosophy. Where do we start?

Good question.  I think you should bring this up on the hotspot-dev mailing 
list.  People from the runtime team might have some input to this (at least I 
hope; because I don’t, really).

 
 - Charlie
 ___
 mlvm-dev mailing list
 mlvm-dev@openjdk.java.net
 http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

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

[Christian Thalinger]

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 to use different 
 names just because they are used in other namespaces.  This is not a C 
 define.
 
 They stand for JVM signatures as well as basic types.  The letters are 
 signature letters.  Can we move on from this?

Sure.  Push it.

 
 — John
 ___
 mlvm-dev mailing list
 mlvm-dev@openjdk.java.net
 http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

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

[Christian Thalinger]

On Mar 26, 2014, at 8:01 AM, Vladimir Ivanov vladimir.x.iva...@oracle.com 
wrote:

 Here's a version with the new naming scheme:
 http://cr.openjdk.java.net/~vlivanov/8037210/webrev.03.naming
 
 I like existing naming scheme and OBJECT/VOID/LONG/etc names are quite 
 popular(e.g. Wrapper  ASM (Opcodes) use them).

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 names just 
because they are used in other namespaces.  This is not a C define.

 So, I'm in favor of leaving it as is.
 
 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,Wrapper.INT),
 + J_TYPE('J', long.class,   Wrapper.LONG),
 + F_TYPE('F', float.class,  Wrapper.FLOAT),
 + D_TYPE('D', double.class, Wrapper.DOUBLE),  // all primitive types
 + V_TYPE('V', void.class,   Wrapper.VOID);// not valid in all 
 contexts
 
 I would suggest to not name them X_TYPE but give them meaningful names like 
 Int, Float, Void.  The enum BasicType already infers that it’s a type.  If 
 you think it’s not clear that it’s a type just use BasicType.Double in that 
 places.
 
 On Mar 24, 2014, at 9:29 AM, Vladimir Ivanov vladimir.x.iva...@oracle.com 
 wrote:
 
 Updated version:
 http://cr.openjdk.java.net/~vlivanov/8037210/webrev.03/
 
 - changed the way how arrays of types are created:
static final BasicType[] ALL_TYPES = BasicType.values();
static final BasicType[] ARG_TYPES = Arrays.copyOf(ALL_TYPES, 
 ALL_TYPES.length-1);
 
 - added a test for BasicType (LambdaFormTest.testBasicType).
 
 Best regards,
 Vladimir Ivanov
 
 On 3/22/14 2:08 AM, Vladimir Ivanov wrote:
 John, thanks for the feedback.
 
 Updated webrev:
 http://cr.openjdk.java.net/~vlivanov/8037210/webrev.02
 
 Also moved LambdaForm.testShortenSignature() into a stand-alone unit test.
 
 Best regards,
 Vladimir Ivanov
 
 On 3/21/14 10:54 PM, John Rose wrote:
 On Mar 21, 2014, at 8:49 AM, Vladimir Ivanov
 vladimir.x.iva...@oracle.com mailto:vladimir.x.iva...@oracle.com
 wrote:
 
 Thanks for the feedback.
 
 What do you think about the following:
 http://cr.openjdk.java.net/~vlivanov/8037210/webrev.01/
 
 That looks nice.  Strong typing; who woulda' thunk it.  :-)
 
 The uses of .ordinal() are the extra cost relative to using just small
 integers.  They seem totally reasonable in the code.
 
 I suggest either wrapping ordinal as something like id or else
 changing temp names like id to ord, to reinforce the use of a common
 name.
 
 Don't make the enum class public.  And especially don't make the mutable
 arrays public:
 
 +public static final BasicType[] ALL_TYPES = { L_TYPE, I_TYPE,
 J_TYPE, F_TYPE, D_TYPE, V_TYPE };
 +public static final BasicType[] ARG_TYPES = { L_TYPE, I_TYPE,
 J_TYPE, F_TYPE, D_TYPE };
 
 — John
 
 P.S.  That would only be safe if we had (what we don't yet) a notion of
 frozen arrays like:
 
 +public static final BasicType final[] ALL_TYPES = { L_TYPE,
 I_TYPE, J_TYPE, F_TYPE, D_TYPE, V_TYPE };
 +public static final BasicType final[] ARG_TYPES = { L_TYPE,
 I_TYPE, J_TYPE, F_TYPE, D_TYPE };
 
 
 
 ___
 mlvm-dev mailing list
 mlvm-dev@openjdk.java.net
 http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
 
 ___
 mlvm-dev mailing list
 mlvm-dev@openjdk.java.net
 http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
 
 ___
 mlvm-dev mailing list
 mlvm-dev@openjdk.java.net
 http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
 
 ___
 mlvm-dev mailing list
 mlvm-dev@openjdk.java.net
 http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

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

[Christian Thalinger]

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 auxiliary code together 
 w/ a test code, many methods aren't connected w/ each other, etc. All this 
 leads to that it is very very hard to understand, maintain.

Yes, it is.

 
 Fix:
 - the auxiliary code was moved to testlibray
 - the test code was moved to a separate subpackage

This is very nice.  Are there plans to do this for the other existing tests as 
well?

 - random signature is used for target and handler
 - added scenarios w/ different return types
 
 webrev: http://cr.openjdk.java.net/~iignatyev/8038186/webrev.01/
 jbs: https://bugs.openjdk.java.net/browse/JDK-8038186
 -- 
 Igor
 ___
 mlvm-dev mailing list
 mlvm-dev@openjdk.java.net
 http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

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

[Christian Thalinger]

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 char-based description of 
 basic types by numeric constants.

Why are we not using an Enum instead of an untyped byte?

 
 Contributed-by: john.r.r...@oracle.com
 
 Testing: jdk/java/{lang/invoke,util}, vm.mlvm.testlist, nashorn, jruby
 Flags: -ea -esa -Xverify:all -D...COMPILE_THRESHOLD={0,30}
 
 Best regards,
 Vladimir Ivanov
 ___
 mlvm-dev mailing list
 mlvm-dev@openjdk.java.net
 http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

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

[Christian Thalinger]

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) 
 that you can't assign an int or char to a byte w/o a cast.
 That's why it is not just a plain int.
 
 But those values (L_TYPE etc.) are used a lot as numbers, and specifically as 
 low-level array indexes, and also comparisons (x  V_TYPE).
 
 To turn them into enums, we'd have to add lots of calls to '.ordinal()' to 
 turn them right back to numbers.  That dilutes (completely IMO) the value 
 they have as enums to raise the level of the code.

But without being strongly typed we get bugs like this one:
 @Override
-MethodHandle bindArgument(int pos, char basicType, Object value) {
+MethodHandle bindArgument(int pos, byte basicType, Object value) {
 // If the member needs dispatching, do so.
 if (pos == 0  basicType == 'L') {
I’m just saying that for the sake of maintainability and correctness an Enum 
would be better.

 
 — John
 ___
 mlvm-dev mailing list
 mlvm-dev@openjdk.java.net
 http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

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

[Christian Thalinger]

Even better.

On Mar 10, 2014, at 3:21 PM, Vladimir Ivanov vladimir.x.iva...@oracle.com 
wrote:

 Chris, thanks for the review.
 
 John suggested an elegant way to fix the problem - use asFixedArity.
 
 Updated fix:
 http://cr.openjdk.java.net/~vlivanov/8036117/webrev.01/
 
 Best regards,
 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...@oracle.com 
 wrote:
 
 http://cr.openjdk.java.net/~vlivanov/8036117/webrev.00/
 https://bugs.openjdk.java.net/browse/JDK-8036117
 84 lines changed: 74 ins; 3 del; 7 mod
 
 I have to revert a cleanup I did for 8027827.
 MethodHandle.invokeWithArguments (and generic invocation) has unpleasant
 peculiarity in behavior when used with VarargsCollector. So,
 unfortunately, invokeWithArguments is not an option there.
 
 Looking at the API (excerpts from javadoc [1] [2]), the following
 condition doesn't hold in that case:
   trailing parameter type of the caller is a reference type identical
 to or assignable to the trailing parameter type of the adapter.
 
 Example:
   target.invokeWithArguments((Object[])args)
   =
   target.invoke((Object)o1,(Object)o2,(Object)o3)
   =/
   target.invokeExact((Object)o1, (Object)o2, (Object[])o3)
 
 because Object !: Object[].
 
 The fix is to skip unnecessary conversion when invoking a method handle
 and just do a pairwise type conversion.
 
 Testing: failing test case, nashorn w/ experimental features (octane)
 
 Thanks!
 
 Best regards,
 Vladimir Ivanov
 
 [1] MethodHandle.invokeWithArguments
 Performs a variable arity invocation, ..., as if via an inexact invoke
 from a call site which mentions only the type Object, and whose arity is
 the length of the argument array.
 
 [2] MethodHandle.asVarargsCollector
 When called with plain, inexact invoke, if the caller type is the same
 as the adapter, the adapter invokes the target as with invokeExact.
 (This is the normal behavior for invoke when types match.)
 
 Otherwise, if the caller and adapter arity are the same, and the
 trailing parameter type of the caller is a reference type identical to
 or assignable to the trailing parameter type of the adapter, the
 arguments and return values are converted pairwise, as if by asType on a
 fixed arity method handle.
 
 Otherwise, the arities differ, or the adapter's trailing parameter type
 is not assignable from the corresponding caller type. In this case, the
 adapter replaces all trailing arguments from the original trailing
 argument position onward, by a new array of type arrayType, whose
 elements comprise (in order) the replaced arguments.
 ___
 mlvm-dev mailing list
 mlvm-dev@openjdk.java.net
 http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
 
 ___
 mlvm-dev mailing list
 mlvm-dev@openjdk.java.net
 http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
 
 ___
 mlvm-dev mailing list
 mlvm-dev@openjdk.java.net
 http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

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

[Christian Thalinger]

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:

 http://cr.openjdk.java.net/~vlivanov/8036117/webrev.00/
 https://bugs.openjdk.java.net/browse/JDK-8036117
 84 lines changed: 74 ins; 3 del; 7 mod
 
 I have to revert a cleanup I did for 8027827. 
 MethodHandle.invokeWithArguments (and generic invocation) has unpleasant 
 peculiarity in behavior when used with VarargsCollector. So, 
 unfortunately, invokeWithArguments is not an option there.
 
 Looking at the API (excerpts from javadoc [1] [2]), the following 
 condition doesn't hold in that case:
   trailing parameter type of the caller is a reference type identical 
 to or assignable to the trailing parameter type of the adapter.
 
 Example:
   target.invokeWithArguments((Object[])args)
   =
   target.invoke((Object)o1,(Object)o2,(Object)o3)
   =/
   target.invokeExact((Object)o1, (Object)o2, (Object[])o3)
 
 because Object !: Object[].
 
 The fix is to skip unnecessary conversion when invoking a method handle 
 and just do a pairwise type conversion.
 
 Testing: failing test case, nashorn w/ experimental features (octane)
 
 Thanks!
 
 Best regards,
 Vladimir Ivanov
 
 [1] MethodHandle.invokeWithArguments
 Performs a variable arity invocation, ..., as if via an inexact invoke 
 from a call site which mentions only the type Object, and whose arity is 
 the length of the argument array.
 
 [2] MethodHandle.asVarargsCollector
 When called with plain, inexact invoke, if the caller type is the same 
 as the adapter, the adapter invokes the target as with invokeExact. 
 (This is the normal behavior for invoke when types match.)
 
 Otherwise, if the caller and adapter arity are the same, and the 
 trailing parameter type of the caller is a reference type identical to 
 or assignable to the trailing parameter type of the adapter, the 
 arguments and return values are converted pairwise, as if by asType on a 
 fixed arity method handle.
 
 Otherwise, the arities differ, or the adapter's trailing parameter type 
 is not assignable from the corresponding caller type. In this case, the 
 adapter replaces all trailing arguments from the original trailing 
 argument position onward, by a new array of type arrayType, whose 
 elements comprise (in order) the replaced arguments.
 ___
 mlvm-dev mailing list
 mlvm-dev@openjdk.java.net
 http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

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

[Christian Thalinger]

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 
 these changes.
 
 I changed LF representation a bit and added 2 auxiliary method handles 
 - argument boxing and wrapping into Object[] and result unboxing. These 
 operations depend on actual type and can't be shared among arbitrary 
 combinators with the same basic type. They are used only during LF 
 interpretation and are completely ignored in compiled LFs.
 
 On 2/20/14 7:51 PM, Paul Sandoz wrote:
 Hi Vladimir,
 
 I know just enough about this area to be dangerous
 
 
 src/share/classes/java/lang/invoke/BoundMethodHandle.java
 
  865 private static final SpeciesData[] SPECIES_DATA_CACHE = new 
 SpeciesData[4];
 
 
 Only 3 elements are stored in the above array?
 Fixed.
 
 
 
 
 src/share/classes/java/lang/invoke/MethodHandleImpl.java
 
  634 // t_{i+2}:L=ValueConversions.unbox(t_{i+1}) OR 
 ValueConversions.identity(t_{i+1})
  635 if (type.returnType().isPrimitive()) {
  636 names[UNBOX_RESULT] = new 
 Name(ValueConversions.unbox(type.returnType()),
  637   names[TRY_CATCH]);
  638 } else {
  639 names[UNBOX_RESULT] = new Name(ValueConversions.identity(),
  640   names[TRY_CATCH]);
  641 }
 
 
 You could create the form without the identity transform for the 
 non-primitive case?
 
   final int UNBOX_RESULT = type.returnType().isPrimitive() ? nameCursor++ : 
 0;
 ...
 
   if (UNBOX_RESULT  0) { ...
   names[UNBOX_RESULT] = new 
 Name(ValueConversions.unbox(type.returnType()), names[TRY_CATCH]);
   }
 I can, but it complicates matching and compiling the pattern in 
 InvokerBytecodeGenerator. I decided to keep the shape uniform for all cases.
 
 
 
  699 try {
  700 GUARD_WITH_CATCH
  701 = IMPL_LOOKUP.findStatic(MethodHandleImpl.class, 
 guardWithCatch,
  702 MethodType.methodType(Object.class, 
 MethodHandle.class, Class.class, MethodHandle.class, Object[].class));
  703 } catch (ReflectiveOperationException ex) {
  704 throw new RuntimeException(ex);
  705 }
  706 return GUARD_WITH_CATCH;
 
 
 Should #704 be:
 
   throw newInternalError(ex);
 
 ?
 Fixed. Also updated other places where RuntimeException was thrown.

A tiny bit of history here on newInternalError:  in JDK 8 we added new 
constructors that take a cause as argument; JDK 7 doesn’t have them.  In order 
to make java.lang.invoke backporting from 8 to 7 easier we used a wrapper 
method to instantiate InternalErrors.

 
 
 
 test/java/lang/invoke/MethodHandles/TestCatchException.java
 
  100 Object o = new Object();
  101 Object[] obj1 = new Object[] { str };
  102
  103 Object r1 = target.invokeExact(o, o, o, o, o, o, o, o, obj1);
  104 Object r2 = gwc.invokeExact(o, o, o, o, o, o, o, o, obj1);
  105 assertTrue(r1 != null);
  106 assertTrue(r1.equals(r2));
 
 To be on the safe side should probably assert as follows:
 
   assertEquals(r1, obj);
   assertEquals(r2, obj);
 Fixed.
 
 Best regards,
 Vladimir Ivanov
 
 Paul.
 
 
 On Feb 19, 2014, at 10:46 PM, Vladimir Ivanov vladimir.x.iva...@oracle.com 
 wrote:
 
 http://cr.openjdk.java.net/~vlivanov/8027827/final/webrev.00
 https://jbs.oracle.com/bugs/browse/JDK-8027827
 354 lines changed: 193 ins; 91 del; 70 mod
 
 OVERVIEW
 
 MethodHandles.catchException combinator implementation is based on generic 
 invokers (MethodHandleImpl$GuardWithCatch.invoke_*). It is significantly 
 slower than a Java equivalent (try-catch).
 
 Future Nashorn performance improvements require catchException combinator 
 speed to be on par with try-catch in Java.
 
 So, it should be represented in a more efficient form.
 
 I chose the following lambda form representation:
 
  t_{i}:L=ValueConversions.array(a1:L,...,a_{k}:L);
 t_{i+1}:L=MethodHandleImpl.guardWithCatch(t_{p1}, t_{p2}, t_{p3}, t_{i}:L);
 t_{i+2}:I=ValueConversions.unbox(t7:L);
 OR :L=ValueConversions.identity(t_{n+1})
 OR :V=ValueConversions.ignore(t_{n+1})
 
 where:
  a1, ..., a_{k} - arguments
  t_{p1}, t_{p2}, t_{p3} - target method handle, exception class, catcher 
 method handle respectively; passed as bounded parameters;
 
 During lambda form compilation it is converted into bytecode equivalent of 
 the following Java code:
  try {
  return target.invokeBasic(...);
  } catch(Throwable e) {
  if (!exClass.isInstance(e)) throw e;
  return catcher.invokeBasic(e, ...);
  }
 
 There's a set of microbenchmarks (attached to the bug) I wrote to verify 
 performance characteristics of new implementation.
 
 FURTHER WORK
 
 What is missing is lambda 

Re: Groovy bugs on JIRA

[Christian Thalinger]

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 cedric.champ...@gmail.com wrote:

 Alright, so after building the latest (jdk7u this time) JDK sources... I have 
 coherent (but failing) results. Both 7u60b04 [1] and latest jdk7 sources [2] 
 fail, with similar errors:
 
 target and fallback types must match: 
 (Object,Object,Object,Object,Object,Object,Object,Object,Object)Object != 
 (Class,SourceUnit,Object,Object,Object,Object,Expression,Object,Object)Object
 
 This means that [3] can be closed, but not [4].
 
 Best regards,
 
 (login: guest, no password)
 
 [1] 
 http://ci.groovy-lang.org/viewLog.html?buildTypeId=Groovy_Jdk7snapshotBuildbuildId=878
 [2] 
 http://ci.groovy-lang.org/viewLog.html?buildTypeId=Groovy_Jdk7snapshotBuildbuildId=877
 [3] https://bugs.openjdk.java.net/browse/JDK-8033671
 [4] https://bugs.openjdk.java.net/browse/JDK-8033669
 
 Le 07/02/2014 09:49, Cédric Champeau a écrit :
 Hi all,
 
 I am the reporter of both bugs on JIRA, on behalf of the Groovy team. I 
 would definitely like to comment on the JIRA issues and give more insight 
 here, unfortunately this is impossible and it makes communication really 
 painful. I created those bug reports after Rory asked me to. So I feel like 
 repeating myself too many times. Now that I bragged about it, let's get to 
 the point :)
 
 So the context. We have a CI server which tests multiple JDK configurations. 
 All configurations can be seen in [1], the server is public, you have access 
 to all build log files as well as exception stack traces (just use guest 
 to login and no password).
 
 The JDK 7 build is using JDK 1.7u11, which is the latest JDK7 version to 
 successfully pass all tests of Groovy.
 The JDK 7 snapshot build is using a JDK built from sources. It is using 
 the *latest sources*, and it corresponds to the bug report [2]. So when you 
 see b17, it doesn't mean it corresponds to *your* b17, it's just that JDK7 
 uses an environment variable to set the build version, while JDK8 does *not* 
 (uses -internal instead).
 The JDK 8 snapshot build is using a JDK built from sources too. This 
 version passes all tests of Groovy.
 
 We also run specific builds when you release EAP versions of the JDK. This 
 one [4] is for example on JDK7u60b04. So my first bug report[3] corresponds 
 to a crash test on JDK7u60b04, that is to say the latest published JDK7 
 version. This is really different from my second bug report [2] which 
 corresponds to the latest state of JDK7 sources.
 
 So to sum up:
 * no version of JDK7u60, be it 7u60b04 or latest sources, allows us to 
 build Groovy. The errors are indeed different in both versions, hence 
 different bug reports, but reproducible, as I encourage you to take a look 
 at the stack traces on the CI server.
 * JDK8, including the RC, passes the build successfully.
 * JDK7u11 is the *latest* known version of JDK which successfully passes 
 the Groovy build *and* doesn't have any annoying bug (like the infinite loop 
 in classloader)
 
 It would really be a pity if u60 goes out and that we still don't have a 
 JDK7 version which successfully completes the Groovy build. The fact that we 
 don't have the same errors on 7u60b04 and snapshot jdk is puzzling and makes 
 things even more complicated. I just hope those explanations make things 
 clearer.
 
 
 [1] http://ci.groovy-lang.org/
 [2] https://bugs.openjdk.java.net/browse/JDK-8033671
 [3] https://bugs.openjdk.java.net/browse/JDK-8033669
 [4] 
 http://ci.groovy-lang.org/viewLog.html?buildId=410tab=buildResultsDivbuildTypeId=Groovy_Jdk7snapshotBuild
 
 Best regards,
 -- 
 Cédric Champeau
 SpringSource - Pivotal
 http://spring.io/
 http://www.gopivotal.com/
 http://twitter.com/CedricChampeau
 
 
 -- 
 Cédric Champeau
 SpringSource - Pivotal
 http://spring.io/
 http://www.gopivotal.com/
 http://twitter.com/CedricChampeau

___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

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

[Christian Thalinger]

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 class is omitted.
 
 The fix is to ensure that access check on a reference class is always 
 performed.
 
 Testing: regression test, jdk/test/java/lang/invoke/, 
 jdk/test/java/util/stream, vm.defmeth.testlist, vm.mlvm.testlist, 
 nashorn (unit tests, octane), groovy
 
 Thanks!
 
 Best regards,
 Vladimir Ivanov
 
 [1] http://cr.openjdk.java.net/~vlivanov/8032585/webrev.00/
 ___
 mlvm-dev mailing list
 mlvm-dev@openjdk.java.net
 http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

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

[Christian Thalinger]

[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 incorrect bytecode for a LambdaForm 
 when invoking a method from Object declared in an interface.
 
 The problem is the following:
   (1) java.lang.CharSequence interface declares abstract method String 
 toString();
 
   (2) after 8014013 fix, VM resolves 
 CharSequence::toString()/invokeInterface to 
 CharSequence::toString()/invokeVirtual;

Without having looked at the changes of 8014013, why did the invoke type 
change?  Is it an optimization that was added?

 
   (3) during LambdaForm compilation, CharSequence is considered 
 statically invocable (see 
 InvokeBytecodeGenerator::isStaticallyInvocable) and invokevirtual for 
 CharSequence::toString() is issued, which is wrong (invokevirtual throws 
 ICCE if it references an interface);
 
 The fix is straightforward: during LambdaForm compilation, switch back 
 from invokevirtual to invokeinterface instruction when invoking a method 
 on an interface.

I find this risky.  Right now MemberName is only used in a couple places in 
java.lang.invoke but in the future it might be used for other things (e.g. 
java.lang.reflect).  The information MemberName contains should be correct and 
usable without changing.  Otherwise all users have to patch the information the 
same way as you do in your patch.

I would like to see the VM passing correct information (whatever the definition 
of correct is here).

 
 The fix is targeted for 8. Will be also integrated into 9.
 
 Testing: regression test, jdk/test/java/lang/invoke, vm.mlvm.testlist, 
 nashorn, jruby.
 
 Thanks!
 
 Best regards,
 Vladimir Ivanov
 ___
 mlvm-dev mailing list
 mlvm-dev@openjdk.java.net
 http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

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

[Christian Thalinger]

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 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 incorrect bytecode for a LambdaForm
 when invoking a method from Object declared in an interface.
 
 The problem is the following:
   (1) java.lang.CharSequence interface declares abstract method String
 toString();
 
   (2) after 8014013 fix, VM resolves
 CharSequence::toString()/invokeInterface to
 CharSequence::toString()/invokeVirtual;
 
 Without having looked at the changes of 8014013, why did the invoke type 
 change?  Is it an optimization that was added?
 
 
 After 8014013, LinkResolver::resolve_interface_call returns virtual 
 (_call_kind = CallInfo::vtable_call), instead of interface method and 
 MethodHandles::init_method_MemberName uses it as is (without any fine 
 tuning, which was done before).
 
 It's caused by the following:
   - LinkResolver::linktime_resolve_interface_method returns 
 CharSequence::toString method, but it has vtable index, instead of 
 itable index;
 
   - LinkResolver::runtime_resolve_interface_method looks at resolved 
 method and sets _call_kind to vtable_call, since resolved method doesn't 
 have itable index.
 
   - then MethodHandles::init_method_MemberName looks at CallInfo passed 
 in and sets the reference kind flag to JVM_REF_invokeVirtual.
 
 That's how the conversion from invokeInterface to invokeVirtual occurs.
 
 I did a quick debugging session with pre-8014013 hotspot to check how it 
 worked before, but don't remember all the details now.
 
 
   (3) during LambdaForm compilation, CharSequence is considered
 statically invocable (see
 InvokeBytecodeGenerator::isStaticallyInvocable) and invokevirtual for
 CharSequence::toString() is issued, which is wrong (invokevirtual throws
 ICCE if it references an interface);
 
 The fix is straightforward: during LambdaForm compilation, switch back
 from invokevirtual to invokeinterface instruction when invoking a method
 on an interface.
 
 I find this risky.  Right now MemberName is only used in a couple places in 
 java.lang.invoke but in the future it might be used for other things (e.g. 
 java.lang.reflect).  The information MemberName contains should be correct 
 and usable without changing.  Otherwise all users have to patch the 
 information the same way as you do in your patch.
 
 I would like to see the VM passing correct information (whatever the 
 definition of correct is here).
 
 
 It's an interesting question what kind of correctness is required for 
 MemberName and I don't know the answer. Looking through the code, I got 
 an impression MemberName isn't designed to provide information to be 
 used as is for bytecode generation, because, at least:
   - MemberName::referenceKindIsConsistent already expects 
 (clazz.isInterface()  refKind == REF_invokeVirtual  
 isObjectPublicMethod()) case;
 
   - InvokeBytecodeGenerator::emitStaticInvoke already has a special 
 case for REF_invokeSpecial referenceKind, converting it to 
 REF_invokeVirtual;

John would know the answer.

Given this change should go into JDK 8 I think we should push for now.  If we 
can come up with a better way to handle these situations we can push another 
change for 9 or 8u20.

 
 Best regards,
 Vladimir Ivanov
 ___
 mlvm-dev mailing list
 mlvm-dev@openjdk.java.net
 http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

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

[Christian Thalinger]

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 of classes at startup. 
 I don't know how much impact that will have

If it’s only hundreds it’s probably negligible.  You could do a simple 
experiment if you are worried:  change ClassValueMap.INITIAL_ENTRIES to 1, 
compile it and prepend it to the bootclasspath.

 
 bye Jochen
 
 -- 
 Jochen blackdrag Theodorou - Groovy Project Tech Lead
 blog: http://blackdragsview.blogspot.com/
 german groovy discussion newsgroup: de.comp.lang.misc
 For Groovy programming sources visit http://groovy-lang.org
 
 ___
 mlvm-dev mailing list
 mlvm-dev@openjdk.java.net
 http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

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

[Christian Thalinger]

On Jan 8, 2014, at 2:26 AM, MacGregor, Duncan (GE Energy Management) 
duncan.macgre...@ge.com wrote:

 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.

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 Project 
 mlvm-dev@openjdk.java.netmailto:mlvm-dev@openjdk.java.net
 Subject: 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 Systemhttps://bugs.openjdk.java.net/browse/JDK-8031043
 
 Is my assumption correct that most language runtimes only attach a small 
 number of values (maybe only one) or that it wouldn’t matter if the map would 
 grow as needed?
 ___
 mlvm-dev mailing list
 mlvm-dev@openjdk.java.net
 http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

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

[Christian Thalinger]

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://bugs.openjdk.java.net/browse/JDK-8031043
 
 Is my assumption correct that most language runtimes only attach a 
 small number of values (maybe only one) or that it wouldn’t matter if 
 the map would grow as needed?
 
 I see a good reason to have more than one ClassValue per runtime,
 you want monkey patch realm, you want to be able to modify the class 
 (meta class ?) of your runtime objects but you want several views of the 
 class depending on the source file or the 'module' of the source file. 
 There was some discussions about that in Ruby and Groovy 3 seems to 
 support something like that too.
 
 Anyway, monkey patching is not a fast operation usually because of the 
 switch point invalidation so if it grows as needed, it should not be a 
 problem.

That’s what I figured.  Thanks.

 
 Rémi
 
 ___
 mlvm-dev mailing list
 mlvm-dev@openjdk.java.net
 http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

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

[Christian Thalinger]

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 https://bugs.openjdk.java.net/browse/JDK-8031043
 
 Is my assumption correct that most language runtimes only attach a small
 number of values (maybe only one) or that it wouldn’t matter if the map
 would grow as needed?
 
 I expect about 3-5 values for Groovy 3 as the standard case. 32 might be 
 really too much, 8 would be probably still enough for most use cases

If we’d go with an initial value of 1 would it be a performance problem for you 
if it grows automatically?

 
 bye Jochen
 
 -- 
 Jochen blackdrag Theodorou - Groovy Project Tech Lead
 blog: http://blackdragsview.blogspot.com/
 german groovy discussion newsgroup: de.comp.lang.misc
 For Groovy programming sources visit http://groovy-lang.org
 
 ___
 mlvm-dev mailing list
 mlvm-dev@openjdk.java.net
 http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

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

[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

Is my assumption correct that most language runtimes only attach a small number 
of values (maybe only one) or that it wouldn’t matter if the map would grow as 
needed?___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

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

[Christian Thalinger]

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) { 
 public static RtCallSite bootStrapSelf(MethodHandles.Lookup callerLookup, 
 String name, MethodType type, Object... arg) { 
 
 The type errors went away so I assume this was a good idea but now I get a 
 hard trap shortly after I enter my dynamic code. About 
 300 or so method creations in. 
 
 The log has lots of: 
 instanceKlass java/lang/invoke/LambdaForm$BMH 
 instanceKlass java/lang/invoke/LambdaForm$MH 
 instanceKlass java/lang/invoke/LambdaForm$MH 
 instanceKlass java/lang/invoke/LambdaForm$BMH 
 instanceKlass java/lang/invoke/LambdaForm$MH 
 instanceKlass java/lang/invoke/LambdaForm$MH 
 
 like a couple hundred in a row in one spot.  I am using the ExactMath class 
 to do longs and I seem to recall 
 some issues there as well. 

Exact math intrinsics are disabled in the next build (25.0-b62; or b120 for 
that matter):

https://bugs.openjdk.java.net/browse/JDK-8028997

Try: -XX:-UseMathExactIntrinsics

 
 I am also running in Eclipse Luna. 
 
 The fault says: 
 # A fatal error has been detected by the Java Runtime Environment: 
 # 
 #  SIGSEGV (0xb) at pc=0x0001102cd02c, pid=3318, tid=20995 
 # 
 # JRE version: Java(TM) SE Runtime Environment (8.0-b119) (build 
 1.8.0-ea-b119) 
 # Java VM: Java HotSpot(TM) 64-Bit Server VM (25.0-b61 mixed mode bsd-amd64 
 compressed oops) 
 # Problematic frame: 
 # V  [libjvm.dylib+0x39902c] 
 # 
 
 any suggestions?  I plan to try compile and run outside of eclipse and add 
 logging to see if the crash 
 is repeatable. 

If it still crashes with exact math intrinsics off try to build a debug VM so 
we can see if we hit an assert.

 
 thx 
 mark___
 mlvm-dev mailing list
 mlvm-dev@openjdk.java.net
 http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

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

[Christian Thalinger]

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 collectArguments(mh, N, coll)}
+ * is equivalent to {@code filterArguments(mh, N, coll)}.

Otherwise this looks good.

On Sep 12, 2013, at 7:55 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/8001110/webrev.00/
 
 Summary: promote an existing private method; make unit tests on all argument 
 positions to arity 10 with mixed types
 
 The change is to javadoc and unit tests, documenting and testing some corner 
 cases of JSR 292 APIs.
 
 Bug Description:  Currently, a method handle can be transformed so that 
 multiple arguments are collected and passed to the original method handle. 
 However, the two routes to doing this are both limited to special purposes. 
 
 (They are asCollector, which collects only trailing arguments, and only into 
 an array; and foldArguments, which collects only leading arguments into 
 filter function, and passes both the filtered result *and* the original 
 arguments to the original.)
 
 MethodHandles.collectArguments(mh, pos, collector) should produce a method 
 handle which acts like lambda(a*, b*, c*) { x = collector(b*); return mh(a*, 
 x, c*) }, where the span of arguments b* is located by pos and the arity of 
 the collector.
 
 There is internal machinery in any JSR 292 implementation to do this. It 
 should be made available to users.
 
 This is a missing part of the JSR 292 spec.
 
 Thanks,
 — John
 
 P.S. Since this is a change which oriented toward JSR 292 functionality, the 
 review request is to mlvm-dev and core-libs-dev.
 Changes which are oriented toward performance will go to mlvm-dev and 
 hotspot-compiler-dev.
 ___
 mlvm-dev mailing list
 mlvm-dev@openjdk.java.net
 http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

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

[Christian Thalinger]

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 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 name=privacc/a
 + * emDiscussion of private access:/em
 
 Same here.
 
 + * h1a name=secmgr/aSecurity manager interactions/h1
 
 And here.
 
 Wow; I don't know where HTML5 fits in the javadoc story.  That might be nice 
 to upgrade, but I'm not gonna go first:

Sure :-)  It was only a note.

 
   fgrep 'a name=' $(hg loc -I src/share/classes/java -X 
 src/share/classes/java/lang/invoke) | wc
 2351372   23349
 
   fgrep 'a id=' $(hg loc -I src/share/classes/java -X 
 src/share/classes/java/lang/invoke) | wc
   0   0   0
 
   grep '[a-z]* id=' $(hg loc -I src/share/classes/java) | wc
  12  721186   ## a few CSS tags
 
   fgrep 'a name=' $(hg loc -I src/share/classes/java/lang/invoke) | wc
   8  46 884## lots of people were going faster than me, 
 officer!
 
 
 + * because the desired class member is missing, because the
 
 Did you want an or before because like the others?
 
 Yes, you are right.  It started out as a, b, or c but then got out of 
 control.  Switching to a, or b, or
 
 Otherwise this looks good.
 
 Thanks.  At your verbal suggestion I also did this:
 
  * If the filter returns a value, the target must accept that value as
 - * its {@code pos} argument, plus any arguments not passed to the filter.
 + * its argument in position {@code pos}, preceded and/or followed by
 + * any arguments not passed to the filter.
  * If the filter returns void, the target must accept all arguments
  * not passed to the filter.

Thanks!

 
 — John
 ___
 mlvm-dev mailing list
 mlvm-dev@openjdk.java.net
 http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

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

[Christian Thalinger]

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 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 much value in documenting buggy behavior of early JDK7 in JDK8 
 code. So, I would remove it.
 
 OK.  I think I had it in mainly to make sure the unit tests did something 
 interesting.
 
 
 Regarding the test:
 31  * @run main/othervm/timeout=3600
 - why do you have timeout set to 1h?
 
 Copy-and-paste from some other test.  Removed.
 
 I like the idea how you count events.
 
 As a suggestion for enhancement - maybe it's more reliable to check the 
 type of event as well? To ensure that particular class was initialized.
 
 Good idea.  But since each unique init event is stored in a separate 
 variable, it's easy to check this without explicit event types.  I did the 
 following, for each of the six test cases:
 
 @@ -150,9 +150,11 @@
   }
 
   private static int runFoo() throws Throwable {
 +assertEquals(Init1Tick, 0);  // Init1 not initialized yet
   int t1 = tick(runFoo);
   int t2 = (int) INDY_foo().invokeExact();
   int t3 = tick(runFoo done);
 +assertEquals(Init1Tick, t2);  // when Init1 was initialized
   assertEquals(t1+2, t3);  // exactly two ticks in between
   assertEquals(t1+1, t2);  // init happened inside
   return t2;
 
 
 
 — John
 
 Best regards,
 Vladimir Ivanov
 
 On 9/20/13 1:38 AM, John Rose wrote:
 On Sep 12, 2013, at 7:24 PM, John Rose john.r.r...@oracle.com
 mailto:john.r.r...@oracle.com wrote:
 
 Please review this change for a change to the JSR 292 implementation:
 
 http://cr.openjdk.java.net/~jrose/8024599/webrev.00/
 
 Summary: Align MH semantic with bytecode behavior of constructor and
 static member accesses, regarding clinit invocation.
 
 The change is to javadoc and unit tests, documenting and testing some
 corner cases of JSR 292 APIs.
 
 I have a reviewer (Alex Buckley) for the documentation changes, but I
 would also like a quick code review for the unit test.
 
 Also, there is a code insertion (predicated on a false symbolic
 constant) which serves to document the buggy JDK 7 behavior.  I'm not
 particularly attached to it, so I'm open to either a yea or nay on
 keeping it.  Leaning nay at the moment.
 
 — John
 
 
 ___
 mlvm-dev mailing list
 mlvm-dev@openjdk.java.net
 http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
 
 
 ___
 mlvm-dev mailing list
 mlvm-dev@openjdk.java.net
 http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
 
 ___
 mlvm-dev mailing list
 mlvm-dev@openjdk.java.net
 http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
 
 ___
 mlvm-dev mailing list
 mlvm-dev@openjdk.java.net
 http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

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

[Christian Thalinger]

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 much value in documenting buggy behavior of early JDK7 in JDK8 
 code. So, I would remove it.
 
 OK.  I think I had it in mainly to make sure the unit tests did something 
 interesting.

 
 Regarding the test:
 31  * @run main/othervm/timeout=3600
 - why do you have timeout set to 1h?
 
 Copy-and-paste from some other test.  Removed.
 
 I like the idea how you count events.
 
 As a suggestion for enhancement - maybe it's more reliable to check the 
 type of event as well? To ensure that particular class was initialized.
 
 Good idea.  But since each unique init event is stored in a separate 
 variable, it's easy to check this without explicit event types.  I did the 
 following, for each of the six test cases:
 
 @@ -150,9 +150,11 @@
 }
 
 private static int runFoo() throws Throwable {
 +assertEquals(Init1Tick, 0);  // Init1 not initialized yet
 int t1 = tick(runFoo);
 int t2 = (int) INDY_foo().invokeExact();
 int t3 = tick(runFoo done);
 +assertEquals(Init1Tick, t2);  // when Init1 was initialized
 assertEquals(t1+2, t3);  // exactly two ticks in between
 assertEquals(t1+1, t2);  // init happened inside
 return t2;

 
 
 — John
 
 Best regards,
 Vladimir Ivanov
 
 On 9/20/13 1:38 AM, John Rose wrote:
 On Sep 12, 2013, at 7:24 PM, John Rose john.r.r...@oracle.com
 mailto:john.r.r...@oracle.com wrote:
 
 Please review this change for a change to the JSR 292 implementation:
 
 http://cr.openjdk.java.net/~jrose/8024599/webrev.00/
 
 Summary: Align MH semantic with bytecode behavior of constructor and
 static member accesses, regarding clinit invocation.
 
 The change is to javadoc and unit tests, documenting and testing some
 corner cases of JSR 292 APIs.
 
 I have a reviewer (Alex Buckley) for the documentation changes, but I
 would also like a quick code review for the unit test.
 
 Also, there is a code insertion (predicated on a false symbolic
 constant) which serves to document the buggy JDK 7 behavior.  I'm not
 particularly attached to it, so I'm open to either a yea or nay on
 keeping it.  Leaning nay at the moment.
 
 — John
 
 
 ___
 mlvm-dev mailing list
 mlvm-dev@openjdk.java.net
 http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
 
 
 ___
 mlvm-dev mailing list
 mlvm-dev@openjdk.java.net
 http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

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

[Christian Thalinger]

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 ClassVerifier::verify_invoke_instructions
 ++   // and LinkResolver::check_method_accessability.)
 ++   // Because the JVM does not allow separate methods on array types,
 +// there is no separate method for int[].clone.
 +// All arrays simply inherit Object.clone.
 +// But for access checking logic, we make Object.clone
 +// (normally protected) appear to be public.
 +// Later on, when the DirectMethodHandle is created,
 +// its leading argument will be restricted to the
 +// requested array type.
 ++   // N.B. The return type is not adjusted, because
 ++   // that is *not* the bytecode behavior.
 
 Oddly, the JVMS does not mention this hack explicitly.  Maybe it's buried in 
 the Prolog code.
 
 On Sep 21, 2013, at 2:34 AM, Morris Meyer morris.me...@oracle.com wrote:
 
 This looks good.  Might want to point out where in HotSpot this change 
 originates from in your comment.
 
   --mm
 
 
 On Sep 18, 2013, at 10:32 PM, John Rose ros...@me.com wrote:
 
 http://cr.openjdk.java.net/~jrose/8001105/webrev.00/
 
 Summary: Replicate JVM logic for access control that makes Object.clone 
 appear public when applied to an array type.
 
 See: 
 http://mail.openjdk.java.net/pipermail/mlvm-dev/2012-October/005035.html
 
 — John
 
 
 ___
 mlvm-dev mailing list
 mlvm-dev@openjdk.java.net
 http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
 ___
 mlvm-dev mailing list
 mlvm-dev@openjdk.java.net
 http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
 
 ___
 mlvm-dev mailing list
 mlvm-dev@openjdk.java.net
 http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

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

[Christian Thalinger]

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 name=privacc/a
+ * emDiscussion of private access:/em

Same here.

+ * h1a name=secmgr/aSecurity manager interactions/h1

And here.

+ * because the desired class member is missing, because the

Did you want an or before because like the others?

Otherwise this looks good.

On Oct 1, 2013, at 3:19 PM, John Rose john.r.r...@oracle.com wrote:

 http://cr.openjdk.java.net/~jrose/8024438/webrev.00
 
 These are miscellaneous edits to javadoc and unit tests, clarifying various 
 minor corner cases and improving presentation.
 
 There is also a single API change (already under review by CCC): Adding a 
 missing wildcard to Constructor?.
 
 Please review.
 
 Thanks,
 — John
 
 ___
 mlvm-dev mailing list
 mlvm-dev@openjdk.java.net
 http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

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

[Christian Thalinger]

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., getDirectMethodNoSecurityManager.  The result is more 
 clearly correct and maintainable.
 
 Here is the respin:
  http://cr.openjdk.java.net/~jrose/8025112/webrev.01
 
 — John
 
 On Oct 1, 2013, at 3:15 PM, John Rose john.r.r...@oracle.com wrote:
 
 This change updates the javadoc to reflect previous changes in the behavior 
 of the security manager, especially with respect to caller sensitivity.
 
 It also adjusts some unit tests.
 
 The key change is to the order of the security manager logic.  The purpose 
 is to align the bytecode behavior of method handles more closely with the 
 native behavior of the corresponding bytecode instructions.  This means that 
 fully trusted method handles do not incur security checks if they are 
 equivalent to bytecodes that the user could have written.
 
 The API spec. and security rules have been internally reviewed.  This is a 
 review of implementation and unit tests.
 
 http://cr.openjdk.java.net/~jrose/8025112/webrev.00
 
 For more background, see my JavaOne presentation:
 http://cr.openjdk.java.net/~jrose/pres/201309-IndyUpdate.pdf
 
 Thanks,
 — John
 
 ___
 mlvm-dev mailing list
 mlvm-dev@openjdk.java.net
 http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

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

[Christian Thalinger]

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 missing p in a few 
 other places too.
 
 The test code looks ok, though the logic is over-complicated.
 But the whole MethodHandlesTest is written in the same vein.
 
 Thanks.  (Looks like it wasn't written by a real test engineer.)

:-D  I try to not touch MethodHandlesTest.  We should think about splitting it 
into smaller test cases.

 
 — John
 ___
 mlvm-dev mailing list
 mlvm-dev@openjdk.java.net
 http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

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

[Christian Thalinger]

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)
 +MethodType invocationType = 
 MethodType.genericMethodType(3 + argv.length);
 +MethodHandle spreader = 
 invocationType.invokers().spreadInvoker(3);
 
 Could we use a defined constant for 3?
 
 Yes.
 
 src/share/classes/java/lang/invoke/Invokers.java:
 
 +if (targetType == targetType.erase()  targetType.parameterCount() 
  10)
 
 The same here for 10.
 
 Fixed; factored to a subroutine.
 
 Actually, exactInvoker and generalInvoker's code could be factored into one 
 method.
 
 +/*non-public*/ MethodHandle basicInvoker() {
 +//invoker.form.compileToBytecode();
 
 Done.
 
 Please remove commented lines.
 
 +static MemberName exactInvokeLinkerMethod(MethodType mtype, Object[] 
 appendixResult) {
 +static MemberName genericInvokeLinkerMethod(MethodType mtype, Object[] 
 appendixResult) {
 
 These two could also be factored into one method.
 
 Done.  I removed those two, and called the one new method from 
 MethodHandleNatives.
 
 +// Return an adapter for invokeExact or generic invoke, as a MH or 
 constant pool linker
 +// mtype : the caller's method type (either basic or full-custom)
 +// customized : whether to use a trailing appendix argument (to carry 
 the mtype)
 +// which0x01 : whether it is a CP adapter (linker) or MHs.invoker 
 value (invoker)
 +// which0x02 : whether it is for invokeExact or generic invoke
 +//
 +// If !customized, caller is responsible for supplying, during adapter 
 execution,
 +// a copy of the exact mtype.  This is because the adapter might be 
 generalized to
 +// a basic type.
 +private static LambdaForm invokeHandleForm(MethodType mtype, boolean 
 customized, int which) {
 
 Why are you not using Javadoc style for this method comment?  It's still 
 helpful in IDEs.
 
 Fixed.
 
 src/share/classes/java/lang/invoke/LambdaForm.java:
 
static void traceInterpreter(String event, Object obj, Object... args) {
 +if (!(TRACE_INTERPRETER  INIT_DONE))  return;
 
 Done.
 
 Why not use the same pattern:
 
 +if (TRACE_INTERPRETER  INIT_DONE)
 
 as the other places?
 
 +static final boolean INIT_DONE = Boolean.TRUE.booleanValue();
 
 Why are we having this after all?
 
 I removed it; see webrev.  There's a comment which explains the problem and 
 the nicer replacement.

Good comment.  Thank you.

 
 src/share/classes/java/lang/invoke/MemberName.java:
 
 +public MemberName asNormalOriginal() {
 
 Could you add a comment to this method?  It's not clear to me what normal 
 and original mean here.
 
 Done.
 
 +public MemberName(byte refKind, Class? defClass, String name, Object 
 type) {
 +@SuppressWarnings(LocalVariableHidesMemberVariable)
 +int kindFlags;
 
 The SuppressWarnings is in the other constructors because of the name 
 flags.  You don't need it here.  Maybe rename the others as well and get 
 rid of the annotation.
 
 OK; I removed 2/3 of them.
 
 src/share/classes/java/lang/invoke/MethodHandleNatives.java:
 
static String refKindName(byte refKind) {
assert(refKindIsValid(refKind));
 -return REFERENCE_KIND_NAME[refKind];
 +switch (refKind) {
 
 After this change REFERENCE_KIND_NAME is not used anymore.
 
 Good catch.
 
 src/share/classes/java/lang/invoke/MethodHandles.java:
 
 +member.getName().getClass(); member.getType().getClass();  // 
 NPE
 
 Please don't!  It would be nice to have at least a different line number in 
 the backtrace.
 
 OK.  I split three such lines.
 
 I would like to switch all these to Objects.requireNonNull, but only after a 
 little performance testing to make sure we don't have surprises.
 
 src/share/classes/java/lang/invoke/MethodTypeForm.java:
 
 +//Lookup.findVirtual(MethodHandle.class, name, type);
 
 Either remove it or add a comment why it's there.
 
 Commented better now.

 
 While testing, I found a spot in BoundMethodHandle that needed a tweak to 
 avoid a bootstrap problem.  (Too many of those.)

 
 I sharpened the type of 'caller' in CallSite.makeSite.

 
 The webrev is updated:
  http://cr.openjdk.java.net/~jrose/8024761/webrev.01/

This looks good.

 
 Thanks!
 
 — John
 
 On Sep 12, 2013, at 6:36 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/8024761/webrev.00/
 
 Bug description:  The performance of MethodHandle.invoke is very slow when 
 the call site type differs from the method handle type. When the types 
 differ, the invocation is defined to proceed as if two steps were taken: 
 
 1. the target method handle is first adjusted to the call site

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

[Christian Thalinger]

On Sep 19, 2013, at 9:57 AM, David Chase david.r.ch...@oracle.com wrote:

 Recommended changes made:
 
 http://cr.openjdk.java.net/~drchase/8022701/webrev.04/

Looks good.  Thanks for using ASM.

 
 Test with jtreg (for pass and for induced failure) on MacOS,
 not sure what additional other testing is desired since it is entirely in the 
 libraries.
 
 I included code to handle the case of a broken field-referencing methodhandle,
 but did not test it because there's no syntax for these in Java, nor is their 
 creation
 well-documented.
 
 David
 
 
 On 2013-09-13, at 12:02 AM, John Rose john.r.r...@oracle.com wrote:
 
 On Sep 12, 2013, at 5:44 PM, David Chase david.r.ch...@oracle.com wrote:
 
 Do these sibling bugs have numbers?
 
 Yes, 8022701.  I just updated the bug to explain their common genesis.
 
 And I take it you would like to see
 
 1) a test enhanced with ASM to do all 3 variants of this
 
 Yes, please.  The case of no such field does not have a direct cause from 
 lambda expressions AFAIK, but it can occur with raw 
 CONSTANT_MethodHandles.  (It would be reasonable for javac to emit 
 CONSTANT_MH's for fields in some very limited circumstances, but I'll bet it 
 doesn't.)
 
 2) DO attach the underlying cause
 
 Yes.  Read the javadoc for ExceptionInInitializerError for an example of why 
 users want the underlying cause for linkage errors.
 
 (Golly, I wonder what happens if resolution of a CONSTANT_MethodHandle tries 
 to touch a class with a booby-trapped clinit.  I hope it's the case that 
 the ExceptionInInitializerError just passes straight up the stack.  But if 
 it were to get wrapped in a ROE of some sort, it would probably bubble up as 
 an IAE.  Could be a charming exploration.  Actually, no, I don't want to go 
 in there.  Getting all possible linkage errors correct is fine, but we have 
 more important things to do.)
 
 — John
 
 David
 
 On 2013-09-12, at 5:35 PM, John Rose john.r.r...@oracle.com wrote:
 
 It looks good.  I have three requests.
 
 Regarding this comment:
 + * See MethodSupplier.java to see how to produce these bytes.
 + * They encode that class, except that method m is private, not 
 public.
 
 The recipe is incomplete, since it does not say which bits to tweak to 
 make m private.  Please add that step to the comments more explicitly, or 
 if possible to the code (so bogusMethodSupplier is a clean copy of the od 
 output).  I suppose you could ask sed to change the byte for you.  That 
 will make this test a better example for future tests, and make it easier 
 to maintain if javac output changes.  The high road to use would be asm, 
 although for a single byte tweak od works OK.
 
 Also, this bug has two twins.  The same thing will happen with 
 NoSuchMethodE* and NoSuchFieldE*.  Can you please make fixes for those 
 guys also?
 
 FTR, see MemberName.makeAccessException() for logic which maps the other 
 way, from *Error to *Exception.  I don't see a direct way to avoid the 
 double mapping (Error=Exception=Error) when it occurs.
 
 For the initCause bit we should do this:
 
 } catch (IllegalAccessException ex) {
 Error err = new IllegalAccessError(ex.getMessage());
 err.initCause(ex.getCause());  // reuse underlying cause of ex
 throw err;
 } ... and for NSME and NSFE...
 
 That way users can avoid the duplicate exception but can see any 
 underlying causes that the JVM may include.
 
 Thanks for untangling this!
 
 — John
 
 On Sep 12, 2013, at 12:17 PM, David Chase david.r.ch...@oracle.com 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 wrapped with InvocationTargetException, which is 
 completely correct.
 HOWEVER, the exception inside the wrapper is the wrong one.
 
 The new test checks the exception in both the reflective-invocation and 
 plain-invocation cases,
 and also checks both a method handle call (which threw the wrong 
 exception) and a plain
 call (which threw, and throws, the right exception).
 
 The test also uses a tweaked classloader to substitute the borked 
 bytecodes 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:
 http://cr.openjdk.java.net/~drchase/8022701/webrev.03/
 
 I think the change is good given that the tests work now.  Is your test 
 derived from the test in the bug report?
 
 And it would be good if John could also have a quick look (just be to be 
 sure).
 
 -- Chris
 
 
 On 2013-09-12, at 1:53 PM, David Chase david.r.ch...@oracle.com wrote:
 
 I believe it produced extraneous output -- it was not clear to me that 
 it was either necessary or useful to fully describe all the converted

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

[Christian Thalinger]

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 rejects 
 them.
 
 I think you should say JVM byte code verifier here.
 
 Done.  s/byte code/bytecode/.
 
 
 + * em(Note:  JVM internal methods named {@code init} not 
 visible to this API,
 + * even though the {@code invokespecial} instruction can refer to 
 them
 + * in special circumstances.  Use {@link #findConstructor 
 findConstructor}
 
 Not exactly sure but should this read are not visible?
 
 Yes.
 
 
MemberName resolveOrFail(byte refKind, Class? refc, String name, 
 MethodType type) throws NoSuchMethodException, IllegalAccessException {
 +type.getClass();  // NPE
checkSymbolicClass(refc);  // do this before attempting to resolve
 -name.getClass(); type.getClass();  // NPE
 +checkMethodName(refKind, name);
 
 Could you add a comment here saying that checkMethodName does an implicit 
 null pointer check on name?  Maybe a comment for checkMethodName too.
 
 Done.
 
 
 What was the problem with the null pointer exceptions?  Is it okay that we 
 might throw another exception before null checking name?
 
 Foo.  The reordering of those null checks seems to be a needless change that 
 crept in.  I'm going to keep them the way they are.
 
 See updated webrev:
  http://cr.openjdk.java.net/~jrose/8001108/webrev.01/

Looks good.

 
 — John
 
 On Sep 12, 2013, at 6:47 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/8001108/webrev.00
 
 Summary: add an explicit check for leading , upgrade the unit tests
 
 The change is mostly to javadoc and unit tests, documenting and testing 
 some corner cases of JSR 292 APIs.
 
 In the RI, there is an explicit error check.
 
 Thanks,
 — John
 
 P.S. Since this is a change which oriented toward JSR 292 functionality, 
 the review request is to mlvm-dev and core-libs-dev.
 Changes which are oriented toward performance will go to mlvm-dev and 
 hotspot-compiler-dev.
 ___
 mlvm-dev mailing list
 mlvm-dev@openjdk.java.net
 http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
 
 ___
 mlvm-dev mailing list
 mlvm-dev@openjdk.java.net
 http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
 
 ___
 mlvm-dev mailing list
 mlvm-dev@openjdk.java.net
 http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

Re: jdk8 metaspace problem with indy

[Christian Thalinger]

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 it seems. The groovy program looks like this:
 
println Started
for(int i = 0; i  100; i++) {
print .
for (int j=0;j10;j++) {
Container c = new Container()
c.run()
}
}
println \ndone
 
 public class Container implements Runnable {
  public Container() {}
  public void run() {
GroovyShell gs = new GroovyShell()
Script script = gs.parse()
script.run()
  }
 }
 
 What happens is that gs.parse will create a new script and a new class 
 every time. Now using our custom call site code this works fine. Using 
 the indy port, it fails with a permgen error on any jdk7 before u40. On 
 u40 this works fine again. In jdk8 this fails sometimes with a metaspace 
 error, while in u40 it seems to work quite reliable.
 
 The problem must be more than just creating many classes, because our 
 custom callsite caching creates just as many classes for the scripts as 
 the indy version does. What does not happen so much there though is code 
 generated by reflection and of course non from indy. So I especially 
 suspect the code cache here to be responsible for the problem, but I 
 have no real basis for this. I lack the means to diagnose the problem 
 further
 
 Is there a way to make this work on older jdk7 vms? And is there a way 
 for me to make this work on jdk8? Do others here have similar experiences?

Is this 64-bit with compressed oops?  Is tiered compilation on?

 
 bye Jochen
 -- 
 Jochen blackdrag Theodorou - Groovy Project Tech Lead
 blog: http://blackdragsview.blogspot.com/
 german groovy discussion newsgroup: de.comp.lang.misc
 For Groovy programming sources visit http://groovy-lang.org
 
 ___
 mlvm-dev mailing list
 mlvm-dev@openjdk.java.net
 http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

Re: JDK7u, hotspot, CC_INTERP, and COBOL

[Christian Thalinger]

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 working the bytecode cppInterpreter instead of the 
 template based interpreter adding the CC_INTERP=true preprocessor define, but 
 I got several compile errors -- see below --
 
 By looking at the Wiki and the OpenJDK website, I discovered that the 
 cppInterpreter was no more maintained.

I have no idea if it works on Windows but on Linux you can build Zero:

http://openjdk.java.net/projects/zero/

Zero uses the C++ interpreter.

 
 So I am wondering why the cppInterpreter is not anymore maintained and would 
 like to understand if this decision is definitive or not, because it seems to 
 me that there are very few errors. (see above) and that, IMHO, a somewhat 
 small effort should be made to fix the cppInterpreter (but it could be 
 totally wrong).
 
 I need the cppInterpreter to make a proposal to the MLVM project to slightly 
 change the JVM spec for all xALOAD  and xASTORE bytecodes for a specific 
 class version number for an efficient support of a _COBOL __runtime_.
 
 Regards
 
 Francis
 
 
 cppInterpreter_x86.cpp
 1  frame_x86.cpp
 1  interpreter_x86_32.cpp
 1  interp_masm_x86_32.cpp
 1..\..\src\cpu\x86\vm\frame_x86.cpp(691): error C2039: 
 'interpreter_frame_sender_sp_offset' : n'est pas membre de 'frame'
 1 Z:\DEV\OpenJDK7u\hotspot\src\share\vm\runtime/frame.hpp(73) : voir la 
 déclaration de 'frame'
 1..\..\src\cpu\x86\vm\frame_x86.cpp(691): error C2065: 
 'interpreter_frame_sender_sp_offset' : identificateur non déclaré
 1..\..\src\cpu\x86\vm\frame_x86.cpp(692): error C2039: 
 'interpreter_frame_last_sp_offset' : n'est pas membre de 'frame'
 1 Z:\DEV\OpenJDK7u\hotspot\src\share\vm\runtime/frame.hpp(73) : voir la 
 déclaration de 'frame'
 1..\..\src\cpu\x86\vm\frame_x86.cpp(692): error C2065: 
 'interpreter_frame_last_sp_offset' : identificateur non déclaré
 1..\..\src\cpu\x86\vm\frame_x86.cpp(693): error C2039: 
 'interpreter_frame_method_offset' : n'est pas membre de 'frame'
 1 Z:\DEV\OpenJDK7u\hotspot\src\share\vm\runtime/frame.hpp(73) : voir la 
 déclaration de 'frame'
 1..\..\src\cpu\x86\vm\frame_x86.cpp(693): error C2065: 
 'interpreter_frame_method_offset' : identificateur non déclaré
 1..\..\src\cpu\x86\vm\frame_x86.cpp(694): error C2039: 
 'interpreter_frame_mdx_offset' : n'est pas membre de 'frame'
 1 Z:\DEV\OpenJDK7u\hotspot\src\share\vm\runtime/frame.hpp(73) : voir la 
 déclaration de 'frame'
 1..\..\src\cpu\x86\vm\frame_x86.cpp(694): error C2065: 
 'interpreter_frame_mdx_offset' : identificateur non déclaré
 1..\..\src\cpu\x86\vm\frame_x86.cpp(695): error C2039: 
 'interpreter_frame_cache_offset' : n'est pas membre de 'frame'
 1 Z:\DEV\OpenJDK7u\hotspot\src\share\vm\runtime/frame.hpp(73) : voir la 
 déclaration de 'frame'
 1..\..\src\cpu\x86\vm\frame_x86.cpp(695): error C2065: 
 'interpreter_frame_cache_offset' : identificateur non déclaré
 1..\..\src\cpu\x86\vm\frame_x86.cpp(696): error C2039: 
 'interpreter_frame_locals_offset' : n'est pas membre de 'frame'
 1 Z:\DEV\OpenJDK7u\hotspot\src\share\vm\runtime/frame.hpp(73) : voir la 
 déclaration de 'frame'
 1..\..\src\cpu\x86\vm\frame_x86.cpp(696): error C2065: 
 'interpreter_frame_locals_offset' : identificateur non déclaré
 1..\..\src\cpu\x86\vm\frame_x86.cpp(697): error C2039: 
 'interpreter_frame_bcx_offset' : n'est pas membre de 'frame'
 1 Z:\DEV\OpenJDK7u\hotspot\src\share\vm\runtime/frame.hpp(73) : voir la 
 déclaration de 'frame'
 1..\..\src\cpu\x86\vm\frame_x86.cpp(697): error C2065: 
 'interpreter_frame_bcx_offset' : identificateur non déclaré
 1..\..\src\cpu\x86\vm\frame_x86.cpp(698): error C2039: 
 'interpreter_frame_initial_sp_offset' : n'est pas membre de 'frame'
 1 Z:\DEV\OpenJDK7u\hotspot\src\share\vm\runtime/frame.hpp(73) : voir la 
 déclaration de 'frame'
 1..\..\src\cpu\x86\vm\frame_x86.cpp(698): error C2065: 
 'interpreter_frame_initial_sp_offset' : identificateur non déclaré
 1  sharedRuntime_x86_32.cpp
 1..\..\src\cpu\x86\vm\interp_masm_x86_32.cpp(56): error C2220: avertissement 
 considéré comme une erreur - aucun fichier 'object' généré
 1..\..\src\cpu\x86\vm\interp_masm_x86_32.cpp(56): warning C4146: opérateur 
 moins unaire appliqué à un type non signé, le résultat sera non signé
 1..\..\src\cpu\x86\vm\interp_masm_x86_32.cpp(1414): error C2039: 
 'increment_mask_and_jump' : n'est pas membre de 'InterpreterMacroAssembler'
 1 z:\dev\openjdk7u\hotspot\src\cpu\x86\vm\interp_masm_x86_32.hpp(34) : voir 
 la déclaration de 'InterpreterMacroAssembler'
 1..\..\src\cpu\x86\vm\interp_masm_x86_32.cpp(1417): error C2061: erreur de 
 syntaxe : identificateur 'Condition'
 1..\..\src\cpu\x86\vm\interp_masm_x86_32.cpp(1419): error C3861: 'movl' : 
 identificateur introuvable
 1..\..\src\cpu\x86\vm\interp_masm_x86_32.cpp(1421): 

Re: Reproducible InternalError in lambda stuff

[Christian Thalinger]

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 users to test it.
 
 If you have time, please give them a try.  Do hg qgoto meth-lfc.patch.
 
 If this stuff helps we would like to work towards a fix in 7u.
 
 What is your time frame for JRuby 1.7.5?
 
 It is on hold indefinitely while we work out user-reported issues
 (most are not 7u40-related, but we'd like to have an answer for those
 before release too).
 
 I've attached one user's hs_err dump. This was with a 4GB heap. Code
 cache full

You mean perm gen, right?

 and failing spectacularly?
 
 - Charlie
 hs_err_pid1184.log___
 mlvm-dev mailing list
 mlvm-dev@openjdk.java.net
 http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

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

[Christian Thalinger]

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().spreadInvoker(3);

Could we use a defined constant for 3?

src/share/classes/java/lang/invoke/Invokers.java:

+if (targetType == targetType.erase()  targetType.parameterCount()  
10)

The same here for 10.

Actually, exactInvoker and generalInvoker's code could be factored into one 
method.

+/*non-public*/ MethodHandle basicInvoker() {
+//invoker.form.compileToBytecode();

Please remove commented lines.

+static MemberName exactInvokeLinkerMethod(MethodType mtype, Object[] 
appendixResult) {
+static MemberName genericInvokeLinkerMethod(MethodType mtype, Object[] 
appendixResult) {

These two could also be factored into one method.

+// Return an adapter for invokeExact or generic invoke, as a MH or 
constant pool linker
+// mtype : the caller's method type (either basic or full-custom)
+// customized : whether to use a trailing appendix argument (to carry the 
mtype)
+// which0x01 : whether it is a CP adapter (linker) or MHs.invoker value 
(invoker)
+// which0x02 : whether it is for invokeExact or generic invoke
+//
+// If !customized, caller is responsible for supplying, during adapter 
execution,
+// a copy of the exact mtype.  This is because the adapter might be 
generalized to
+// a basic type.
+private static LambdaForm invokeHandleForm(MethodType mtype, boolean 
customized, int which) {

Why are you not using Javadoc style for this method comment?  It's still 
helpful in IDEs.

src/share/classes/java/lang/invoke/LambdaForm.java:

 static void traceInterpreter(String event, Object obj, Object... args) {
+if (!(TRACE_INTERPRETER  INIT_DONE))  return;

Why not use the same pattern:

+if (TRACE_INTERPRETER  INIT_DONE)

as the other places?

+static final boolean INIT_DONE = Boolean.TRUE.booleanValue();

Why are we having this after all?

src/share/classes/java/lang/invoke/MemberName.java:

+public MemberName asNormalOriginal() {

Could you add a comment to this method?  It's not clear to me what normal and 
original mean here.

+public MemberName(byte refKind, Class? defClass, String name, Object 
type) {
+@SuppressWarnings(LocalVariableHidesMemberVariable)
+int kindFlags;

The SuppressWarnings is in the other constructors because of the name flags.  
You don't need it here.  Maybe rename the others as well and get rid of the 
annotation.

src/share/classes/java/lang/invoke/MethodHandleNatives.java:

 static String refKindName(byte refKind) {
 assert(refKindIsValid(refKind));
-return REFERENCE_KIND_NAME[refKind];
+switch (refKind) {

After this change REFERENCE_KIND_NAME is not used anymore.

src/share/classes/java/lang/invoke/MethodHandles.java:

+member.getName().getClass(); member.getType().getClass();  // NPE

Please don't!  It would be nice to have at least a different line number in the 
backtrace.

src/share/classes/java/lang/invoke/MethodTypeForm.java:

+//Lookup.findVirtual(MethodHandle.class, name, type);

Either remove it or add a comment why it's there.

On Sep 12, 2013, at 6:36 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/8024761/webrev.00/
 
 Bug description:  The performance of MethodHandle.invoke is very slow when 
 the call site type differs from the method handle type. When the types 
 differ, the invocation is defined to proceed as if two steps were taken: 
 
 1. the target method handle is first adjusted to the call site type, by 
 MethodHandles.asType 
 
 2. the type-adjusted method handle is invoked directly, by 
 MethodHandles.invokeExact 
 
 The existing code (from JDK 7) awkwardly performs the type adjustment on 
 every call. But performing the type analysis and adapter creation on every 
 call is inherently slow. A good fix is to cache the result of step 1 
 (MethodHandles.asType), since step 2 is already reasonably fast. 
 
 For most applications, a one-element cache on each individual method handle 
 is a reasonable choice. It has the particular advantage of speeding up 
 invocations of non-varargs bootstrap methods. To benefit from this, the 
 bootstrap methods themselves need to be uniquified across multiple class 
 files, so this work will also include a cache to benefit commonly-used 
 bootstrap methods, such as JDK 8's LambdaMetafactory.metafactory. 
 
 Additional caches could be based on the call site, the call site type, the 
 target type, or the target's MH.form. 
 
 Thanks,
 — John
 
 P.S. Since this is an implementation change oriented toward performance, the 
 review request is to mlvm-dev and 

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

[Christian Thalinger]

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 though the {@code invokespecial} instruction can refer to them
+ * in special circumstances.  Use {@link #findConstructor 
findConstructor}

Not exactly sure but should this read are not visible?

 MemberName resolveOrFail(byte refKind, Class? refc, String name, 
MethodType type) throws NoSuchMethodException, IllegalAccessException {
+type.getClass();  // NPE
 checkSymbolicClass(refc);  // do this before attempting to resolve
-name.getClass(); type.getClass();  // NPE
+checkMethodName(refKind, name);

Could you add a comment here saying that checkMethodName does an implicit null 
pointer check on name?  Maybe a comment for checkMethodName too.

What was the problem with the null pointer exceptions?  Is it okay that we 
might throw another exception before null checking name?

On Sep 12, 2013, at 6:47 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/8001108/webrev.00
 
 Summary: add an explicit check for leading , upgrade the unit tests
 
 The change is mostly to javadoc and unit tests, documenting and testing some 
 corner cases of JSR 292 APIs.
 
 In the RI, there is an explicit error check.
 
 Thanks,
 — John
 
 P.S. Since this is a change which oriented toward JSR 292 functionality, the 
 review request is to mlvm-dev and core-libs-dev.
 Changes which are oriented toward performance will go to mlvm-dev and 
 hotspot-compiler-dev.
 ___
 mlvm-dev mailing list
 mlvm-dev@openjdk.java.net
 http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

Re: Interpreting Mission Control numbers for indy

[Christian Thalinger]

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 what I see.
 
 In the Code/Overview results, where it lists hot packages, the #1
 and #2 packages are java.lang.invoke.LambdaForm$MH and DMH, accounting
 for over 37% of samples. That sounds high, but I'm willing to grant
 they're hit pretty hard for a fully dynamic application.
 
 Results in the Hot Methods tab show similar things, like
 LambdaForm...invokeStatic_LL_L as the number one result and LambdaForm
 entries dominating the top 50 entries in the profile. Again, I know
 I'm hitting dynamic call sites hard and sampling is not always
 accurate.
 
 If I look at compilation events, I only see a handful of
 LambdaForm...convert being compiled. I'm not sure if that's good or
 bad. My assumption is that LFs don't show up here because they're
 always being inlined into a caller.
 
 The performance numbers for the app have me worried too. If I run
 JRuby with stock settings, we will chain up to 6 call targets at a
 call site. The lower I drop this number, the better performance gets;
 when I drop all the way to zero, forcing all invokedynamic call sites
 to fail over immediately to a monomorphic inline cache, performance
 *almost* gets back to the non-indy implementation. This leads me to
 believe that the less I use invokedynamic (or the fewer LFs involved),
 the better. That doesn't bode well.
 
 I believe the user would be happy to allow me to make these JMC
 recordings available, and I'm happy to re-run with additional events
 or gather other information. The JRuby community has a number of very
 large applications that push the limits of indy. We should work
 together to improve it.

We talked about this in the past.  Can we somehow get access to one of these 
large applications?

 
 - Charlie
 ___
 mlvm-dev mailing list
 mlvm-dev@openjdk.java.net
 http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

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

[Christian Thalinger]

+ // 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 thrown in call of methodhandle to private method
 
 fix: detect special case of IllegalAccessException, convert to 
 IllegalAccessError
 
 testing:
 verified that the test would pass with modified library
 verified that the test would fail with old library
 verified that the test would fail if the class substitution (for some reason) 
 did not occur
 jtreg of jdk/test/java/lang/invoke -- note that the new exception thrown is a 
 subtype of the old one, so this is unlikely to create a new surprise
 
 
 ___
 mlvm-dev mailing list
 mlvm-dev@openjdk.java.net
 http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

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

[Christian Thalinger]

On Sep 12, 2013, at 11:28 AM, David Chase david.r.ch...@oracle.com wrote:

 New webrev, commented line removed:
 http://cr.openjdk.java.net/~drchase/8022701/webrev.03/

I think the change is good given that the tests work now.  Is your test derived 
from the test in the bug report?

And it would be good if John could also have a quick look (just be to be sure).

-- Chris

 
 On 2013-09-12, at 1:53 PM, David Chase david.r.ch...@oracle.com wrote:
 
 I believe it produced extraneous output -- it was not clear to me that it 
 was either necessary or useful to fully describe all the converted 
 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
 

___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

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

[Christian Thalinger]

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 APIs.
 
 Since the RI is already correct, there are no implementation code changes.

This looks good.  The only thing that sounds odd is very large arity:

+ * a href=MethodHandle.html#maxarityvery large arity/a,

-- Chris

 
 Thanks,
 — John
 ___
 mlvm-dev mailing list
 mlvm-dev@openjdk.java.net
 http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

Re: Reproducible InternalError in lambda stuff

[Christian Thalinger]

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

 t5:I=MethodHandle(ThreadContext,IRubyObject,IRubyObject,IRubyObject)boolean(a1:L,a2:L,a3:L,a4:L);

 t6:L=MethodHandleImpl.selectAlternative(t5:I,(MethodHandle(ThreadContext,IRubyObject,IRubyObject,IRubyObject)IRubyObject),(MethodHandle(ThreadContext,IRubyObject,IRubyObject,IRubyObject)IRubyObject));
t7:L=MethodHandle.invokeBasic(t6:L,a1:L,a2:L,a3:L,a4:L);t7:L}
 
 I think it's happening at an OutOfMemory event (bumping up memory
 makes it go away), so it may not be a critical issue, but I thought
 I'd toss it out here.

Do know where it's coming from?  -- Chris

 
 - Charlie
 ___
 mlvm-dev mailing list
 mlvm-dev@openjdk.java.net
 http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

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

[Christian Thalinger]

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 finds the first method 
 without @CallerSensitive. It only returns the caller of the caller. So, for 
 example:
 
 Stack 1
 @CallerSensitive Reflection.getCallerClass()
 @CallerSensitive MyClass1.method1();
 MyClass2.method2();
 
 In this case, getCallerClass() returns MyClass2.class. BUT:
 
 Stack 2
 @CallerSensitive Reflection.getCallerClass()
 @CallerSensitive MyClass1.method1();
 @CallerSensitive MyClass2.method2();
 MyClass3.method3();
 
 In this case, getCallerClass() STILL returns MyClass2.class. Based on the 
 plain-language meaning of @CallerSensitive, I would expect getCallerClass() 
 to return MyClass3.class in the second case. But, indeed, the JavaDoc for 
 Reflection.getCallerClass() says: Returns the class of the caller of the 
 method calling this method. So, then, what's the point of @CallerSensitive? 
 Looking at the code:
 
   vframeStream vfst(thread);
   // Cf. LibraryCallKit::inline_native_Reflection_getCallerClass
   for (int n = 0; !vfst.at_end(); vfst.security_next(), n++) {
 Method* m = vfst.method();
 assert(m != NULL, sanity);
 switch (n) {
 case 0:
   // This must only be called from Reflection.getCallerClass
   if (m-intrinsic_id() != vmIntrinsics::_getCallerClass) {
 THROW_MSG_NULL(vmSymbols::java_lang_InternalError(), 
 JVM_GetCallerClass must only be called from Reflection.getCallerClass);
   }
   // fall-through
 case 1:
   // Frame 0 and 1 must be caller sensitive.
   if (!m-caller_sensitive()) {
 THROW_MSG_NULL(vmSymbols::java_lang_InternalError(), 
 err_msg(CallerSensitive annotation expected at frame %d, n));
   }
   break;
 default:
   if (!m-is_ignored_by_security_stack_walk()) {
 // We have reached the desired frame; return the holder class.
 return (jclass) JNIHandles::make_local(env, 
 m-method_holder()-java_mirror());
   }
   break;
 }
   }
 
 It seems to me that @CallerSensitive is completely pointless. This is ALWAYS 
 going to return the first non-reflection frame after frame 1, regardless of 
 @CallerSensitive. If @CallerSensitive were really supposed to have an actual 
 purpose, it would seem to me that the last part should be this:
 
   if (!m-is_ignored_by_security_stack_walk()  !m-caller_sensitive()) {
 // We have reached the desired frame; return the holder class.
 return (jclass) JNIHandles::make_local(env, 
 m-method_holder()-java_mirror());
   }
 
 Am I completely missing the point here? I just don't see a reason for 
 @CallerSensitive. The code could do the exact same thing it currently is 
 without @CallerSensitive (except for enforcing that frame 1 is 
 @CallerSensitive, which really isn't necessary if you aren't using it in 
 further frames).
 
 Thoughts?

You are missing the second (and perhaps more important) part of this change.  
Read:

http://openjdk.java.net/jeps/176

-- Chris

 
 Nick
 
 On Jul 30, 2013, at 10:33 AM, Jochen Theodorou wrote:
 
 Am 30.07.2013 16:16, schrieb Peter Levart:
 
 On 07/30/2013 03:19 PM, Jochen Theodorou wrote:
 Am 30.07.2013 14:17, schrieb Peter Levart:
 [...]
 So what would give Groovy or other language runtimes headaches when all
 there was was a parameter-less getCallerClass() API? Aren't the
 intermediate frames inserted by those runtimes controlled by the
 runtimes? Couldn't the surface runtime-inserted methods capture the
 caller and pass it down? I guess the problem is supporting calling the
 caller-sensitive methods like Class.forName(String) and such which don't
 have the overloaded variant taking caller Class or ClassLoader as an
 argument...
 Speaking for Groovy...
 those intermediate frames are runtime controlled, yes, but passing down
 the caller class is exactly the problem. Imagine I would suggest that
 each and every method definition in Java automatically gets an
 additional parameter for the caller class, just to have access to it
 inside the method. You would not accept that for Java, would you? And so
 we cannot accept that for Groovy if we want to keep integration with
 Java...
 
 Are you talking about internal Groovy implementation (the
 runtime-inserted methods) or the publicly visible API?
 
 that's the problem, it is a mix, some internal, other not. We are going to 
 change that in Groovy 3
 
 One solution for
 internal implementation of Groovy could be (speaking by heart since I
 don't know the internals of Groovy) for the surface public API method
 which doesn't have to have the special caller parameter, to capture the
 caller with getCallerClass() parameterless API (possibly enclosed with a
 quick check confirming that it might actually be needed) and bind it to
 a 

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

[Christian Thalinger]

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
 language-specific stack traces. Currently JRuby post-processes
 exception traces to mine out compiled Ruby lines and transform
 interpreter frames into proper file:line pairs. A way to say at this
 point, call back my code to build a StackTraceElement would be very
 useful across languages.
 
 Of course, omitting from stack trace has very little to do with
 stack-walking frame inspection tricks like CallerSensitive.
 +1 the solution to annotate classes so that they are transparent to the 
 stack frames, combined with @CallerSensitive, is likely to fix our problem 
 (unless Jochen remembers if there was really a problem with it). But that's 
 the future.
 
 We're facing a serious problem: we already have a bug report using openjdk 
 1.7.0_25, and if the removal is really intended to go into 1.7u40, Groovy 
 will just be broken. This is something that needs to be considered seriously. 
 For example, @Grab, our dependency download tool which works in scripts 
 depends on getCallerClass. It's a major feature that would be broken. The bug 
 I'm talking about which has been reported a few days ago is about 
 ResourceBunder.getBundle which nows trigger an infinite loop if used in 
 Groovy. (Unfortunately, we couldn't reproduce locally since we need to build 
 an older jdk version, this takes a bit of time). We are really happy to 
 discuss an alternative for JDK 8, but it's too soon to remove in JDK7, 
 because as we said, there's no alternative!

If the patch ends up in 7u40 then there will be a property or command line 
switch to turn it back on for applications which just can't live without it.  
There is plenty of time to figure something out until 8.

This mailing list is perhaps not the right list to express your concerns.  I'm 
not sure if you've already done this but you might think about posting to 
jdk7u-dev.

-- Chris

 
 The only reasonable explanation I can find for removing getCallerClass(int) 
 from JDK 1.7u40 is a major security issue. If there's not, please reconsider 
 it, or Groovy will be broken (if anyone sees how we can replace it today with 
 a solution that would work on jdks 5 - 7, we're happy to consider it). There 
 are lots of applications in production with Groovy and Grails and starting to 
 see them fail after a JDK update would be a total disaster.
 
 Thanks!
 
 -- 
 Cédric Champeau
 SpringSource - Pivotal
 http://www.springsource.org/
 http://www.gopivotal.com/
 http://twitter.com/CedricChampeau
 ___
 mlvm-dev mailing list
 mlvm-dev@openjdk.java.net
 http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

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

[Christian Thalinger]

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 to not
 appear in any stacktrace?
 Personally, I'd love to see *any* way to teach JVM about
 language-specific stack traces. Currently JRuby post-processes
 exception traces to mine out compiled Ruby lines and transform
 interpreter frames into proper file:line pairs. A way to say at this
 point, call back my code to build a StackTraceElement would be very
 useful across languages.
 
 Of course, omitting from stack trace has very little to do with
 stack-walking frame inspection tricks like CallerSensitive.
 +1 the solution to annotate classes so that they are transparent to the 
 stack frames, combined with @CallerSensitive, is likely to fix our problem 
 (unless Jochen remembers if there was really a problem with it). But that's 
 the future.
 
 We're facing a serious problem: we already have a bug report using openjdk 
 1.7.0_25, and if the removal is really intended to go into 1.7u40, Groovy 
 will just be broken. This is something that needs to be considered 
 seriously. For example, @Grab, our dependency download tool which works in 
 scripts depends on getCallerClass. It's a major feature that would be 
 broken. The bug I'm talking about which has been reported a few days ago is 
 about ResourceBunder.getBundle which nows trigger an infinite loop if used 
 in Groovy. (Unfortunately, we couldn't reproduce locally since we need to 
 build an older jdk version, this takes a bit of time). We are really happy 
 to discuss an alternative for JDK 8, but it's too soon to remove in JDK7, 
 because as we said, there's no alternative!
 
 If the patch ends up in 7u40 then there will be a property or command line 
 switch to turn it back on for applications which just can't live without it.

Here is the CR btw.:

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8014925

-- Chris

  There is plenty of time to figure something out until 8.
 
 This mailing list is perhaps not the right list to express your concerns.  
 I'm not sure if you've already done this but you might think about posting to 
 jdk7u-dev.
 
 -- Chris
 
 
 The only reasonable explanation I can find for removing getCallerClass(int) 
 from JDK 1.7u40 is a major security issue. If there's not, please reconsider 
 it, or Groovy will be broken (if anyone sees how we can replace it today 
 with a solution that would work on jdks 5 - 7, we're happy to consider it). 
 There are lots of applications in production with Groovy and Grails and 
 starting to see them fail after a JDK update would be a total disaster.
 
 Thanks!
 
 -- 
 Cédric Champeau
 SpringSource - Pivotal
 http://www.springsource.org/
 http://www.gopivotal.com/
 http://twitter.com/CedricChampeau
 ___
 mlvm-dev mailing list
 mlvm-dev@openjdk.java.net
 http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
 
 ___
 mlvm-dev mailing list
 mlvm-dev@openjdk.java.net
 http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

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

[Christian Thalinger]

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
 
 Detailed replies follow.
 
 On Jul 1, 2013, at 3:36 PM, Vladimir Ivanov vladimir.x.iva...@oracle.com 
 wrote:
 
 John,
 
 I have some minor suggestions about code style and code readability.
 Otherwise, the change looks good!
 
 src/share/classes/java/lang/invoke/MemberName.java:
public MemberName(Method m, boolean wantSpecial) {
 ...
MethodHandleNatives.init(this, m);
 +if (clazz == null) {  // MHN.init failed
 +if (m.getDeclaringClass() == MethodHandle.class 
 +isMethodHandleInvokeName(m.getName())) {
 
 Please, add a comment with a short description why a custom init procedure 
 for MH.invoke* cases is needed.
 
 Done:
// The JVM did not reify this signature-polymorphic instance.
// Need a special case here.
// See comments on MethodHandleNatives.linkMethod.
 
 And I added several paragraphs in the javadoc for linkMethod.
 They cover non-reification, linker methods, appendixes, synthetic, varargs, 
 and more.
 
 +/** Create a name for a signature-polymorphic invoker. */
 +static MemberName makeMethodHandleInvoke(String name, MethodType type) {
 +return makeMethodHandleInvoke(name, type, MH_INVOKE_MODS | 
 SYNTHETIC);
 
 Please, add a comment why SYNTHETIC flag is necessary.
 
/**
 * Create a name for a signature-polymorphic invoker.
 * This is a placeholder for a signature-polymorphic instance
 * (of MH.invokeExact, etc.) that the JVM does not reify.
 * See comments on {@link MethodHandleNatives#linkMethod}.
 */
 
 src/share/classes/java/lang/invoke/MethodHandleInfo.java:
 src/share/classes/java/lang/invoke/MethodHandles.java:
 
 +import java.security.*;
 
 This import isn't used.
 
 Fixed.
 
 src/share/classes/java/lang/invoke/MethodHandles.java:
 
 +public MethodHandleInfo revealDirect(MethodHandle target) {
 ...
 +byte refKind = member.getReferenceKind();
 ...
 +// Check SM permissions and member access before cracking.
 +try {
 +//@@checkSecurityManager(defc, member, lookupClass());
 +checkSecurityManager(defc, member);
 +checkAccess(member.getReferenceKind(), defc, member);
 +} catch (IllegalAccessException ex) {
 +throw new IllegalArgumentException(ex);
 +}
 
 You prepare a separate refKind for MethodHandleInfo, but perform security 
 checks against original member.getReferenceKind(). Is it intentional?
 
 No, it's bug.  Thanks for catching that.
 
 src/share/classes/java/lang/invoke/InfoFromMemberName.java:
 
 81 public T extends Member T reflectAs(ClassT expected, Lookup 
 lookup) {
 82 if (member.isMethodHandleInvoke()  !member.isVarargs()) {
 83 // this member is an instance of a signature-polymorphic 
 method, which cannot be reflected
 84 throw new IllegalArgumentException(cannot reflect signature 
 polymorphic method);
 
 Please, add a comment why (!member.isVarargs()) check is necessary.
 
// This member is an instance of a signature-polymorphic method, 
 which cannot be reflected
// A method handle invoker can come in either of two forms:
// A generic placeholder (present in the source code, and varargs)
// and a signature-polymorphic instance (synthetic and not 
 varargs).
// For more information see comments on {@link 
 MethodHandleNatives#linkMethod}.
 
 
 src/share/classes/java/lang/invoke/InfoFromMemberName.java:
 
 127 private void checkAccess(Member mem, Lookup lookup) throws 
 IllegalAccessException {
 128 byte refKind = (byte) getReferenceKind();
 129 if (mem instanceof Method) {
 130 boolean wantSpecial = (refKind == REF_invokeSpecial);
 131 lookup.checkAccess(refKind, getDeclaringClass(), new 
 MemberName((Method) mem, wantSpecial));
 132 } else if (mem instanceof Constructor) {
 133 lookup.checkAccess(refKind, getDeclaringClass(), new 
 MemberName((Constructor) mem));
 134 } else if (mem instanceof Field) {
 135 boolean isSetter = (refKind == REF_putField || refKind == 
 REF_putStatic);
 136 lookup.checkAccess(refKind, getDeclaringClass(), new 
 MemberName((Field) mem, isSetter));
 137 }
 138 }
 
 Can you introduce a factory method to convert a Member instance into 
 MemberName and call lookup.checkAccess(refKind, getDeclaringClass(), 
 covertToMemberName(mem)) instead? It'll considerably simplify the code and 
 make the intention clearer.
 
 Good idea.  Done.
 
 — John
 
 Best regards,
 Vladimir Ivanov
 
 On 6/27/13 

Re: speed of invokeExact

[Christian Thalinger]

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?

No.  I was referring to your comment about hotspot should throw out the 
invocation completely, but it does not.  That's the case in both examples.

 That is 
 unexpected. And if that is the case, then why does this:
 
MethodHandle mh = MethodHandles.lookup().findVirtual(String.class, 
 toString, MethodType.methodType(String.class));
MethodType invokeType = MethodType.methodType(Object.class, 
 String.class);
int tmax = 1_000_000;
for (int k=0; k20; k++) {
long t1 = System.nanoTime();
for (int i=0; itmax; i++) {
MethodHandle invoker = mh.asType(invokeType);
}
long t2 = System.nanoTime();
System.out.println((t2-t1)/tmax);
}
 
 take that long as well? Maybe it changed, but I thought only handles 
 coming from a final field are constant enough for inlining. If I compare 
 to 1.7.11 (or 1.7.6) then I get around 23 for the first, and 200-300 for 
 the second and third test. That is about a factor 10-15 slowdown, that 
 is what I would expect from the call not being inlined for example. But 
 I always thought 1.7 will not inline in this case at all. On my 1.8 it 
 was almost a factor 100. So unless the noninlined call on a method 
 handle got extremely expensive compared to 1.7, there must be something 
 else too.

I haven't looked but maybe the slowdown is because the asType call cannot be 
inlined completely and so the compiler doesn't know it always returns the same 
result.

-- Chris

 
 bye blackdrag
 
 -- 
 Jochen blackdrag Theodorou - Groovy Project Tech Lead
 blog: http://blackdragsview.blogspot.com/
 german groovy discussion newsgroup: de.comp.lang.misc
 For Groovy programming sources visit http://groovy-lang.org
 
 ___
 mlvm-dev mailing list
 mlvm-dev@openjdk.java.net
 http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

Re: speed of invokeExact

[Christian Thalinger]

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 is not constant
 we can't do any inlining  and it will be an out-of-line call (with a 
 trampoline in between). Is
 your DMH a static or virtual?
 
 arg... looks like I made a mistake. It is not the invokeExact that is
 slow, it is my preparation of the handle that is slow.
 
 So it's an insertArgs and asType that's slow.  Can you distill the 
 operations into a micro-benchmark for us?
 
 to reduce it to only asType:
 
 compare the times of this:
 
MethodHandle mh = MethodHandles.lookup().findVirtual(String.class, 
 toString, MethodType.methodType(String.class));
int tmax = 1_000_000;
for (int k=0; k20; k++) {
long t1 = System.nanoTime();
for (int i=0; itmax; i++) {
String s = (String) mh.invokeExact(str);
}
long t2 = System.nanoTime();
System.out.println((t2-t1)/tmax);
}
 
 with this:
 
MethodHandle mh = MethodHandles.lookup().findVirtual(String.class, 
 toString, MethodType.methodType(String.class));
MethodType invokeType = MethodType.methodType(Object.class, 
 String.class);
int tmax = 1_000_000;
for (int k=0; k20; k++) {
long t1 = System.nanoTime();
for (int i=0; itmax; i++) {
MethodHandle invoker = mh.asType(invokeType);
Object o = invoker.invokeExact(str);
}
long t2 = System.nanoTime();
System.out.println((t2-t1)/tmax);
}
 
 The first one has times of about 9-15 on my machine, the later one 
 800-900. I am aware that this is a test in which hotspot should throw 
 out the invocation completely, but it does not.

That's because your method handle is not constant and so the compiler cannot 
inline the call.

-- Chris

 Even more interesing is 
 when you reduce the test even further:
 
MethodHandle mh = MethodHandles.lookup().findVirtual(String.class, 
 toString, MethodType.methodType(String.class));
MethodType invokeType = MethodType.methodType(Object.class, 
 String.class);
int tmax = 1_000_000;
for (int k=0; k20; k++) {
long t1 = System.nanoTime();
for (int i=0; itmax; i++) {
MethodHandle invoker = mh.asType(invokeType);
}
long t2 = System.nanoTime();
System.out.println((t2-t1)/tmax);
}
 
 Now this should really be optimized away completely by hotspot, but is 
 not and takes about the same time as the second case... which is not 
 surprising since the asType call is totally dominating the benchmark.
 
 btw, the test was with a jdk 1.8.0 ea with tiered compilation turned 
 off. The tests contain no warmup, but that's what why the test is 
 repeated 20 times to see the development of the values instead of doing 
 a one time measurement. And the values in this test go up and down a lot too
 
 bye blackdrag
 
 -- 
 Jochen blackdrag Theodorou - Groovy Project Tech Lead
 blog: http://blackdragsview.blogspot.com/
 german groovy discussion newsgroup: de.comp.lang.misc
 For Groovy programming sources visit http://groovy-lang.org
 
 ___
 mlvm-dev mailing list
 mlvm-dev@openjdk.java.net
 http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

Re: speed of invokeExact

[Christian Thalinger]

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 without 
 the invokedynamic bytecode and with a non constant method handle. I am 
 aware of that being a non optimized path in indy, but it does not really 
 look fast to me at all. Maybe compared to Reflection, but to a runtime 
 generated class for the method invocation, it seems to be very very 
 slow- at least on my 64-Bit Server VM (build 25.0-b14, mixed mode) here.

Do you have any numbers?  The problem is that if the MH is not constant we 
can't do any inlining and it will be an out-of-line call (with a trampoline in 
between).  Is your DMH a static or virtual?

-- Chris

 
 Now.. is that commonly known? Did I see wrong? Is there a way to improve 
 the speed (it is a DirectMethodHandle I am invoking already)?
 
 bye Jochen
 ___
 mlvm-dev mailing list
 mlvm-dev@openjdk.java.net
 http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

Re: method handle cracking API

[Christian Thalinger]

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 exception information. So although
 I don't think it should extend Member I do think it should have a standard
 way to return a Member, sort of the opposite of Lookup.unreflect().

John and I referred to this method yesterday as:  Lookup.ununreflect()

;-)

-- Chris

 
 As for transformed method handles a cracking interface may not need to
 return an representation of the original structure, it might be enough to
 return the parts that remain (both method handles and bound objects) as I
 would guess that would be enough for debugging purposes and resource leak
 hunting.
 
 Regards, Duncan.
 
 On 24/04/2013 08:02, John Rose john.r.r...@oracle.com wrote:
 
 Those of you who have been following 292 details may have noticed the
 type java.lang.invoke.MethodHandleInfo show up in support of Project
 Lambda.
 
 The 292 EG has been thinking about the problem of method handle
 reflection, since JDK 7, in background mode.  We are sure we want
 something that can crack direct method handles, and not ready to
 venture anything more elaborate.
 
 (Arbitrarily transformed method handles probably can never have an
 implementation-independent cracked form, so there are real problems
 specifying a cracking function that is defined for every method handle.
 For example, recording the series of transforms that gave rise to every
 MH rules out many interesting implementations, and recovering a likely
 series of transforms for a MH seems perilously close to the
 function-equivalence problem, which we know is undecidable.)
 
 I am working on polishing this restricted cracking API for direct method
 handles.  Here is a webrev of it, starting at MethodHandleInfo:
 
 http://cr.openjdk.java.net/~jrose/8008688/javadoc.00/java/lang/invoke/Meth
 odHandleInfo.html
 
 Comments would be welcome.
 
 Thanks,
 ‹ John
 
 P.S. No testing yet; it is doc-ware at the moment.  I just posted a
 checkpoint of the source patches here:
 
 http://hg.openjdk.java.net/mlvm/mlvm/jdk/file/tip/meth-info-8008688.patch
 
 P.P.S.  Here are my fix-me comments at this point:
 
 // Should this extend java.lang.reflect.Member?  (default: no)
 // Should we include getModifiers?  (default: no)
 // Should the direct parts be separated into a sub-interface (to allow
 for future extensions)?
 //If we don't have a subinterface, later on we might need an isDirect
 method.
 //If we do have a subinterface, then MethodHandleInfo becomes an
 empty type (like java.lang.reflect.Type).
 // Define SecurityManager checks. (TO DO)
 
 ___
 mlvm-dev mailing list
 mlvm-dev@openjdk.java.net
 http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
 
 ___
 mlvm-dev mailing list
 mlvm-dev@openjdk.java.net
 http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

Re: Update 12 build 3 - performance report question

[Christian Thalinger]

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 that I believe 
 was planned? I can't quite tell from the jdk7u-dev list.

Are you talking about JDK 7u13?  No, it does not contain the new JSR 292 
implementation (using LambdaForms).

-- Chris

 
 Anyway, something has shifted cos we've got generally better performance 
 across our micro-benchmarks (geom mean down 15% relative to u9), with a small 
 set of regressions, particularly around some work Duncan did to improve 
 perform's, er, performance. Thanks for the speed-ups! Happy to follow up on 
 the regressions if you're interested.
 
 Any idea when u12 is likely to ship?
 George
 ___
 mlvm-dev mailing list
 mlvm-dev@openjdk.java.net
 http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

Re: Perf regression since b72

[Christian Thalinger]

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 back to b72 
 performance. I can confirm this on JRuby as well, but in any case it seems 
 that something has regressed.
 
 Here's some numbers with JRuby. Numbers are for b72, hotspot-comp, and 
 hotspot-comp with InlineSmallCode=2000. You can see that current hotspot-comp 
 builds do not perform as well as b72 unless that flag is passed.
 
 https://gist.github.com/headius/de7f99b52847c2436ee4
 
 I have not yet started to explore the inlining or assembly output, but I 
 wanted to confirm that others are seeing this degradation.
 
 My build of hotspot-comp is current.
 
 I do have some benchmarks that look fine without the additional flag 
 (neural_net, for example), so I'm confused what's different in the degraded 
 cases.

I'm not sure if Marcus talked to you already about this but there are two fixes 
that caused this regression:

1.  http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8007439

which was fixed by:

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8010222

in HS25-b24.

2.  We turned off tiered compilation:

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8005811

The InlineSmallCode=2000 is a way to work around the tiered slowdown.

-- Chris

 
 - Charlie
 ___
 mlvm-dev mailing list
 mlvm-dev@openjdk.java.net
 http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

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

[Christian Thalinger]

On Dec 21, 2012, at 2:22 AM, MacGregor, Duncan (GE Energy Management) 
duncan.macgre...@ge.com wrote:

 Okay I've been experimenting a bit before you sent that, and If the code
 cache is set to something rather large then we seem to get good
 performance on large applications anyway, though we do still see lambda
 form classes getting loaded (though at a lower rate once everything has
 been running for a while) so without lambda form caching running instances
 would almost certainly end up running out of permgen eventually. I'll keep
 tracking application performance and memory usage on 7u12 and 8, and see
 what difference caching and incremental unlinking make.
 
 BTW. Is there any good way to get instrumentation on code cache usage?
 Either in real time or by processing the compilation log afterwards? I can
 piece together a lot from the compilation log method and make_not_entrant
 information so I can see when things have become zombies, but I don't see
 anything in there to indicate when zombies have actually been flushed.

+PrintMethodFlushing should log the current code cache state.  I don't think we 
have anything that prints flushed methods.

-- Chris

 
 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 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 somewhere between 50 and 70%,
 which seems to be due to the new LambdaForm infrastructure being slower
 on initialisation/initial calls. That isn't great but is something I
 think we can live with and will probably push us to look at ways of
 improving overall startup time.
 
 The large number of LamdbaForms created means permgen usage has
 increased substantially ­ it was over 300MB by the time the applications
 has started.
 
 Compilation never really settles down during use of the app. I'll look
 into this (I don't think it ever really settled down on 7u9 either but
 performance was considerably better).
 
 I'm going to try running everything with PrintCompilation and
 LogCompilation to try and work out why compilation isn't settling down
 and narrow the problem down.
 
 You are on the bleeding edge right now even with 7u12 (since the code is
 basically the same as in 8).  For better performance we need to wait for
 two changes:
 
 1. incremental inlining: http://bugs.sun.com/view_bug.do?bug_id=8005071
 
 2. LambdaForm caching (can't find the bug number right now)
 
 These must (and will) go into 7u12 and 8.
 
 -- Chris
 
 
 From: John Rose john.r.r...@oracle.commailto:john.r.r...@oracle.com
 Reply-To: Da Vinci Machine Project
 mlvm-dev@openjdk.java.netmailto:mlvm-dev@openjdk.java.net
 Date: Wednesday, 12 December 2012 19:42
 To: Da Vinci Machine Project
 mlvm-dev@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 an idea.
 
 The bug is probably in GuardWithCatch.invoke_V, in this file:
 
 http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/tip/src/share/classes/java/
 lang/invoke/MethodHandleImpl.java
 
 I'll look into it.
 
 ‹ John
 ___
 mlvm-dev mailing list
 mlvm-dev@openjdk.java.net
 http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
 
 ___
 mlvm-dev mailing list
 mlvm-dev@openjdk.java.net
 http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
 
 ___
 mlvm-dev mailing list
 mlvm-dev@openjdk.java.net
 http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

Re: Studying LF performance

[Christian Thalinger]

[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 1.5s I get without the patches, and compared to the old logic's
 best time of 0.726. Both results are rather variable (maybe as much as
 15%) due to the amount of allocation and GC happening. So it's not
 quite at the level of the old logic, but it's darn close.

That's really good to hear.

 
 However, here's a benchmark that's still considerably slower than on
 the Java 7 impl: https://gist.github.com/4367878
 
 This requires the perfer gem (gem install perfer) and should be
 level between the static and included versions. The overall loop
 should be a lot faster too.
 
 Numbers for Java 7u9 are in the gist. Numbers for current hotspot-comp
 + Christian's patch:
 
 system ~/projects/jruby $ jruby -Xcompile.invokedynamic=true
 ../jruby/static_versus_include_bench.rb
 Session Static versus included method invocation with jruby 1.7.2.dev
 (1.9.3p327) 2012-12-22 51cc3ad on OpenJDK 64-Bit Server VM
 1.8.0-internal-headius_2012_12_23_22_29-b00 +indy [darwin-x86_64]
 Taking 10 measurements of at least 1.0s
 control loop 10.99 ns/i ± 1.304 (11.9%) = 90938318 ips
 static invocation 17.65 ns/i ± 1.380 ( 7.8%) = 56658156 ips
 included invocation 11.15 ns/i ± 3.132 (28.1%) = 89630324 ips
 
 The static case (Foo.foo) basically boils down to a SwitchPoint +
 cached value for Foo and then SwitchPoint + GWT + field read +
 reference comparison for the call. The included case is just the
 latter, so this seems to indicate that the SwitchPoint for the Foo
 lookup is adding more overhead than it should. I have not dug any
 deeper, so I'm tossing this out there.

Thanks.  We need to look into that.

-- Chris

 
 Will try to get some logging for the benchmark tomorrow.
 
 - Charlie
 
 On Sun, Dec 23, 2012 at 10:26 PM, Charles Oliver Nutter
 head...@headius.com wrote:
 Excellent! I'll give it a look and base my experiments on that!
 
 - Charlie
 
 On Sun, Dec 23, 2012 at 4:04 PM, Vladimir Kozlov
 vladimir.koz...@oracle.com wrote:
 Hi Charlie,
 
 If you want to experiment :) you can try the code Roland and Christian
 pushed.
 
 Roland just pushed Incremental inlining changes for C2 which should help
 LF inlining:
 
 http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/d092d1b31229
 
 You also need Christian's inlining related changes in JDK which :
 
 http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/12fa4d7ecaf5
 
 Regards,
 Vladimir
 
 On 12/23/12 11:21 AM, Charles Oliver Nutter wrote:
 A thread emerges!
 
 I'm going to be taking some time this holiday to explore the
 performance of the new LF indy impl in various situations. This will
 be the thread where I gather observations.
 
 A couple preliminaries...
 
 My perf exploration so far seems to show LF performing nearly
 equivalent to the old impl for the smallest benchmarks, with
 performance rapidly degrading as the size of the code involved grows.
 Recursive fib and tak have nearly identical perf on LF and the old
 impl. Red/black performs about the same on LF as with indy disabled,
 well behind the old indy performance. At some point, LF falls
 completely off the cliff and can't even compete with non-indy logic,
 as in a benchmark I ran today of Ruby constant access (heavily
 SwitchPoint-dependent).
 
 Discussions with Christian seem to indicate that the fall-off is
 because non-inlined LF indy call sites perform very poorly compared to
 the old impl. I'll be trying to explore this and correlate the perf
 cliff with failure to inline. Christian has told me that (upcoming?)
 work on incremental inlining will help reduce the performance impact
 of the fall-off, but I'm not sure of the status of this work.
 
 Some early ASM output from a trivial benchmark: loop 500M times
 calling #foo, which immediately calls #bar, which just returns the
 self object (ALOAD 2; ARETURN in essence). I've been comparing the new
 ASM to the old, both presented in a gist here:
 https://gist.github.com/4365103
 
 As you can see, the code resulting from both impls boils down to
 almost nothing, but there's one difference...
 
 New code not present in old:
 
 0x000111ab27ef: je 0x000111ab2835  ;*ifnull
 ; -
 java.lang.Class::cast@1 (line 3007)
 ; -
 java.lang.invoke.LambdaForm$MH/763053631::guard@12
 ; -
 java.lang.invoke.LambdaForm$MH/518216626::linkToCallSite@14
 ; -
 ruby.__dash_e__::method__0$RUBY$foo@3 (line 1)
 
 A side effect of inlining through LFs, I presume? Checking to ensure
 non-null call site? If so, shouldn't this have folded away, since the
 call site is constant?
 
 In any case, it's 

Re: Studying LF performance

[Christian Thalinger]

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
 ../rubybench/bench/time/bench_red_black.rb
 jruby 1.7.2.dev (1.9.3p327) 2012-12-22 51cc3ad on OpenJDK 64-Bit
 Server VM 1.8.0-internal-headius_2012_12_23_22_29-b00 +indy
 [darwin-x86_64]
 9.191
 1.923
 1.429
 1.183
 1.226
 1.237
 1.211
 1.284
 1.267
 1.223
 
 system ~/projects/jruby $ jruby -v ../rubybench/bench/time/bench_red_black.rb
 jruby 1.7.2.dev (1.9.3p327) 2012-12-22 51cc3ad on OpenJDK 64-Bit
 Server VM 1.8.0-internal-headius_2012_12_23_22_29-b00 +indy
 [darwin-x86_64]
 4.58
 1.421
 0.912
 0.922
 0.835
 0.83
 0.891
 0.816
 0.825
 0.853

The Nashorn people have seen similar results when using tiered.  We haven't 
investigated yet but I have the feeling that it's related to the huge compile 
tasks that come out of LFs.  Sometimes it's better to already have compiled 
code for a method rather than inlining it.  And with tiered it seems that's 
what's happening.

It could also be related to racing compiles (tiered has more compiler threads 
and C1 compiles faster).

-- Chris

 
 And here's those Java 7 numbers. I guess it's not as close as what I
 posted previously, but it's still a lot better:
 
 system ~/projects/jruby $ (pickjdk 5; jruby -v
 -Xcompile.invokedynamic=true
 ../rubybench/bench/time/bench_red_black.rb )
 New JDK: jdk1.7.0_09.jdk
 jruby 1.7.2.dev (1.9.3p327) 2012-12-22 51cc3ad on Java HotSpot(TM)
 64-Bit Server VM 1.7.0_09-b05 +indy [darwin-x86_64]
 3.105
 1.595
 1.182
 0.825
 1.751
 0.794
 0.756
 0.746
 0.702
 0.777
 
 - Charlie
 
 On Sun, Dec 23, 2012 at 11:56 PM, Charles Oliver Nutter
 head...@headius.com wrote:
 Ok, things are definitely looking up with Roland's and Christian's patches!
 
 Numbers for red/black get as low as 0.74s with the new logic instead
 of the 1.5s I get without the patches, and compared to the old logic's
 best time of 0.726. Both results are rather variable (maybe as much as
 15%) due to the amount of allocation and GC happening. So it's not
 quite at the level of the old logic, but it's darn close.
 
 However, here's a benchmark that's still considerably slower than on
 the Java 7 impl: https://gist.github.com/4367878
 
 This requires the perfer gem (gem install perfer) and should be
 level between the static and included versions. The overall loop
 should be a lot faster too.
 
 Numbers for Java 7u9 are in the gist. Numbers for current hotspot-comp
 + Christian's patch:
 
 system ~/projects/jruby $ jruby -Xcompile.invokedynamic=true
 ../jruby/static_versus_include_bench.rb
 Session Static versus included method invocation with jruby 1.7.2.dev
 (1.9.3p327) 2012-12-22 51cc3ad on OpenJDK 64-Bit Server VM
 1.8.0-internal-headius_2012_12_23_22_29-b00 +indy [darwin-x86_64]
 Taking 10 measurements of at least 1.0s
 control loop 10.99 ns/i ± 1.304 (11.9%) = 90938318 ips
 static invocation 17.65 ns/i ± 1.380 ( 7.8%) = 56658156 ips
 included invocation 11.15 ns/i ± 3.132 (28.1%) = 89630324 ips
 
 The static case (Foo.foo) basically boils down to a SwitchPoint +
 cached value for Foo and then SwitchPoint + GWT + field read +
 reference comparison for the call. The included case is just the
 latter, so this seems to indicate that the SwitchPoint for the Foo
 lookup is adding more overhead than it should. I have not dug any
 deeper, so I'm tossing this out there.
 
 Will try to get some logging for the benchmark tomorrow.
 
 - Charlie
 
 On Sun, Dec 23, 2012 at 10:26 PM, Charles Oliver Nutter
 head...@headius.com wrote:
 Excellent! I'll give it a look and base my experiments on that!
 
 - Charlie
 
 On Sun, Dec 23, 2012 at 4:04 PM, Vladimir Kozlov
 vladimir.koz...@oracle.com wrote:
 Hi Charlie,
 
 If you want to experiment :) you can try the code Roland and Christian
 pushed.
 
 Roland just pushed Incremental inlining changes for C2 which should help
 LF inlining:
 
 http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/d092d1b31229
 
 You also need Christian's inlining related changes in JDK which :
 
 http://hg.openjdk.java.net/hsx/hotspot-main/jdk/rev/12fa4d7ecaf5
 
 Regards,
 Vladimir
 
 On 12/23/12 11:21 AM, Charles Oliver Nutter wrote:
 A thread emerges!
 
 I'm going to be taking some time this holiday to explore the
 performance of the new LF indy impl in various situations. This will
 be the thread where I gather observations.
 
 A couple preliminaries...
 
 My perf exploration so far seems to show LF performing nearly
 equivalent to the old impl for the smallest benchmarks, with
 performance rapidly degrading as the size of the code involved grows.
 Recursive fib and tak have nearly identical perf on LF and the old
 impl. Red/black performs about the same on LF as with indy disabled,
 well behind the old indy performance. At some point, LF falls
 completely off the cliff and can't even compete with non-indy 

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

[Christian Thalinger]

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 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 somewhere between 50 and 70%, which 
 seems to be due to the new LambdaForm infrastructure being slower on 
 initialisation/initial calls. That isn't great but is something I think we 
 can live with and will probably push us to look at ways of improving overall 
 startup time.
 
 The large number of LamdbaForms created means permgen usage has increased 
 substantially – it was over 300MB by the time the applications has started.
 
 Compilation never really settles down during use of the app. I'll look into 
 this (I don't think it ever really settled down on 7u9 either but performance 
 was considerably better).
 
 I'm going to try running everything with PrintCompilation and LogCompilation 
 to try and work out why compilation isn't settling down and narrow the 
 problem down.

You are on the bleeding edge right now even with 7u12 (since the code is 
basically the same as in 8).  For better performance we need to wait for two 
changes:

1. incremental inlining: http://bugs.sun.com/view_bug.do?bug_id=8005071

2. LambdaForm caching (can't find the bug number right now)

These must (and will) go into 7u12 and 8.

-- Chris

 
 From: John Rose john.r.r...@oracle.commailto:john.r.r...@oracle.com
 Reply-To: Da Vinci Machine Project 
 mlvm-dev@openjdk.java.netmailto:mlvm-dev@openjdk.java.net
 Date: Wednesday, 12 December 2012 19:42
 To: Da Vinci Machine Project 
 mlvm-dev@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 an idea.
 
 The bug is probably in GuardWithCatch.invoke_V, in this file:
  
 http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/tip/src/share/classes/java/lang/invoke/MethodHandleImpl.java
 
 I'll look into it.
 
 — John
 ___
 mlvm-dev mailing list
 mlvm-dev@openjdk.java.net
 http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

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

[Christian Thalinger]

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 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 
 proper error handling code, we are failing to be bind properly. The failure 
 occurs with methods with 9 or more arguments where the last one is an array.
 
 I've attached a minimal test case which works under update 10 but fails under 
 update 12 (all tests on Windows x64) and shows the difference in behaviour 
 with the number of args.
 MethodHandleBug.java
 ___
 mlvm-dev mailing list
 mlvm-dev@openjdk.java.net
 http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

Re: unreflectGetter and static class initialization

[Christian Thalinger]

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 give you the semantics you 
 want, since the init would happen early.
 
 Or, you could wrap the buggy MH in a MH which first forces initialization.  
 With a switchpoint you can make it a once-only event (per thread, at least).

...or move to JDK 8 until 7u with an updated 292 is released.  Doesn't the 
NoClassDefFoundError bite you anyway?

-- Chris

 
 — John
 ___
 mlvm-dev mailing list
 mlvm-dev@openjdk.java.net
 http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

Re: Latest experiments...happiness and sadness

[Christian Thalinger]

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.
 Because Hotspot's EA can't do partial EA, any unfollowed paths that
 would receive the allocated object have to be considered escapes, and
 so anywhere we're doing guarded logic (either in indy or in Java code,
 like Fixnum overflow checks) the unfollowed paths prevent EA from
 happening. Boo-hoo.
 
 Thoughts?
 
 I'm very new to this (have not even looked at the source code to Hotspot 
 yet), but is it possible
 to push the allocation/boxing to paths that are believed to be rarely taken?

That's what partial EA does.  I'm trying to get Vladimir to work on it and it 
seems I'm successful.

-- Chris

   This is not unlike
 region-based register allocation, where register allocation is limited to 
 what are believe to be
 the hot regions, and worry about region exits later -- if necessary, you can 
 always spill there. 

 
 David
 
 ___
 mlvm-dev mailing list
 mlvm-dev@openjdk.java.net
 http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

Re: Reflection vs MethodHandle performance in Oracle JDK 7u7

[Christian Thalinger]

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. 
 
 I had refrained from posting this question for some time but I couldn't wait 
 any longer after I saw a reference to this bug fix 
 http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7023639 (Bug ID: 7023639 
 JSR 292 method handle invocation needs a fast path for compiled code) on this 
 forum. I suppose this change will go into the Oracle JDK sometime later.
 
 I still went ahead with Oracle JDK 7u7 and ran a simple test using Google 
 Caliper (http://code.google.com/p/caliper/) on a Win 7, 64bit, 1 cpu x 2 core 
 x 4 HT, i7 920 laptop.
 
 Q1: MethodHandle still seems slower than Reflection. Will that change 
 sometime in the future?
 
 Q2: Also, am I using MethodHandle the right way in the code 
 Temp::timeHandle(int) below?
 
 Test results:
  0% Scenario{vm=java, trial=0, benchmark=Reflect, serverMode=-server, 
 memoryMin=-Xmx96M, memoryMax=-Xmx96M} 16.76 ns; ?=0.18 ns @ 10 trials
 20% Scenario{vm=java, trial=0, benchmark=Handle, serverMode=-server, 
 memoryMin=-Xmx96M, memoryMax=-Xmx96M} 21.98 ns; ?=0.57 ns @ 10 trials
 40% Scenario{vm=java, trial=0, benchmark=Direct, serverMode=-server, 
 memoryMin=-Xmx96M, memoryMax=-Xmx96M} 4.93 ns; ?=0.06 ns @ 10 trials
 60% Scenario{vm=java, trial=0, benchmark=Iface, serverMode=-server, 
 memoryMin=-Xmx96M, memoryMax=-Xmx96M} 4.94 ns; ?=0.30 ns @ 10 trials
 80% Scenario{vm=java, trial=0, benchmark=Static, serverMode=-server, 
 memoryMin=-Xmx96M, memoryMax=-Xmx96M} 4.88 ns; ?=0.03 ns @ 3 trials
 
 benchmarkns linear runtime
   Reflect 16.76 ==
Handle 21.98 ==
Direct  4.93 ==
 Iface  4.94 ==
Static  4.88 ==
 
 vm: java
 trial: 0
 serverMode: -server
 memoryMin: -Xmx96M
 memoryMax: -Xmx96M
 
 
 Test code:
 public class Temp extends SimpleBenchmark {
 public static void main(String[] args) throws Exception {
 Runner.main(Temp.class, args);
 }
 
 public void timeReflect(int reps) throws Exception {
 Method m = K.class.getMethod(exec, Object.class);
 
 K k = new K();
 
 for (int i = 0; i  reps; i++) {
 m.invoke(k, i);
 }
 }
 
 public void timeHandle(int reps) throws Throwable {
 MethodHandle mh = MethodHandles.lookup().findVirtual(K.class, exec, 
 MethodType.methodType(void.class, Object.class));
 
 K k = new K();
 
 for (int i = 0; i  reps; i++) {
 mh.invokeExact(k, (Object) i);
 }
 }
 
 public void timeDirect(int reps) throws Exception {
 Method m = K.class.getMethod(exec, Object.class);
 
 K k = new K();
 
 for (int i = 0; i  reps; i++) {
 k.exec(i);
 }
 }
 
 public void timeIface(int reps) throws Exception {
 M m = new K();
 
 for (int i = 0; i  reps; i++) {
 m.exec(i);
 }
 }
 
 public void timeStatic(int reps) throws Exception {
 for (int i = 0; i  reps; i++) {
 K.execS(i);
 }
 }
 }
 
 public class K implements M {
 static long s = 0;
 
 long l = 0;
 
 @Override
 public void exec(Object o) {
 l += o.hashCode();
 }
 
 public static void execS(Object o) {
 s += o.hashCode();
 }
 }
 
 public interface M {
 void exec(Object o);
 }
 
 Thanks,
 Ashwin (http://www.ashwinjayaprakash.com).
 ___
 mlvm-dev mailing list
 mlvm-dev@openjdk.java.net
 http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

Re: Bug report: failing to call overridden method

[Christian Thalinger]

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 words, it doesn't honor
 the override, and calls the direct target.
 
 Details are toward the end in this JRuby bug:
 http://jira.codehaus.org/browse/JRUBY-6920
 
 It only fails in tier 1 with indy enabled. Does not fail with -Xint or 
 -Tiered.
 
 Hopefully that's enough to go on :)

Indeed.  Thanks for the deep analysis.  I filed:

8000821: JSR 292: C1 fails to call virtual method (JRUBY-6920)

-- Chris

 
 - Charlie
 ___
 mlvm-dev mailing list
 mlvm-dev@openjdk.java.net
 http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

Re: Back to work...JDK8

[Christian Thalinger]

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 
then in hotspot.log).

-- Chris

 
 made not compilable
 rubyjit.Sprockets::Helpers::RailsHelper$$asset_paths_E7117E440B09EADB5156B41F6B4DBBB1B0325779648508524::__file__
 (305 bytes)
 
 On Sat, Sep 15, 2012 at 3:08 PM, Charles Oliver Nutter
 head...@headius.com wrote:
 Ok...I'm starting to poke a bit at JDK8 indy stuff to investigate perf
 challenges. This thread will host my observations.
 
 Today I'm monitoring compilation logs, and the odd thing is that no
 matter how long I run, PrintCompilation shows no signs of slowing. I
 would assume that the compilation logs have a longer tail due to
 tiering, but this seems excessive...it's just going on and on and on.
 
 That alone wouldn't worry me unless the JVM guys tell me to worry, but
 then I see things like this over and over in the logs:
 
 782140 40781   4
 rubyjit.Rack::Session::Abstract::OptionsHash$$\=\{\}_CBCE967579AE6F1F55C9FF71BA8804158EC7869A648508524::__file__
 (10 bytes)
 782144 40666   3
 rubyjit.Rack::Session::Abstract::OptionsHash$$\=\{\}_CBCE967579AE6F1F55C9FF71BA8804158EC7869A648508524::__file__
 (10 bytes)   made not entrant
 782144 40781   4
 rubyjit.Rack::Session::Abstract::OptionsHash$$\=\{\}_CBCE967579AE6F1F55C9FF71BA8804158EC7869A648508524::__file__
 (10 bytes)   made not entrant
 
 So this particular piece of code was compiled and then made not
 entrant just 4ms later?
 
 I see this over and over and over again...in fact, late in this run,
 perhaps 3/4 of the output lines are made not entrant or made
 zombie and it just goes and goes and goes.
 
 Should I be concerned about this?
 
 Here's a dump of just a small portion of PrintCompilation output...
 
 
 1249422 50524   3
 rubyjit.Rack::Request$$port_C30B05D438C56FB2565C807617206F20B98E2FE2648508524::__file__
 (8 bytes)
 1249424 50525   3
 rubyjit.Mime::Mimes$$symbols_100420D4F9BB142680CD7BB51F79045E1B619030648508524::__file__
 (8 bytes)
 1249810 50526   4
 rubyjit.ActiveRecord::LogSubscriber$$runtime=_CD1758211548CDD3492DAD323D979039EA4BC0ED648508524::__file__
 (10 bytes)
 1249824 50315   3
 rubyjit.ActiveRecord::LogSubscriber$$runtime=_CD1758211548CDD3492DAD323D979039EA4BC0ED648508524::__file__
 (10 bytes)   made not entrant
 1249825 50526   4
 rubyjit.ActiveRecord::LogSubscriber$$runtime=_CD1758211548CDD3492DAD323D979039EA4BC0ED648508524::__file__
 (10 bytes)   made not entrant
 1249969 50527   3
 rubyjit.Rack::Request$$GET_D76DBE1FD595925EB82EFFF575EF7260C14C3234648508524::__file__
 (10 bytes)
 1249979 50528   3
 rubyjit.ActionDispatch::Http::ParameterFilter$$compiled_filter_E4708BFBB5F4AD1657B9E83836ACFDC8B379C6DB648508524::__file__
 (8 bytes)
 1249980 50474   4
 rubyjit.#Class:0x11e31625$$asset_host_9AFC94A2EF47E84248C0CF85B1FB121C8BE53470648508524::__file__
 (15 bytes)   made zombie
 1249981 50529   3
 rubyjit.ActionDispatch::Http::MimeNegotiation$$accepts_34A6B9527E85807CF247423542D5090EEF79001A648508524::__file__
 (8 bytes)
 1249986 50530   3
 rubyjit.ActionDispatch::Request$$method_EC59F5DFD894E82F7D9FF308054AAFB27CBE06AB648508524::__file__
 (8 bytes)
 1249990 50305   3
 rubyjit.Time$$minus_with_coercion_0F5E81EFFA4D396BAA52CFBEA356B55F32726771648508524::__file__
 (10 bytes)   made zombie
 1249992 50531   3
 rubyjit$ActionController::Instrumentation$$process_action_1910D6D8DE3509AA678DB94D5691451BDEB50046648508524$block_0$RUBY$__file__::call
 (13 bytes)
 1249998 50532   3
 rubyjit.ActionController::Base$$_run_process_action_callbacks_1CEABAA1B8561DBCB7E134F0C024BA9AF08B531A648508524::__file__
 (10 bytes)
 1250006 50533   3
 rubyjit.ActionController::RequestForgeryProtection$$verified_request?_F8254ECDD493CE9EE41068057805A438954180D2648508524::__file__
 (8 bytes)
 1250010 50106   3
 rubyjit.Rack::Cache::CacheControl$$parse_AFED9E9AA448B78AAAB435669B61A6DADA1E75DF648508524::__file__
 (10 bytes)   made zombie
 1250014 50466   4
 rubyjit.#Module:0x7fe59880$$locale_595319C157ACD915A0CB1B6E65F30E93C7D07C8C648508524::__file__
 (8 bytes)   made zombie
 1250016 50534   3
 rubyjit.AbstractController::ViewPaths$$formats=_978E9AE3520041B33FAA82EED51F2733EDB234D5648508524::__file__
 (10 bytes)
 1250018 50460   4
 rubyjit.Rack::Cache::CacheControl$$parse_AFED9E9AA448B78AAAB435669B61A6DADA1E75DF648508524::__file__
 (10 bytes)   made zombie
 1250020 50276   3
 rubyjit.Rack::Request$$scheme_C395E273E8CBF823C70EDCBBFC52DF10B6269234648508524::__file__
 (8 bytes)   made zombie
 1250020 50480   4
 rubyjit.Rack::Request$$GET_D76DBE1FD595925EB82EFFF575EF7260C14C3234648508524::__file__
 (128 bytes)   made zombie
 1250026 50535   3
 

Re: Diagnosing performance cliffs on JDK7.

[Christian Thalinger]

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 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 question is compiled a couple of times and then produces a
 
 COMPILE SKIPPED: out of nodes before macro expansion (not retry able)
 
 What JDK version are you seeing this problem with?
 
 JDK 1.7.0 update 4, hotspot 23.0.b21

I see.  Honestly I never saw this before with JSR 292 code but I have an idea 
why this is happening.  It is a performance cliff but a different one than the 
one we were always talking about.  This might also hit us in the new 
implementation.  At least now until we revisited our inlining.

Could you try to run this with the latest JDK 8 b52:

http://jdk8.java.net/download.html

That is the first JDK 8 build that contains our new JSR 292 implementation.

-- Chris

 
 ___
 mlvm-dev mailing list
 mlvm-dev@openjdk.java.net
 http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

Re: Missing invokehandle handling in bytecodeInterpreter.cpp

[Christian Thalinger]

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 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/openjdk/hotspot-comp/hotspot/src/share/vm/interpreter/bytecodeInterpreter.cpp:2464),
  pid=18585, tid=140737337317120
 #  fatal error: Unimplemented opcode 232 = invokehandle
 
 Looking at bytecodeInterpreter.cpp it seem to simply not handle
 invokehandle. I would like to add this, but I don't know what exactly
 this bytecode is supposed to do. Could you give me pointers to the
 necessary information or provide some help with this? (Or maybe I am
 doing something wrong here, and should not arrive there at all?)
 
 I disabled the invokevirtual-invokehandle rewriting for now (this
 should be safe/correct, right?), and it brings me further into my
 unimplemented handler for vmIntrinsics::_invokeBasic. Need to figure out
 what this is supposed to do (any hints about this one?)..
 
 You can't disable the rewriting and run JSR 292 code.  That simply won't 
 work.  Look at one of the implementations of TemplateTable::_invokehandle 
 and try to do the same in the C++ interpreter.
 
 -- Chris
 
 Ok, I think I made some progress, but now got stuck again.
 
 Alright, I think I figured everything out. Implemented interpreter
 bytecode handler for invokehandle and basically rewrote the
 invokedynamic handler, and implemented the intrinsics for invokeBasic,
 linkToStatic, linkToSpecial, linkToVirtual and linkToInterface and it
 works (i.e. passes jtreg testcases for java/lang/invoke). I will make
 the code available soon (as soon as it's cleaned up, probably after my
 vacation, last week of August).

That's great!  Sorry I couldn't reply.

-- Chris

 
 Cheers,
 Roman
 
 
 ___
 mlvm-dev mailing list
 mlvm-dev@openjdk.java.net
 http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

Re: Missing invokehandle handling in bytecodeInterpreter.cpp

[Christian Thalinger]

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/openjdk/hotspot-comp/hotspot/src/share/vm/interpreter/bytecodeInterpreter.cpp:2464),
  pid=18585, tid=140737337317120
 #  fatal error: Unimplemented opcode 232 = invokehandle
 
 Looking at bytecodeInterpreter.cpp it seem to simply not handle
 invokehandle. I would like to add this, but I don't know what exactly
 this bytecode is supposed to do. Could you give me pointers to the
 necessary information or provide some help with this? (Or maybe I am
 doing something wrong here, and should not arrive there at all?)
 
 I disabled the invokevirtual-invokehandle rewriting for now (this
 should be safe/correct, right?), and it brings me further into my
 unimplemented handler for vmIntrinsics::_invokeBasic. Need to figure out
 what this is supposed to do (any hints about this one?)..

You can't disable the rewriting and run JSR 292 code.  That simply won't work.  
Look at one of the implementations of TemplateTable::_invokehandle and try to 
do the same in the C++ interpreter.

-- Chris

 
 Regards,
 Roman
 
 
 ___
 mlvm-dev mailing list
 mlvm-dev@openjdk.java.net
 http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

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

[christian . thalinger]

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.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

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

[Christian Thalinger]

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 scales only with type schema
 complexity, not workload complexity.
 
 If I had a nickel...
 
 Not sure if this logic is applicable in this particular case. This is
 the potential performance cliff you are eager to get rid of with new
 implementation.

No it's not.  We know exactly what causes the performance cliff.  It's a 
completely unrelated issue in the VM.

-- Chris

 Given enough users and applications make use of this
 code, someone will eventually step and burn on this.
 
 This wishful thinking it's okay to use synchronized here, because this
 couldn't possibly get contended lead to many beautiful scalability
 bottlenecks throughout the JDK. While it is usually a simple thing to
 fix, I'm keen on not allowing to make the same mistakes over and over again.
 
 So in this case, static synchronized is the correct choice.
 
 I shall wait for mainline integration to complete and then try to run
 the microbenchmarks against the new backend; will see if this potential
 issue is the practical one.
 
 -Aleksey.
 
 ___
 mlvm-dev mailing list
 mlvm-dev@openjdk.java.net
 http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

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

[christian . thalinger]

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
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

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

[christian . thalinger]

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 list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

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

[Christian Thalinger]

JDK testing found a small bug:

diff --git a/src/share/vm/oops/cpCacheOop.cpp b/src/share/vm/oops/cpCacheOop.cpp
--- a/src/share/vm/oops/cpCacheOop.cpp
+++ b/src/share/vm/oops/cpCacheOop.cpp
@@ -486,7 +486,8 @@
 // virtual and final so _f2 contains method ptr instead of vtable index
 if (f2_as_vfinal_method() == old_method) {
   // match old_method so need an update
-  set_f2_as_vfinal_method(new_method);
+  // NOTE: can't use set_f2_as_vfinal_method as it asserts on different 
values
+  _f2 = (intptr_t)new_method;
   if (RC_TRACE_IN_RANGE(0x0010, 0x0040)) {
 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. Should we call 
 throw_IncompatibleClassChangeError() as we do in other places?:
 
 +  if (!EnableInvokeDynamic) {
 +// rewriter does not generate this bytecode
 +__ should_not_reach_here();
 +return;
 +  }
 
 Hmm.  This really should not happen and EnableInvokeDynamic is on by default 
 anyway.  I doubt someone turns it off.
 
 It's now a diagnostic switch.  It can be used to verify that an app. is not 
 using 292, which is occasionally helpful.
 
 constantPoolOop.cpp:
 Why not use guarantee() for bad operants?
 
 Not sure.  John?
 
 The code in that file uses assert; I think I'm following the existing 
 practice there.  The CP code operates after initial verification passes, so 
 assert is suitable, I think.
 
 Why you need separate scopes in resolve_bootstrap_specifier_at_impl()?
 
 To keep oops from being visible.  Might result in bad crashes.
 
 Yes.  An alternative is to have the x_oop variables visible at top level, but 
 to put in DEBUG_ONLY(x_oop = NULL).  Having the temporary scoped seems 
 cleaner to me, but maybe my sense of style is off here.
 
 
 I will refresh the review patch in mlvm.  Thank you!
 
 Yes, thanks!
 
 — John
 ___
 mlvm-dev mailing list
 mlvm-dev@openjdk.java.net
 http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

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

[christian . thalinger]

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.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

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

[Christian Thalinger]

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
 --- a/src/share/vm/oops/cpCacheOop.cpp
 +++ b/src/share/vm/oops/cpCacheOop.cpp
 @@ -486,7 +486,8 @@
 // virtual and final so _f2 contains method ptr instead of vtable index
 if (f2_as_vfinal_method() == old_method) {
   // match old_method so need an update
 -  set_f2_as_vfinal_method(new_method);
 +  // NOTE: can't use set_f2_as_vfinal_method as it asserts on different 
 values
 +  _f2 = (intptr_t)new_method;
   if (RC_TRACE_IN_RANGE(0x0010, 0x0040)) {
 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. Should we call 
 throw_IncompatibleClassChangeError() as we do in other places?:
 
 +  if (!EnableInvokeDynamic) {
 +// rewriter does not generate this bytecode
 +__ should_not_reach_here();
 +return;
 +  }
 
 Hmm.  This really should not happen and EnableInvokeDynamic is on by 
 default anyway.  I doubt someone turns it off.
 
 It's now a diagnostic switch.  It can be used to verify that an app. is not 
 using 292, which is occasionally helpful.
 
 constantPoolOop.cpp:
 Why not use guarantee() for bad operants?
 
 Not sure.  John?
 
 The code in that file uses assert; I think I'm following the existing 
 practice there.  The CP code operates after initial verification passes, so 
 assert is suitable, I think.
 
 Why you need separate scopes in resolve_bootstrap_specifier_at_impl()?
 
 To keep oops from being visible.  Might result in bad crashes.
 
 Yes.  An alternative is to have the x_oop variables visible at top level, 
 but to put in DEBUG_ONLY(x_oop = NULL).  Having the temporary scoped seems 
 cleaner to me, but maybe my sense of style is off here.
 
 
 I will refresh the review patch in mlvm.  Thank you!
 
 Yes, thanks!
 
 — John
 ___
 mlvm-dev mailing list
 mlvm-dev@openjdk.java.net
 http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
 
 ___
 mlvm-dev mailing list
 mlvm-dev@openjdk.java.net
 http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

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

[christian . thalinger]

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 list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

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

[Christian Thalinger]

On Jul 17, 2012, at 4:32 PM, Vladimir Kozlov wrote:

  linkResolver.cpp:
  Can you replace infinite for(;;) in resolve_invokedynamic() with finite 
  loop since the body is executed once or twice.
 
  Hmm.  What limit do you have in mind?
 
 It is not loop by logic. The code is trying to avoid double the check for 
 CallSite has been bound already. I think it could be re-arranged as next:
 
 +  Handle bootstrap_specifier;
 +  // Check if CallSite has been bound already:
 +  ConstantPoolCacheEntry* cpce = pool-cache()-secondary_entry_at(index);
 +  if (cpce-is_f1_null()) {
 +int pool_index = 
 pool-cache()-main_entry_at(index)-constant_pool_index();
 +oop bsm_info = pool-resolve_bootstrap_specifier_at(pool_index, CHECK);
 +assert(bsm_info != NULL, );
 +// FIXME: Cache this once per BootstrapMethods entry, not once per 
 CONSTANT_InvokeDynamic.
 +bootstrap_specifier = Handle(THREAD, bsm_info);
 +  }
 +  if (!cpce-is_f1_null()) {
 +methodHandle method(THREAD, cpce-f2_as_vfinal_method());
 +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 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 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_check(). Use 
 brx() instead of br() since you compare pointers. And use 
 cmp_and_brx_short() if delayed instruction is nop().
 Done.
 Use fatal() instead of guarantee:
 guarantee(false, err_msg(special_dispatch=%d, special_dispatch));
 Done.
 interpreter_sparc.cpp:
 In generate_method_entry() use fatal() instead of ShouldNotReachHere():
 fatal(err_msg(unexpected method kind: %d, kind));
 Good idea.  Done.
 
 methodHandles_sparc.cpp:
 In MethodHandles::verify_klass() calls restore() should be after BINDs.
 Argh.  I haven't seen you've found this bug.  It took me a while to debug 
 this :-)
 In MethodHandles::jump_from_method_handle() use cmp_and_br_short(temp, 0, )
 Done.
 Instead of 100 use strlen(name)+50:
 +char* qname = NEW_C_HEAP_ARRAY(char, 100);
 +jio_snprintf(qname, 100,
 Done.
 sharedRuntime_x86_32.cpp:
 sharedRuntime_x86_64.cpp:
 The same problem with L_fail label as in sharedRuntime_sparc.cpp.
 Done.
 templateInterpreter_x86_32.cpp:
 templateInterpreter_x86_64.cpp:
 Again use use fatal() instead of ShouldNotReachHere() in 
 generate_method_entry()
 Done.
 I see in several files next code pattern. Should we call 
 throw_IncompatibleClassChangeError() as we do in other places?:
 
 +  if (!EnableInvokeDynamic) {
 +// rewriter does not generate this bytecode
 +__ should_not_reach_here();
 +return;
 +  }
 Hmm.  This really should not happen and EnableInvokeDynamic is on by default 
 anyway.  I doubt someone turns it off.
 c1_FrameMap.cpp:
 Why is ShouldNotReachHere() for mh_invoke in  
 FrameMap::java_calling_convention()?
 That was old, unused code.  Removed.
 c1_GraphBuilder.cpp:
 add parenthesis:
 const bool is_invokedynamic = code == Bytecodes::_invokedynamic;
 Done.
 nmethod.cpp:
 Don't put printing nmethod's addresses under Verbose flag.
 Leftover.  Removed.
 linkResolver.cpp:
 Can you replace infinite for(;;) in resolve_invokedynamic() with finite 
 loop since the body is executed once or twice.
 Hmm.  What limit do you have in mind?
 templateInterpreter.cpp:
 why you need additional {} around the loop?
 We don't.  I think it was used for better visibility of the MH code.  
 Removed.
 constantPoolOop.cpp:
 Why not use guarantee() for bad operants?
 Not sure.  John?
 Why you need separate scopes in resolve_bootstrap_specifier_at_impl()?
 To keep oops from being visible.  Might result in bad crashes.
 symbol.cpp:
 The loop in index_of_at() should be for(; scan = limit; scan++) and after 
 loop return -1.
 Done.
 bytecodeInfo.cpp:
 Don't add spaces into conditions, looks strange.
 It's more readable:
  if ( callee-is_native()) return native method;
  if ( callee-is_abstract())   return abstract method;
  if (!callee-can_be_compiled())   return not compilable 
 (disabled);
  if (!callee-has_balanced_monitors()) return not compilable 
 (unbalanced monitors);
  if ( callee-get_flow_analysis()-failing())  return not compilable (flow 
 analysis failed);
 vs.
  if (callee-is_native())  return native method;
  if (callee-is_abstract())return abstract method;
  if (!callee-can_be_compiled())   return not compilable 
 (disabled);
  if (!callee-has_balanced_monitors()) return not compilable 
 (unbalanced monitors

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

[christian . thalinger]

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-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

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

[christian . thalinger]

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

___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

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

[christian . thalinger]

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 list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

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

[Christian Thalinger]

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_check(). Use brx() 
 instead of br() since you compare pointers. And use cmp_and_brx_short() if 
 delayed instruction is nop().

Done.

 
 Use fatal() instead of guarantee:
 guarantee(false, err_msg(special_dispatch=%d, special_dispatch));

Done.

 
 interpreter_sparc.cpp:
 In generate_method_entry() use fatal() instead of ShouldNotReachHere():
 fatal(err_msg(unexpected method kind: %d, kind));

Good idea.  Done.

 
 
 methodHandles_sparc.cpp:
 In MethodHandles::verify_klass() calls restore() should be after BINDs.

Argh.  I haven't seen you've found this bug.  It took me a while to debug this 
:-)

 
 In MethodHandles::jump_from_method_handle() use cmp_and_br_short(temp, 0, )

Done.

 
 Instead of 100 use strlen(name)+50:
 +char* qname = NEW_C_HEAP_ARRAY(char, 100);
 +jio_snprintf(qname, 100,

Done.

 
 sharedRuntime_x86_32.cpp:
 sharedRuntime_x86_64.cpp:
 The same problem with L_fail label as in sharedRuntime_sparc.cpp.

Done.

 
 templateInterpreter_x86_32.cpp:
 templateInterpreter_x86_64.cpp:
 Again use use fatal() instead of ShouldNotReachHere() in 
 generate_method_entry()

Done.

 
 I see in several files next code pattern. Should we call 
 throw_IncompatibleClassChangeError() as we do in other places?:
 
 +  if (!EnableInvokeDynamic) {
 +// rewriter does not generate this bytecode
 +__ should_not_reach_here();
 +return;
 +  }

Hmm.  This really should not happen and EnableInvokeDynamic is on by default 
anyway.  I doubt someone turns it off.

 
 c1_FrameMap.cpp:
 Why is ShouldNotReachHere() for mh_invoke in  
 FrameMap::java_calling_convention()?

That was old, unused code.  Removed.

 
 c1_GraphBuilder.cpp:
 add parenthesis:
 const bool is_invokedynamic = code == Bytecodes::_invokedynamic;

Done.

 
 nmethod.cpp:
 Don't put printing nmethod's addresses under Verbose flag.

Leftover.  Removed.

 
 linkResolver.cpp:
 Can you replace infinite for(;;) in resolve_invokedynamic() with finite loop 
 since the body is executed once or twice.

Hmm.  What limit do you have in mind?

 
 templateInterpreter.cpp:
 why you need additional {} around the loop?

We don't.  I think it was used for better visibility of the MH code.  Removed.

 
 constantPoolOop.cpp:
 Why not use guarantee() for bad operants?

Not sure.  John?

 Why you need separate scopes in resolve_bootstrap_specifier_at_impl()?

To keep oops from being visible.  Might result in bad crashes.

 
 symbol.cpp:
 The loop in index_of_at() should be for(; scan = limit; scan++) and after 
 loop return -1.

Done.

 
 bytecodeInfo.cpp:
 Don't add spaces into conditions, looks strange.

It's more readable:

  if ( callee-is_native()) return native method;
  if ( callee-is_abstract())   return abstract method;
  if (!callee-can_be_compiled())   return not compilable 
(disabled);
  if (!callee-has_balanced_monitors()) return not compilable 
(unbalanced monitors);
  if ( callee-get_flow_analysis()-failing())  return not compilable (flow 
analysis failed);

vs.

  if (callee-is_native())  return native method;
  if (callee-is_abstract())return abstract method;
  if (!callee-can_be_compiled())   return not compilable 
(disabled);
  if (!callee-has_balanced_monitors()) return not compilable 
(unbalanced monitors);
  if (callee-get_flow_analysis()-failing())   return not compilable (flow 
analysis failed);

You REALLY want me to remove it? ;-)

 Remove commented code for inline ForceInline methods.

Agreed.  We need to revisit that anyway.

 
 callGenerator.cpp:
 Please, decide which code to use: +#if 1. And I don't think new code is 
 correct.

PredictedDynamicCallGenerator is dead.  Removed.

 
 graphKit.cpp:
 Remove commented debug print.

Done.

 insert_argument() and remove_argument() are not used.

Correct.  Removed.

I will refresh the review patch in mlvm.  Thank you!

-- Chris

 
 
 Vladimir
 
 John Rose wrote:
 As some of you have noticed, Chris Thalinger, Michael Haupt, and I have been 
 working on the mlvm patches [1] for JEP-160 [2] for several months.  These 
 changes make method handles more optimizable.  They refactor lots of magic 
 out of the JVM and into more manageable Java code.
 To get an idea of how much magic is being removed, consider that the 
 change removes 12,000 lines of non-comment code from the JVM, including much 
 assembly code.  It inserts 4900 lines of non-comment code.
 These changes are now stable enough to integrate.  They pass jtreg tests in 
 a number of execution modes and platforms.  They also correctly run various 
 JRuby and Nashorn test programs.  Although there are no performance gains to 
 boast 

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

[christian . thalinger]

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-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

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

[Christian Thalinger]

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
 + meth-lazy-7023639.init.patch

Somehow this patch prevents compilation(?) of LFs and we always run in the LF 
interpreter:

@ 20   
java.lang.invoke.LambdaForm$MH007/1350355205::linkToCallSite (18 bytes)   
inline (hot)
  @ 1   
java.lang.invoke.Invokers::getCallSiteTarget (8 bytes)   inline (hot)
@ 4   
java.lang.invoke.MutableCallSite::getTarget (5 bytes)   inline (hot)
  @ 14   
java.lang.invoke.LambdaForm$LFI005/1770098351::interpret_L (29 bytes)   inline 
(hot)
@ 25   
java.lang.invoke.LambdaForm::interpretWithArguments (124 bytes)   inline (hot)
   !  @ 41   
java.lang.invoke.LambdaForm::compileToBytecode (95 bytes)   too big
  @ 53   
java.lang.invoke.LambdaForm::arityCheck (130 bytes)   inline (hot)
@ 113   
java.lang.invoke.MethodHandle::internalForm (5 bytes)   inline (hot)
  @ 73   java.util.Arrays::copyOf (13 bytes)   
inline (hot)
@ 3   java.lang.Object::getClass (0 bytes)  
 (intrinsic)
@ 6   java.util.Arrays::copyOf (47 bytes)   
(intrinsic)
  @ 96   
java.lang.invoke.LambdaForm::interpretName (122 bytes)   already compiled into 
a big method

Haven't figured out what the exact problem is.

-- Chris

 ! series
 
 ___
 mlvm-dev mailing list
 mlvm-dev@openjdk.java.net
 http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

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

[christian . thalinger]

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
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

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

[christian . thalinger]

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
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

Re: Testing out latest work

[Christian Thalinger]

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 problem that explains a lot of these intermittent failures 
(which I'm about to push after some sanity testing).  And Charlie applied the 
xbmh patch which might explain some of the performance problems (just a wild 
guess).

-- Chris

 
 — John
 ___
 mlvm-dev mailing list
 mlvm-dev@openjdk.java.net
 http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

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

[christian . thalinger]

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

___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

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

[Christian Thalinger]

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 do this).
 
 @@ -2560,10 +2727,11 @@
 TempNewSymbol sde_symbol is never used.
 
 Fixed; thanks.
 
 
 On Jul 11, 2012, at 2:35 PM, Vladimir Kozlov wrote:
 
 c1_GraphBuilder.cpp, can you remove setting bailout message for forced 
 inlining? It should be done proper uniform way for C1 inlining later.
 
 Done.
 
 I think, next assert should check (id = _unknown  id  _annotation_LIMIT) 
 instead:
 
 +void set_annotation(ID id) {
 +  assert((int)id  0  (int)id  BitsPerInt, oob);
 
 Good.  I added this to the constructor
   assert((int)_annotation_LIMIT = (int)sizeof(_annotations_present) * 
 BitsPerByte, );
 
 In header file classFileParser.hpp you should not specify ClassFileParser:: 
 in method parse_classfile_attributes(() declaration:
 
 ClassFileParser::ClassAnnotationCollector* parsed_annotations
 
 Good catch.
 
 Instead of asserts in apply_to() methods we should use guarantee(not 
 implemented) or something.
 
 Done:
   +  guarantee(false, no field annotations yet);

fatal would be the right one; it doesn't take a boolean.

-- Chris

 
 
 I don't think next should be part of these changes:
 
 +#if 0
 +// The parsing of @Retention is for example only.
 
 Yes, Michael asked about that too.  The point is to show how annotation 
 payloads can be processed.  Somebody will need it at some point.  I'll make 
 it into a comment; is that OK?
 +// For the record, here is how annotation payloads can be collected.
 +// Suppose we want to capture @Retention.value.  Here is how:
 +//if (id == AnnotationCollector::_class_Retention) {
 
 Add parenthesis around expression in next condition:
 
 +  while (--nann = 0  index-2 + min_size = limit) {
 
 Done:
   +  while ((--nann) = 0  (index-2 + min_size = limit)) {
 
 Instead of passing pointers to classFileParser's new attributes fields 
 (_synthetic_flag, _sourcefile, ...) as arguments add accessors functions 
 which set these fields.
 
 The pointer passing is following the pattern already present for parsing 
 other constructs.  parse_fields is the clearest example.  The parsed 
 information is returned by reference.  I could do as you suggest, but it 
 would work only for top-level class attributes, so there would still be a mix 
 of styles.  My thought is to make the style more uniform by relying on the 
 return-by-reference pattern.
 
 But I'll change it if you insist.
 
 I think next is typo, should be _in_method check:
 
 +  case 
 vmSymbols::VM_SYMBOL_ENUM_NAME(java_lang_invoke_ForceInline_signature):
 +if (_location != _in_class)  break;
 +return _method_ForceInline;
 +  default: break;
 +  }
 
 Yes; thanks.
 
 — John
 ___
 mlvm-dev mailing list
 mlvm-dev@openjdk.java.net
 http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

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

[christian . thalinger]

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
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

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

[christian . thalinger]

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
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

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

[christian . thalinger]

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 mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

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

[christian . thalinger]

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
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

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

[christian . thalinger]

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

___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

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

[christian . thalinger]

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
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

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

[Christian Thalinger]

Vote: yes

On Jun 19, 2012, at 2:31 PM, John Rose wrote:

 I hereby nominate Michael Haupt to Multi-Language VM Committer.
 
 Starting in January 2012, Michael has made the following contributions to the 
 current effort to optimizing the method handles implementation:
 
 * bytecode generation for LambdaForm invokers,
  http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/4d68984c88ac
  http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/ff435bb51f76
  http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/ec43dd5d3757
 
 * @ForceInline annotation, its detection in HotSpot and exploitation by C1,
  http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/4ad86bc6f440
 
 * a first step towards a more lightweight BoundMethodHandle implementation.
  http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/113942a6e532
  http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/b7a013ed6f4c
 
 In addition to the above six contributions (some of which are quite large), 
 Michael's insights have been useful to Christian and me in forming our design 
 for JSR 292 optimizations.
 
 Michael is a member of the Maxine team at Oracle Labs, where he is working on 
 an implementation of JSR 292 that will be based on results from the MLVM 
 project.
 
 Votes are due by July 3, 5:00 PM PDT.
 
 Only current Multi-Language VM Committers [1] are eligible to vote on
 this nomination.  Votes must be case in the open by replying to
 to this mailing list.
 
 For Lazy Consensus voting instructions, see [2].
 
 Here is more information to expedite 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.
 
 The following is a minimum affirmative reply:
 
 To: Da Vinci Machine Project mlvm-dev@openjdk.java.net
 Subject: Re: CFV: New Multi-Language VM Committer: Michael Haupt
 — message body —
 Vote: yes
 
 Best wishes,
 
 John Rose
 MLVM Lead
 
 [1] http://openjdk.java.net/census
 [2] http://openjdk.java.net/projects/#committer-vote
 
 ___
 mlvm-dev mailing list
 mlvm-dev@openjdk.java.net
 http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

Re: performance degeneration from jdk7u2 to jdk7u6?

[Christian Thalinger]

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 to the next directly involved method 
 call. So in
 
 int fib(int x) {
 if (x=1) return 1
 return fib(x-1)+fib(x-2)
 }
 
 the plus will now have directly return type int, instead of Object.
 
 In a first iteration I made a primitives taking minus method, that also 
 returns int. And nice, runtime is down from 3.5 (on update 2) to 2.5 (no 
 tiered compilation and update 6).
 
 That is not yet making really use of the type back propagation, so in 
 the next iteration I added a (II)I plus method as well. Before the 
 callsite target type was (II)Object, now it is (Object,Object)I, so only 
 little I can save on boxing, but let us see... 2.1s! And it stabilizes 
 much faster than before too. That's almost as much gain as before (in 
 percent). Certainly more than I thought.
 
 Had I only used the plus method and not the minus method as well, I 
 would have ended up with 4.2s. only both together do make it that fast 
 now. A behaviour I noticed with primitive optimizations as well. An 
 optimization done in isolation can make things slower or does show only 
 little gain, but in combination they are suddenly much better. Another 
 interesting aspect is, now I don't see the slowdown through tiered 
 compilation anymore. The times are more or less equal with and without 
 tiered compilation, while before it was always slower with tiered 
 compilation not disabled (in update 6 it is on by default).
 
 So the current state of my fib program is:
 
 indy: 2.1s
 primopts: 1.2s
 callsite caching: 4s
 
 Now I know that using catchException is causing quite a problem for 
 indy, so I removed that guard for the math operations plus and minus. It 
 is legal, since in those cases I can be certain I don't need it. And now 
 indy is at 1.2s! That means primopts and indy are no on par. That's very 
 cool! I mean I expected indy to come near indy, but to actually get on 
 par with it... I would never have thought that is possible.

Sorry, I was to busy to even read this thread, yet.  But cool you figured it 
out :-)

-- Chris

 
 The assembly is still quite big: http://rifers.org/paste/show/1717
 But much better already.
 
 bye Jochen
 
 -- 
 Jochen blackdrag Theodorou - Groovy Project Tech Lead
 blog: http://blackdragsview.blogspot.com/
 german groovy discussion newsgroup: de.comp.lang.misc
 For Groovy programming sources visit http://groovy-lang.org
 
 ___
 mlvm-dev mailing list
 mlvm-dev@openjdk.java.net
 http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

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

[christian . thalinger]

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
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev