Re: RFR[9]:Fix java/lang/invoke/MethodHandleImpl's use of Unsafe.defineAnonymousClass()

[Rémi Forax]

yes, adding @Hidden solves the first item of my list, but nevertheless changing 
the behavior of defineAnonymousClass does not solve the other items.

That said, i hijack this thread because i have not noticed that 
defineAnonymousClass behavior was changed. I should have started another thread 
about that.

Rémi


Le 11 mai 2016 15:10:02 CEST, Vladimir Ivanov  a 
écrit :
>Let me clarify: both proposed patches move invoker class out of 
>java.lang.invoke package, but add @Hidden on invoke_V instead.
>
>So, JVM should not list it in stack traces and you don't have to filter
>
>it out on your side.
>
>Moreover, I think the absence of @Hidden on 
>j.l.i.MethodHandleImpl.T.invoke_V was an overlook.
>
>Best regards,
>Vladimir Ivanov
>
>On 5/11/16 3:59 PM, fo...@univ-mlv.fr wrote:
>> - Mail original -
>>> De: "Vladimir Ivanov" 
>>> À: "Remi Forax" , "shilpi rastogi"
>
>>> Cc: core-libs-...@openjdk.java.net, "John Rose"
>, "Michael Haupt" ,
>>> "paul sandoz" , "Da Vinci Machine Project"
>
>>> Envoyé: Mercredi 11 Mai 2016 14:50:25
>>> Objet: Re: RFR[9]:Fix java/lang/invoke/MethodHandleImpl's use of
>Unsafe.defineAnonymousClass()
>>>
>>> Remi, I'm curious why doesn't @Hidden on the invoker method solve
>your
>>> problem?
>>>
>>> Best regards,
>>> Vladimir Ivanov
>>
>> Hi Vladimir,
>> as far as i know @Hidden only work on the stackframe that correspond
>to a method marked with @Hidden,
>> not for the stackframe on top of the stackframe marked.
>> So having the invoker marked with @Hidden is not enough, but maybe
>i'm wrong.
>>
>> Rémi
>>
>>>
>>> On 5/11/16 3:44 PM, Remi Forax wrote:
 Hi all,
 changing the behavior of defineAnonymousClass in 9 is huge burden
>for me
 and i believe for anybody that maintains a dynamic language
>runtime.

 As an implementer, being able to choose the package of an anonymous
>class
 is an important feature.
 I use to choose carefully the package name for:
 - filtering the stack trace element that will be shown or not to
>the user.
   This patch specifically broke the stack trace that my runtime
>will emit
   because it removes "java.lang.invoke".
   I'm not the only one to filter out stacktrace element that starts
>with
   "java.lang.invoke", Nashorn or JRuby do that too.
   I can modify the code to use the new StackWalking API if all the
>method
   handle form artifact are marked with an interface or something
>like
   this.

 - generate proxy in an existing package
   see https://github.com/forax/proxy2

 - generate code specialization (specialization of an existing
>method for
 some primitive types) of an existing class in an existing package
   (for the specialization, i specialize the constant pool at
>runtime so i
   have no choice but to use defineAnonymousClass).


 I understand that being able to generate a class in any package do
>not work
 well with the jigsaw view of the world but that's why
>defineAnonymousClass
 is in Unsafe after all.

 regards,
 Rémi

 - Mail original -
> De: "shilpi rastogi" 
> À: core-libs-...@openjdk.java.net, "John Rose"
>,
> "Michael Haupt" ,
> "paul sandoz" , "Vladimir Ivanov"
> 
> Envoyé: Mercredi 11 Mai 2016 13:24:09
> Objet: RFR[9]:Fix java/lang/invoke/MethodHandleImpl's use of
>   Unsafe.defineAnonymousClass()
>
> Hi All,
>
> Please review the following-
>
> https://bugs.openjdk.java.net/browse/JDK-8149574
>
> Solution: Changed anonymous class package name with the package
>name of
> its host class.
>
> Two approaches to solve this-
> 1.  Parse .class and get the class name index form constant pool
>and
> patch it with new name
> http://cr.openjdk.java.net/~srastogi/8149574/webrev.05/
>
> 2. Create class with new name (With ASM)
> http://cr.openjdk.java.net/~srastogi/8149574/webrev.06/
>
> Which approach is better?
>
> Thanks,
> Shilpi
>
>
>
>
>>>

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

Re: JFokus VM Tech Day 2016

[Rémi Forax]

:)

Do you plan to attend the VM Tech day ?

Rémi


Le 12 novembre 2015 02:37:04 CET, John Rose  a écrit :
>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.
>
>
>
>___
>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: What can we improve in JSR292 for Java 9?

[Rémi Forax]

Hi John,
comment inlined

Le 26 août 2015 00:30:00 CEST, John Rose  a écrit :
>On Feb 25, 2015, at 6:29 PM, John Rose  wrote:
>> 
>> Maybe this is general enough:
>> 
>>MHs.loop(init, predicate, body)(*a)
>>=> { let i = init(*a); while (predicate(i, *a)) { i = body(i, *a);
>} return i; }
>> 
>> ...where the type of i depends on init, and if init returns void then
>you
>> have a classic side-effect-only loop.
>
>FTR, I've been thinking more about this one, with help from Michael
>Haupt.
>
>The above loop is pretty good, except for a couple of things: 'i' ought
>to be tuple of loop-varying values, and the exit path needs a more
>general post-processing step, a "finalizer" that corresponds to the
>initializers that set up the loop variables.
>
>A generalized (linear) loop has two kinds of values flowing within it:
>loop-invariant and loop-varying. (The control predicate has a special
>role, but may be classed as loop-varying. The finalizer is also
>special, and loop-invariant.) Loop-varying values can be inputs,
>control values (array indices, etc.), and outputs, but can all, I
>think, be modeled as "step" functions using a common signature.
>
>This takes us to something like the C for-loop, but with a sprinkle of
>tuples, with a finishing bow around it to tie it up:
>for ((v1,v2,v3,…) = inits; predicate(v1…); (v1…) = step(v1…))  { … }; 
>return finish(v1…);
>
>Loop-local but invariant values can be modeled as non-updated loop
>variables, as in this C idiom:
>  for (int i, limit = computeLimit(); i < limit; i++) …
>
>Pure side effects can be modeled as void-valued step functions, so we
>want to allow void as a corner case for loop variable types.  (I.e.,
>where there is a step but not a value.)  I don't want to make any more
>special provision for pure side effects (such as a unique Runnable-like
>"body" for a loop), both because it isn't necessary, and because it
>encourages sloppy side-effect-driven loops.
>
>If we allow each loop variable to have its own predicate and finalizer,
>we can properly model the effects of ordered guards and special
>early-exit paths.
> 
>loop({init*}, {pred*}, {step*}, {fini*}) := lambda (arg*) {
>  let var* = init*(arg*)
>  for (;;) {
>for ((v,p,s,f) in (var*, pred*, step*, fini*))
>  if (!p(var*, arg*))
>return f(var*, arg*)
>  v = s(var*, arg*)
 // all vars help update each var
>}
>  }
>}
>
>All invocations are exact.
>
>As a bonus we can easily derive post-checked loops (do-while), and
>time-shifted index variables (p++) simply by adding more variables
>and/or steps.

but i think i prefer to have pre and post updates instead of several 
predicates/finishers.

Like this:
loop({init*}, {prestep*}, {pred}, {poststep*}, {fini}) := lambda (arg*) {
  let var* = init*(arg*)
  for (;;) {
foreach v in vars:
  v = prestep(var*, args*)
if (!pred(var*, arg*))
  return fini(var*, arg*)
foreach v in vars:
  v = poststep(var*, args*)
  }

it's less powerful but it seems you can encode all your examples of loops too.

>Constraints on parameter and return types: 
>- There must be the same number of inits, preds, steps, and finis.
>- There must be at least one input function (e.g., a pred, so that the
>loop has a chance to exit).
>- Parameter lists of the init functions must all be the same.
>- Parameter lists of the pred, step, and fini functions must all be the
>same.
>- Parameter lists of the step functions must be a suffix of the
>parameter lists of the init functions.
>- Parameters of the step functions must be the same as the return types
>of the init functions (with voids removed), followed by the common
>suffix.
>- Return types of the predicates must all be boolean.
>- Return types of the finalizers must all be the same (and can be
>void).
>- The return type of each init function must match the return type of
>the corresponding step function (a "var" type or void).
>
>The result, a looping method handle, has a return type taken from the
>finalizer function(s), and argument types taken from the init
>functions.  The loop has one iteration variable for each non-void
>init/step function pair.  Each step/pred/fini call takes all of the
>iteration variable values, followed by all the external
>(loop-invariant) arguments.  No throws are caught by the loop; throws
>cause the loop to terminate abnormally.
>
>In some loops, such as "find first match", the predicate naturally
>follows the step function, because it needs to evaluate the result of
>the step.  To model post-checks (and the classic do/while shape), a
>second "void-valued" loop variable is required:
>
>loop(...) := lambda (arg*) {
>  let (var, _) = (null, void)
>  for (;;) {
>if (_) return _ // trivial predicate: exit branch never taken
>var = s(_, arg*)  // pick up next search key
>if (!p(var, arg*))  // did we find it?
>  return f(var, arg*)  // extract value from search key as needed
>_ = _(var, arg*) // void value, no side effect
>  }
>}
>
>This variable

Re: ClassValue rooting objects after it goes away?

[Rémi Forax]

No,
it's not expected !

Rémi 

Le 6 août 2015 20:26:43 CEST, Charles Oliver Nutter  a 
écrit :
>Pardon me if this has been discussed before, but we had a bug (with
>fix) reported today that seems to indicate that the JVM is rooting
>objects put into a ClassValue even if the ClassValue goes away.
>
>Here's the pull request: https://github.com/jruby/jruby/pull/3228
>
>And here's one example of the root trace leading back to our JRuby
>runtime. All the roots appear to be VM-level code:
>
>https://dl.dropboxusercontent.com/u/9213410/class-values-leak.png
>
>Is this expected? If we have to stuff a WeakReference into the
>ClassValue it seriously diminishes its utility to us.
>
>- 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: invokedynamic and subclasses

[Rémi Forax]

Hi Mike, 
i've compiled a small list of patterns,
  https://code.google.com/p/jsr292-cookbook/

take a look to the first inlining cache example.

cheers,
Rémi 

Le 24 juin 2015 14:19:32 CEST, Mike Jarmy  a écrit :
>I've been experimenting with invokedynamic in a compiler for a dynamic
>language
>that I'm working on, and I've run into a problem that I'm having
>difficulty
>solving.
>
>Let's say I have a class called A (Java syntax used for clarity):
>
>public class A {
>}
>
>And another called B, that is a subclass of A:
>
>public class B extends A {
>public Value foo;
>public Value bar;
>}
>
>There will be lots of other subclasses of A as well (let's call them C,
>D,
>E,
>etc), some of which will have a field called foo, and some of which
>won't.
>The
>class A will never have any fields -- its sole purpose is to be the
>base
>class
>of everything else.
>
>I have been able to successfully use a static bootstrap method in B, so
>that I
>can compile a call to invokedynamic on the imaginary method get_foo()
>of an
>instance of B, and then reroute the call inside B's bootstrap method
>via
>MethodHandles.Lookup.findGetter(), and finally return the current value
>of
>foo.
>So far, so good.
>
>However, at the place where I am compiling the invokedynamic
>instruction, I
>have no idea if the target is a B, C, D, or what.  All I know is that
>it
>must
>be an A.
>
>So what I really want to be able to do (I think) is to use a static
>bootstrap
>method in A. I want get_foo() to succeed for every invokedynamic call
>to an
>instance of A who's *subclass* really does have a field called foo.
>
>Unfortunately there doesn't seem to be a way to make A do what I want.
>I
>understand why that is -- foo doesn't exist in A, so there is no way to
>create
>a findGetter() call.  But I'm hoping there might be some clever way to
>do it
>anyway.  I've tried all kinds of different approaches (making yet
>another
>invokedynamic call from inside A, etc, etc) but I can't come up with
>anything
>that works.
>
>Any ideas?
>
>By the way, I've figured out how to do this the "old" way, by
>generating
>interfaces for each class that has e.g. a foo field, and casting to
>that
>interface every time I compile a get_foo() invocation.  This works, and
>its
>reasonably performant, but using invokedynamic seems like it would be a
>more
>elegant and flexible solution.
>
>
>
>
>___
>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: Backport 2.0 RC

[Rémi Forax]

On 07/27/2012 09:49 PM, Mark Roos wrote:
>
> Hi Remi
>
> How do I run with the backport?  I am using OSX Lion.
>
> regards
> mark
>
>

download the backport, unzip the zip,
in lib you have two files one is asm-4 and the other is the backport 
(jsr292-backport.jar)

the jsr292-bkkcport.jar is a Java agent so you can just run with the 
jdk6 provided by Apple,
   java -javaagent:lib/jsr292-backport.jar YourMain

the only constraint is that because jsr292-backport.jar has a dependency 
on asm.jar,
they should be in the same directory.

cheers,
Rémi

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

Re: Backport 2.0 RC

[Rémi Forax]

On 07/27/2012 07:56 PM, Jochen Theodorou wrote:
> Am 27.07.2012 18:44, schrieb Rémi Forax:
>> As traditionally for the JVM Summit,
>> I'm please to announce a new version of the JSR 292 backport,
>> http://code.google.com/p/jvm-language-runtime/downloads/list
>>
>> This version as some speed improvements and numerous bug fixes thanks to
>> the Nashorn Team.
>>
>> I'm still interested by any report of your favorite language running
>> with the backport,
>> Jochen?, Mark?, Duncan?, Charles*? or anyone that develop a language
>> runtime.
> The Groovy plans for invokedynamic are that version 3 of Groovy, coming
> next year, will use invokedynamic per default and the backport will be
> then used as a way to make it run on earlier VMs. I haven't really tried
> it out yet, instead in Groovy 2.0.1 we support invokedynamic as a Groovy
> VM plugin for jdk7. But I intend to test your backport against our call
> site caching after the summit
>
> well... I will be in Santa Clara on Sunday already if you want we could
> meet up and try making an integration of your backport. A meeting with
> whoever wants to participate in the invokedynamic workshop to speak what
> to do there is also something that could be done. Otherwise I will have
> to think of it all by myself.

My plane will land Sunday late in the evening, so I think it's better to 
try to figure out that during the summit.

>
> bye blackdrag
>

C U soon,
Rémi

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

Backport 2.0 RC

[Rémi Forax]

As traditionally for the JVM Summit,
I'm please to announce a new version of the JSR 292 backport,
http://code.google.com/p/jvm-language-runtime/downloads/list

This version as some speed improvements and numerous bug fixes thanks to 
the Nashorn Team.

I'm still interested by any report of your favorite language running 
with the backport,
Jochen?, Mark?, Duncan?, Charles*? or anyone that develop a language 
runtime.

cheers,
Rémi
* can I also beg for a special voodoo option of the CLI of JRuby to 
force invokedynamic bytecode on a 1.6 VM ?

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

Re: MethodHandle.bindTo() only for reference types?

[Rémi Forax]

On 07/26/2012 11:50 AM, Aleksey Shipilev wrote:
> Hi John,
>
> On 07/24/2012 11:02 PM, John Rose wrote:
>> On Jul 24, 2012, at 11:09 AM, Attila Szegedi wrote:
>> MethodHandle.bind is a less-general primitive.  The general API is
>> insertArguments.
>>
>> Good 292 support for primitives requires a signature-polymorphic API.
>>
>> Therefore, we have been considering adding something like this, to fill
>> functionality not covered by bind and insertArguments:
> Thanks for thinking forward on this. But let's get back to the original
> issue: inconsistent API between MH.bindTo() and MHs.insertArguments().
> If the latter boxes primitive values, why not to allow the former to do
> the same? Albeit it is not "a good support for primitives", but this is
> the consistency improvement.

The idea that that bindTo() should be used as Attila said when you want 
to de-virtualize a method by fixing the receiver to a particular object.
The idea is that when you see bindTo() in a code you know the intent of 
the programmer without having to track precisely which parameter is 
bound with which value.

>
> Thanks,
> Aleksey.

cheers,
Rémi

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

Re: MethodHandle.bindTo() only for reference types?

[Rémi Forax]

On 07/24/2012 09:02 PM, John Rose wrote:
> On Jul 24, 2012, at 11:09 AM, Attila Szegedi wrote:
>
>> I don't think technically there'd be a difficulty in having it
>> work on primitives, it's just that it ain't the intent; you still use
>> insertArguments() for uses that are not semantically "bind"s.
>
> MethodHandle.bind is a less-general primitive. The general API is 
> insertArguments.
>
> Good 292 support for primitives requires a signature-polymorphic API.
>
> Therefore, we have been considering adding something like this, to 
> fill functionality not covered by bind and insertArguments:
>
> class MethodHandle {
> /** Binds the given argument(s) to the method handle, but does not 
> invoke it.
> * Arguments are not boxed, but rather passed in a 
> signature-polymorphic call.
> * Requires an exact match to the corresponding leading parameter types.
> * Returns a method handle which accepts any remaining arguments,
> * and invokes the original on the combined argument lists.
> * Equivalent to insertArguments(this, 0, args), but may be more efficient.
> * Equivalent to this.bind(args[0]), but may be more efficient.
> */
> public final native MethodHandle invokePartial(Object… args) throws 
> Throwable;
> }
>
> If we do, we will first experiment internally with it (as a non-public 
> API).

invokePartial is in fact, invokedynamic + insertArguments + 
insertArguments (to insert 0) + asType(asVarargCollector) + escape 
analysis (to remove the array allocation and boxing).
I would prefer a way to gently ask the compiler to substitute a 
classical Java call to an invokedynamic one.

The question is: are VMs able to do the escape analysis here or not.
BTW, invokePartial is important because it is the primitive needed when 
you want to create a lambda that capture some values from the scope
so even Java will use it.

>
> — John

Rémi

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

Re: build error on OSX

[Rémi Forax]

On 07/22/2012 07:25 PM, Henri Gomez wrote:
> Hum, commited without this import ?

maybe lost in the patch queue ??

Rémi

> Le 22 juil. 2012 à 15:46, Rémi Forax  a écrit :
>
>> On 07/22/2012 11:38 AM, Henri Gomez wrote:
>>> Hi to all,
>>>
>>> Even using Java 8 for building MLVM, using stephen scripts or my own,
>>> build failed :
>>>
>>>
>>> # Running javac:   43 files; in
>>> /Users/henri/Downloads/mlvm/sources/jdk/make/java/invoke
>>> /Library/Java/JavaVirtualMachines/1.8.0.jdk/Contents/Home/bin/java
>>> -XX:-PrintVMOptions -XX:+UnlockDiagnosticVMOptions -XX:-LogVMOutput
>>> -Djava.awt.headless=true -Xmx512m -Xms512m -XX:PermSize=32m
>>> -XX:MaxPermSize=160m
>>> -Xbootclasspath/p:/Users/henri/Downloads/mlvm/sources/build/macosx-x86_64/langtools/dist/bootstrap/lib/javac.jar
>>> -jar 
>>> /Users/henri/Downloads/mlvm/sources/build/macosx-x86_64/langtools/dist/bootstrap/lib/javac.jar
>>> -Xlint:-path -source 7 -target 7 -encoding ascii
>>> -Xbootclasspath:/Users/henri/Downloads/mlvm/sources/build/macosx-x86_64/classes
>>> -sourcepath 
>>> /Users/henri/Downloads/mlvm/sources/build/macosx-x86_64/gensrc:::/Users/henri/Downloads/mlvm/sources/jdk/src/macosx/classes:/Users/henri/Downloads/mlvm/sources/jdk/src/solaris/classes:/Users/henri/Downloads/mlvm/sources/jdk/src/share/classes
>>> -d /Users/henri/Downloads/mlvm/sources/build/macosx-x86_64/classes
>>> @/Users/henri/Downloads/mlvm/sources/build/macosx-x86_64/tmp/java/java.lang.invoke/.classes.list.filtered
>>> ../../../src/share/classes/java/lang/invoke/MethodType.java:996:
>>> error: cannot find symbol
>>>  private final ConcurrentHashMap map = new
>>> ConcurrentHashMap();
>>>^
>>>symbol:   class ConcurrentHashMap
>>>location: class WeakInternSet
>>> ../../../src/share/classes/java/lang/invoke/MethodType.java:996:
>>> error: cannot find symbol
>>>  private final ConcurrentHashMap map = new
>>> ConcurrentHashMap();
>>>  ^
>>>symbol:   class ConcurrentHashMap
>>>location: class WeakInternSet
>>> 2 errors
>>> make[4]: *** [.compile.classlist] Error 1
>>> make[3]: *** [all] Error 1
>>> make[2]: *** [all] Error 1
>>> make[1]: *** [jdk-build] Error 2
>>> make: *** [build_product_image] Error 2
>>>
>>> *** create symbolic link to last build and persist
>>> 1.8.0_00-mlvm-2012_07_22.jdk into .last_build
>>>
>>> build/macosx-x86_64/j2sdk-bundle/jdk1.8.0.jdk/Contents/Home/bin/java
>>> does not exist, rebuild MLVM with ./update.sh
>>>
>>> Any ideas ?
>> add import java.util.concurrent.ConcurrentHashMap to
>> java/lang/invoke/MethodType.java.
>>> Thanks
>> 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

Re: build error on OSX

[Rémi Forax]

On 07/22/2012 11:38 AM, Henri Gomez wrote:
> Hi to all,
>
> Even using Java 8 for building MLVM, using stephen scripts or my own,
> build failed :
>
>
> # Running javac:   43 files; in
> /Users/henri/Downloads/mlvm/sources/jdk/make/java/invoke
> /Library/Java/JavaVirtualMachines/1.8.0.jdk/Contents/Home/bin/java
> -XX:-PrintVMOptions -XX:+UnlockDiagnosticVMOptions -XX:-LogVMOutput
> -Djava.awt.headless=true -Xmx512m -Xms512m -XX:PermSize=32m
> -XX:MaxPermSize=160m
> -Xbootclasspath/p:/Users/henri/Downloads/mlvm/sources/build/macosx-x86_64/langtools/dist/bootstrap/lib/javac.jar
> -jar 
> /Users/henri/Downloads/mlvm/sources/build/macosx-x86_64/langtools/dist/bootstrap/lib/javac.jar
> -Xlint:-path -source 7 -target 7 -encoding ascii
> -Xbootclasspath:/Users/henri/Downloads/mlvm/sources/build/macosx-x86_64/classes
> -sourcepath 
> /Users/henri/Downloads/mlvm/sources/build/macosx-x86_64/gensrc:::/Users/henri/Downloads/mlvm/sources/jdk/src/macosx/classes:/Users/henri/Downloads/mlvm/sources/jdk/src/solaris/classes:/Users/henri/Downloads/mlvm/sources/jdk/src/share/classes
> -d /Users/henri/Downloads/mlvm/sources/build/macosx-x86_64/classes
> @/Users/henri/Downloads/mlvm/sources/build/macosx-x86_64/tmp/java/java.lang.invoke/.classes.list.filtered
> ../../../src/share/classes/java/lang/invoke/MethodType.java:996:
> error: cannot find symbol
>  private final ConcurrentHashMap map = new
> ConcurrentHashMap();
>^
>symbol:   class ConcurrentHashMap
>location: class WeakInternSet
> ../../../src/share/classes/java/lang/invoke/MethodType.java:996:
> error: cannot find symbol
>  private final ConcurrentHashMap map = new
> ConcurrentHashMap();
>  ^
>symbol:   class ConcurrentHashMap
>location: class WeakInternSet
> 2 errors
> make[4]: *** [.compile.classlist] Error 1
> make[3]: *** [all] Error 1
> make[2]: *** [all] Error 1
> make[1]: *** [jdk-build] Error 2
> make: *** [build_product_image] Error 2
>
> *** create symbolic link to last build and persist
> 1.8.0_00-mlvm-2012_07_22.jdk into .last_build
>
> build/macosx-x86_64/j2sdk-bundle/jdk1.8.0.jdk/Contents/Home/bin/java
> does not exist, rebuild MLVM with ./update.sh
>
> Any ideas ?

add import java.util.concurrent.ConcurrentHashMap to 
java/lang/invoke/MethodType.java.
>
> Thanks

cheers,
Rémi

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

Re: State of MLVM and Lambda

[Rémi Forax]

On 07/20/2012 11:25 AM, Roman Kennke wrote:
> Hello,
>
> Maybe this is a stupid beginner question. I would like to know what is
> the status of MLVM with respect to project Lambda. Is it possible to
> build a JVM that has both (has lambda, or parts of it, already been
> merged into hotspot-comp?)? Is there any overlap between the two, or are
> they largely independent (MLVM mostly hotspot-centric vs. Lambda mostly
> javac centric?)?
>
> Cheers,
> Roman

Hi Roman,
there are two parts in lambda project, you have lambda and default methods,
lambda currently doesn't require runtime support (only javac + JDK)
but default methods are resolved by the VM and as far as I know, the 
default methods part
is not merged into hotspot-comp.

cheers,
Rémi


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

Re: Crash using sun.misc.Unsafe.static

[Rémi Forax]

On 07/18/2012 12:55 AM, John Rose wrote:
> On Jul 16, 2012, at 4:06 PM, Krystal Mok wrote:
>
>> And you're right that this has to do with the PermGen removal 
>> project. The difference comes from [1], which is a part of CR 7017732.
>> To be specific, before the 7017732, static fields are stored in the 
>> instanceKlass of a Java class; an instanceKlass (or its enclosing 
>> klassOopDesc to be exact) is not an Java object.
>> After 7017732, static fields are moved to the tail of java.lang.Class 
>> instances, which are Java objects.
>>
>> So to answer your question, you just shouldn't expect the the code to 
>> work in JDK6/HotSpot.
>
> The API for unsafe access to statics is designed to allow 
> implementations to do one of two things:
>
> 1. store a static variable at a fixed offset within a managed object 
> (addressable via Java references)
> 2. store a static variable at an arbitrary but fixed 64-bit VA (in 
> which case the object base is just null)
>
> The JDK 6 system is in a middle state, where the instanceKlass is a 
> managed object and can move  is not compatible with Java references. 
>  I think there was a time when non-Java oops could be manipulated via 
> Java reference variables, but the practice has always been rather… unsafe.
>
> This could be fixed in JDK 6, but it's probably not worth it.  I 
> recommend spinning bytecoded accessors for statics on JDK 6.  On JDK 7 
> and later, the Class is the base (as Kris pointed out).  This is 
> probably how it's going to stay.

I spin bytecode by default if the field is visible from the callsite and 
wanted to use unsafe with a constant base object
if the field is not visible. So to workaround that bug, I store the base 
object in a non-constant field exactly like reflection does, so it works 
on jdk6. Exactly, I should try to detect if the VM is hotspot or not 
because neither JRockit nor J9 have the same issue.

>
> Thanks for the report.
>
> — John
>
> P.S. For multi-tenancy VMs, the addressing arithmetic for statics 
> would need to take into account the task ID.  But the above design 
> (baseOrNull + longOffset) still works, since the unsafe API doesn't 
> say how the two components get combined.

Rémi

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

Re: Crash using sun.misc.Unsafe.static

[Rémi Forax]

On 07/17/2012 01:06 AM, Krystal Mok wrote:
> Hi Remi,
>
> Looks like it's a trap if you're running this on JDK6's HotSpot VM. If 
> you're running a debug build of the same VM, you should hit an 
> assertion before hitting the ShouldNotReachHere() part.
>
> opto/type.cpp:2477
> assert(o->is_java_object(), "must be java language object");
>
> Even though the source code of JDK6u33 is not open sourced, you could 
> try a similar version of HotSpot VM from OpenJDK, namely the 
> hsx/hsx20/baseline branch, or jdk6/jdk6/hotspot. Make a fastdebug 
> build and you should see the assertion.
>
> And you're right that this has to do with the PermGen removal project. 
> The difference comes from [1], which is a part of CR 7017732.
> To be specific, before the 7017732, static fields are stored in the 
> instanceKlass of a Java class; an instanceKlass (or its enclosing 
> klassOopDesc to be exact) is not an Java object.
> After 7017732, static fields are moved to the tail of java.lang.Class 
> instances, which are Java objects.
>
> So to answer your question, you just shouldn't expect the the code to 
> work in JDK6/HotSpot.

Hi Krys,
Too bad because I wanted to use a similar code in the jsr292 backport
(a Java agent that enable dynamic language runtime written with 
invokedynamic to run on a jdk6 stock VM)

This remember me another question, the java agent use 
java.lang.instrument.Instrumentation.retransform to change
code at runtime and it seems that using retransform disable OSR on the 
retransformed class.
Is there a reason for that ?


>
> [1]: 
> http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/diff/c7f3d0b4570f/src/share/vm/prims/unsafe.cpp

Rémi

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

Crash using sun.misc.Unsafe.static

[Rémi Forax]

Hi guys,
the latest jdk6 (jdk6 update 33) fails hard in the compiler if I try to 
store the result of unsafe.staticFieldBase() in
a static final field, i.e if it's considered as a constant.
Neither recent jdk7 nor jdk8 crash, only jdk6 (it also failed with 
update 21 which is the oldest version I have).

I think it doesn't crash with recent VM because the result of 
unsafe.staticFieldBase() is not a real object
with jdk6 but is a real one with jdk7/jdk8 (because of permgen removal)

Is this bug can be fixed or should I just do not do that ?

cheers,
Rémi

package sun.misc;

import java.lang.reflect.Field;

public class UnsafeCrash {
   private static int value = 1;

   private static final Unsafe UNSAFE;
   private static final Object STATIC_FIELD_BASE;
   private static final long STATIC_FIELD_OFFSET;

   static {
 Field field;
 try {
   field = UnsafeCrash.class.getDeclaredField("value");
 } catch (NoSuchFieldException e) {
   throw new AssertionError(e);
 }
 Unsafe unsafe = Unsafe.getUnsafe();
 UNSAFE = unsafe;
 STATIC_FIELD_BASE = unsafe.staticFieldBase(field);
 STATIC_FIELD_OFFSET = unsafe.staticFieldOffset(field);
   }

   private static int test() {
 return UNSAFE.getInt(STATIC_FIELD_BASE, STATIC_FIELD_OFFSET);
   }

   public static void main(String[] args) {
 int sum = 0;
 for(int i=0; i<10; i++) {
   sum += test();
 }
 System.out.println(sum);
   }
}


[forax@localhost src]$ /usr/jdk/jdk1.6.0_33/bin/java -Xbootclasspath/p:. 
sun.misc.UnsafeCrash
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (type.cpp:2520), pid=26155, tid=139712055437056
#  Error: ShouldNotReachHere()
[thread 139712054384384 also had an error]#

# JRE version: 6.0_33-b04
# Java VM: Java HotSpot(TM) 64-Bit Server VM (20.8-b03 mixed mode 
linux-amd64 compressed oops)
# An error report file with more information is saved as:
# /home/forax/java/workspace/java-blog/src/hs_err_pid26155.log
10
#
# If you would like to submit a bug report, please visit:
#   http://java.sun.com/webapps/bugreport/crash.jsp
#
Aborted

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (type.cpp:2520), pid=26155, tid=139712055437056
#  Error: ShouldNotReachHere()
#
# JRE version: 6.0_33-b04
# Java VM: Java HotSpot(TM) 64-Bit Server VM (20.8-b03 mixed mode 
linux-amd64 compressed oops)
# If you would like to submit a bug report, please visit:
#   http://java.sun.com/webapps/bugreport/crash.jsp
#

---  T H R E A D  ---

Current thread (0x7f1160093800):  JavaThread "C2 CompilerThread0" 
daemon [_thread_in_native, id=26169, 
stack(0x7f113f5f6000,0x7f113f6f7000)]

Stack: [0x7f113f5f6000,0x7f113f6f7000], sp=0x7f113f6f3860,  
free space=1014k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, 
C=native code)
V  [libjvm.so+0x85f725]  VMError::report_and_die()+0x265
V  [libjvm.so+0x3e4dd6]  report_should_not_reach_here(char const*, int)+0x46
V  [libjvm.so+0x830041]  TypeOopPtr::make_from_constant(ciObject*, 
bool)+0x2a1
V  [libjvm.so+0x73bcd5]  Parse::push_constant(ciConstant, bool)+0x385
V  [libjvm.so+0x73b628]  Parse::do_get_xxx(TypePtr const*, Node*, 
ciField*, bool)+0x3e8
V  [libjvm.so+0x73b152]  Parse::do_field_access(bool, bool)+0x142
V  [libjvm.so+0x73a926]  Parse::do_one_bytecode()+0x68d6
V  [libjvm.so+0x72b07a]  Parse::do_one_block()+0x1aa
V  [libjvm.so+0x728ad0]  Parse::do_all_blocks()+0x150
V  [libjvm.so+0x72860b]  Parse::Parse(JVMState*, ciMethod*, float)+0x59b
V  [libjvm.so+0x322064]  ParseGenerator::generate(JVMState*)+0x84
V  [libjvm.so+0x39e7e2]  Compile::Compile(ciEnv*, C2Compiler*, 
ciMethod*, int, bool, bool)+0x762
V  [libjvm.so+0x3217de]  C2Compiler::compile_method(ciEnv*, ciMethod*, 
int)+0x9e
V  [libjvm.so+0x3a914a] 
CompileBroker::invoke_compiler_on_method(CompileTask*)+0x2ca
V  [libjvm.so+0x3a8a35]  CompileBroker::compiler_thread_loop()+0x355
V  [libjvm.so+0x8208c9]  compiler_thread_entry(JavaThread*, Thread*)+0x9
V  [libjvm.so+0x819dd1]  JavaThread::run()+0x121
V  [libjvm.so+0x7117af]  java_start(Thread*)+0x13f


Current CompileTask:
C2: 57   1  sun.misc.UnsafeCrash.test()I (13 bytes)


---  P R O C E S S  ---

Java Threads: ( => current thread )
   0x7f1160098800 JavaThread "Low Memory Detector" daemon 
[_thread_blocked, id=26171, stack(0x7f113f3f4000,0x7f113f4f5000)]
   0x7f1160096000 JavaThread "C2 CompilerThread1" daemon 
[_thread_in_native, id=26170, stack(0x7f113f4f5000,0x7f113f5f6000)]
=>0x7f1160093800 JavaThread "C2 CompilerThread0" daemon 
[_thread_in_native, id=26169, stack(0x7f113f5f6000,0x7f113f6f7000)]
   0x7f1160091000 JavaThread "Signal Dispatcher" daemon 
[_thread_blocked, id=26168, stack(0x7f113f6f7000,0x7f113f7f8000)]
   0x7f1160074800 JavaThread "Finalizer" daemon [_thread_blocked, 
id=26167, stack(0x7f113f7f8000,0x7f113f8

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

[Rémi Forax]

On 07/14/2012 02:02 PM, David Schlosnagle wrote:
> On Fri, Jul 13, 2012 at 5:41 AM, John Rose  
> wrote:
>> On Jul 11, 2012, at 5:53 PM, 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.
>>> …
>>> An associated webrev for hotspot-comp/jdk/ will be posted soon; it 
>>> is already present on mlvm-dev for the curious to examine.  (This 
>>> change set also deletes a lot of old code.)
>> Here is that webrev:
>> http://cr.openjdk.java.net/~jrose/7023639/webrev.jdk.00/
>>
>> These are the changes to JDK code that accompany the JVM changes 
>> already under review.
>>
>> There are 2900 LOC deleted, and 7000 LOC added.  Key changes:
>>   - method handle behavior is fully represented by LambdaForm objects
>>   - chained method handles (including "adapter method handles") are gone
>>   - an ASM-based bytecode spinner compiles LambdaForms when they warm up
>>   - bound method handles are compactly represented without boxing
>>   - the private symbol-resolution interface to the JVM (MemberName) 
>> is improved
>>   - unit tests have more systematic coverage
>>   - a number of minor bugs are fixed
>>
>> This is implementation work.  No public Java APIs are changed, 
>> although the javadoc is slightly edited for clarity.
>>
>> Please have a look.
>>
>> — John

> John,

Hi David,
I hijack the thread ...

>
> I had a few quick comments on your webrev. Some of these might be
> considered premature or unnecessary optimization, so take them as you
> wish.
>
> src/share/classes/java/lang/invoke/BoundMethodHandle.java
>
> On lines 131-132: Just out of curiosity, why use pos+1 in one line
> versus 1+pos on the next? Would it be worthwhile to extract pos+1 to a
> local int end to save some bytecode?
>  MethodHandle bindArgument(int pos, char basicType, Object value) {
>  int end = pos + 1;
>  MethodType type = type().dropParameterTypes(pos, end);
>  LambdaForm form = internalForm().bind(basicType, end, tcount());
>  if (basicType == 'I' && !(value instanceof Integer)) {
>  // Cf. ValueConversions.unboxInteger
>  value = ValueConversions.primitiveConversion(Wrapper.INT,
> value, true);
>  }
>  return cloneExtend(type, form, basicType, value);
>  }

Usually you should not care about this kind of change, micro-optimizing 
is useless.
Or this code is not called enough and you don't care or this code is hot 
and
the JIT will do what should be done and because the JIT may inline
the code of dropParameterTypes and bind(), it will better optimize that you
because it will be able to share more sub-expressions.

Now just for fun, if you count the number of bytecodes, I think your 
proposed code
is bigger because 'end' is the local variable 4 and the is no 
istore_4/iload_4 so
the compiler will use the generic iload/istore which takes 2 bytes.
so pos + 1 is iload_1, iconst_1, iadd, so the current version use 6 
bytecodes,
your version use  iload_1, iconst_1, iadd, istore 4 + iload 4 * 2= 9 
bytecodes

>
> On lines 202-212: Similarly would it be worthwhile to extract types()
> to a local String within internalValues()?
>  final Object internalValues() {
>  String types = types();
>  Object[] boundValues = new Object[types.length()];
>  for (int i = 0; i < boundValues.length; ++i) {
>  try {
>  switch (types.charAt(i)) {
>  case 'L': boundValues[i] = argL(i); break;
>  case 'I': boundValues[i] = argI(i); break;
>  case 'F': boundValues[i] = argF(i); break;
>  case 'D': boundValues[i] = argD(i); break;
>  case 'J': boundValues[i] = argJ(i); break;
>  default : throw new InternalError("unexpected type: "
> + types.charAt(i));
>  }
>  } catch (Throwable t) {
>  throw new InternalError(t);
>  }
>  }
>  return Arrays.asList(boundValues);
>  }

default case should never be called, so don't 'optimize' for it.

>
> On line 464: Is there any reason CACHE should not be final?
>  static final Map CACHE = new IdentityHashMap<>();

this one may be important, static final => const for the VM

>
> On lines 473-486: Do the accesses and mutations of CACHE need to be
> thread safe or are the uses assumed to be safe by other means?
>
> On lines 778-784: Should this use types.charAt(int) rather than
> toCharArray() to copy the array?
>  private static String makeSignature(String types, boolean 
> ctor) {
>  StringBuilder buf = new StringBuilder(SIG_INCIPIT);
>  for (int i = 0; i < types.length(); ++i) {
>  buf.append(typeSig(types.cha

Re: hg: mlvm/mlvm/hotspot: meth: fix to intrinsic compilation; assembler tweaks for debugging; backtrace filtering

[Rémi Forax]

On 07/12/2012 07:14 PM, Charles Oliver Nutter wrote:
> On Thu, Jul 12, 2012 at 2:11 AM, John Rose  wrote:
>> One problem with mixed mode systems is that a method like
>> "executeMyLanguagesInterpretedMethodUntilItGetsCompiled" wants to display a
>> method name based on some value inside the frame itself.  Simply filtering
>> or renaming JVM methods does not cover this case at all.
> This is indeed the problem we face in JRuby. The Hidden annotation
> might help us hide JRuby internals used for call-to-call plumbing, but
> there's no static way to solve the problem of generating a trace for
> interpreter frames.

I agree, but it will greatly simplify the problem because stacktrace will
be smaller so it will be faster to patched them.

>
> Here's part of a Java trace from JRuby, with both compiled and
> interpreted bits in it:
>
> Trace snippit:
>
>   at 
> org.jruby.runtime.callsite.CachingCallSite.call(CachingCallSite.java:135)
>   at org.jruby.ast.CallNoArgNode.interpret(CallNoArgNode.java:63)
>   at org.jruby.ast.NewlineNode.interpret(NewlineNode.java:104)
>   at 
> org.jruby.evaluator.ASTInterpreter.INTERPRET_METHOD(ASTInterpreter.java:75)
>   at 
> org.jruby.internal.runtime.methods.InterpretedMethod.call(InterpretedMethod.java:139)
>   at 
> org.jruby.internal.runtime.methods.DefaultMethod.call(DefaultMethod.java:175)
>   at 
> java.lang.invoke.MethodHandle.invokeWithArguments(MethodHandle.java:566)
>   at 
> org.jruby.runtime.invokedynamic.InvocationLinker.invocationFallback(InvocationLinker.java:149)
>   at blah.method__0$RUBY$foo(blah.rb:4)
>   at 
> java.lang.invoke.MethodHandle.invokeWithArguments(MethodHandle.java:566)
>   at 
> org.jruby.runtime.invokedynamic.InvocationLinker.invocationFallback(InvocationLinker.java:149)
>   at blah.__file__(blah.rb:13)
>   at blah.load(blah.rb)
>
> To generate a Ruby backtrace from this, we use the Java backtrace as a
> "master" and mine out the interesting pieces. Specifically:
>
> 1. Elements with RUBY and __file__ in them are included because they
> represent compiled Ruby code.
> 2. Any Java-based Ruby method in the trace is included, using a list
> we maintain in JRuby as those methods are bound.
> 3. Interpreter entry points are indicated by INTERPRET_METHOD,
> INTERPRET_EVAL, and so on. For each such element, we insert backtrace
> data from our interpreter's backtrace stack (on heap)
>
> This works well for Ruby code but does often omit frames users *want*
> to see, like reflection-called Java methods.
>
> Hiding would work for removing elements, but we'd have to tag a large
> amount of JRuby code (like the entire interpreter) to remove
> everything. Having an annotation to indicate the actual method name
> would be useful for (2) above, but it would not do anything to help us
> dynamically determine the frame for an interpreted section.
>
> While I'd love to see better programmatic access to backtrace
> generation, I can't really envision what it would look like.

A special method handle acting as a decorator should be enough :)
Let say we have a static method backtraceDecorator in MethodHandles
that takes a target method handle and returns a new method handle.
The new method handle will have a supplementary parameter of type String
before all parameters, the content of this parameter will be used
instead of the method name of the target method in the stack trace.
So basically, the handle handle will change the method name of the 
method handle
taken as argument, so the target method handle must be either a constant 
method handle
or the result of a lookup.find* or lookup.unreflect*.

Now in the runtime instead of calling INTERPRET_METHOD directly, the 
runtime should
call the method handle created like this:
MethodHandle interpreterEntryPoint = MethodHandles.backtraceDecorator(
   lookup.findVirtual(..., ''INTERPRET_METHOD"));
and this method handle should be called with the method name as first 
parameter.

>
> On the plus side...the requirement that we always "assemble" our
> backtraces from bits and bobs means we can do fun things like
> alternative formatting and adding color :)
>
> http://min.us/mbIkONLut
>
> I dare say JRuby has the nicest stack traces of any language on the JVM.
>
> - Charlie

cheers,
Rémi


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

Re: hg: mlvm/mlvm/jdk: meth-lazy: merged BMH factory into BMH, added test for primitive parameter binding

[Rémi Forax]

On 07/12/2012 12:10 AM, Michael Haupt wrote:
> Hi Remy,
>
> Am 11.07.2012 um 22:48 schrieb Rémi Forax:
>> Hi Mickael,
>> some minor comments,
>> makeSignature should use a StringBuilder and not a StringBuffer.
>
> good point, thanks!
>
>> ans I don't think generateConcreteBMHClass needs to return a Class> extends BoundMethodHandle>,
>> a Class seems enough so the cast near the end of the method can be
>> removed.
>
> I'd like to keep that to make really clear what Class type instances 
> are expected.
> (There are places where Class would just feel very wrong.)

but the cast seems wrong to me because this one is not enforced by the VM
so if there is a bug, you may lure the reader of the code.
I think a doc comment is better here.

Or perhaps you can use asSubClass() ?

>
> Best,
>
> Michael

regards,
Rémi

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

Re: hg: mlvm/mlvm/jdk: meth: add @Hidden annotations

[Rémi Forax]

On 07/11/2012 10:24 PM, John Rose wrote:
> On Jul 11, 2012, at 2:29 AM, Rémi Forax wrote:
>
>> just a question, even if it's not a big deal if one is able to generate
>> bytecode,
>> why Hidden is not a top level type of java.lang.invoke ?
>
> Good question. The answer is that hiding of stack frames is limited to 
> hiding method handle implementation details. Specifically, the frames 
> that are to be hidden are those which are not specified by the JSR 292 
> modifications to the JVMS.
>
> For example, if you have z=filterReturnValue(::x,::y), and some method 
> m does z.invoke(), the visible stack frames will be m calling x and m 
> calling y. Internally there will be a continuation during the call to 
> x which waits to apply y. This must be some sort of activation frame, 
> but the JVMS requires it to be hidden. In JDK 7 it was a ricochet 
> frame (hand assembly code) and in JDK 8 it will be a lambda form 
> activation (bytecode). Both must be suppressed in backtraces.
>
> A general Lisp-machine-style convention for redacting back traces 
> would be interesting, but it would also require a new JSR.
>
> On the other hand, Hidden could be top-level. It's a matter of coding 
> taste. Binding it to LF makes it more clear that it has a specific use.

Emulating a language call using bytecode is something that should ring a 
bell for a lot of people of this list :)
And even for the JDK, it by example generates bytecode when optimizing a 
call to j.l.r.Method and this bytecode should
not appear in the stacktrace.

>
> — John

Rémi


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

Re: hg: mlvm/mlvm/jdk: meth-lazy: merged BMH factory into BMH, added test for primitive parameter binding

[Rémi Forax]

On 07/11/2012 10:07 PM, michael.ha...@oracle.com wrote:
> Changeset: 79c955d995f0
> Author:mhaupt
> Date:  2012-07-11 22:07 +0200
> URL:   http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/79c955d995f0
>
> meth-lazy: merged BMH factory into BMH, added test for primitive parameter 
> binding
>
> ! meth-lazy-7023639.xbmh.patch
>
> ___
> mlvm-dev mailing list
> mlvm-dev@openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

Hi Mickael,
some minor comments,
makeSignature should use a StringBuilder and not a StringBuffer.
ans I don't think generateConcreteBMHClass needs to return a Class,
a Class seems enough so the cast near the end of the method can be 
removed.

Rémi





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

Re: hg: mlvm/mlvm/jdk: meth: add @Hidden annotations

[Rémi Forax]

On 07/11/2012 08:19 AM, john.r.r...@oracle.com wrote:
> Changeset: 77f38b00af98
> Author:jrose
> Date:  2012-07-10 23:19 -0700
> URL:   http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/77f38b00af98
>
> meth: add @Hidden annotations
>
> ! meth-lazy-7023639.patch
> ! meth-lazy-7023639.xbmh.patch

just a question, even if it's not a big deal if one is able to generate 
bytecode,
why Hidden is not a top level type of java.lang.invoke ?

Rémi


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

Re: hg: mlvm/mlvm/hotspot: meth: fix to intrinsic compilation; assembler tweaks for debugging; backtrace filtering

[Rémi Forax]

On 07/10/2012 12:10 PM, Guillaume Laforge wrote:
> It'd be useful for others as well :-)

Yes, for JRuby which is mixed mode (AST walker + bytecode compiler), you 
still have to do some
post processing but for Groovy which is compiled only, I think you can 
avoid any processing
at runtime if you post process the groovy.jar at compile time (because 
Hidden is not a public annotation) :)

Rémi

>
> On Tue, Jul 10, 2012 at 11:12 AM, Rémi Forax  <mailto:fo...@univ-mlv.fr>> wrote:
>
> On 07/10/2012 10:42 AM, john.r.r...@oracle.com
> <mailto:john.r.r...@oracle.com> wrote:
> > Changeset: 851ca5831589
> > Author:jrose
> > Date:  2012-07-10 01:42 -0700
> > URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/851ca5831589
> >
> > meth: fix to intrinsic compilation; assembler tweaks for
> debugging; backtrace filtering
> >
> > ! meth-lazy-7023639.patch
>
> I think backtrace filtering, should be enhanced by adding a new method
> attribute in the bytecode that indicates if a method should be visible
> or not
> when dumping a stacktrace and a display name that should be used
> instead of the bytecode method name.
>
> This may reduce the need of stacktrace post-processing and makes
> Charles
> happy.
>
> Rémi
>
>
> ___
> mlvm-dev mailing list
> mlvm-dev@openjdk.java.net <mailto:mlvm-dev@openjdk.java.net>
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>
>
>
>
> -- 
> Guillaume Laforge
> Groovy Project Manager
> SpringSource, a division of VMware
>
> Blog: http://glaforge.appspot.com/
> Social: @glaforge <http://twitter.com/glaforge> / Google+ 
> <https://plus.google.com/u/0/114130972232398734985/posts>
>
>
>
> ___
> 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: How to making Class.forName work in indy?

[Rémi Forax]

On 07/10/2012 10:07 PM, Jochen Theodorou wrote:
> Hi all,
>
> assuming you have to compile code with indy that realizes this:
>
> Class.forName(x)
>
> Meaning, we want to execute forName from Class using invokedynamic. If
> you then have frames in your trace looking like this:
>
>> java.lang.Class.forName0(Native Method)
>> java.lang.Class.forName(Class.java:186)
>> java.lang.invoke.MethodHandleImpl$GuardWithCatch.invoke_L2(MethodHandleImpl.java:1130)
>> org.codehaus.groovy.vmplugin.v7.IndyInterface.selectMethod(IndyInterface.java:680)
>> groovy.util.JavadocAssertionTestSuite.(JavadocAssertionTestSuite.groovy:71)
> then it is clear to me, why it is failing. At least the Indyinterface
> part, if not even the GuradWithCatch part are disturbing the stack
> walking Class#forName is using.
>
> has anyone any idea on how to make this work across JVMs? One version,
> that sounds quite crazy to me, but may just work, is to compile a helper
> method on the class, that directly calls Class#forName and thus making
> it work, since there is no longer a wrong stack frame at the position
> Class#forName is looking for. But well... it may be a possibility
>
> bye Jochen
>

Class.forName(name) is equivalent to Class.forName(name, true, 
lookup.lookupClass().getClassLoader())
As true and lookup.lookupClass().getClassLoader() are constant in the BSM,
you can bound them using insertArguments.

Rémi

||

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

Re: hg: mlvm/mlvm/hotspot: meth: fix to intrinsic compilation; assembler tweaks for debugging; backtrace filtering

[Rémi Forax]

On 07/10/2012 10:42 AM, john.r.r...@oracle.com wrote:
> Changeset: 851ca5831589
> Author:jrose
> Date:  2012-07-10 01:42 -0700
> URL:   http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/851ca5831589
>
> meth: fix to intrinsic compilation; assembler tweaks for debugging; backtrace 
> filtering
>
> ! meth-lazy-7023639.patch

I think backtrace filtering, should be enhanced by adding a new method
attribute in the bytecode that indicates if a method should be visible 
or not
when dumping a stacktrace and a display name that should be used
instead of the bytecode method name.

This may reduce the need of stacktrace post-processing and makes Charles 
happy.

Rémi


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

Re: Improving the performance of stacktrace generation

[Rémi Forax]

On 07/08/2012 12:50 AM, Charles Oliver Nutter wrote:
> On Saturday, July 7, 2012, Rémi Forax wrote:
>
> You can use Throwable.getStackTraceElement()
> which is package visible and OpenJDK specific but at least
> it will be faster for all VMs that uses OpenJDK.
>
> I'll certainly explore that to see if it improves the situation. If 
> it's faster, it might be a way out in some circumstances.
>
> It seems like an official public API is needed here...
>
> Please never optimize warnings, they are here to bug users
>
> until they fix the thing. So they should be slow :)
>
>
> Yes, except when *everyone else* has faster warnings than you. Then 
> you're just giving people another reason to not use your stuff.
>
> Granted, JRuby is now becoming far and away the fastest Ruby 
> implementation for exactly the reasons that stack traces are slow, but 
> often making 90% of the code 5x faster but 10% of the code 100x slower 
> means people give up on you without bothering.
>
> Remember, I agree with you...but I also feel like this attitude has 
> allowed stack trace generation to avoid optimization effort for a long 
> time, and there *are* useful things you can do with an introspectable 
> call stack.

Throwable.getStackTraceElement() let you walk the stack trace without 
generating the whole stack trace,
in my opinion it's enough.

BTW, I also think you are responsible too for the cost of generating 
stacktraces because the cost depends on the size of the stacktrace
and an AST interpreter is a big consumer of stack frames. I am guilty 
too, PHP.reboot has the same issue and
I try to mitigate that by avoiding to have an helper methods in the 
stacktrace of calls (not that easy without tailcall).

>
> - Charlie

Rémi

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

Re: Improving the performance of stacktrace generation

[Rémi Forax]

On 07/08/2012 12:03 AM, Charles Oliver Nutter wrote:
> Today I have a new conundrum for you all: I need stack trace
> generation on Hotspot to be considerably faster than it is now.
>
> In order to simulate many Ruby features, JRuby (over)uses Java stack
> traces. We recently (JRuby 1.6, about a year ago) moved to using the
> Java stack trace as the source of our Ruby backtrace information,
> mining out compiled frames and using interpreter markers to peel off
> interpreter frames. The result is that a Ruby trace with mixed
> compiled and interpreted code like this
> (https://gist.github.com/3068210) turns into this
> (https://gist.github.com/3068213). I consider this a great deal better
> than the plain Java trace, and I know other language implementers have
> lamented the verbosity of stack traces coming out of their languages.
>
> The unfortunate thing is that stack trace generation is very expensive
> in the JVM, and in order to generate normal exceptions and emulate
> other features we sometimes generate a lot of them. I think there's
> value in exploring how we can make stack trace generation cheaper at
> the JVM level.
>
> Here's a few cases in Ruby where we need to use Java stack traces to
> provide the same features:
>
> * Exceptions as non-exceptional or moderately-exceptional method results
>
> In this case I'm specifically thinking about Ruby's tendency to
> propagate errno values as exceptions; EAGAIN/EWOULDBLOCK for example
> are thrown from nonblocking IO methods when there's no data available.
>
> You will probably say "that's a horrible use for exceptions" and I
> agree. But there are a couple reasons why it's nicer too:
> - using return value sigils requires you to propagate them back out
> through many levels of calls
> - exception-handling is cleaner in code than having all your errno
> handling logic spliced into regular program flow
>
> In any case, the cost of generating a stack trace for potentially
> every non-blocking IO call is obviously too high. In JRuby, we default
> to having EAGAIN/EWOULDBLOCK exceptions not generate a stack trace,
> and you must pass a flag for them to do so. The justification is that
> these exceptions are almost always used to branch back to the top of a
> nonblocking IO loop, so the backtrace is useless.

I don't see how to do more.

>
> * Getting the current or previous method's name/file/line
>
> Ruby supports a number of features that allow you to get basic
> information about the method currently being executed or the method
> that called it. The most general of these features is the "caller"
> method, which provides an array of all method name + file + line that
> would appear in a stack trace at this point. This feature is often
> abused to get only the current or previous frame, and so in Ruby 1.9
> they added __method__ to get the currently-executing method's
> name+file+line.
>
> In both cases, we must generate a full Java trace for these methods
> because the name of a method body is not necessarily statically known.
> We often want only the current frame or the current and previous
> frames, but we pay the cost of generating an entire Java stack trace
> to get them.

You can use Throwable.getStackTraceElement()
which is package visible and OpenJDK specific but at least
it will be faster for all VMs that uses OpenJDK.

>
> * Warnings that actually report the line of code that triggered them
>
> In Ruby, it is possible to generate non-fatal warnings to stderr. In
> many cases, these warnings automatically include the file and line at
> which the triggering code lives. Because the warning logic is
> downstream from the Ruby code, we again must use a full Java stack
> trace to find the most recent (on stack) Ruby frame. This causes
> warnings to be as expensive as regular exceptions.

Please never optimize warnings, they are here to bug users
until they fix the thing. So they should be slow :)

>
> Because the use of frame introspection (in this case through stack
> traces) has largely been ignored on current JVMs, I suspect there's a
> lot of improvement possible. At a minimum, the ability to only grab
> the top N frames from the stack trace could be a great improvement
> (Hotspot even has flags to restrict how large a trace it will
> generate, presumably to avoid the cost of accounting for deep stacks
> and generating traces from them).
>
> Any thoughts on this? Does anyone else have need for lighter-weight
> name/file/line inspection of the call stack?
>
> - Charlie

Rémi

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

Re: TaggedArrays (Proposal)

[Rémi Forax]

On 07/07/2012 07:02 PM, Dain Sundstrom wrote:
> On Jul 7, 2012, at 1:56 AM, Rémi Forax wrote:
>
>> You have also to figure out how to get two return values from a method call,
>> but exceptions are your best friend here.
> Can you give an example of what you mean here?  Also, from all the 
> presentations I've seen on the JVM, exceptions are very expensive to throw 
> and catch, so I would expect this to be way slower then say returning the 
> multiple values using a generated results class.

Exception are not expensive if you throw them and just catch them (and 
don't use them) in the same inlining horizon,
so you can use them to implement non Java control flow without thinking 
too much.

Anyway, the idea here is to use exception as an exceptional mechanism by 
example when
something that should be an int is not. In that case, throwing an 
exception is not a big deal
because the VM will have to deopt which usual have a bigger impact on 
the run time.

>
> -dain

Rémi

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

Re: TaggedArrays (Proposal)

[Rémi Forax]

On 07/07/2012 04:54 AM, Mark Roos wrote:
> Hi Rémi,  you mention
> And now the trick, there is a nice way (several in fact) to explain to
> the JIT
> that even if the bytecode contains tests, if the variable contains
> effectively an int,
> it's a good idea to remove them.
>
> Ok,  in Smalltalk there are some methods which are usually integer ops
> so its easy to determine vars that are likely integer.  I have slots in
> the stack reserved for just this idea.
>
> So if I have a pair of slots A and B where A would be the integer from 
> and B the reference.
> Would I test B to be null and if so do an integer op on A?

yes, that the basic idea.

>
> So plese point me at the bytecode tricks that make the test go away.

It's not a bytecode trick, it's a JIT trick.
The VM profiles jump instruction like 'if' to know which branch is 
taken, and
doesn't generate code but a deoptimization code if a branch is never taken.
So the generator of a backend will generate a code like this for a + 1:

   int r1 = ...
   Object o1 = ...
   if (o1 == null) {
  r2 = r1 + 1
  o2 = null
   } else {
  r2 = 0
  o2 = invokedynamic + o1, 1
   }

   if (o2 == null) {  // next instruction
   ...
   } else { ...
   ...

and because o1 is never null, the JIT will generate

jne a_deoptimization_code
inc r2

also because the JIT propagates null value aggressively, the jump can 
also disappear because
there is perhaps already another check before, by example, the check o2 
== null will
be removed here.

So the idea is to consider that if a variable can store an int, you 
should use two variables in the bytecode,
so result of an operation will be spilled into two variables instead of 
using the stack.
I call this idea, split-path and this is really effective, the main 
drawback is that the generated bytecode size
is big compared to the code of the generated assembler so the JIT may 
decide to not inline something
that it should.

You have also to figure out how to get two return values from a method call,
but exceptions are your best friend here.

>
> regards
> mark

rgds,
Rémi

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

Re: TaggedArrays (Proposal)

[Rémi Forax]

On 07/06/2012 08:48 PM, Mark Roos wrote:
> From Rémi on static analysis for loops
>
> Not having such kind of analysis is almost a crime.
>
> For a language like Smalltalk I was thinking that having such an analysis
> would be the work of the gods.
>
> With user overridable methods, reflection and run time code creation I 
> have only found a few
> places where I could do such an static analysis.  And those are fragile.
>
> So do you have a good paper that would apply?  I have looked at many 
> from the 80s/90s and
> have yet to find a general approach for a Smalltalk style language.
>
> I am thinking of adding a mutable flag to integers so I can share a 
> body but 'lazy' freeze to
> a real integer but it seems like I'll be adding lots of checks just to 
> fix what could be a small problem
> over an entire application.

yes, i don't think it's a good idea too because it's too late,
you want to avoid boxing not try to share boxes.

>
> I also have a thought to allocate a few primitive slots in each stack 
> frame to pass real primitives
> but again I have to test everywhere for which slot is valid.

First the idea is to use an analysis but not to answer to the question, 
"is this variable is an integer or not"
but to answer to the question "is this variable may be an integer or not".
Once the analysis done, you know how many supplementary slots you need.
And now the trick, there is a nice way (several in fact) to explain to 
the JIT
that even if the bytecode contains tests, if the variable contains 
effectively an int,
it's a good idea to remove them.

>
> The best thought may be to add patterns to the language to avoid the 
> use of visible integers
> as indexes  ( e.g. instead of '1 to:3 do:[aBlock over a collection]' 
> do 'aCollection from:1 to:3 do:[ aBlock on each indexed item]')
> Now I can do the static analysis.  As they say 'If it hurts don't do it'

> regards
> mark

cheers,
Rémi

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

Re: TaggedArrays (Proposal)

[Rémi Forax]

On 07/05/2012 10:42 PM, Jim Laskey wrote:
> Fairly common patterns like
>
> var p =  {
>   fontsize: 15,
>   lineheight: 22,
>   color: 0x000,
>   fontfamily: "Georgia, FreeSerif, Times, serif"
> };
>
> p.color = "white";
>
> We need flexible slots without allocating 2x memory.
>
> For "for like" constructs we typically use static analysis to reduce 
> to integer.

Not having such kind of analysis is almost a crime.

Jim, do you have a paper explaining the static analysis you use,
I have some trouble to keep mine linear.

> With TaggedArray slots for frames we could use integer dynamically.

yes, but performance will be awful (ok, better than using boxing but 2x 
or 3x slower
than C or Java) if you don't have any kind of type propagation.

>
> Cheers,
>
> -- Jim

cheers,
Rémi

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

Re: TaggedArrays (Proposal)

[Rémi Forax]

On 07/04/2012 03:18 AM, Jim Laskey wrote:
> Actually it's built on a modified 7. Getting it into a 7 release is a 
> community issue. I think tagged values comes under JSR-292, so some of 
> the process is covered. Not sure what the other steps involve. And of 
> course the API/implementation needs to be picked on a bit too.
>
> Sent from my iPhone 4

Jim, is there a way to getting it as a patch in the mlvm workspace,
so we can test a little bit the API/implementation.

Rémi

>
> On 2012-07-03, at 10:01 PM, Mark Roos  > wrote:
>
>> Hi Jim,  You made a comment:
>>
>> implementation for platforms not supporting TaggedArrays (and JDK 1.7)
>>
>> Are you saying that a native version fo jdk1.7 is not possible,  or 
>> just that you have not got around to it?
>>
>> regards
>> 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


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

Re: Working around NoClassDefFound

[Rémi Forax]

On 07/04/2012 03:01 AM, Mark Roos wrote:
> From Charlie
>
> It also doesn't appear to happen with JRuby on the boot
> classpath...it happens only when JRuby is loaded in a child
> classloader.
>
> That was my experience as well.  The only way I found to avoid it was to
> put my code into the bootClassPath.  I messed with other ideas ( but not
> Rémi's) but the error always eventually returned.
>
> regards
> mark

There is only one workaround to avoid the NoClassDefFound error as far 
as I know,
the signature of all invokedynamic calls must not contain any class 
which is not in the bootclasspath.
So either you put the runtime classes in the bootclasspath or you erase 
all your signature to only use
primitive types and Object.

cheers,
Rémi

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

Re: TaggedArrays (Proposal)

[Rémi Forax]

On 07/02/2012 04:11 PM, ravenex wrote:
> Very cool stuff, Jim and Rickard!
> I guess people are going to start missing NaN encoded tagged 
> value/pointers now that there's something real to play with ;-)
>
> @Remi The subclass suggestion sounds a lot like Maxine's Hybrid 
> objects, where named fields and an untyped array is bundled into a 
> single object. Which pretty much emulates what people like to do in 
> C/C++, something nice to have.
>
> > I think that getValue()/setValue() should return the long with the 
> bit set because
> > If i want to execute x + 1, I can convert it to x + 2 at compile 
> time thus avoid the shifts at runtime.
>
> Even without changing the API, this kind of transformation could 
> easily be intrinsified in the JITs, not a big worry. Cheers, Raven 

Yes, it's the Maxine hybrid object and also comes from the fact that 
most of the runtime have a common super type,
like RubyObject in JRuby, GroovyObject in Groovy etc. which is used to 
provide a base class for some
specialized runtime classes.

Rémi

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

Re: TaggedArrays (Proposal)

[Rémi Forax]

On 07/02/2012 03:05 PM, Jim Laskey wrote:
> During a week in the rarefied air of Stockholm back in May, a 
> sleepless night got me thinking.  The day after that, the thinking 
> became a reality.  I've been sitting on the code since, not sure what 
> to do next.  So..., why not start the month leading up to the JVMLS 
> with a discussion about dynamic values.
>
> Every jLanguage developer knows that primitive boxing is the enemy. 
>  Even more so for untyped languages.  We need a way to interleave 
> primitive types with references.
>
> Tagged values (value types) for dynamic languages have been approached 
> from a dozen different angles over the history of Java.  However, no 
> one seems to be satisfied with any of the proposals so far.  Either 
> the implementation is too limiting for the language developer or too 
> complex to implement.
>
> Most recently, John (Rose) proposed hiding value tagging in the JVM 
> via the Integer/Long/Float/Double.valueof methods.  I saw a few issues 
> with this proposal.  First, the implementation works differently on 32 
> bit and 64 bit platforms (only half a solution on each).  Secondly, 
> control of the tag bits is hidden such that it doesn't give a language 
> implementor any leeway on bit usage.  Finally, it will take a long 
> time for it to get introduced into the JVM.  The implementation is 
> complex, scattered all over the VM and will lead to a significant 
> multiplier for testing coverage.

but it will also help Java perf.

>
> It occurred to me on that sleepless Monday night, that the solution 
> for most dynamic languages could be so much simpler.  First, we have 
> to look at what it is we really need.  Ultimately it's about boxing. 
>  We want to avoid allocating memory whenever we need to store a 
> primitive value in an object.  Concerning ourselves with passing 
> around tagged values in registers and storing in stack frames is all 
> red herring.  All that is needed is a mechanism for storing tagged 
> values (or compressed values) in a no-type slot of a generic object. 
>  Thinking about it in these terms isolates all issues to a single 
> array-like class, and thus simplifies implementation and simplifies 
> testing.  Instances of this class can be used as objects, as stack 
> frames and even full stacks.  A good percentage of a dynamic language 
> needs are covered.

using it as a stack frames will require a pretty good escape analysis if 
you want same perf as the native stack
or is there a trick somewhere ?
But given that there is a trick to avoid boxing for local variables (see 
my talk at next JVM Summit),
having an array like this just for storing fields is enough to pull its 
weight.

>
> So, Rickard Bäckman (also of Oracle) and I defined an API and 
> implemented (in HotSpot) an interface called TaggedArray. 
>  Conceptional, TaggedArray is a fixed array of no-type slots (64-bit), 
> where each slot can contain either a reference or a tagged long value 
> (least significant bit set.)  Internally, TaggedArray class's doOop 
> method knows that it should skip any 64-bit value with the least 
> significant bit set.  How the language developer uses the other 63 
> bits is up to them.  References are just addresses.  On 32 bit 
> machines, the address (or packed address) is stored in the high 
> 32-bits (user has no access)  So there is no interference with the tag 
> bit.
>
> We supply four implementations of the API.  1) is a naive two parallel 
> arrays (one Object[], one long[]) implementation for platforms not 
> supporting TaggedArrays (and JDK 1.7), 2) an optimized version of 1) 
>  that allocates each array on demand, 3) a JNI implementation 
> (minimally needed for the interpreter) that uses the native 
> implementation and 4) the native implementation that is recognized by 
> both the C1/C2 compilers (effort only partially completed.)  In 
> general, the implementation choice is transparent to the user (optimal 
> choice.)

Being able to subclass it in order to add fixed field like a metaclass 
field, i.e a field that
is always a reference, would be cool too.

About the API, the two method set should be setValue()/setReference().
I think that getValue()/setValue() should return the long with the bit 
set because
If i want to execute x + 1, I can convert it to x + 2 at compile time 
thus avoid the shifts at runtime.

>
> I've enclosed a JavaDoc and the roughed out source.  For discussion. 
>  Fire away.
>
> Cheers,
>
> -- Jim

cheers,
Rémi

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

Re: two things invokedynamic canbot do

[Rémi Forax]

On 06/26/2012 02:24 PM, Jochen Theodorou wrote:
> Am 26.06.2012 13:37, schrieb Julien Ponge:
>> You may bypass the invokespecial (…)V as a first method
>> invocation within a constructor requirement by launching the JVM with
>> -noverify. As long as you don't do anything stupid in the bytecode it
>> will be just ok and you can call a constructor using indy.
>>
>> Anyway I confess that disabling verification is probably not what you
>> want ;-)
> That is indeed not really what I want ;) No, seriously... we want to be
> able to use Groovy classes in an environment not under our control, even
> in a application server. For those things -noveriffy is surely no option.
>
> bye Jochen
>

BTW, It's usually better to use unsafe.defineClass() than noverify
because you can just ask to not verify some classes.

cheers,
Rémi


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

Re: two things invokedynamic canbot do

[Rémi Forax]

On 06/26/2012 12:37 PM, Jochen Theodorou wrote:
> Am 26.06.2012 11:59, schrieb Rémi Forax:
>> On 06/26/2012 11:40 AM, Jochen Theodorou wrote:
>>> Hi all,
>>>
>>> just to be sure I understand correctly... afaik there are two things
>>> invokedynamic cannot do.
>>>
>>> (1) calling private methods
>>> actually I am not sure this is really true. There is a Lookup instance I
>>> can use to get handles to private methods (afaik), therefore it should
>>> be possible. Or is there an artificial restriction of some kind?
>> No restriction, or you need a way to get the proper lookup
>> or you use reflection to get a j.l.r.Method, call setAccessible(true)
>> and unreflect it as a MethodHandle (see MethodHandles.unreflect*).
> ok, so I can remove those stupid helper methods ;)
>
>>> (2) calling super()
>>> afaik I cannot generate a call site that replaces the invokeSpecial call
>>> to a super class constructor.
>> You can call super.foo()
> ah true... this is not reflection.. even if I get the handle from the
> super class it won't call the overriding method in the current class. I
> totally forgot... how do you handle this in your backport?

I don't :(

The current plan is to add an empty trampoline method in the code
by default and to redefine the code of this method when you create
a method handle that use invokespecial.
But it only works in agent mode not in reflection only mode.

>
>   > but not super().
>> It's because the VM verifies that you should not have access to an
>> uninitialized object, ie. access to an object before calling super().
>> So if you do a super() using a MethodHandle, because it's hidden
>> by an invokedynamic (or a constant method handle) the VM as no
>> way to know that this invokedynamic will call the constructor
>> of the super class, so the verifier will not let you call invokedynamic
>> on this in a constructor without calling explicitly super() before.
> I see... that is a bit unfortunate. I have to do quite some tricks to
> enable the super constructor call according to Groovy rules for method
> dispatch. And what I do I won't call fast.

For Dart, I don't generate Dart constructor as Java constructor,
I create public default Java constructor that just call super()
and translate the Dart constructor to a Java method.

Then, a call to new is translated to an invokedynamic that will,
at runtime, fold the call to the Java constructor and the call to
the method that correspond to the Dart constructor.

This allow me to workaround the VM limitation but
I don't allow any Dart to Java integration like being able
in Java to inherits from a Dart class.

>
> bye blackdrag
>


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

Re: two things invokedynamic canbot do

[Rémi Forax]

On 06/26/2012 11:40 AM, Jochen Theodorou wrote:
> Hi all,
>
> just to be sure I understand correctly... afaik there are two things
> invokedynamic cannot do.
>
> (1) calling private methods
> actually I am not sure this is really true. There is a Lookup instance I
> can use to get handles to private methods (afaik), therefore it should
> be possible. Or is there an artificial restriction of some kind?

No restriction, or you need a way to get the proper lookup
or you use reflection to get a j.l.r.Method, call setAccessible(true)
and unreflect it as a MethodHandle (see MethodHandles.unreflect*).

>
> (2) calling super()
> afaik I cannot generate a call site that replaces the invokeSpecial call
> to a super class constructor.

You can call super.foo() but not super().
It's because the VM verifies that you should not have access to an
uninitialized object, ie. access to an object before calling super().
So if you do a super() using a MethodHandle, because it's hidden
by an invokedynamic (or a constant method handle) the VM as no
way to know that this invokedynamic will call the constructor
of the super class, so the verifier will not let you call invokedynamic
on this in a constructor without calling explicitly super() before.

>
> Am I right about those?
>
> bye blackdrag
>
>

Rémi

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

Re: megamorphic lambda prevention

[Rémi Forax]

On 06/21/2012 09:17 PM, Jochen Theodorou wrote:
> Mark,
>
> can you explain what you mean with "depth"? if you mean the depth of a
> call path, then more than 20 is indeed more rare, but it depends on the
> circumstances. In Grails for example (web frame work in the Groovy
> world) a depth of 20 should be a much more commen case, simply because
> there is a framework around it, that already has the usual call path
> depth. As for seeing depth of the call path from the point the blokc is
> called to the point the iterator method is called, that is usually a
> quite short path of maybe depth <3. But maybe you something else by depth.

No, I think here depth means depth of the guardWithTest,
i.e. number of different receiver types.

> Anyway, the goal is inlining and inlining is something you get with a
> more or less constant call site. Invalidating it means to remove that
> attribute of being constant, the counter will start new. That's why you
> may be able to remove old cases from your call site structure that way,
> but for inlining it does not help at all. Well... I am sure Remi will
> correct me should I tell wrong things here ;)

adding a new GWT to a tree of GWTs or trashing the tree of GWTs
and use only one GWT is equivalent if the tree of GWTs is already JITed,
because the generated code will be deoptimized anyway.

A big tree of GWTs is really bad because it's a linear search so it's slow,
moreover a code with to many nodes will not be inlined at all.

Also trashing a tree of GWTs is not only a way remove path that
has not used but also a way to re-order a tree of GWTs.

> bye Jochen

cheers,
Rémi

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

Re: megamorphic lambda prevention

[Rémi Forax]

On 06/21/2012 04:38 PM, Matt Fowles wrote:
> All~
>
> Couldn't the VM detect hot mega-morphic methods and have them bestow 
> some of their hotness upon the callers.

Yes, that's basically the idea when I say the VM can create a path backward.

>  Making their callers more likely to inline them.

only if the receiver of the call depends on parameters.
Also, the VM should not trust the profile but the propagated types from 
the parameters.

>  Then you have a different call site for the each which is likely to 
> be monomorphic.

yes;
Also in case of OSR, the VM has more info because it knows the call 
stack, so going backward can be easier.

>
> Matt

Rémi

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

Re: megamorphic lambda prevention

[Rémi Forax]

On 06/21/2012 04:38 PM, Matt Fowles wrote:
> All~
>
> Couldn't the VM detect hot mega-morphic methods and have them bestow 
> some of their hotness upon the callers.  Making their callers more 
> likely to inline them.  Then you have a different call site for the 
> each which is likely to be monomorphic.
>
> Matt

yes, that the idea when i said the the VM can go backward.
Note that it works only for callsites that are megamorphic because of a 
value
that comes from the parameters of the high order method.

There is also a special case for OSR because in that case you may have 
the stack
so it can be easier to go backward.

Rémi

>
> On Thu, Jun 21, 2012 at 10:30 AM, Rémi Forax  <mailto:fo...@univ-mlv.fr>> wrote:
>
> On 06/21/2012 04:12 PM, Jochen Theodorou wrote:
> > Am 21.06.2012 16 :00, schrieb Rémi Forax:
> >> On 06/21/2012 03:52 PM, Jochen Theodorou wrote:
> >>> Am 21.06.2012 13 :57, schrieb Krystal Mok:
> > [...]
> >>>> I wonder how well the new interpreter design in Graal would
> handle this
> >>>> kind of case, since it's supposed to have picked the good
> parts from
> >>>> trace-based compilation, but without actually having to do
> tracing.
> >>>> Can't wait to see more details of it at this year's JVM
> Language Summit.
> >>> If I understood Thomas right, then Graal doesn't have that
> problem.
> >>> Afaik hotspot doesn't have to have that problem too. It just was a
> >>> design decision not to make call site caching per execution
> path. Afaik
> >>> chaning that now would take quite some effort, but is not
> impossible.
> >> You can create the execution path backward, when it's needed.
>
> I was thinking that the VM can create the path backward.
>
> > you can in PHP.reboot, but in Groovy I don't have access to the full
> > execution path. Inside "each" I don't know what did call me and
> at the
> > point of where I call each, I don't see what each will actually do.
>
> yes, but you can detect that 'each' is a special method because
> it takes a closure (Closure) as parameter and try to do some magic.
>
> >
> > bye blackdrag
> >
>
> Rémi
>
> ___
> mlvm-dev mailing list
> mlvm-dev@openjdk.java.net <mailto: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: megamorphic lambda prevention

[Rémi Forax]

On 06/21/2012 04:38 PM, Matt Fowles wrote:
> All~
>
> Couldn't the VM detect hot mega-morphic methods and have them bestow 
> some of their hotness upon the callers.  Making their callers more 
> likely to inline them.  Then you have a different call site for the 
> each which is likely to be monomorphic.
>
> Matt

yes, that the idea when i said the the VM can go backward.
Note that it works only for callsites that are megamorphic because of a 
value
that comes from the parameters of the high order method.

There is also a special case for OSR because in that case you may have 
the stack
so it can be easier to go backward.

Rémi

>
> On Thu, Jun 21, 2012 at 10:30 AM, Rémi Forax  <mailto:fo...@univ-mlv.fr>> wrote:
>
> On 06/21/2012 04:12 PM, Jochen Theodorou wrote:
> > Am 21.06.2012 16 :00, schrieb Rémi Forax:
> >> On 06/21/2012 03:52 PM, Jochen Theodorou wrote:
> >>> Am 21.06.2012 13 :57, schrieb Krystal Mok:
> > [...]
> >>>> I wonder how well the new interpreter design in Graal would
> handle this
> >>>> kind of case, since it's supposed to have picked the good
> parts from
> >>>> trace-based compilation, but without actually having to do
> tracing.
> >>>> Can't wait to see more details of it at this year's JVM
> Language Summit.
> >>> If I understood Thomas right, then Graal doesn't have that
> problem.
> >>> Afaik hotspot doesn't have to have that problem too. It just was a
> >>> design decision not to make call site caching per execution
> path. Afaik
> >>> chaning that now would take quite some effort, but is not
> impossible.
> >> You can create the execution path backward, when it's needed.
>
> I was thinking that the VM can create the path backward.
>
> > you can in PHP.reboot, but in Groovy I don't have access to the full
> > execution path. Inside "each" I don't know what did call me and
> at the
> > point of where I call each, I don't see what each will actually do.
>
> yes, but you can detect that 'each' is a special method because
> it takes a closure (Closure) as parameter and try to do some magic.
>
> >
> > bye blackdrag
> >
>
> Rémi
>
> ___
> mlvm-dev mailing list
> mlvm-dev@openjdk.java.net <mailto: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: megamorphic lambda prevention

[Rémi Forax]

On 06/21/2012 04:12 PM, Jochen Theodorou wrote:
> Am 21.06.2012 16:00, schrieb Rémi Forax:
>> On 06/21/2012 03:52 PM, Jochen Theodorou wrote:
>>> Am 21.06.2012 13:57, schrieb Krystal Mok:
> [...]
>>>> I wonder how well the new interpreter design in Graal would handle this
>>>> kind of case, since it's supposed to have picked the good parts from
>>>> trace-based compilation, but without actually having to do tracing.
>>>> Can't wait to see more details of it at this year's JVM Language Summit.
>>> If I understood Thomas right, then Graal doesn't have that problem.
>>> Afaik hotspot doesn't have to have that problem too. It just was a
>>> design decision not to make call site caching per execution path. Afaik
>>> chaning that now would take quite some effort, but is not impossible.
>> You can create the execution path backward, when it's needed.

I was thinking that the VM can create the path backward.

> you can in PHP.reboot, but in Groovy I don't have access to the full
> execution path. Inside "each" I don't know what did call me and at the
> point of where I call each, I don't see what each will actually do.

yes, but you can detect that 'each' is a special method because
it takes a closure (Closure) as parameter and try to do some magic.

>
> bye blackdrag
>

Rémi

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

Re: megamorphic lambda prevention

[Rémi Forax]

On 06/21/2012 03:55 PM, Jochen Theodorou wrote:
> Am 21.06.2012 13:21, schrieb MacGregor, Duncan (GE Energy):
>> Yes, it is very easy for those sites to become megamorphic. We work round
>> this by using exactInvokers on function invocation call sites, and caching
>> on the method type of the functions rather than the types.
> So in my own words... you don't check on the type of the lambda, but on
> what it takes as input, thus you get no changes for differing lambdas.
> Is that about right? That's a nice idea, indeed
>
> bye blackdrag
>

at least you will not change the inlining cache too often and
you can adapt arguments for several method handles
but the VM will not consider the method handle as constant
so it will not be inlined with the code of the loop.

Another way is to transform the high order function (each() in your example)
as a method handle tree but the JSR 292 lacks a loop combiner.

In Groovy, you can also duplicate the bytecode of the high order function
when you are able to emit bytecode at runtime, see [1].

Said differently and with Hotspot in mind, an idea is that you can 
execute a code but
with another profile metadata object that the usual one.
Because Hotspot is already able to generate code with a profile object
created by the interpreter (for tiered compilation), having a way to ask
for a specialized version of a method with a fresh profile doesn't seem 
too hard
but it's more a hack than a real answer.

Rémi
[1] 
http://weblogs.java.net/blog/forax/archive/2011/04/08/fixing-inlining-%E2%80%9Cproblem%E2%80%9D-prototype


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

Re: megamorphic lambda prevention

[Rémi Forax]

On 06/21/2012 03:52 PM, Jochen Theodorou wrote:
> Am 21.06.2012 13:57, schrieb Krystal Mok:
>> That's "the inlining problem" that Cliff Click was talking about [1], right?
> yes, the issue was actually mentioned more than once on this list already
>
>> I wonder how well the new interpreter design in Graal would handle this
>> kind of case, since it's supposed to have picked the good parts from
>> trace-based compilation, but without actually having to do tracing.
>> Can't wait to see more details of it at this year's JVM Language Summit.
> If I understood Thomas right, then Graal doesn't have that problem.
> Afaik hotspot doesn't have to have that problem too. It just was a
> design decision not to make call site caching per execution path. Afaik
> chaning that now would take quite some effort, but is not impossible.

You can create the execution path backward, when it's needed.

>
> bye blackdrag
>

Rémi

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

Re: megamorphic lambda prevention

[Rémi Forax]

On 06/21/2012 01:57 PM, Krystal Mok wrote:
> That's "the inlining problem" that Cliff Click was talking about [1], 
> right?

yes,

>
> I wonder how well the new interpreter design in Graal would handle 
> this kind of case, since it's supposed to have picked the good parts 
> from trace-based compilation, but without actually having to do 
> tracing. Can't wait to see more details of it at this year's JVM 
> Language Summit.

I spend a couple of days in Linz last month with the Autrian part of the 
Graal team (Thomas, Lukas and Gilles)
and we discuss about this issue (among other things).
I think we should book a room during the Summit to try to see if 
something can be done in Hotspot.

>
> - Kris

Rémi

>
> [1]: 
> http://www.azulsystems.com/blog/cliff/2011-04-04-fixing-the-inlining-problem 
>
>
> On Thu, Jun 21, 2012 at 6:37 PM, Jochen Theodorou  > wrote:
>
> Hi all,
>
> I was wondering... if I have code like this:
>
> list.each { x -> foo(x) }
> list.each { x -> bar(x) }
> list.each { x -> something(x) }
>
> then isn't it the a case where within the each method we easily get
> something megamorphic, since there are too many different kinds of
> lambdas involved? Isn't that a general problem with internal iterators
> and is there any plan to enhance hotspot to counter that problem?
>
> 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: performance degeneration from jdk7u2 to jdk7u6?

[Rémi Forax]

On 05/24/2012 10:38 AM, Jochen Theodorou wrote:
> Am 23.05.2012 23:33, schrieb Rémi Forax:
>> On 05/23/2012 07:50 PM, Jochen Theodorou wrote:
>>> no one helping me on the assembly analysis?
>> Wow, you have generated the biggest fib function I have ever seen.
>>
>> About the bytecode you generate, as you said you have to remove
>> $getCallSiteArray() because it seems it does some side effects
>> so the JIT is not able to remove it.
> the first time an array is generated, later nothing happens anymore...
> but yes, this has to go.
[...]
> the method signature is (I)I, it is called with Object in the body,
> because I cannot ensure that x-1 and x-2 will return an int. Since I
> cannot know for sure that fib(I)I is called, the result of the recursive
> fib call is seen as Object. All I know for sure is that the result of
> "fib(x-1)+fib(x-2)" will be converted to an int later and will cause an
> exception if the conversion is not possible. But that is the result of
> the plus, thus you don't exactly need a compatible return type for fib.
> In for example:
>
> int fib(int x) {
> if (x<2) return 1
> this.metaClass.fib = {int i ->  i==1?"Forax":"Remi "}
> String.metaClass.plus = {String b ->  delegate.length()+b.length()}
> return fib(x-1)+fib(x-2)
> }
> assert fib(3)== 10
>
> I replace fib inside fib with, well it returns a String, but signature
> wise I replace it with a method returning Object. String is not
> compatible with int. And it does not lead to an exception because I also
> replace String#plus with a version that simply returns the added length
> of both Strings. So fib(3) will call fib(2) and fib(1), which has the
> results "Remi " and "Forax". Then I call plus on those results, leading
> to String#plus, which returns the added lengths, which is 10 and
> compatible with int.

yes, you're right, I've forgotten that you can change two methods
at the same time.

>
>> Also, you should never use methods like
>> |DefaultTypeTransformation.intUnbox|
>> because you know that the return type is an int, you should
>> back-propagate it and the return type of plus should be (Object;Object)I
> in the original example that is true, yes. That may allow to skip at
> intUnbox call... but only if I later select a plus method that returns
> int or Integer. In a different thread I already asked for requirements
> in that direction and that I get very differing results depending on
> what signatures I use. No I have at lest the hint, that returning int or
> Integer might be a good idea.

if invokedynamic knows more, you can provide a path with
less boxing so it's usually better.

>
>> Now, the generated code, because of getCallSiteArray(),
>> your real code starts at line 168 and here you start
>> to box the two ints to two Integers to be able to call
>> NumberMath.subtract(Number,Number) which call
>> IntegerMath.substractImpl that unbox them.
>> The VM is not able to remove calls to box / unbox for j.l.Integer.
> I see... unfortunate.
>
>> You should generate a must simpler path here.
>> You should never call a class like g.r.typehandling.*Math because
>> all of these methods takes Numbers as parameters.
>> You should create one simple class, with methods like this:
>>  static int add(int left, int right) {
>>return left + right;
>>  }
>> because it doesn't force you to do the boxing.
>> So you will do the boxing only if it's necessary, i.e. only
>> when the parameter is Object.
>> And to now which method you have to call, instead of
>> relying on getMath() you should use guardWithTest and
>> test only parameters that are Object.
> Object is pretty often the case. Well if I count boxing and unboxing for
> (a+b)+(c+d), then now I have to box a to d, unbox for the add, box the
> result, no boxing for the outer plus call, but two unboxing and a boxing
> for the result and... if the method returns int, a final unboxing. That
> makes 7 boxing and 7 unboxing.
>
> If I use your add(II)I and backpropagate the return type, then I have
> one boxing each for the inner pluses, two unboxing for the outer plus.
> Totals to 2 boxing, 2 unboxing. Sounds better... even without
> backpropagating the call. I will try that out.

:)

>
> bye Jochen
>

cheers,
Rémi

___
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?

[Rémi Forax]

On 05/23/2012 07:50 PM, Jochen Theodorou wrote:
> no one helping me on the assembly analysis?

Wow, you have generated the biggest fib function I have ever seen.

About the bytecode you generate, as you said you have to remove
$getCallSiteArray() because it seems it does some side effects
so the JIT is not able to remove it.

I don't understand why when you call fib in the body of fib,
you are not able to say that the signature is (Object)I. You detect
that this is a recursive call (you don't use the same BSM)
but it seems you think that because fib can be changed
using the meta object protocol, you should type it (Object)Object.
But because you are in already fib, you already suppose that
at least the return type is int. Basically, you can change
the method fib when being in the middle of the execution of fib,
because at least one call of fib is on the stack,
the new method must have a return type which is compatible with fib.

Also, you should never use methods like 
|DefaultTypeTransformation.intUnbox|
because you know that the return type is an int, you should
back-propagate it and the return type of plus should be (Object;Object)I

Now, the generated code, because of getCallSiteArray(),
your real code starts at line 168 and here you start
to box the two ints to two Integers to be able to call
NumberMath.subtract(Number,Number) which call
IntegerMath.substractImpl that unbox them.
The VM is not able to remove calls to box / unbox for j.l.Integer.

You should generate a must simpler path here.
You should never call a class like g.r.typehandling.*Math because
all of these methods takes Numbers as parameters.
You should create one simple class, with methods like this:
   static int add(int left, int right) {
 return left + right;
   }
because it doesn't force you to do the boxing.
So you will do the boxing only if it's necessary, i.e. only
when the parameter is Object.
And to now which method you have to call, instead of
relying on getMath() you should use guardWithTest and
test only parameters that are Object.

cheers,
Rémi


>
> Am 19.05.2012 09:23, schrieb Jochen Theodorou:
>> Hi all,
>>
>> I was about to get a brand new assembly to ask some questions on the
>> list here when I installed the newest available jdk7 update 6. I ran my
>> simple Fibonacci test program and noticed that the time it took was
>> sudden 4.6s, where it was 3.5s before. This plus 1s doesn't look too god
>> to me. Has there been anything special that causes this? I mean before
>> the indy version was a little faster than our call site caching, now it
>> is a little slower. General java performance seems not to be reduced, so
>> I would assume it is special to indy.
>>
>> See http://rifers.org/paste/show/1702
>>
>> ... so now... is there sombody who can tell me why my indy version is
>> now even slower than my call site version? Sadly I am not really fit
>> enough in assembler anymore, especially the one produced by hotspot to
>> really read that output. So I have no idea what is wrong.
>>
>> Two things I should mention... the call to $getCallSiteArray is surplus,
>> yes, but that doesn't take much time. The only thing I know that really
>> takes a lot of time is the exception guard, but that I have to have
>> until I find a way to avoid it and the call site version has both as
>> well of course. They should not count as satisfying explanation.
>>
>> bye Jochen
>>
>

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

Re: using MethodHandle in place of virtual methods?

[Rémi Forax]

On 05/19/2012 08:04 AM, Per Bothner wrote:
> On 05/16/2012 05:52 PM, Charles Oliver Nutter wrote:
>
> Thanks for a detailed and helpful response!
>
>> On Wed, May 16, 2012 at 12:55 PM, Per Bothner   wrote:
>>> The attachment ProcUsingMH.java is a sketch of an alternative implementation
>>> where each apply[01N] method has a matching MethodHandle field.  The
>>> apply[01N]
>>> method is now final and just invokes the corresponding MethodHandle.
>> I don't think this would optimize like you're hoping.
> I'm not expecting a big performance gain.
> I'm hoping for a slight gain getting rid of using a dispatch-switch,
> partly because it avoids an extra indirection (and virtual dispatch), and
> partly because (as you mentioned) HotSpot may have trouble
> optimizing switches, at least large ones.
>
> To summarize my questions, before I actually try to implement this:
> (1) A change to replace a virtual applyX method by a final method
> that calls a InvokeMethod in a final field: My guess is this would
> performancewise be more-or-less a wash, with neither major gain
> or less.  Is that likely?
> (2) My guess is using the new MethodHandle scheme might be slighly
> more efficient than using a switch on a "procedure-index".  It be
> be significantly more efficient in cases of big switch.  Is that likely?
>
> I think there may be additional benefits to getting rid of the
> dispatch-switch: More helpful exception stack traces;
> plus avoiding the need to generate the dispatch classes.
>
>>> Finally, it seems that if Kawa in the future makes use of invokedynamic,
>>> having the MethodHandles in the Procedure would be an advantage.
>> We do keep a method handle in each method object, but only so we can
>> more easily retrieve it and bind it to the invokedynamic call site. I
>> don't think your'e going to see the performance gain you're hoping for
>> with the Procedure object that aggregates handles. You really need the
>> invokedynamic call site for the whole thing to optimize together well.
> It probably makes sense to not implement a switch to using MethodHandles
> until I have a design (roadmap) for using invokedynamic, since the
> benefit of the former change is at best modest and probably not worth the
> effort unless Kawa also makes use of invokedynamic.  Does that match
> your advice?

As Charles said, you will not see big gain to use method handle
until you use invokedynamic, but I think it worth a test.

Here a version of Procedure that doesn't use inheritance at all
and that you be more or less backward compatible with code
that are already compiled with Procedure.

import java.lang.invoke.MethodHandle;
import java.lang.invoke.MethodHandles;
import java.lang.invoke.MethodHandles.Lookup;
import java.lang.invoke.MethodType;

class Procedure {
 public final MethodHandle mh;   // Used for classical call.
 private MethodHandle varargsMH; // Used for varargs call, allocated 
lazily

 Procedure(MethodHandle mh) {
 this.mh = mh;
 }

 /** backward compatibility. */
 public final Object apply0() throws Throwable {
 if (mh.type().parameterCount() != 0)
 throw new RuntimeException();
 return mh.invokeExact();
 }
 /** backward compatibility. */
 public final Object apply1(Object arg1) throws Throwable {
 if (mh.type().parameterCount() != 1)
 throw new RuntimeException();
 return mh.invokeExact(arg1);
 }
 /** backward compatibility. */
 public final Object applyN(Object[] args) throws Throwable {
 MethodHandle varargsMH = this.varargsMH;
 if (varargsMH == null) {
varargsMH = mh.asSpreader(Object[].class, 
mh.type().parameterCount());
 }
 return varargsMH.invokeExact(args);
 }
}

class Builtins {
 public static final Object hash(Object arg1) {
 return arg1.hashCode();
 }

 private static Procedure createProcedure(Lookup lookup, String 
name, int parameterCount) {
   MethodHandle mh;
   try {
 mh = lookup.findStatic(Builtins.class, name, 
MethodType.genericMethodType(parameterCount));
   } catch (NoSuchMethodException | IllegalAccessException e) {
 throw (LinkageError)new LinkageError().initCause(e);
   }
   return new Procedure(mh);
 }

 static final Procedure hash;

 static {
   Lookup lookup = MethodHandles.lookup();
   hash = createProcedure(lookup, "hash", 1);
 }
}

class Main {
   public static void main(String[] args) throws Throwable {
 // new way, get the method handle and call
 System.out.println(Builtins.hash.mh.invokeExact((Object)"foo"));

 // old way - apply1
 System.out.println(Builtins.hash.apply1("foo"));

 // old way - applyN
 System.out.println(Builtins.hash.applyN(new Object[]{"foo"}));
   }
}


cheers,
Rémi

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

Re: Boxing, still a limit of invokedynamic?

[Rémi Forax]

On 05/13/2012 10:21 PM, Jochen Theodorou wrote:
> Am 13.05.2012 19:55, schrieb Rémi Forax:
> [...]
>> I think currently Groovy allows to replace + by a method
>> that will return everything you want.
>> But here, I think the spec of Groovy (if it means something)
>> should be changed to say that when your replace a method
>> by another, the return type must be a subtype of the
>> existing method.
> that helps if the argument types are known and there is an exact match
> to a method. It helps because in that case we can save the casting and
> converting plus the checks to see if we even have to do that. Yes. But
> currently that is not the case. And it won't change for Groovy2, maybe
> for a later Groovy.
>
> [...]
>> Object ->   int is not equivalent to Object ->   Integer ->   int,
>> it can be Object ->   Byte ->   int by example.
>> You have to chain several calls to asType()
>>
>> see slide 20 of my jvm summit talk last year,
>> http://wiki.jvmlangsummit.com/images/9/93/2011_Forax.pdf
> so you mean to tell me that I have first to convert the Object to an
> Integer and that Integer to int, instead of directly converting the
> Object to an int? I see, I will try that out.

Yes.
You should not have to do that because you first check if the
parameter is an Integer but currently the VM doesn't propagate
this information.
(there is a patch for that, but not yet integrated)
Also, it should be faster before the JIT is kicked in.


>
> bye Jochen

cheers,
Rémi

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

Re: Boxing, still a limit of invokedynamic?

[Rémi Forax]

On 05/13/2012 07:21 PM, Charles Oliver Nutter wrote:
> On Sun, May 13, 2012 at 11:04 AM, Jochen Theodorou  wrote:
>> I wanted to ask you of your opinion. If I am going to compile something
>> like a+b-c and a,b,c are all primtives, but I won't know that the
>> results will be really the primtives too, then this means I will most
>> probably compile it like this:
>>
>> invokedynamic("minus", invokedynamic("plus",a,b), c)
>>
>> meaning the result of a+b will be an Object (since I won't know it is a
>> primitive) and then there will be one boxing for that, just to unbox
>> again for the minus and then box again for the result of the minus. If
>> now the result is not supposed to be a primitive, then there won't be
>> another unbox, till the next operation done with that value.
> You could also encode "a+b-c" as a single invokedynamic operation, but
> I guess you're looking for a general solution...
>
>> Now, even if the JIT is able to see through the one boxing and unboxing
>> fro the result of plus, what will stay is the boxing for the result of
>> the minus plus the many unboxing actions used when this result is
>> used. Isn't that a conceptual problem? And how do others deal with that?
> First of all...how are you expecting that JIT will see through the
> first boxing? If the return result is going to be Object, it's going
> to go into an Integer. Perhaps you are hoping for escape analysis to
> get rid of it?
>
> If that's the case, why wouldn't the same expectation apply to the
> second call? If (a+b) returns an Integer that's immediately passed
> into (tmp-c) and both calls inline, in theory EA should have enough to
> eliminate the intermediate. If the result of (tmp-c) is never used as
> an object and never escapes, then EA should be able to get rid of that
> too.
>
> Of course this is all assuming that EA will be working across indy
> boundaries in the near future. Currently, it does not.
>
> In JRuby, where we have no static typing or type hints, we always do
> these invocations as all reference types. We're banking on JVM helping
> us out in the future, so my goal is to just use indy as efficiently as
> possible and keep call protocols simple.
>
> A confusing point for me: in your case, where you know they're all
> ints, how do you not know that + and - also return int? Can't you
> determine statically that this whole expression will return a
> primitive int?

I think currently Groovy allows to replace + by a method
that will return everything you want.
But here, I think the spec of Groovy (if it means something)
should be changed to say that when your replace a method
by another, the return type must be a subtype of the
existing method.

>
>> I am asking because I was experimenting with method signatures and for
>> such plus and minus methods and got mixed results. I was expecting the
>> primtive versions would achieve the best results, but that was not the
>> case. a plus(int, int) had worse performance than a plus(int,Integer) or
>> plus(Integer,int) in some cases and sometimes it looked like
>> plus(Integer,Integer) is worse, in other cases not. Well, this is
>> causing me some problems. Why do I get such strange results? I would
>> assume it depends on the JIT and the boxing logic it is able to
>> recognize and not.
> What does the assembly look like?
>
> In my case, passing int instead of Fixnum where possible (usually only
> when a literal integer appears in the argument list) definitely helps;
> I don't have to construct a Fixnum or go to a cache to get it, and on
> the other side there's no type-checking required to make sure I really
> have a Fixnum. The int paths should be faster than the Integer paths.
>
> And again remember...I don't think the JIT in u4- does anything with
> the boxing coming out of these calls. It might do something on the
> other side, but not across the invokedynamic call.
>
>> One more thing I noticed is, that if I have a = b+c, with all of them
>> being int and b+c returning object, then letting the MethodHandle do the
>> conversion from Object to int is actually much worse performance wise,
>> than a cast to integer and calling valueOf. Shouldn't that be at least
>> equal, if not fast considering that the result of b+c was first boxed
>> and then is unboxed?
> Perhaps doing it in the handles makes the code more opaque? Do the
> non-handle way and the handle way have exactly the same logic?

Object -> int is not equivalent to Object -> Integer -> int,
it can be Object -> Byte -> int by example.
You have to chain several calls to asType()

see slide 20 of my jvm summit talk last year,
http://wiki.jvmlangsummit.com/images/9/93/2011_Forax.pdf

>
> Bottom line here is that if you need a reference type on LHS, you'll
> have to create a reference type, and we need the JVM to figure out
> that it can brush that part away.
>
> - Charlie

Rémi

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

Re: selective inlining of MH.invokeExact() callsites

[Rémi Forax]

On 05/09/2012 08:02 PM, Christian Thalinger wrote:
> On May 8, 2012, at 2:11 AM, Garcia Gutierrez Miguel Alfredo wrote:
>
>> What's the behavior of @ForceInlining , in particular for 
>> MethodHandle.invokeExact() ?
> We introduced that annotation as an experiment for inlining exact invokers 
> for LambdaForms (note:  LambdaForm is not directly related to Project 
> Lambda).  The generated bytecode versions of these LFs are usually just 
> argument shuffling or binding and calling the target.  We know that this code 
> compiles down to almost nothing in native machine code and that's why we 
> force them to inline.
>
> The ForceInline annotation is a powerful tool which may produce bad results 
> in the hands of costumers.  Currently we don't hide it completely from users 
> but that might happen in the future.

and Christian correctly if I'm wrong but it only forces inlining when 
the JIT is triggered.
So using the annotation on something which is not called enough will do 
nothing.

As I said in an earlier mail, the golden hammer is the annotation
PleaseJITThisCodeWithAPrivateMetaDataObjectNowAndReJITLaterWhenTheMethodOrTheLoopIsHot
 


>
> -- Chris

Rémi

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

Re: Question about inlining caching by Hotspot and classes implementing an method from an interface

[Rémi Forax]

f.foo() is a megamorphic call so the inlining cache does not work,
too many possible receiver types, so the inlining cache tree
is like a linked list, painfully.
With a language like Java, the VM will fallback to use
a vtable dispatch, you have no inlining but it's faster than
either update the inlining cache each time or to crawle the linked list.

So the idea here is to do exactly the same thing and simulate a vtable.
Because it's a dynamic language, you can't construct a vtable
but you can construct a dynamic lookup table for this precise call site.

I've tried to explain this pattern at the JVM Summit last year,
but I'm not sure someone even understand me :(
Anyway, take a look to the sample bi-morphic cache in the cookbook [1],
look for the comment 'bimorphic cache defeated', the DispatchMap
is what you' looking for.

Rémi
[1] 
http://code.google.com/p/jsr292-cookbook/source/browse/trunk/bimorphic-cache/src/jsr292/cookbook/bicache/RT.java

On 05/08/2012 12:18 AM, Jochen Theodorou wrote:
> Hi all,
>
> I have the feeling we have talked about this already, but I couldn't
> really find it and back then it was independend of invokedynamic...
> Anyway...
>
>
> Assuming I have an interface Foo with a void method foo(). And assuming
> I have the class Bar0, Bar1 to BarN implementing that interface. Let us
> assume further I have code like this:
>
>
> method(bar0)
> method(bar1)
> ...
> method(barN)
>
> where bar0,bar1,..., barN are instance of the corresponding Bar classes
> and method is more or less this:
>
> void method(Foo f){f.foo();}
>
> I was thinking about how I would have to implement the call site checks
> for this case in invokedynamic in that method and the current approach
> would be to check for the implementation class, meaning BarX and meaning
> also to have an invalidation and reselection of the method each time
> method is called. This is surely not the optimal case. It surely would
> be better to check that f implements Foo... well or in the case here we
> can simply forget that check on the receiver... if that where
> reflection. But I think that does not work with MethodHandles I think. I
> guess I will need the reference to the implementation method instead and
> then also a guard for the receiver. Am I wrong? IS there a way around?
>
> THis thought did lead me to another question how does the JVM do
> this for the pure bytecode case? Wouldn't the JVM do mostly the same? I
> mean add a receiver check for the implementation class, just to
> invalidate this site for each of the calls to method? Or how is it done
> there?
>
> 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: hg: mlvm/mlvm/jdk: meth-lazy: moved to ASM for bytecode generation

[Rémi Forax]

On 05/02/2012 02:37 AM, Christian Thalinger wrote:
> On May 1, 2012, at 2:38 PM, Rémi Forax wrote:
>
>> On 05/01/2012 09:24 PM, christian.thalin...@oracle.com wrote:
>>> Changeset: 5ec0f6472b4b
>>> Author:twisti
>>> Date:  2012-05-01 12:24 -0700
>>> URL:   http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/5ec0f6472b4b
>>>
>>> meth-lazy: moved to ASM for bytecode generation
>>>
>>> ! meth-lazy-7023639.patch
>>>
>>> ___
>>> mlvm-dev mailing list
>>> mlvm-dev@openjdk.java.net
>>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>> Hi Christian,
>> in emitIconstInsn, you forget ICONST_M1, also
> We don't need M1 :-)
>
>> ICONST_M1, ICONST_0, ICONST_1, etc are subsequent values so
>> you can write:
>> switch(i) {
>> case -1:
>> case 0:
>> case 1:
>> case 2:
>> case 3:
>> case 4:
>> case 5:
>>opcode = Opcodes.ICONST_0 + i;
>> ...
>> }
> I could do that, right.
>
>> for emitLoadInsn, emitStoreInsn and emitReturnType, you can use
>> the same switch that map 'I', 'J', 'F', 'D', 'A', 'V' to 0...5,
>> because ISTORE, ILOAD and IRETURN variants are all in the same order.
>>
>> Also nextEIID and nextNFID can use an AtomicInter and its method
>> getAndIncrement
>> instead of a synchronized method, it should be more efficient.
> These were supposed to be debugging only since the anonymous class loader 
> defines each class uniquely anyway.  Not sure if we keep them or not.

Yes, right.

>
> -- Chris

Rémi

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

Re: hg: mlvm/mlvm/jdk: meth-lazy: moved to ASM for bytecode generation

[Rémi Forax]

On 05/01/2012 09:24 PM, christian.thalin...@oracle.com wrote:
> Changeset: 5ec0f6472b4b
> Author:twisti
> Date:  2012-05-01 12:24 -0700
> URL:   http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/5ec0f6472b4b
>
> meth-lazy: moved to ASM for bytecode generation
>
> ! meth-lazy-7023639.patch
>
> ___
> mlvm-dev mailing list
> mlvm-dev@openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

Hi Christian,
in emitIconstInsn, you forget ICONST_M1, also
ICONST_M1, ICONST_0, ICONST_1, etc are subsequent values so
you can write:
switch(i) {
case -1:
case 0:
case 1:
case 2:
case 3:
case 4:
case 5:
   opcode = Opcodes.ICONST_0 + i;
...
}

for emitLoadInsn, emitStoreInsn and emitReturnType, you can use
the same switch that map 'I', 'J', 'F', 'D', 'A', 'V' to 0...5,
because ISTORE, ILOAD and IRETURN variants are all in the same order.

Also nextEIID and nextNFID can use an AtomicInter and its method 
getAndIncrement
instead of a synchronized method, it should be more efficient.

cheers,
Rémi


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

Re: hg: mlvm/mlvm/hotspot: annot: brought up-to-date

[Rémi Forax]

On 04/27/2012 12:54 AM, christian.thalin...@oracle.com wrote:
> Changeset: 4ad86bc6f440
> Author:twisti
> Date:  2012-04-26 15:53 -0700
> URL:   http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/4ad86bc6f440
>
> annot: brought up-to-date
> annot-inline: new patch for supporting @Inline annotation
> meth-lazy: refreshed
> Contributed-by: Haupt Michael
>
> + annot-inline.patch
> ! annot.patch
> ! meth-lazy-7023639.jit.patch
> ! meth-lazy-7023639.patch
> ! series

Hi Christian,
@Inline is really cool.

adds a new Annotation AlwaysCompile and I will be happy forever :)

Rémi

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

Re: hg: mlvm/mlvm/hotspot: meth-lazy: renamed ConstantPoolCacheEntry vfinalMethod to f2Oop; use from_interpreted_offset instead of interpreter_entry_offset in TemplateTable::invokedynamic

[Rémi Forax]

On 04/26/2012 07:32 PM, christian.thalin...@oracle.com wrote:
> Changeset: 81bd2928d85d
> Author:twisti
> Date:  2012-04-26 10:32 -0700
> URL:   http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/81bd2928d85d
>
> meth-lazy: renamed ConstantPoolCacheEntry vfinalMethod to f2Oop; use 
> from_interpreted_offset instead of interpreter_entry_offset in 
> TemplateTable::invokedynamic
>
> ! meth-lazy-7023639.patch

Hi Christian,
You forget to rename the name 'vfinal' in the comment

+ // Preserve the value of the vfinal flag on invokevirtual bytecode
+ // which may be shared with this constant pool cache entry.


cheers,
Rémi

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

Re: Boxed types and constat propagation

[Rémi Forax]

On 04/25/2012 07:23 PM, Fredrik Öhrström wrote:
>>> That's a lot of optimization that I otherwise wouldn't have to do, if
>>> only boxed types and constant propagation worked well, but yeah, I see
>>> how it can work now.
> Clearly the C1/C2 compiler needs to be improved. In the meantime
> you have to work around their limitations.
>
>> BTW, I've patched the JIT to consider all final fields of a class of
>> java/lang as truly final
>> but that not enough for having the escape analysis to work with integers.
>> It seems that because of the cache used in Integer.valueOf(), the JIT
>> considers
>> that the Integers are not escapable.
> I think System.out and System.err are final, but they are in fact
> set during the start of the jvm. Just so that you take that into
> account, in case any optimizations would happen that early.
> (There are probably more examples of this.)

The exact code is considering all fields of java/lang classes except the 
one from j/l/System.
The other problem with out and err is setOut() and setErr().

>
> The escape analysis in C2 is broken, combining that with
> the limited amount of boxing removal support, and the cache
> of Integer.valueOf, you get a bad optimizations.
>
> At least we have an intern right now in Stockholm who is
> working on porting the JRockit autoboxing removal optimizations
> to C2. Yay!

Yay too !

>
> //Fredrik

Rémi

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

Re: Boxed types and constat propagation

[Rémi Forax]

On 04/25/2012 06:38 PM, Christian Thalinger wrote:
> On Apr 23, 2012, at 4:29 PM, Rémi Forax wrote:
>
>> On 04/24/2012 12:57 AM, Kohsuke Kawaguchi wrote:
>>> On 04/23/2012 11:18 AM, Rémi Forax wrote:
>>>>> So again, I don't see how shifting from method handle tree to byte
>>>>> code generation would somehow make this non-issue.
>>>> In fact, it's easy to know that a.foo() is a boolean because
>>>> &&   can be only applied on booleans so the invokedynamic call
>>>> corresponding to a.foo() should return a boolean.
>>>>   From the compiler perspective, you have to back-propagate
>>>> the excepted type from the root to the leaf.
>>> Charles was alluding to the same thing, so I was thinking about this,
>>> and I think I understand it now.
>>>
>>> That's a lot of optimization that I otherwise wouldn't have to do, if
>>> only boxed types and constant propagation worked well, but yeah, I see
>>> how it can work now.
>>>
>>> Thanks for all the insights.
>> BTW, I've patched the JIT to consider all final fields of a class of
>> java/lang as truly final
>> but that not enough for having the escape analysis to work with integers.
>> It seems that because of the cache used in Integer.valueOf(), the JIT
>> considers
>> that the Integers are not escapable.
> Correct.  That's the main problem.  Unfortunately the caching is now part of 
> the spec.
>
> Although something that John and I talked about yesterday could help here:  
> immutable (or stable) arrays.  We might add some optimization for this soon 
> since we'd need it for bound arguments in our new JSR 292 implementation.

I've done something similar in the backport, it takes an array
(in fact a map object to integer index but that an implementation detail)
and generates a class with one static final field by array item
and I substitute the bound argument array access by the static field
when generating the bytecode.

My main issue is that when the MethoHandle is GCed,
the bound arguments are not GCed.

>
> -- Chris

Rémi

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

Re: Boxed types and constat propagation

[Rémi Forax]

On 04/24/2012 01:43 AM, Kohsuke Kawaguchi wrote:
>
> Any chance you can share that patch with us? It'd give me some 
> pointers into poking around JDK code, now that I learned how to build 
> it...

Sure, it's easy, in ciField.cpp, there is a method named 
trust_final_non_static_fields(),
you can add

if (holder->is_in_package("java/lang"))
 return true;

or change the flag TrustFinalNonStaticFields to true if you have build 
the fastdebug VM.

cheers,
Rémi

>
> On 04/23/2012 04:29 PM, Rémi Forax wrote:
>> On 04/24/2012 12:57 AM, Kohsuke Kawaguchi wrote:
>>>  On 04/23/2012 11:18 AM, Rémi Forax wrote:
>>>>>   So again, I don't see how shifting from method handle tree to byte
>>>>>   code generation would somehow make this non-issue.
>>>>
>>>>  In fact, it's easy to know that a.foo() is a boolean because
>>>> &&   can be only applied on booleans so the invokedynamic call
>>>>  corresponding to a.foo() should return a boolean.
>>>> From the compiler perspective, you have to back-propagate
>>>>  the excepted type from the root to the leaf.
>>>
>>>  Charles was alluding to the same thing, so I was thinking about this,
>>>  and I think I understand it now.
>>>
>>>  That's a lot of optimization that I otherwise wouldn't have to do, if
>>>  only boxed types and constant propagation worked well, but yeah, I see
>>>  how it can work now.
>>>
>>>  Thanks for all the insights.
>>
>> BTW, I've patched the JIT to consider all final fields of a class of
>> java/lang as truly final
>> but that not enough for having the escape analysis to work with 
>> integers.
>> It seems that because of the cache used in Integer.valueOf(), the JIT
>> considers
>> that the Integers are not escapable.
>>
>> Rémi
>>
>>
>
>

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

Re: Boxed types and constat propagation

[Rémi Forax]

On 04/24/2012 12:57 AM, Kohsuke Kawaguchi wrote:
> On 04/23/2012 11:18 AM, Rémi Forax wrote:
>>>  So again, I don't see how shifting from method handle tree to byte
>>>  code generation would somehow make this non-issue.
>>
>> In fact, it's easy to know that a.foo() is a boolean because
>> &&  can be only applied on booleans so the invokedynamic call
>> corresponding to a.foo() should return a boolean.
>>   From the compiler perspective, you have to back-propagate
>> the excepted type from the root to the leaf.
>
> Charles was alluding to the same thing, so I was thinking about this, 
> and I think I understand it now.
>
> That's a lot of optimization that I otherwise wouldn't have to do, if 
> only boxed types and constant propagation worked well, but yeah, I see 
> how it can work now.
>
> Thanks for all the insights.

BTW, I've patched the JIT to consider all final fields of a class of 
java/lang as truly final
but that not enough for having the escape analysis to work with integers.
It seems that because of the cache used in Integer.valueOf(), the JIT 
considers
that the Integers are not escapable.

Rémi

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

Re: Boxed types and constat propagation

[Rémi Forax]

On 04/23/2012 06:37 PM, Kohsuke Kawaguchi wrote:
> 2012/4/22 Rémi Forax:
>>> So as you can see, 30 and 12 are not recognized as constants.
>> You're right, 30 and 12 are not recognized as int constant
>> but they are recognized as java/lang/Integer constant.
>>
>> 0x7f785ca29706: mov$0x7d66619d8,%r10  ;   {oop(a 'java/ang/nteger' = 
>> 30)}
>>
>> so escape analysis works but Hotspot doesn't trust
>> final field thus doesn't consider the value in the Integer
>> as a constant.
> I see why HotSpot can't in general trust the 'final' keyword, but it
> sure would be nice if it can at least for these boxed types. After
> all, if Integer.value is modified via reflection, all kinds of weird
> things start to happen...

I fully agree :)

Also it's good to know that Graal, the JIT written in Java
on top of Hotspot, trusts final by default and doesn't seem
to have real trouble to run usual benchmarks.
It's a prototype so I suppose that at some point they will have to
change that but anyway it is possible to consider some final fields
as constants without breaking all programs.

>
>>> After a few more experiments, I realize the root cause of this isn't
>>> so much as JSR-292 but more in HotSpot. For example, the following
>>> method produces the following assembly code, and as you can see it's
>>> failing to optimize body() into just "return false".
>> In fact, Hotspot doesn't fail.
>> But Hotspot also obfuscates the code :(
>>
>>> So my question is:
>>>
>>>- Am I missing something?
>> yes :)
>> in that case, the body of 'body' is
>> (there is a ret at 0x7fadf244130c)
>>
>> 0x7fadf24412e6: mov$0x7d6602fe0,%r10  ;   {oop(a 'java/lang/Class' = 
>> 'java/lang/Boolean')}
>>0x7fadf24412f0: mov0x74(%r10),%r8d;*getstatic FALSE
> This is doing "Boolean %r8 = Boolean.FALSE"
>
>> java.lang.Boolean::valueOf@10 (line 149)
>>  ; -
>> BoxedBooleanInlineTest::bool1@1 (line 29)
>>  ; -
>> BoxedBooleanInlineTest::body@1 (line 21)
>>0x7fadf24412f4: movzbl 0xc(%r12,%r8,8),%r11d
> This is doing "%r11 = %r8.value" with proper sign bit expansion
>
>>0x7fadf24412fa: test   %r11d,%r11d
> and this is testing if %r11 is 0.

I have forgotten to say that I barely able to read the assembler code.
So here is my mistake, I was thinking this code was useless.
test is always something mysterious to me.

>
>>0x7fadf24412fd: jne0x7fadf244130d  ;*iconst_0
>>  ; -
>> BoxedBooleanInlineTest::body@24 (line 21)
>>0x7fadf24412ff: xor%eax,%eax  ;*ireturn
> and yes, this is "return 0"
>
>> The code is fully optimized xor %eax, %eax put 0 in eax,
>> which is by convention the register containing the return value
>> and the rest of the code is not used.
>> The question here is why Hostspot generates the unnecessary codes
>> above the xor instruction. The code tests that zero is equals to zero
>> before returning zero :)
> I don't see that as a question. As I said and as you observed earlier,
> this code is *not* fully optimized, in that it doesn't treat
> "Boolean.FALSE.value" as a constant. And under that assumption, every
> instruction in the above code does make sense.

You're right.

>
>
>>>- How do other language implementers cope with this?
>> You are the first as far as I know to use only a tree of method handles
>> to implement expressions. The rest of us generates bytecodes
>> and have a compiler that does constant propagation.
> OK, that's good to know, but I'm not seeing how that changes the picture.
>
> The issue is that, as things stand now, the language runtime would
> have to do the type inference to use primitive types instead of
> Object, or else it won't benefit from constant propagation (which
> triggers other optimizations like dead code elimination and further
> escape analysis.)
>
> Say I compile "a.foo()&&  a.bar()" in JEXL to a byte code (or "a.foo
> &&  a.bar" in JRuby if that helps people understand the example
> better.) Unless I can somehow prove that "a.foo()" returns a boolean,
> I'd have to treat it like they return Object. And so even if at the
> runtime HotSpot discovers that "a" is mostly bound to a specific type
> that implements foo() as "re

Re: Boxed types and constat propagation

[Rémi Forax]

On 04/23/2012 12:34 AM, Charles Oliver Nutter wrote:
> On Sun, Apr 22, 2012 at 2:12 AM, Rémi Forax  wrote:
>> You are the first as far as I know to use only a tree of method handles
>> to implement expressions. The rest of us generates bytecodes
>> and have a compiler that does constant propagation.
> JRuby doesn't do any constant propagation in our existing compiler,
> but we will be able to do some in the newer compiler. Ruby's constants
> are lazily discovered at runtime, so we can't propagate their
> values...but Hotspot should be able to in many cases.

Obviously, doing constant propagation on something that can be
monkey patched is harder.

Do you have a kind of closed world assumption ?
i.e. the compiler knows that there is no eval and will never load new 
code ?

>
> - Charlie

Rémi

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

Re: Boxed types and constat propagation

[Rémi Forax]

See inlined comments :)

On 04/22/2012 12:02 AM, Kohsuke Kawaguchi wrote:
> Hi,
>
> I was inspired by the talk by Charles in JAX 2012 and was playing with
> invokedynamic a bit. I'm observing what seems like a constant
> propagation failure, which I'd imagine would affect some important use
> cases, so I wanted to check if I'm not doing something stupid.
>
> I've used Apache JEXL [1] as my toy "dynamic language". My basic
> strategy was to convert an expression into a graph of MethodHandles.
> This is a fairly straight-forward process, where each node in the JEXL
> AST is converted into function of the type (JexlContext)->Object.
> JexlContext represents the context object for an evaluation.
>
> I then compiled the expression "30+12" to see how well it'd optimize,
> which essentially does the following:
>
> 
> import static java.lang.invoke.MethodHandles.*;
>
>  public void test1() throws Throwable {
>  // builds 30+12 as tree
>  MethodHandle a = constant(Object.class, 30);
>  MethodHandle b = constant(Object.class, 12);
>
>  MethodHandle h =
> lookup().unreflect(getClass().getMethod("add",int.class,int.class));
>  MethodHandle r =
> foldArguments(foldArguments(h,asReturnType(int.class,a)),asReturnType(int.class,b));
>  r = Sandbox.wrap(r);
>
>  assertEquals(42, r.invokeWithArguments());
>  }
>
>  public static int add(int a, int b) {
>  return a+b;
>  }
>
>  public static MethodHandle asReturnType(Class type, MethodHandle h) {
>  return h.asType(MethodType.methodType(type,h.type()));
>  }
> 
>
> I was hoping that this would optimize to "return 42", but on my JDK7u3
> on linux-amd64, it only gets optimized to the followig:
>
> 
># {method} 'invokedynamic' '()I' in 'Gen0'
>#   [sp+0x20]  (sp of caller)
>0x7f785ca29700: push   %rbp
>0x7f785ca29701: sub$0x10,%rsp
>0x7f785ca29705: nop   ;*synchronization entry
>  ; - Gen0::invokedynamic@-1
>0x7f785ca29706: mov$0x7d66619d8,%r10  ;   {oop(a
> 'java/ang/nteger' = 30)}
>0x7f785ca29710: mov0xc(%r10),%eax
>0x7f785ca29714: mov$0x7d66618b8,%r10  ;   {oop(a
> 'java/ang/nteger' = 12)}
>0x7f785ca2971e: add0xc(%r10),%eax ;*iadd
>  ; -
> GuardedIntAddTest::add@2 (line 27)
>  ; -
> java.lang.invoke.MethodHandle::invokeExact@14
>  ; - Gen0::invokedynamic@0
>0x7f785ca29722: add$0x10,%rsp
>0x7f785ca29726: pop%rbp
>0x7f785ca29727: test   %eax,0x5b2c8d3(%rip)# 0x7f7862556000
>  ;   {poll_return}
>0x7f785ca2972d: retq
> 
>
> So as you can see, 30 and 12 are not recognized as constants.

You're right, 30 and 12 are not recognized as int constant
but they are recognized as java/lang/Integer constant.

0x7f785ca29706: mov$0x7d66619d8,%r10  ;   {oop(a 'java/ang/nteger' = 
30)}

so escape analysis works but Hotspot doesn't trust
final field thus doesn't consider the value in the Integer
as a constant.

>
> I think this would affect dynamic languages that treat primitives and
> reference types interchangeably, which is the majority.  If I
> understand correctly, those languages need to compose method handlers
> of the type "(...)->Object", like I did, and rely on the inlining to
> discover unnecessary boxing/unboxing. p.18 in JSR 292 cookbook [2] is
> affected by this, too, since it uses a similar MethodHandle types.
>
>
> After a few more experiments, I realize the root cause of this isn't
> so much as JSR-292 but more in HotSpot. For example, the following
> method produces the following assembly code, and as you can see it's
> failing to optimize body() into just "return false".

In fact, Hotspot doesn't fail.
But Hotspot also obfuscates the code :(

> So my question is:
>
>   - Am I missing something?

yes :)
in that case, the body of 'body' is
(there is a ret at 0x7fadf244130c)

0x7fadf24412e6: mov$0x7d6602fe0,%r10  ;   {oop(a 'java/lang/Class' = 
'java/lang/Boolean')}
   0x7fadf24412f0: mov0x74(%r10),%r8d;*getstatic FALSE
 ; -
java.lang.Boolean::valueOf@10 (line 149)
 ; -
BoxedBooleanInlineTest::bool1@1 (line 29)
 ; -
BoxedBooleanInlineTest::body@1 (line 21)
   0x7fadf24412f4: movzbl 0xc(%r12,%r8,8),%r11d
   0x7fadf24412fa: test   %r11d,%r11d
   0x7fadf24412fd: jne0x7fadf244130d  ;*iconst_0
 ; -
BoxedBooleanInlineTest::body@24 (line 21)
   0x7fadf24412ff: xor%

Re: 7127687: MethodType leaks memory due to interning

[Rémi Forax]

John,
I think you can remove all public methods of class WeakInternSet
but ,add() i.e. tailor the implementation only for the need, at least 
until Doug Lea
provides a weak/concurent/hashmap in java.util.concurent.

Rémi

On 03/29/2012 11:45 AM, Jim Laskey wrote:
> What we are trying to do is intern the MethodType. Maps are designed 
> to provide the key -> value relationship (one way.) If we only used 
> the key and a dummy value in the Map, it would be equivalent to a 
> write only collection, since there is no method to return a found key. 
> We would have to set the value to sometime meaningful like the 
> existing MethodType. Doing so creates the hard reference to the 
> MethodType and transitively to the unloadable Classes.
>
> We encountered this problem in Nashorn where we generate object 
> classes at runtime. MethodTypes that referred to these classes "hung 
> on" to them indefinitely. When running JavaScript test suites, we soon 
> exhausted the perm gen.
>
> I tried using WeakHashMap initially but then realized the 
> implications. WeakHashSet is useless, since it uses WeakHashMap, 
> making it not weak at all.
>
> This fix has been well tested, as it is integrated in our test system 
> (4 times a day on several different platforms.)
>
>
> Sent from my iPhone
>
> On 2012-03-28, at 11:51 PM, Vitaly Davidovich  > wrote:
>
>> We only care about keys here anyway, right? WeakHashMap with a dummy 
>> value object (some static reference) should achieve the same thing 
>> since its Entry will have the key referenced weakly and the value 
>> strongly (but we don't care since the value is a dummy static ref). 
>> Maybe I misunderstood the intent though ...
>>
>> Sent from my phone
>>
>> On Mar 28, 2012 9:02 PM, "Jim Laskey" > > wrote:
>>
>> The WeakHashMap leads to a non-weak reference to the class, since
>> only the key is weak. Same is true for public versions of
>> WeakHashSet. The collection used here is truly weak.
>>
>> Sent from my iPhone 4
>>
>> On 2012-03-28, at 9:42 PM, Vitaly Davidovich > > wrote:
>>
>>> Hi John,
>>>
>>> I think you can use diamond generic inference when declaring the
>>> weak intern set.
>>>
>>> Also any reason you didn't use WeakHashMap directly with dummy
>>> value to simulate the set? Or wrap the WeakHashMap and
>>> synchronize the accessors to it?
>>>
>>> Sent from my phone
>>>
>>> On Mar 28, 2012 7:52 PM, "John Rose" >> > wrote:
>>>
>>> http://cr.openjdk.java.net/~jrose/7127687/webrev.00/
>>> 
>>>
>>> 7127687: MethodType leaks memory due to interning
>>> Summary: Replace internTable with a weak-reference version.
>>>
>>> This is a point fix for JDK 8, and will (pending approval)
>>> also be back-ported to JDK 7u.
>>>
>>> — John
>>>
>>> Notes on process: This code is part of JSR 292. Therefore
>>> the review comments will be collected in mlvm-dev, and
>>> changes will be integrated via hsx/hotspot-comp.
>>>
>>> At least one reviewer must be an official Reviewer the JDK 8
>>> Project [1], but other reviewers are most welcome.
>>>
>>> [1] http://openjdk.java.net/census#jdk8
>>>
>>> ___
>>> 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

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

Re: review request (S): 7129034: VM crash with a field setter method with a filterArguments

[Rémi Forax]

On 03/27/2012 10:04 AM, John Rose wrote:
> http://cr.openjdk.java.net/~jrose/7129034/webrev.00/
>
> 7129034: VM crash with a field setter method with a filterArguments
> Summary: add null checks before unsafe calls that take a variable base 
> reference; update unit tests
>
> This is a point fix for JDK 8, and will also be back-ported to JDK 7u.
>
> — John
>
> Note:  This class is part of JSR 292.  Therefore the review comments will be 
> collected in mlvm-dev.

looks good.

Rémi

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

Bug in ClassValue

[Rémi Forax]

Last week, Fredrik found that I've forgotten to implement ClassValue
in the backport of jsr292.

While struggling to implement it, I've found a bug in the implementation
of the JDK. This snippet creates an infinite loop :(

java.lang.ClassValue cv = new 
java.lang.ClassValue() {
 @Override
 protected Integer computeValue(Class type) {
 remove(int.class);
 return 1;
 }
 };
 cv.get(int.class);

while this code is naughty, I think it's a legal one.

cheers,
Rémi

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

Re: This was very cool, adding a profiler using MH

[Rémi Forax]

On 02/17/2012 11:10 AM, Charles Oliver Nutter wrote:
> On Fri, Feb 17, 2012 at 4:05 AM, Rémi Forax  wrote:
>>> You could also interpose on abnormal termination (exceptions), using 
>>> guardWithCatch.
>> The try-finallly method handle combiner is one example of the cookbook:
>> http://code.google.com/p/jsr292-cookbook/source/browse/trunk/interceptors/src/jsr292/cookbook/interceptors/Interceptors.java#68
> So painful! :)
>
> handle = Binder
>  .from(target.type())
>  .tryFinally(handler)
>  .invoke(target);

pardon :)

handle = tryFinally(target, handler);

>
> - Charlie

Rémi

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

Re: This was very cool, adding a profiler using MH

[Rémi Forax]

On 02/17/2012 06:29 AM, John Rose wrote:
> On Feb 16, 2012, at 8:43 PM, Mark Roos wrote:
>
>> The key code is below and it shows the power of methodHandles is ways one 
>> may not expect.  And it
>> added almost nothing to the run time ( maybe a few %).  It inserts itself 
>> into each callsite target and
>> collect entry and exit data.
> Nice!
>
> As a bonus, your profile points are given a chance to modify the arguments 
> and return value.
>
> If you don't want to pass the arguments and return value, you can use a 
> void-returning combiner with foldArguments (instead of filterArguments).  The 
> combiner will "see" the arguments and then "return nothing", allowing the 
> invoker to continue as before.

Yes, in PHP.reboot I track the hotness of a method by calling a void 
returning method that will increment
a counter that is bound to the method.
My first version was using a code very similar to the code of Mark.
I have then switch to use a fold + a void-returning combiner when we 
decide to support that idiom.

>
> A different use of foldArguments would also let you pass both the original 
> arguments and the return value to the profileExit routine, so it could see 
> the whole call.  Something like this:
>
> invoker = {spreader which takes standard RtObject[] array};
> profileExit = {method of type (RtCallSite, RtObject, RtObject[]) =>  
> RtObject};
> profileExit = insertArguments(profileExit, 0, thisCallSite);  // 
> (RtObject, RtObject[]) =>  RtObject
> invoker = foldArguments(profileExit, invoker);  // note that invoker 
> serves as *combiner*
>
> // add entry profiling last, so that profileExit will see (possibly) 
> transformed arguments:
> profileEntry = {method of type (RtCallSite, RtObject[]) =>  RtObject[]};
> profileEntry = insertArguments(0, thisCallSite);  // (RtObject[]) =>  
> RtObject[]
> invoker = filterArguments(invoker, profileEntry);
>
> You could also interpose on abnormal termination (exceptions), using 
> guardWithCatch.

The try-finallly method handle combiner is one example of the cookbook:
http://code.google.com/p/jsr292-cookbook/source/browse/trunk/interceptors/src/jsr292/cookbook/interceptors/Interceptors.java#68
 


>
> A relatively simple way to do take full control of traced calls is to 
> delegate the actual calling to the profile routine, but this might 
> (presently) hurt performance, since it will make all calls go through one hot 
> point, profileWrapper:
>
>invoker = {spreader which takes standard RtObject[] array};
>profileWrapper = {method of type (RTCallSite, MethodHandle, RtObject[]) => 
>  RtObject};
>// wrapped call will execute this: profileWrapper(thisCallSite, 
> unwrappedInvoker, arg...)
>invoker = insertArguments(profileWrapper, 0, thisCallSite, invoker);
>
> I'm glad you are enjoying the toolkit!
>
> -- John


cheers,
Rémi

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

Re: Benchmarking Smalltalk on JVM

[Rémi Forax]

On 02/02/2012 04:45 AM, Mark Roos wrote:
> From Rémi
> Anyway, you can optimize the last instructions, <= should 
> return a boolean
>so the sequence should be:
>
>ldc 4100
>aload 1
>indy <= (ILObject;)Z
>if_eq LABEL 1
>
> I am not sure how to handle this in a Smalltalk envrionment.  All of 
> the objects are instances of the same
> java type so <= is a method which returns an RtObject which is the 
> singular instance of true.  I have to
> compare that return to 'true' to get what the if bytecode wants.

<= should be a method that returns a boolean which is wrapped
to a RtObject by invokedynamic if the return type is an Object
but not if the return type is a boolean.

>
> <= could have been a block making type inference more interesting.

The idea is just to propagate the type you need if you can.
So
   for a = 2 <= 3, '<=' will return a RtObject but
   for if (2 <= 3),  '<=' will return a boolean because it's called in 
an if.

>
> thanks for the thoughts
>
> mark

cheers,
Rémi

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

Re: Smalltalk and tiered compile data

[Rémi Forax]

On 02/08/2012 10:47 PM, Mark Roos wrote:
> Hi Rémi

Hi Mark,

>
> I think I am starting to get it.
>
> My normal fallback creates a GWT and does a getTarget + setTarget on 
> the root callsite to put this GWT at the
> head of the chain.  I assume that this use of setTarget is as expected 
> and causes no problems.  I think I
> found this technique in some of your early code.

yes !

>
> For the switchPoint approach I would set the first (root) target to a 
>  switchPoint which invokes a new callsite
> which then takes the normal fallback. This keeps the switchPoint at 
> the head with the GWT chain now
> growing from the second callsite.
>
> The invalidate path has a method handle which will create a new 
> switchPoint with fallbacks and place it
> in the root callsite replacing the now dead switchPoint.  This 
> setTarget will occur on the next invocation
> of the root callSite after the invalidation.
>
> This state is similar to the first after a bootstrap.

yes !

>
> So I am going to do a lot of setTargets.  One for each method cache 
> miss and again for every call site which
> is invalidated plus any lookups it needs to do.
>
> Given that every setTarget involves a safe point this sounds like it 
> could get expensive.  Should I be
> concerned?

No :)
setTarget() doesn't implies automatically a safepoint. There is a 
safepoint if
you do a setTarget() on a Callsites which have been used to generate a 
compiled code.

>
> thanks
>
> mark
>

cheers,
Rémi

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

Re: Smalltalk and tiered compile data

[Rémi Forax]

On 02/08/2012 02:55 AM, Mark Roos wrote:
> Hi Rémi
>
> Just a clarification on the switchpoint usage to invalidate sites.
>
> The switch path would still do a setTarget correct?

No, SwitchPoint.invalidateAll() doesn't call setTarget().

> So I am still sending lots of
> setTargets just based on switch point state?

No.
The idea is that you introduce a guard created from the SwitchPoint
at the beginning of your target. You create the guard with a target 
(your old target)
and a fallback which in this case is the fallback that you install when 
you call
setTarget.
When you call invalidateAll with all your SwitchPoints (you can create 
one by signature
if you want) then the VM ask all other threads to go to a safe point.
For all callsite targets that have been JITed, the code is marked as 
dead and
the next call to invokedynamic on that callsite will go through
the target method handle tree instead of calling the JITed code.
When the VM will call the guard of the invalidated SwitchPoint instead of
calling the target, it will calll the fallback method of the guard.

All will be done at one safepoint.

>
> It also seems that if the switch point is in series with the target 
> that the callsite will not
> invalidate until its next use.

technically, it's the guard of the switch point which is in serie but
yes, JITed code willl be dropped later (when no callsite will be able to 
call it)
and if the code is not JITed, the SwitchPoint is just turn off so
nothing will be done until the callsite is called again.

>  Seems like this could spread the invalidations out over time
> giving hotspot even more to do.

No, because the VM will be able to do the cleanup without using a safepoint
and the cleanup phase is not something heavy.
>
> Or am I not clear on how to do this?
>
> thanks
> mark

cheers,
Rémi

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

Re: Smalltalk and tiered compile data

[Rémi Forax]

On 02/07/2012 08:28 PM, Mark Roos wrote:
> Christian asked:
>
> What exactly do you mean by "invalidate call sites before the 
> benchmark"?
> Are you using MutableCallSites and call setTarget on them?
>
> Exactly.  I am using setTarget to set each call site to its initial 
> fallback method.  This should drop the
> GWT lookup chain forcing each call site to rebuild the chain.  The 
> method handles for the code   still exist but
> the GWTs that reference them are gone.  This is my current way to 
> force the call sites to get new versions
> of the method code.
>
> thanks

Mark, you should use a SwitchPoint instead of calling a lot of setTarget()
because each setTarget() may require all threads of the VM to go to a 
safepoint
so you may create a 'safepoint storm' (as coined by Dan Heidinga).

>
> mark

Rémi

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

Re: Benchmarking Smalltalk on JVM

[Rémi Forax]

On 02/02/2012 04:45 AM, Mark Roos wrote:
> from Rémi
>
> if you know it will never escape,you should use an int directly.
>
> Well I am trying to build a Smalltalk system which has no static types so
> I have to box the ints. Since the code I showed was programmer entered I
> need to stay with the boxes.
>
> There are cases where the compiler generates the index code and there 
> I do
> use static ints if I can be sure they are not passed.

or you can box only just before it's passed.

The MutableInteger trick only works because the VM does
the escape analysis for you but the escape analysis done
by the VM is more britlle than the one you can write,
by example, you know that increment() is a pure function,
the VM has to inline it to know. So if one call is not inlined in
the middle of the body of the loop, then the VM will
not remove your MutableInteger.

> It does cause some
> issues when I open a debugger on the stack so I may want to keep then 
> boxed
> anyway and thus the MutableInteger

??, yes your debugger has to support it, but if you
want a typed smalltalk you will need that anyway.

>
> mark
>

Rémi

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

Re: Benchmarking Smalltalk on JVM

[Rémi Forax]

On 02/02/2012 04:45 AM, Mark Roos wrote:
> From Rémi
> Without the descriptors of invokedynamic and the code of the 
> BSM, it's
>hard to tell.
>
> Yes but they have no invoke dynamics and I was just wondering if my 
> indy part was causing the
> issue.  Your answer told me that I should be OK so that was helpful.   
> This same code was much
> faster on jdk8-b20 for some reason.

It can be an escape analysis change.
As far as I know, escape analysis don't work through indy call but
if Charles see same performance as Java, escape analysis has to work ??

>
> I will play around and see where the time is going .  Would be nice to 
> have an way to get the 8086 object code.

https://wikis.oracle.com/display/HotSpotInternals/PrintAssembly

>
> thanks
>
> mark

Rémi

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

Re: Benchmarking Smalltalk on JVM

[Rémi Forax]

On 02/01/2012 10:44 PM, Mark Roos wrote:
> This may be a little much to ask but...   These bytecodes take about 
> 20ns per cycle to run on
> my 2.8 GHz mac using jdk8-B23 without TieredCompile.  Does this seem 
> reasonable given the number of indy calls?
> The GWT depth on the method sends is 1
>
> thanks
> mark
>
>LABEL <56>  LABEL 1
> <56>  aload 4
> <58>  aload 3
> <59>  astore 1
> <60>  aload 1
>INDY (asm) <61>  ["at:"] RtCallSite, (6) {RtTestCases class 
> benchmarkLoop, 19}
> <66>  astore 1
> <67>  aload 1
> <68>  astore 5
>INDY (asm) <70>  ["41"] ConstantCallSite, (6) {dummy}
> <75>  aload 4
> <77>  astore 1
> <78>  aload 1
>INDY (asm) <79>  ["increment:"] RtCallSite, (6) {RtTestCases class 
> benchmarkLoop, 23}
> <84>  astore 1
>LABEL <85>  LABEL 0
> <85>  aload 4
> <87>  astore 1
>INDY (asm) <88>  ["4100"] ConstantCallSite, (6) {dummy}
> <93>  aload 1
>INDY (asm) <94>  ["<="] RtCallSite, (6) {RtTestCases class 
> benchmarkLoop, 24}
> <99>  astore 1
> <100>  aload 1
> <101>  getstatic ri/core/rtalk/RtObject _true Lri/core/rtalk/RtObject;
>JUMP <104>  if_acmpeq LABEL 1

Without the descriptors of invokedynamic and the code of the BSM, it's 
hard to tell.

Anyway, you can optimize the last instructions, <= should return a boolean
so the sequence should be:

ldc 4100
aload 1
indy <= (ILObject;)Z
if_eq LABEL 1

for that you have to propagate types, from root to leafs to type the 
return type
of invokedynamic with the expected type (the condition of an if is a 
boolean)
an from leafs to root (the first argument of <= is an int).

cheers,
Rémi

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

Re: Benchmarking Smalltalk on JVM

[Rémi Forax]

On 02/01/2012 10:44 PM, Mark Roos wrote:
> Hi Charles
>
> Its pretty simple.  All of my integers are boxed and are by definition 
> immutable.  However I noticed
> that many uses of integer were for loop counters and indexes where the 
> integer never escapes from
> the method.  So I added two primitives, one to copy a integer into a 
> new box  and the other to increment
> the java primitive held inside the box.  In all other ways it inherits 
> from my Integer class.  The value is in
> reducing Integer creation for big loop/index ints.
>
> Usage looks like
> position := 1 newMutable.   gets a mutable integer with an 
> initial value of 1
> position increment:1.increments the internal 
> primitive
> position <= 10  normal integer compare method
>
> I'll probably add a mutable bit to the header to protect the unwary in 
> case it escapes but for now its
> a power tool.
>
> regards
> mark

if you know it will never escape,you should use an int directly.

Rémi

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

Re: Benchmarking Smalltalk on JVM

[Rémi Forax]

On 02/01/2012 01:52 AM, Mark Roos wrote:
> I just loaded about 250K lines of Smalltalk code into my jvm 
> implementation so now I can start
> some real benchmarks using our application.  All of this was done on a 
> Mac.
>
> My first try was a object load which takes about 20 files and creates 
> a pretty complex object set.  This
> takes 100 seconds in ST and using the initial jdk7 release I also get 
> 100 seconds.  Not bad.  But
> I see that one of the major slowdowns is in my use of boxed integers 
> vs STs use of Fixnums.  So
> I did some more detailed experiments.
>
> Using this code snippet which creates and drops about 2 million 
> Integers which ST does in about 10ms.
>
> | bytes pos sum |
> bytes := ByteArray new:100.
> sum := 0.
> pos := 1.
> [pos <= 100]whileTrue:[
> sum := bytes at:pos.
> pos := pos + 1].
> ^sum
>
> For the initial JDK7 I get 400ms,  moving to jdk8 b20 it drops to 
> 117ms ( very nice).
> I then converted some constructor lookups to statics to get to 66ms.
> Then the obvious move to make an integer cache for which I used the 
> jTalk range of -2000 to 4000 gave 30ms
> And finally ( to handle the index integer) I created a MutableInteger 
> which dropped me to 5ms.
>
> So 2X better than the ST I started with.
>
> But then I upgraded to jsk8b23 and now the best I see is 16ms.  It 
> also seems like the jit sometimes
> compiles and sometimes not even using the same startup sequence. 
>  Bleeding edge I would guess.
>
> But for the final test I used jdk7u4 and my load is 73 seconds.  Not 
> as good as the best jdk8b20 ( 60 seconds)
> but faster than native Smalltalk

Hi Mark, I believe tiered compilation was enable by default between 
jdk8b20 and jdk8b23.
I have seen some weird compilation pattern too but no time to really 
investigate.

>
> looking good
> mark

Rémi

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

Re: No way to create a no-op MethodHandle that returns void?

[Rémi Forax]

On 01/24/2012 09:40 AM, John Rose wrote:
> On Jan 23, 2012, at 11:26 PM, Charles Oliver Nutter wrote:
>
>> Oh, that does seem to work...what an ugly hack. And actually, you can
>> just use Object.class but cast the resulting return to void, and it
>> works.
>>
>> So basically, I do this:
>>
>> handler = MethodHandles.constant(Object.class, null)
>> handler = MethodHandles.asType(void.class)
> The EG considered things like having MethodHandles.constant(void.class, null) 
> or identity(void.class).
> Even identity(methodType(void.class, Throwable.class, String.class)).
> There is a certain logic to such things but it didn't feel regular enough, 
> and users can get the same effect by asType (as you realized).
>
> Noctarius is right in referring to Void.  The MH API treats Void fairly 
> regularly as the wrapper type for void, with a unique (unit) wrapped value of 
> null.
>
>> handler = MethodHandles.dropArguments(0, Throwable.class, String.class)
>>
>> And then use that as the exception handler.
>>
>> It's not exactly the no-op I wanted, since it has the cast logic in
>> there, but it's close enough.
>>
>> FWIW, I'm using this in the tests for invokebinder, for testing the
>> tryFinally operation:
> That binder stuff is great.  Next, we want a builder syntax in Java (for more 
> than just List+Map constants).  Plus a little type-system bridge from 
> Foo::bar and foo->bar to MethodHandle.  Then we can compose our method 
> handles quite swimmingly.

Lambda should provide bridge from Foo::bar to MethodHandle :)

>
> -- John

Rémi

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

Re: hg: mlvm/mlvm/jdk: LF'ified makeAllocator; 18 MethodHandlesTests working

[Rémi Forax]

On 01/04/2012 05:28 PM, Christian Thalinger wrote:
> On Dec 30, 2011, at 4:25 PM, Christian Thalinger wrote:
>
>> On Dec 30, 2011, at 3:45 PM, Rémi Forax wrote:
>>
>>> On 12/30/2011 03:26 PM, christian.thalin...@oracle.com wrote:
>>>> Changeset: 700540b4b52b
>>>> Author:twisti
>>>> Date:  2011-12-30 15:25 +0100
>>>> URL:   http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/700540b4b52b
>>>>
>>>> LF'ified makeAllocator; 18 MethodHandlesTests working
>>>>
>>>> ! meth-lazy-7023639.bcg.patch
>>> Hi Christian,
>>> I believe you should create the UNSAFE_ALLOCATEINSTANCE with
>>> lookup.bind() instead of doing a findVirtual + a bindReceiver
>>> to avoid to bind the receiver for each call of findConstructor.
> Recent changes allows this now and I just pushed a changeset that does 
> exactly that.  Thanks again!
>
> -- Chris

:)

Rémi

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

Re: hg: mlvm/mlvm/jdk: LF'ified makeAllocator; 18 MethodHandlesTests working

[Rémi Forax]

On 12/30/2011 03:26 PM, christian.thalin...@oracle.com wrote:
> Changeset: 700540b4b52b
> Author:twisti
> Date:  2011-12-30 15:25 +0100
> URL:   http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/700540b4b52b
>
> LF'ified makeAllocator; 18 MethodHandlesTests working
>
> ! meth-lazy-7023639.bcg.patch

Hi Christian,
I believe you should create the UNSAFE_ALLOCATEINSTANCE with
lookup.bind() instead of doing a findVirtual + a bindReceiver
to avoid to bind the receiver for each call of findConstructor.

BTW, nice to see that collect is not used anymore during the allocation.

cheers,
Rémi


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

JSR 292 Goodness: Almost static final field

[Rémi Forax]

I've written a blog entry about how to write a static volatile final 
variable, i.e. a variable which is considered as constant
by the compiler (the JIT) and if the variable changes, the JITed code is 
deoptimized and
jump back in interpreter mode to eventually optimize it again later.

http://weblogs.java.net/blog/forax/archive/2011/12/17/jsr-292-goodness-almost-static-final-field

The code is a little bit more convoluted than it should because there is 
no invokedynamic
in Java but you can emulate it.

Rémi

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

Re: How to monitor SwitchPoint's impact?

[Rémi Forax]

On 12/12/2011 05:38 PM, Charles Oliver Nutter wrote:
> I'm still of the opinion that you shouldn't fix it, or at least
> shouldn't demote "noisy" call sites to never optimize. It's not
> common, but there are Ruby programs that may define a new class or
> method at runtime even at steady state. Not for every request, but
> occasionally. I don't like the thought that a "read mostly" call site
> that never completely settles down might get demoted and never
> optimized when it's still mostly steady.
>
> The cost of updating call sites or switch points is part of the fun :)
> I consider that cost when I'm deciding how and when to update call
> sites, how and when to failover my own logic to a demoted version, and
> so on. I think it's my responsibility to deal with those costs, not
> yours...
>
> - Charlie

I agree.

In my opinion, it's up to the language runtime designer to estimate
if it's a good idea to invalidate something at some point or not
because the runtime has more information than the VM.

Moreover any throttle logic just make the API less predictable,
the throttle logic should be removed to help the designers
to easily predict the behaviour of their runtimes.

Rémi

>
> On Mon, Dec 12, 2011 at 6:25 AM, Christian Thalinger
>   wrote:
>> If the bugger here is a repeatedly invalidated SwitchPoint then we (reads: 
>> I) should fix:
>>
>> 7087838: JSR 292: add throttling logic for optimistic call site optimizations
>>
>> I just don't have a good frequency-based logic yet...
>>
>> -- Chris
>>
>> On Dec 1, 2011, at 10:55 PM, Charles Oliver Nutter wrote:
>>
>>> Perfect, Tom, thanks.
>>>
>>> On Thu, Dec 1, 2011 at 3:21 PM, Tom Rodriguez  
>>> wrote:
 On Dec 1, 2011, at 1:34 AM, Charles Oliver Nutter wrote:

> My recent explorations into Stephen B's perf degradation on JRuby have
> led me to an unfortunate conclusion: something SwitchPoint-related is
> responsible for the remaining slowdown.
>
> I had bugs I fixed, like the awful PIC-causes-repeat-rebinding issue
> or the heavy-class-mutation-never-stabilizes issue, but the last "fix"
> I found was to disable SwitchPoint-based call site invalidation
> entirely.
 The upside of the push based invalidation of SwitchPoint is that the 
 executed code runs quickly but the downside is that invalidation is 
 expensive, possibly requiring a deopt and recompilation.  If you suspect 
 that's happening, try running with -XX:+UnlockDiagnosticVMOptions 
 -XX:+LogVMOutput -XX:+PrintCompilation and look for dependency_failed 
 messages where type='call_site_target_value'.  Any following 
 make_not_entrant messages are probably caused by the invalidation of the 
 SwitchPoint.

 tom

> Now I'm not (yet) saying this is a perf issue in SwitchPoint itself.
> My problem is that it's very difficult to get any visibility into how
> frequently SwitchPoints are being invalidated (though I could
> instrument my own code, of course), or more importantly how
> drastically those invalidations are affecting performance. Does a
> single SwitchPoint invalidation happening repeatedly completely tank
> performance across the entire system? Does it require SwitchPoint
> invalidation that affects a broader surface area?
>
> I will continue investigating on my side. I suspect the problem is
> that there's just a handful of SwitchPoint locations that are
> repeatedly invalidated, but that those invalidations are having a
> drastic global impact. I'm not yet sure how to work around such a
> situation, where one bad apple is spoiling the whole bunch...
>
> - 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
>>> ___
>>> 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: The NoClassDefFoundError bug is back :(

[Rémi Forax]

On 12/08/2011 06:58 PM, Charles Oliver Nutter wrote:
> I just had a report of the same error in 1.7.0GA, and I saw it on the
> CI server last night after I set up a 1.7.0_01 build. Did it linger
> into GA?
>
> http://ci.jruby.org/job/jruby-test-matrix/jdk=sun-java-7,label=master/406/console
>
> On Tue, Dec 6, 2011 at 3:52 AM, Rémi Forax  wrote:
>> I've forget to say that a workaround is to erase the type used the callsite
>> before calling dynamicInvoker().
> Can you elaborate on this? I'm not using dynamicInvoker...I bind the
> site and use invokeWithArguments. Are you saying I could insert an
> asType() that clears everything to Object?

invokeWithArguments uses foldArgument and a generic invoker
that maybe why you see the same error.

about asType(), the idea is to erase the type before calling 
invokeWithArguments
instead of
   mh.invokeWithArgument(args);
you can use
   mh.asType(mh.type().erase()).invokeWithArguments(args);

and I have no idea if it works and about the perf cost if there is a cost.

>
> If so, would that introduce overhead?
>
> - Charlie

Rémi

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

Re: The NoClassDefFoundError bug is back :(

[Rémi Forax]

On 12/06/2011 10:34 AM, Rémi Forax wrote:
> On 12/05/2011 04:28 PM, Rémi Forax wrote:
>> John, Christian,
>> I was updating the multi-dispatch sample from the cookbook
>> when the NoClassDefFoundError bug re-appear.
> I've reduced the code to this simple sample:
> public class NoClassDefFoundSample {
> public void foo() {
>   // do nothing
> }
>
> public static void main(String[] args) {
>   NoClassDefFoundSample classDefFoundSample = new
> NoClassDefFoundSample();
>   for(int i=0; i<  10; i++) {
> classDefFoundSample.foo();   // invokedynamic
>   }
> }
> }
>
> public class NoClassDefFoundBug {
> // bootstrap method
> public static CallSite invokevirtual(Lookup lookup, String name,
> MethodType type) throws Throwable {
>   MethodHandle mh = lookup.findVirtual(type.parameterType(0), name,
>   type.dropParameterTypes(0, 1));
>
>   CallSite invokerCallSite = new MutableCallSite(mh);
>
>   MethodHandle dynamicInvoker = invokerCallSite.dynamicInvoker();
>
>   CallSite callSite = new MutableCallSite(type);
>   callSite.setTarget(dynamicInvoker);
>
>   return callSite;
> }
> }
>
> The sample triggers the JIT and the JITed code of the dynamicInvoker()
> throws
> the NoClassDefFoundError.
>
> Code is available here:
> https://code.google.com/p/jsr292-cookbook/source/browse/#svn/trunk/multi-dispatch/src/bug
> https://code.google.com/p/jsr292-cookbook/source/browse/trunk/multi-dispatch/NoClassDefFoundSample.java

I've forget to say that a workaround is to erase the type used the callsite
before calling dynamicInvoker().

>
> cheers,
> Rémi

cheers,
Rémi

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

Re: The NoClassDefFoundError bug is back :(

[Rémi Forax]

On 12/05/2011 04:28 PM, Rémi Forax wrote:
> John, Christian,
> I was updating the multi-dispatch sample from the cookbook
> when the NoClassDefFoundError bug re-appear.

I've reduced the code to this simple sample:
public class NoClassDefFoundSample {
   public void foo() {
 // do nothing
   }

   public static void main(String[] args) {
 NoClassDefFoundSample classDefFoundSample = new 
NoClassDefFoundSample();
 for(int i=0; i < 10; i++) {
   classDefFoundSample.foo();   // invokedynamic
 }
   }
}

public class NoClassDefFoundBug {
   // bootstrap method
   public static CallSite invokevirtual(Lookup lookup, String name, 
MethodType type) throws Throwable {
 MethodHandle mh = lookup.findVirtual(type.parameterType(0), name,
 type.dropParameterTypes(0, 1));

 CallSite invokerCallSite = new MutableCallSite(mh);

 MethodHandle dynamicInvoker = invokerCallSite.dynamicInvoker();

 CallSite callSite = new MutableCallSite(type);
 callSite.setTarget(dynamicInvoker);

 return callSite;
   }
}

The sample triggers the JIT and the JITed code of the dynamicInvoker() 
throws
the NoClassDefFoundError.

Code is available here:
https://code.google.com/p/jsr292-cookbook/source/browse/#svn/trunk/multi-dispatch/src/bug
https://code.google.com/p/jsr292-cookbook/source/browse/trunk/multi-dispatch/NoClassDefFoundSample.java

cheers,
Rémi




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

The NoClassDefFoundError bug is back :(

[Rémi Forax]

John, Christian,
I was updating the multi-dispatch sample from the cookbook
when the NoClassDefFoundError bug re-appear.



[forax@localhost multi-dispatch]$ java -ea -cp classes:. Main2
skip java.lang.String.contentEquals/2
skip java.lang.String.replace/3
Exception in thread "main" java.lang.NoClassDefFoundError: Main2
 at java.lang.invoke.MethodHandle.invokeExact(MethodHandle.java)
 at java.lang.invoke.MethodHandle.invokeExact(MethodHandle.java)
 at Main2.test2(Main2.java:27)
 at Main2.main(Main2.java:42)

[forax@localhost src]$ java -version
java version "1.8.0-ea"
Java(TM) SE Runtime Environment (build 1.8.0-ea-b07)
Java HotSpot(TM) 64-Bit Server VM (build 22.0-b03, mixed mode)

The sample is here:
http://code.google.com/p/jsr292-cookbook/source/browse/trunk/multi-dispatch/src/jsr292/cookbook/mdispatch/

You can compile it from src,
javac -d ../classes jsr292/cookbook/mdispatch/*.java

The example that doesn't work is Main2, which is created by compiling 
Main2.java
and then by rewriting all invokevirtual/invokestatic to invokedynamic 
using this line
java -cp classes:../lib/asm-debug-all-4.0_RC1.jar 
jsr292.cookbook.mdispatch.Rewriter Main2.class

Note that Main2.class is already rewritten so you don't have to do it
if you just want to reproduce the bug without modifying Main2.java

I think the error is thrown when calling a method handle created by this 
line
https://code.google.com/p/jsr292-cookbook/source/browse/trunk/multi-dispatch/src/jsr292/cookbook/mdispatch/SmallSelectorMetadata.java?spec=svn13&r=13#121
at this callsite
http://code.google.com/p/jsr292-cookbook/source/browse/trunk/multi-dispatch/Main2.java#27

How the code works: it installs a bimorphic cache on the receiver
and an inlining cache on the parameters. After 3 cache misses, the 
implementation
switch to use a table based resolution that lookup for most specific 
method handle and
use an exactInvoker to call it. The bug appear when the exactInvoker is 
called.

regards,
Rémi

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

Re: review request (L): 7030453: JSR 292 ClassValue.get method is too slow

[Rémi Forax]

On 12/05/2011 01:27 AM, Joe Darcy wrote:
> On 12/4/2011 2:13 PM, Rémi Forax wrote:
>> On 12/04/2011 08:38 PM, Joe Darcy wrote:
>>> Hi John,
>>>
>>> Are there alternatives to adding two new fields to java.lang.Class?  
>>> I assume most Class'es won't have ClassValue information associated 
>>> with them.
>>>
>>> -Joe
>>
>> If you use Groovy, JRuby or Nashorn in your code, all visible classes 
>> will use this two fields.
>>
>> Any alternative will slow down the access to the class value.
>
> In the mean time, all the non-Groovy, non-JRuby, non-Nashorn, etc. 
> uses of class Class and all the classes not visible in those 
> environments when they are being used will be larger.
>
> Adding the fields may be the right time/space trade-off, but I think 
> the point merits some discussion given how many Class objects get 
> created and the relative proportion of Java executions where 
> ClassValue is currently used.
>
> The more reasonable time/space trade-off can change over time of course.
>
> -Joe
>

I agree but as I said, in that case, I think it's better to take a look 
to the big picture
and see if not only class values fields but also annotations related 
fields or reflection related fields
can be moved.

Also, if we don't provide a fast ClassValue, people will create their 
own concurrent weak hash map
using class as key that will be worst because it seems that only few 
people knows
how to do that right. Personally, I don't.

Rémi

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

Re: review request (L): 7030453: JSR 292 ClassValue.get method is too slow

[Rémi Forax]

On 12/04/2011 08:38 PM, Joe Darcy wrote:
> Hi John,
>
> Are there alternatives to adding two new fields to java.lang.Class?  I 
> assume most Class'es won't have ClassValue information associated with 
> them.
>
> -Joe

If you use Groovy, JRuby or Nashorn in your code, all visible classes 
will use this two fields.

Any alternative will slow down the access to the class value.

BTW, if we had to remove some fields, I vote for moving all fields 
related to the reflection
in a delegate class. Looking up for members is slow so most of the code 
that call reflection
methods use their own cache, so the performance impact will be small in 
my opinion
(I have no data to prove that :)

Rémi

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

Re: Process-level fork on OpenJDK...is it madness?

[Rémi Forax]

On 11/30/2011 04:28 PM, Jochen Theodorou wrote:
> Am 30.11.2011 14:02, schrieb Rémi Forax:
> [...]
>>>> What kind of initialization work is this? Could the result of that work
>>>> be cached?
>>> we have to setup the initial meta class system, which requires to use
>>> reflection to inspect some classes and other work. Yes, this could be
>>> cached, if we would know how.
>> It worth to give a try to java.lang.ClassValue, here.
>> You you be able to create your metaclass only when needed.
>>
>> Also note that you can also lazyly initialize the list of methods,
>> fields etc. because even if two threads ask the same list at the
>> same time, the result will be the same, so there is no need
>> to use synchronized here.
>> (this is exactly what java.lang.Class code does) :
> it is all lazy, but what gives it if you need it for even the most
> simple script? For
>
> println 1+1
>
> you will need the a meta class for the current class, you will need the
> int meta class, you will need to load the default methods too... and one
> second is burnt.

The only way I see to avoid that is to not load the meta-class
until someone reference them so you can compile this example
to System.out.println(2) and if there is a ref to a meta-class somewhere,
discard the code and recompile it with meta-class check.

I do something like that in PHP.reboot but my unit of compilation
is the method and not the class, which also avoid to compile a
code you never use.

>
> bye Jochen
>

Rémi

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

Re: Process-level fork on OpenJDK...is it madness?

[Rémi Forax]

On 11/30/2011 12:10 AM, Jochen Theodorou wrote:
> Am 29.11.2011 23:34, schrieb Thomas Wuerthinger:
>> On 11/29/11 11:22 PM, Jochen Theodorou wrote:
>>> Am 29.11.2011 22:32, schrieb Mark Roos:
>>> [...]
 I just finished a paper (link below) on JVM startup time which states
 that for small programs its around
 70ms. So I assume there is some other startup time you are trying to
 improve? Or is the
 paper not applicable to the launching of a new process as you describe it?
>>> For the JVM itself that might be true, but in case of for example Groovy
>>> there is a lot if init work to be done before the first program can be
>>> executed. And this takes time.
>>>
>>> bye Jochen
>> What kind of initialization work is this? Could the result of that work
>> be cached?
> we have to setup the initial meta class system, which requires to use
> reflection to inspect some classes and other work. Yes, this could be
> cached, if we would know how.

It worth to give a try to java.lang.ClassValue, here.
You you be able to create your metaclass only when needed.

Also note that you can also lazyly initialize the list of methods,
fields etc. because even if two threads ask the same list at the
same time, the result will be the same, so there is no need
to use synchronized here.
(this is exactly what java.lang.Class code does) :

>
> bye Jochen
>

cheers,
Rémi

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

Re: Implementing a Smalltalk debugger with JSR292

[Rémi Forax]

On 11/27/2011 07:16 AM, Mark Roos wrote:
One of the key parts of Smalltalk is the 'live' debugger.  Unlike the 
general dynamic language features which
are well supported by the additions from JSR292 the debugger requires 
support which may not have been considered
as necessary to support dynamic languages.  So we were not sure we 
would be able to provide that portion

of the Smalltalk experience on the jvm.

The good news is that we were able to implement almost all of the 
Smalltalk debugger features using only the
services provided in the released jdk7.  I thought I would take a 
moment to describe how we  did it to both

demonstrate the approach and to solicit suggestions for improvements.

The Smalltalk debugger is 'live' in that it exists as a separate 
thread within the same process/memory space as the
thread being debugged.  This allows one to manipulate and inspect all 
objects from the same viewpoint as the
debugged thread.  Smalltalk offers the ability to inspect all 
instances of a class(type),  all references to a specific
object,  the variables on all levels of the stack, senders and 
implementers of methods, and the ability to single step
through method sends.  There is also the ability to restart a thread 
from any level of the stack but we opted to
wait on the coro patch before implementing this ( I also don't use it 
as it can have quite a few side effects ).


The approach we took has two facets, we ( mainly oscar ) coded a C++ 
jvmti agent with a JNI interface which allowed
us to call some JVMTI apis from within the jvm being debugged and we 
added some logic to the callsite to handle the

stepping.

Implementers and senders of methods is handled via reflection on the 
classes and methods present so that was easy.


To support all instances and all references requires heap inspection 
which we get from using the jvmti heap functions.
This had some issues with some of the support classes for invoke 
dynamic but we were able to use a two pass tagging
approach to make sure we found all of the references to our objects. 
 This has to find objects both in arrays and in

instance vars.

Inspecting the stack was straight forward once we filtered the stack 
trace to only have our method sends present.  As
an option one can also inspect the full jvm trace.   Using the jvmti 
variable access api allows the locating the variable
which is then placed into a static field of out debugger support 
class.  This field is then access by Smallltalk via a
primitive (in Smalltalk a primitive is the way we share with the 
underlying environment).  Once we have this object

we can manipulate its instance vars from the Smalltalk side as well.

When an error is thrown the thread is suspended ( we added some jvmti 
thread management apis just to get away
from the deprecated methods) and a new thread is launched with an 
instance of the debugger and a pointer to the
thread to debug.  At this point one can only inspect the thread locals 
and anything else in the object memory.  The

thread is not restartable so we kill it ( by sending ThreadDeath ).

But it the error is a halt or breakpoint we can then step the thread 
along.  We tried this with jvmti but is was broken
and seems to add quite a bit of delay to everything.  Plus its a 
callback approach which looked like a lot of work.  So
instead we tweaked the call site logic to add a debug check. I liked 
the way this worked a lot.


For a dynamic look up we already have a callsite with a target of one 
or more GWTs to select the implementation
which matches the receiver class.  What we have to do to implement a 
debugger is to place before the first GWT
a test which determines if this is the time to suspend.  Unfortunately 
GWTs are added to the end so we need a
way to keep the test at the beginning (thanks to John and Réme 
suggestion) we can simply have a callsite have a target which
is another callsite.  The first callsite points at the test logic and 
the second gets the GWT chain.  One nice thing

is that we can revert to the single site version using a debug flag.

The  code to get the initial target for the bootstrap callsite looks 
like:

*private**void*setBootstrapTarget(MethodHandle mh){
// get the appropriate initial call site sequence
*if*( RtDebugger./_debugEnable/){
// for debugging we need to have a sequence of methodHandles that is 
always the first
// code executed when a _callsite_ is invoked. This checks to see if 
we should

// hold here for a debug step or continue.
_realSite= *new*MutableCallSite(mh);  // this is the extra call site 
to hold the gwts

  MethodHandle invoker = _realSite.dynamicInvoker();
  MethodHandles.Lookup lookup=MethodHandles./lookup/();
  MethodHandle debugEntry= *null*;
  MethodType mt=MethodType./methodType/(*void*.*class*, 
RtObject.*class*);

*try*{
debugEntry = lookup.findStatic(RtDebugger.*class*, 
"debugEntry", mt);

  }
*catch*(Throwable e) {
e.printStackTrace();
  }
  

Re: OpenJDK 8 + lambdas build for OS X

[Rémi Forax]

On 11/17/2011 02:50 PM, Henri Gomez wrote:
>> So Lambda (&  Jigsaw) are in their own Projects with their own
>> hg forests. Note that Mike&  Maurizio synced up the lambda forest
>> with JDK 8 recently:
>> http://mail.openjdk.java.net/pipermail/lambda-dev/2011-November/004128.html
>> so creating such builds should be easier then before, but given that neither
>> Lambda nor the Mac Port are integrated into JDK 8, you'd have three fast
>> moving parts to deal with, so it wouldn't necessarily be trivial:
>> Just potentially a bit easier then a few weeks ago. ;)
> Any interest in having such 'labs/forest' available as package for OS/X users 
> ?
> If so, advices more than welcomed

Hi Henry,
I think having lambda + openjdk8 for Mac users will be cool,
like you have it on windows and linux.
http://jdk8.java.net/lambda/

As Dalibor said, you need to merge lambda workspace and MacPort workspace.

Rémi

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

Re: OpenJDK 8 + lambdas build for OS X

[Rémi Forax]

Hi Behrang,
the lambda workspace is not yet included in the master workspace of 
openjdk 8
because a lot of APIs/implementations are too young/too experimental.

Rémi

On 11/17/2011 01:31 PM, Behrang Saeedzadeh wrote:
> Hi all,
>
> I just grabbed the latest version of the OpenJDK 8 build from
> http://openjdk-osx-build.googlecode.com/files/OpenJDK-1.8-x86_64-b11-2012-release.dmg
> but it doesn't seem to contain the recent drop of lambdas, as I was
> unable to compile this simple Java class:
>
> public class Main {
>   
>   public static void main(String[] args) {
>   runMe(() ->  {});
>   }
>   
>   public static void runMe(Runnable r) {
>   r.run();
>   }
>
> }
>
> Or am I using an incorrect syntax? Or is it that the lambdas aren't
> still included in the builds provided by that Google Code project?
>
> Cheers,
> Behrang Saeedzadeh
> http://www.behrang.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: MutableCallSite + constant handle slower than field accesses?

[Rémi Forax]

On 10/17/2011 10:30 PM, Charles Oliver Nutter wrote:
> It seems like the natural solution! :) Invokedynamic is nothing
> without the handles wiring it up...so they should always live happily
> together in the land of fairies and unicorns.

no pony :(

>
> - Charlie

Rémi

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

Re: Mac+newest JDK changes?

[Rémi Forax]

On 10/14/2011 09:43 AM, Ola Bini wrote:
> Hi,
>
> I'm finally about to get back to hacking on Seph, specifically looking
> at performance - I would really like to be able to run the latest
> changes (things for u2 related to invoke dynamic) in MacOS X - what is
> the current status of this, and is it even possible at the moment?

I will answer with another question :)

What is the hotspot version of the JDK MacOS preview ?
http://jdk7.java.net/macportpreview/

>
> Cheers

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

Re: dyn.js - invokedynamic-based js implementation

[Rémi Forax]

On 10/13/2011 04:24 PM, Douglas Campos wrote:
> Remi,
>>> By example, for javascript Number, it should be a j.l.Double but with
>>> it's own vtable
> when you talk about having a vtable, you mean the "verified-entrypoint" 
> recipe from jsr292 cookbook? (or something into these lines)
>
> So I would be providing "more methods" to a j.l.Double, linking with static 
> methods via methodhandles?

yes, but the vtable of the VEP tailor its method handles in a very 
special way,
a vtable storing simple method handles is enough.

> cheers
> -- qmx

Rémi

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

Re: Google Dart

[Rémi Forax]

On 10/10/2011 08:58 PM, Charles Oliver Nutter wrote:
> I agree it would be an interesting language on the JVM. It may be the
> "dynamic Java" I've wanted to make for a long time, with the added
> bonus of optional static types.
>
> This could almost be a weekend project atop invokedynamic.

The type system is not that simple if you want to avoid
to do one cast for each assignation (and for each method call arguments).
I think you need one supplementary day :)

> - Charlie

Rémi

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

Re: dyn.js - invokedynamic-based js implementation

[Rémi Forax]

On 10/11/2011 12:22 AM, John Rose wrote:
> On Oct 10, 2011, at 7:12 AM, Douglas Campos wrote:
>
>> Hello mlvm friends, just a heads up that dyn.js is released at 
>> https://github.com/dynjs/dyn.js
>>
>> feedback is more than welcome :)
> Congratulations on getting this working...
>
> Nice, crunchy uses of invokedynamic, ASM, ANTLR, and dynalang.  Remarkable 
> leverage!
>
> -- John

If John plays the good guy, I will play the bad one :)

You should get rid of all the scope stuff for local variables.
One var in Javascript should be one local variable on the Java stack.
(if you only implement the strict mode of JavaScript 5, there is no 
problem).

For property, you should try to map them to Java field, you can use 
John's hidden class
or Nashorn double tables trick and avoid hashmaps.

You should also don't use you own hierarchy of classes but try to reuse 
j.l.Object,
j.l.String, etc and boolean, double, void where you can, by example
the condition of a if should be a boolean,  in x + 2, 2 should be a double.

I've some trouble to understand why your DynPrimitiveNumber is not a 
DynNumber
and the difference between a DynAtom and a DynObject.

DynObject.eq and DynObject.toBoolean should be implemented using 
invokedynamic
to adapt the sequence of if/instanceof to the callsite.

And at the end, all predefined Javascript objects should be re-written 
in Javascript,
with some native calls to Java but it will be easier for providing the 
core API.
By example, for javascript Number, it should be a j.l.Double but with 
it's own vtable
to add all Javascript predefined methods.
The idea is that j.l.Double and Javascript Number are the same object at 
runtime but
are seen differently in Java and in Javascript.

cheers,
Rémi

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

Re: Google Dart

[Rémi Forax]

On 10/11/2011 09:08 AM, Krystal Mok wrote:
Variance in Dart somehow bears a problem similar to the one in Java's 
array:

http://try-dart-lang.appspot.com/s/qAoU


The dartboard don't do any type checking at all.
But yes, reading the doc it seems that generics are covariant and 
contravariant.


Rémi



On Mon, Oct 10, 2011 at 4:02 PM, Rémi Forax <mailto:fo...@univ-mlv.fr>> wrote:


On 10/10/2011 09:51 AM, Marcus Lagergren wrote:
> FYI,
>
> Google Dart now has a twitter account :
> https://twitter.com/#!/dart_lang
<https://twitter.com/#%21/dart_lang>
> <https://twitter.com/#%21/dart_lang> and Website is up
> http://www.dartlang.org/
>
> /M

OMG, Dart is the next Java not the next Javascript !

Rémi

___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net <mailto: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