Re: Hotswap patch?

[Thomas Wuerthinger]

 The design of the hotswap patch is described in the PDF linked from 
 this page:
   http://wikis.sun.com/display/mlvm/HotSwap

 I believe (under correction from you, Thomas!) that the patch is the 
 initial result of a research project that he did earlier this year at 
 JKU Linz, that he is now working on other things, and that he doesn't 
 have specific plans (yet) to extend it further.  See the message below.

 Thomas will be talking about this work at Sun on Wednesday, and InfoQ 
 will be taping the talk (like most of the talks at the Summit).
Yes - during the talk I will also outline future directions that I am 
currently considering and I would be happy about any kind of feedback!

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

Re: Hotswap patch?

[Thomas Wuerthinger]

Patrick Wright wrote:
  Thomas--is any special flag required to enable this when launching the
  JVM if I build MLVM with your changeset in it? Also, I assume that if
  classes are redefined we will eventually run into the standard
  problems of PermGen limits on loaded classes?

No, there is no special flag required to enable my hotswap code. When 
you apply the changeset to jdk7-b51, you swap the current hotswapping 
implementation with my version.

Yes, with frequent use of hotswapping the problem of a limited PermGen 
arises. Especially as currently the old classes are still kept in the 
system. A fix for this might be to remove old classes from the system if 
none of their methods are active or reachable from active methods (and 
this is true for all of their subclasses).

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

Re: 答复: Enhanced HotSwapping

[Thomas Wuerthinger]

The attached crash happend when using the standard HotSpot and not the
DCE VM. The version string says Java HotSpot(TM) Server VM and not
Dynamic Code Evolution 64-Bit Server VM, so it cannot be an issue
related to the DCE VM. Most likely the same applies to the first issue
(try to increase permanent generation size with for example
-XX:MaxPermSize=512m).

Please report bugs of the DCE VM at http://ssw.jku.at/dcevm/bugtracking/
as suggested in the crash dumps of the VM.

- thomas


On 12/22/2010 09:41 AM, 玄希 wrote:
 Hi, the HotSwap.patch is amazing work. We expressed regarding this is 
 excited。 We try it on windows for debug our application。
 But some errors happen。
 We use jre 1.6.0_23.
 1,when we load eclipse  eclipse often alert permgen OOM。
 2，when we load jboss，jboss often crash。The jvm erro message are in the 
 attachment。

 Would you tell me how to solve this。

 -邮件原件-
 发件人: mlvm-dev-boun...@openjdk.java.net 
 [mailto:mlvm-dev-boun...@openjdk.java.net] 代表 Thomas Wuerthinger
 发送时间: 2010年12月18日 19:16
 收件人: Da Vinci Machine Project
 主题: Re: Enhanced HotSwapping

 The enhanced hotswapping can be triggered using either the low-level
 JNI/JVMTI interface, class file transformers, or the JDWP debugger
 interface. There is no API change compared to the restricted hotswapping.

 We are currently working on providing a Java API too. In our
 implementation of dynamic mixins for Java
 (http://ssw.jku.at/dcevm/mixins/), we are using such a Java API to
 directly trigger the class redefinition from Java code. Our mixin
 implementation allows to dynamically add an interface and its
 implementation to an existing class.

 - thomas



 On 12/18/10 5:49 AM, Chanwit Kaewkasi wrote:
 Hello Thomas,

 It looks cool, and thank you for binaries.
 Is this working through the debugger interface or JVMTI agents?

 Regards,

 Chanwit

 On Sat, Dec 18, 2010 at 00:56, Thomas Wuerthinger
 thomas.wuerthin...@gmail.com  wrote:
 The source code for the HotSpot version that allows enhanced hotswapping
 (e.g., add and remove methods, fields, and super types) was just updated
 in the mlvm repository. There exists now also a light version of the
 modifications hotswaplight.patch that minimizes the difference to the
 current OpenJDK source code by omitting some of the more advanced
 features (e.g., method forwarding, calling deleted old methods,
 transformer methods). The enhanced VM passes all tests of Oracle's class
 redefinition test suite and comes with unit tests for the new features.

 There are binary builds available from http://ssw.jku.at/dcevm; for
 Mac, Linux, and Windows. So, feel free to install a VM with the new
 hotswapping capabilities on your machine and test them using your
 favorite Java IDE.

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

 This email (including any attachments) is confidential and may be legally 
 privileged. If you received this email in error, please delete it immediately 
 and do not copy it or use it for any purpose or disclose its contents to any 
 other person. Thank you.

 本电邮(包括任何附件)可能含有机密资料并受法律保护。如您不是正确的收件人，请您立即删除本邮件。请不要将本电邮进行复制并用作任何其他用途、或透露本邮件之内容。谢谢。


 ___
 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: Status of Anno Class loader with constant patches?

[Thomas Wuerthinger]

 In fact for hotspot, this kind of constant can be even more optimized
 than a static final field containing a non-primitive values which is 
 not a real constant
 (it can be modified by reflection).
I don't think final fields can be modified via reflection. An 
IllegalAccessException with the message field is final is thrown at 
the end of Reflection::resolve_field in reflection.cpp.

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

Re: Hotspot loves PHP.reboot

[Thomas Wuerthinger]

On 08.09.2011 21:47, John Rose wrote:

On Sep 8, 2011, at 4:57 AM, Thomas Wuerthinger wrote:


Why not the following code pattern? Does it generate too many bytecodes?


That's a reasonable alternative.

It generates data movement bytecodes O(L * M), where L is the average 
number of live values at deopt points and M is the number of deopt 
points.  The quadratic exponent on bytecode size bothers me, at least 
a little.


But with a specialized DeoptimizeException that automatically captures 
the values of the local variables and operand stack at the JVM-level (in 
fillInStackTrace), there would not be any data movement bytecodes at 
all. It would require a 1-1 correspondance between scripting language 
local variables and Java bytecode local variables, but would both be 
efficient to generate and performant at run time. The information could 
be captured for all stack frames between the throwing method and the 
catching method. Here an example for a scripting method that performs 
a+b and is guessed to not overflow.


Object add(int a, int b) {
   try {
 return fastPathAdd(a, b);
} catch(DeoptimizationException e) {
Integer local1 = e.getTopFrame().getLocalAt(0);
Integer local2 = e.getTopFrame().getLocalAt(1);
return slowPathAdd(local1, local2);
}
}

int fastPathAdd(int a, int b) {
   if (canOverflow(a, b)) throw new DeoptimizationException();
   return a + b;
}

Object slowPathAdd(Object a, Object b) {
  // ... generic add implementation ...
}


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

Re: Hotspot loves PHP.reboot

[Thomas Wuerthinger]

On 09.09.2011 01:21, John Rose wrote:

On Sep 8, 2011, at 4:06 PM, Thomas Wuerthinger wrote:

Here an example for a scripting method that performs a+b and is 
guessed to not overflow.


Your example is simplified by the fact that, in the handler, there is 
only one possible deopt point.  What if there are two?


E.g., what if your code is: add(a,b,c) := a+b+c .



The example could be any complex scripting function. So let's consider 
the following method:

function sumUp(n) {
var sum=0;
for (var i=0; in; ++i) sum += i;
return sum;
}

That would transform into:
int sumUpFastPath(int n) {
int sum = 0;
for (int i=0; in; i = safeAdd(i, 1)) sum = safeAdd(sum, i);
return sum;
}

int safeAdd(int a, int b) {
   if (addWouldOverflow(a, b)) throw new DeoptimizationException();
   return a + b;
}

The two deoptimization points are distinguished by the different Java 
bci at the calls to safeAdd. For each of those points, there must be a 
slow-path continuation. While generating the bytecodes for the method 
sumUpFastPath, one can also generate a mapping from 
exception-bci=slowpath-entry-point. Such a slowpath-entry-point could 
either be an interpreter loop method (started with the current locals 
and scripting code position) or a lazily generated generic OSR version 
of the scripting function.


So the code could look like:

Object sumUpGeneric(int n) {
try {
   return sumUpFastPath(n);
} catch(DeoptimizationException e) {
   StackFrame f = e.getStackFrame(sumUpFastPath);
   ScriptingPosition p = map.get(f.bci());
   return invokeInterpreter(sumUpMethod, p, f.getLocals(), 
f.getExpressionStack());

   }
}

The operand stack and locals manipulation in the generated bytecodes 
must exactly match the manipulations done by the scripting interpreter, 
but I think that it is possible to align those (although there might be 
some complexity due to the fact that certain value types require more 
than 1 stack slot). The safeAdd method could be intrinsified to 
deoptimize to the Java interpreter. So, in case an overflow occurs, 
there would be a two-level deoptimization: Java optimized code = Java 
interpreter (which now actually throws the DeoptimizationException) = 
Scripting language interpreter.


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

Re: Hotspot loves PHP.reboot / stack capturing exception

[Thomas Wuerthinger]

On 09.09.2011 03:00, John Rose wrote:

On Sep 8, 2011, at 5:35 PM, Thomas Wuerthinger wrote:

The operand stack and locals manipulation in the generated bytecodes 
must exactly match the manipulations done by the scripting 
interpreter, but I think that it is possible to align those (although 
there might be some complexity due to the fact that certain value 
types require more than 1 stack slot). The safeAdd method could be 
intrinsified to deoptimize to the Java interpreter. So, in case an 
overflow occurs, there would be a two-level deoptimization: Java 
optimized code = Java interpreter (which now actually throws the 
DeoptimizationException) = Scripting language interpreter.


Got it.  I had missed the meaning of your phrase at the JVM-level (in 
fillInStackTrace).  So the exception has an extra-heavy backtrace.

Yes, exactly.
The backtrace amounts to a JVM continuation.  Is there a way to do 
data hiding so that the language runtime can only see locals that it 
has a right to observe?
That IMO is the problem with rich backtraces:  They provide a very 
deep punch into the JVM, which can be exploited (like reflection) to 
break across trust boundaries.
I guess one answer is that we could trust language runtimes.  I'd 
rather find a more compartmentalized solution, hence my interest in 
patterns expressible in current bytecodes.
If this special exception class is declared as a checked exception, a 
method would itself chose if its stack is exposed or not based on its 
throws clause. I think in that case the possible exploitations are 
less than reflection (because it would not be possible to access data 
declared private, but only the stacks of methods that are explicitly 
declared accessible). That this is a first step towards continuation 
support would be a nice side effect of this solution.


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

Re: Hotspot loves PHP.reboot / stack capturing exception

[Thomas Wuerthinger]

On 13.09.2011 00:59, John Rose wrote:
 This exposes the question of liveness:  JVMs routinely nullify 
 non-live variables, but what if the only remaining use is the 
 getLocalArray intrinsic?  Shouldn't it count as a weak reference?  Or 
 will we allow it to reanimate all local values?  That would impose a 
 systemic cost on the register allocator, for the whole method.
I cannot think of a use case where nullifying non-live variables would 
be a problem.

 Now I want to back up to Thomas' specific suggestion.  Instead of 
 putting in a catch, suppose we use the throws clause of the method 
 to control local capture.  This is a clever way to have existing 
 metadata encode an intention to collect locals automagically, 
 without explicit bytecodes or handlers.  It requires an overloading of 
 the idea of throws, so it might be better to use a new attribute or 
 annotation.

 In any case, it seems to me that magic frame metadata which causes 
 fillInStackTrace (of selected Throwable types) to collect local values 
 is almost completely equivalent (modulo some simulation overhead) to 
 collecting the locals in each affected frame's handler.

 I say almost because the magic metadata can provide the local 
 information in unpopped frames, while the less magic method (which can 
 be done today) requires each dying frame to be popped, except perhaps 
 for the oldest, in order for the local values (and other state) to be 
 collected into the flying exception.
Yes. The simulation overhead in terms of additional bytecodes and 
local variable liveness is however possibly significant. Also, the 
try-catch solution does not work for capturing expression stack values. 
The special-exception solution would enable language implementors to 
generate more compact (and simpler) bytecode methods (e.g., they could 
use the Java expression stack as their own expression stack implementation).

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

Re: Hotspot loves PHP.reboot / stack capturing exception

[Thomas Wuerthinger]

On 9/14/11 10:20 PM, Tom Rodriguez wrote:
 On Sep 14, 2011, at 10:10 AM, Thomas Wuerthinger wrote:

 On 13.09.2011 00:59, John Rose wrote:
 This exposes the question of liveness:  JVMs routinely nullify
 non-live variables, but what if the only remaining use is the
 getLocalArray intrinsic?  Shouldn't it count as a weak reference?  Or
 will we allow it to reanimate all local values?  That would impose a
 systemic cost on the register allocator, for the whole method.
 I cannot think of a use case where nullifying non-live variables would
 be a problem.
 But I don't think the compiler knows which locals are live in this case since 
 the state is going to passed to some unknown piece of code.  Any JVMState 
 used by getLocalArray would have to treat all locals as live.

 tom
Yes, true, I guess the fast-path version of a scripting language method 
might leave out usages of locals that are necessary in the slow-path 
version. But one could maybe disable the local variable liveness maps 
for the methods that use this functionality (i.e., the extended 
exception stack trace or the getLocalArray)?

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

Re: TaggedArrays (Proposal)

[Thomas Wuerthinger]

Jim,

can you also make the native part (in particular the JNI implementation) 
available? We'd like to experiment with it in the context of the GraalVM 
repository.


Thx, thomas


On 02.07.2012 15:05, 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.


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.


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


I've enclosed a JavaDoc and the roughed out source.  For discussion. 
 Fire away.


Cheers,

-- Jim








___
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

AW:New Ruby impl based on PyPy...early perf numbers ahead of JRuby

[Thomas Wuerthinger]

Do you also have startup performance metrics - I assume the numbers below are 
about peak performance?

What is the  approximate % of language feature completeness of Topaz and do you 
think this aspect is relevant when comparing performance?

Thanks, thomas

 Charles Oliver Nutter head...@headius.com hat geschrieben: 

So, that new Ruby implementation I hinted at was announced this week.
It's called Topaz, and it's based on the RPython/PyPy toolchain.

It's still very early days, of course, since the vast majority of Ruby
core has not been implemented yet. But for the benchmarks it can run,
it usually beats JRuby + invokedynamic.

Some numbers...

Richards is 4-5x faster on Topaz than JRuby.

Red/black is a bit less than 2x faster on Topaz than the JRuby with
the old indy impl and a bit more than 2x faster than the JRuby with
the new impl.

Tak and fib are each about 10x faster on JRuby. Topaz's JIT is
probably not working right here, perhaps because the benchmarks are
deeply recursive.

Neural is a bit less than 2x faster on Topaz than on JRuby.

I had to do a lot of massaging to get these benchmarks to run due to
Topaz's very-incomplete core classes, but you can see where Topaz
could potentially give us a run for our money. In general, Topaz is
already faster than JRuby, and still implements most of the
difficult Ruby language features that usually hurt performance.

My current running theory for a lot of this performance is the fact
that the RPython/PyPy toolchain does a better job than Hotspot in two
areas:

* It is a tracing JIT, so I believe it's specializing code better. For
example, closures passed through a common piece of code appear to
still optimize as though they're monomorphic all the way. If we're
ever going to have closures (or lambdas) perform as well as they
should, closure-receiving methods need to be able to specialize.
* It does considerably better at escape detection than Hotspot's
current escape analysis. Topaz does *not* use tagged integers, and yet
numeric performance is easily 10x better than JRuby. This also plays
into closure performance.

Anyway, I thought I'd share these numbers, since they show we've got
more work to do to get JVM-based dynamic languages competitive with
purpose-built dynamic language VMs. I'm not really *worried* per se,
since raw language performance rarely translates into application
performance (app perf is much more heavily dependent on the
implementation of core classes, which are all Java code in JRuby and
close to irreducible, perf-wise), but I'd obviously like to see us
stay ahead of the game :-)

- 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: The Great Startup Problem

[Thomas Wuerthinger]

Charlie,

Truffle is such a general-purpose automatic specialization mechanism that works 
like you say via just writing Java code and without a need to use invokedynamic 
and without a need to dynamically generate bytecodes.

- thomas

On 25 Aug 2014, at 15:25, Charles Oliver Nutter head...@headius.com wrote:

 On Mon, Aug 25, 2014 at 6:59 AM, Fredrik Öhrström oehrstr...@gmail.com 
 wrote:
 Calle Wilund and I implemented such a indy/methodhandle solution for
 JRockit, so I know it works. You can see a demonstration here:
 http://medianetwork.oracle.com/video/player/589206011001 That
 implementations jump to C-code that performed the invoke call, no fancy
 optimizations. Though the interpreter implementation of invoke can be
 optimized as well, that was the first half of the talk is about. But its
 really not that important for speed, because the speed comes from inlining
 the invoke call chain as early as possible after detecting that an indy is
 hot.
 
 But can it work in C2? :-)
 
 My impression of C2 is that specialization isn't in the list of things
 it does well. If we had a general-purpose specialization mechanism in
 Hotspot, things would definitely be a *lot* easier. We might not even
 need indy...just write Java code that does all your MH translations
 and specialize it to the caller's call site.
 
 We can certainly get C2 to do these things for us...by generating a
 crapload of mostly-redundant bytecode. Oh wait...
 
 - 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: The Great Startup Problem

[Thomas Wuerthinger]

John,

Thanks for this detailed analysis on the current status and proposed future 
work for invokedynamic. Can you also add some comments on what you believe the 
advantages and disadvantages of using Truffle instead of invokedynamic for 
implementing dynamic languages on top of the JVM are?

- thomas

On 29 Aug 2014, at 05:48, John Rose john.r.r...@oracle.com wrote:

 On Aug 22, 2014, at 1:08 PM, Charles Oliver Nutter head...@headius.com 
 wrote:
 
 Marcus coaxed me into making a post about our indy issues. Our indy
 issues mostly surround startup and warmup time, so I'm making this a
 general post about startup and warmup.
 
 This is a vigorous and interesting discussion.  I will make some piecemeal 
 replies to
 specific points, but first, as a HotSpot team member, I'll comment on the 
 startup
 problem and then set out our position and vision for indy and dynamic 
 languages.
 
 Achilles had two heels, and so does Java:  Startup and warmup.  Many teams of 
 many
 people have worked on these issues for years, with hard-won progress.  
 Compared
 with C programs (say, /bin/awk), the JVM takes a long time to get going.
 
 Fundamentally this comes from the decision to package programs as bytecodes
 (JARs, etc.) rather than machine instructions plus mappable data (dylibs, 
 etc.).
 As everyone on this list knows and appreciates, Java bytecodes are a portable,
 stable, and compact intermediate representation for both code and data 
 structure.
 You can do an amazing variety of great things with them, and there is no 
 credible
 proposal (IMO) to replace them wholesale with some other representation.
 
 As an inherent property, bytecodes cannot be executed directly, requiring
 additional machinery to execute: an interpreter, JIT compiler, and/or AOT 
 engine.
 Making this machinery look small is an ongoing challenge for us JVM 
 implementors.
 I say ongoing (not just historic) because software complexity scales up 
 with time.
 
 Our basic move is organizing cold stuff differently from hot stuff.
 The C2 JIT spends lots of effort on the hot paths in hot methods.
 On the cold side, Java's class data sharing feature tries to organize large
 amounts of start-up bytecode in a form that can be quickly loaded and 
 discarded.
 The most useful distinctions between hot and cold data and code usually
 require some sort of online measurement, which is one reason Java is
 competitive with C++, which generally lacks behavior-dependent optimizations.
 
 Building on these basic considerations, an ideal Java implementation would
 quickly get through the start-up process quickly by executing cold code and/or
 loading pre-configured data structures, with the result that data which must 
 be
 configured by every JVM on startup, or by every invocation of a given 
 application,
 is quickly assembled.  This would be done in some cases by loading a
 pre-composed bitwise data image, or perhaps more efficiently by 
 decompressing
 an operationally encoded description of the initial data image by executing
 some sort of code.  In fact, that is what Java interpreters are pretty good 
 at,
 when augmented by a pre-composed class data archive that maps in
 a pre-parsed version of classes from rt.jar.  (Sometimes this image is
 found in a file called classes.jsa.)
 
 But if more of the initial state of a Java application could be demand-paged 
 from
 an image file (like the initial data of C programs) there might be less 
 latency,
 since there would certainly be fewer order constraints between the different
 loading events (at the page and cache line level), allowing prefetch machinery
 to hide latency.  This is an important area of growth for Java.
 
 Second, an ideal Java implementation would quickly discover the particular
 on-line characteristics of the application under execution, and produce
 tailor-made machine code for that execution, with the result that the
 application's critical inner loops would execute at full performance,
 almost immediately.  This would be done in some cases by capturing
 profile information from early phases of the application and applying them
 to the creation of customized code.  In fact, the profiling interpreter and
 tiered C1 JIT are pretty good at gathering such information, and
 feeding it to the C2 JIT.
 
 What's missing?  Probably a certain amount of prediction of behavior
 based on previous runs of the application, combined with a way of
 loading data and executing code that benefits from that prediction,
 even before the application has gotten that far.  To me that sounds
 like a static compiler of some sort, though an open-world kind that
 allows the compiler's model of the world to change during execution.
 
 Maybe another missing bit is a slightly more static initialization model
 for Java, under which the assembly of initial data can be predicted
 off-line with greater accuracy.  For starters, we should have array
 initializers that are more distinct from random bytecode execution,
 

Re: The Great Startup Problem

[Thomas Wuerthinger]

Yes. Truffle aims to become a production-quality system. A successful research 
project should ultimately also advance the state of the art of what is used in 
production. We are well beyond the initial exploration phase for Truffle and 
focusing currently on stabilisation. There is a Truffle branch in the JRuby 
open source base on github (more info here 
https://github.com/jruby/jruby/wiki/Truffle or here 
http://blog.jruby.org/2014/01/truffle_graal_high_performance_backend/). There 
are open source projects using Truffle that currently develop a prototype for R 
(https://bitbucket.org/allr/fastr), one for Python 
(https://bitbucket.org/ssllab/zippy), and one for Smalltalk 
(https://github.com/smarr/TruffleSOM). We are also working on JavaScript. This 
makes us confident that we can support a wide range of languages.

- thomas

On 29 Aug 2014, at 11:06, Patrick Wright pdoubl...@gmail.com wrote:

 Thomas,
 
 
 
 Thanks for this detailed analysis on the current status and proposed future 
 work for invokedynamic. Can you also add some comments on what you believe 
 the advantages and disadvantages of using Truffle instead of invokedynamic 
 for implementing dynamic languages on top of the JVM are?
 
 Along those lines, could you tell us if Truffle aims to be a 
 production-quality system?  I had thought - perhaps incorrectly - that it was 
 a kind of research project, like (as I understood it) the Maxine VM was a few 
 years ago. 
 
 Thanks!
 Patrick
 ___
 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 Great Startup Problem

[Thomas Wuerthinger]

We are happy to no longer discuss Truffle in this thread if you are looking for 
more short-term solutions and keeping the usage of invokedynamic as an 
invariant. I am confident that Truffle can reach production quality within 12 
months. People interested in Truffle can take a look at the Truffle API in the 
Graal repository and/or engage in the graal-...@openjdk.java.net mailing list.

- thomas

On 29 Aug 2014, at 13:35, Marcus Lagergren marcus.lagerg...@oracle.com wrote:

 I think this is an excellent summary, John. 
 
 I also think that a scary point Charlie and I were trying to make in this 
 thread is that we have = 12 months or so to slim down existing mechanisms to 
 something that works with startup for the existing indy solutions before 9 is 
 frozen. I think, given the time constraints, that there is no way doing this 
 by NOT working with the current compiler infrastructure. We already had some 
 nice ideas in Santa Clara this August.  I don’t think 12 months is enough 
 replace our entire indy architecture with something else entirely, or even to 
 decide what that would be. For the sake of this discussion I am ONLY wearing 
 my “lambda forms scale poorly, we need to fix that for nine” hat, which is a 
 very, very pragmatic hat indeed. I am ONLY wearing this hat. Again: ONLY THE 
 PRAGMATIC HAT. It contains very little architectural vision. 
 
 I’d totally welcome future dynamic language threads that discuss completely 
 new architectures, but it would be good if we could split this thread in more 
 then. I’m just trying to ship a product for Java 9 that works. While I am not 
 PM, 12 months is an incredibly short time to replace the entire world. I 
 don’t think it has ever been done and I don’t think it CAN be done. Even if 
 code exists. Sorry. Pragmatic hat.
 
 Another point, that I know Charlie has brought up earlier, is that we also 
 cannot abandon those who still target the JVM and seek value in a common 
 platform. At least not before bytecode 2.0, whatever that may entail. 
 Interesting discussion, but again - different thread I think. This means 
 bytecode land. This means indy. 
 
 So before we soar up into the cloud free architectural sky (in other 
 threads), can we use this one to discuss things like local escape analysis 
 around indys, maybe with cheating (knowing they are indys), local array 
 explosion, indy callsite layout and by appropriating what we can of Fredrik 
 Öhrström’s magic machine code hats? If this is not what you were after, 
 Charlie, do tell me. I believe you were. 
 
 I want make it absolutely clear, with no possibility of doubt, that I am 
 merely pragmatic right now, which is all I feel I can find the time to be in 
 the current timeframe. I need a near solution. Now. I am wearing blinkers. I 
 am looking straight ahead. The cruel master sits heavy on my saddle with a 
 backpack full of metaspace. I can’t, sadly, afford to live in any other world 
 than this at the moment. Right now, I first want to get rid of lambda form 
 scaling problems. Period. I am trying to ship product. After that we can 
 discuss where our wonderful architectures will take us.
 
 So if possible - let’s do one thing here: discuss what we can do for 9, in 
 the time frame that is left, to make indys go faster for the use cases that 
 have cropped up. With the current architecture. With lambda forms. With the 
 nearly identical problems that both Charlie and we face. Let a thousand other 
 threads start, discussing the rest, though. That is also great and exactly 
 what this group is for, but I need some help with C1/C2 and invokedynamic at 
 the moment! I need machine code rabbits! I think that machine code rabbits 
 were also what Charlie asked for.
 
 Regards
 Marcus
 
 (who is really happy to see MLVM-dev vibrant again, lately)
 
 On 29 Aug 2014, at 05:48, John Rose john.r.r...@oracle.com wrote:
 
 On Aug 22, 2014, at 1:08 PM, Charles Oliver Nutter head...@headius.com 
 wrote:
 
 Marcus coaxed me into making a post about our indy issues. Our indy
 issues mostly surround startup and warmup time, so I'm making this a
 general post about startup and warmup.
 
 This is a vigorous and interesting discussion.  I will make some piecemeal 
 replies to
 specific points, but first, as a HotSpot team member, I'll comment on the 
 startup
 problem and then set out our position and vision for indy and dynamic 
 languages.
 
 Achilles had two heels, and so does Java:  Startup and warmup.  Many teams 
 of many
 people have worked on these issues for years, with hard-won progress.  
 Compared
 with C programs (say, /bin/awk), the JVM takes a long time to get going.
 
 Fundamentally this comes from the decision to package programs as bytecodes
 (JARs, etc.) rather than machine instructions plus mappable data (dylibs, 
 etc.).
 As everyone on this list knows and appreciates, Java bytecodes are a 
 portable,
 stable, and compact intermediate representation for both code and data 
 structure.
 

Re: The Great Startup Problem

[Thomas Wuerthinger]

Thanks for your comment, Mark. Truffle is not at all meant as a replacement for 
Java or the JVM. We fully rely on regular and unmodified Java bytecodes for the 
definition of the Truffle guest language interpreters and on regular Java 
objects for the Truffle guest language object model. We support full Java 
interoperability. Think of it as nodes consisting of statically defined Java 
bytecodes that call each other. There are *no* runtime changes in HotSpot 
necessary - which is a fairly objective indicator that Truffle is arguably 
*closer* to the JVM as originally architected than invokedynamic, which needed 
so far a significant amount of HotSpot runtime changes with further runtime 
changes currently under discussion.

It is also not the case that Truffle and invokedynamic would be incompatible. 
You can use method handles and the invokedynamic bytecode like in every other 
Java program when defining your Truffle interpreters.

I would really be looking forward to hear solid technical arguments on why 
Truffle would somehow be such a dramatic architectural change to the JVM 
ecosystem. It is admittedly a change in thinking, because it demonstrates that 
the JVM functionality can be significantly enhanced without introducing new 
bytecode definitions.

Truffle indeed supports JITing C code on the fly. See Chris Seaton’s blog post 
on how this benefits native Ruby extensions a lot: 
http://www.chrisseaton.com/rubytruffle/pushing-pixels/. 

- thomas

On 29 Aug 2014, at 19:28, Mark Roos mr...@roos.com wrote:

 Thomas stated 
 A successful research project should ultimately also advance the 
 state 
 of the art of what is used in production. 
 
 Thomas one of the reasons many of us are building on the JVM is to take 
 advantage of the entire 
 universe of Java code available.  Truffle, to me at least, appears as a 
 replacement for Java and the 
 JVM not an addition.  Nice if ones goal is to make a new Smalltalk,  not so 
 nice if one wants a 
 Smalltalk DSL. 
 
 It would be interesting if Truffle could be used to create JNI like method 
 handles on the fly.  Then 
 I could do what I do today.  Today I find hot spots, write them in C, call 
 them with JNI.  The problem is that 
 JNI calls are not like hotspot jit code calls ( threads, safe point issues, 
 heap access etc).  I am hoping that 
 the Panama project makes a JNI call more like an intrinsic.  They I could use 
 the LLVM jit to do the 
 C  part on the fly.  Or actually it seems like Truffle could do this as well. 
  So Truffle as an add on would 
 be interesting,  it just has not been presented as such. 
 
 I think your research is very interesting.   
 
 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

Re: The Great Startup Problem

[Thomas Wuerthinger]

Truffle is an architecture based on AST interpreters. This means that immediate 
startup is as fast as it can get to load an AST interpreter written in Java 
into your VM and start executing it. Obviously, this heavily depends on fine 
engineering of the guest language runtime and interpreter (i.e., perform as 
much work lazy as possible), but has architectural advantages over a solution 
that needs to load a Java bytecode generator into the VM and load dynamically 
generated Java bytecodes before it can execute the first line of guest language 
code (in the Java interpreter). More importantly, if you support AOT for Java 
and use it for the AST interpreter and respectively the Java bytecode 
generator, the performance gap widens.

Warmup depends heavily on the speed of the JIT. In the current system, our JIT 
is written in Java and has therefore the architectural disadvantage that it 
needs to warmup as well. If AOT is available, this disadvantage disappears. 
There is no significant additional complication for the JIT when compiling 
Truffle trees compared to compiling method handle trees.

We will work on a comparison between JRuby with invokedynamic and JRuby using 
Truffle to show startup/warmup curves.

We have a separate research project at Oracle Labs called “SubstrateVM” that 
explores a low footprint and low startup option for Truffle guest language 
interpreters via AOT. It brings startup into the 10ms range and makes it 
therefore competitive with native VMs such as MRI or V8. Compared to 
Graal/Truffle, it is however in a far less complete state. We still think that 
this is going to be an interesting opportunity on the long run.

Btw, we will have a workshop on virtual machines at ETH Zurich on 11th and 12th 
of September where we will discuss compilation technologies. Anybody who is 
interested to join, please send me a private message.

- thomas

On 29 Aug 2014, at 20:33, Thomas E Enebo tom.en...@gmail.com wrote:

 I think I said two things at the same time and I apologize.  I am interested 
 in startup time and also warmup time.  Eventual performance looks great on 
 Chris's blogs...
 
 -Tom
 
 
 On Fri, Aug 29, 2014 at 1:29 PM, Thomas E Enebo tom.en...@gmail.com wrote:
 Thomas,
 
   I am very excited about RubyTruffle and Truffle/Graal in general but to 
 date I have never seen any numbers based on startup time?  From what I have 
 gleamed startup time is not a fundamental design goal currently.  I have 
 heard that some of these great numbers take many minutes to warm up.  Is 
 there any data on this?  In my mind it sounds like Truffle today might 
 actually warm up slower than invokedynamic.  Any clarification on this would 
 be great.
 
 -Tom
 
 
 
 On Fri, Aug 29, 2014 at 1:24 PM, Thomas Wuerthinger 
 thomas.wuerthin...@oracle.com wrote:
 Thanks for your comment, Mark. Truffle is not at all meant as a replacement 
 for Java or the JVM. We fully rely on regular and unmodified Java bytecodes 
 for the definition of the Truffle guest language interpreters and on regular 
 Java objects for the Truffle guest language object model. We support full 
 Java interoperability. Think of it as nodes consisting of statically defined 
 Java bytecodes that call each other. There are *no* runtime changes in 
 HotSpot necessary - which is a fairly objective indicator that Truffle is 
 arguably *closer* to the JVM as originally architected than invokedynamic, 
 which needed so far a significant amount of HotSpot runtime changes with 
 further runtime changes currently under discussion.
 
 It is also not the case that Truffle and invokedynamic would be incompatible. 
 You can use method handles and the invokedynamic bytecode like in every other 
 Java program when defining your Truffle interpreters.
 
 I would really be looking forward to hear solid technical arguments on why 
 Truffle would somehow be such a dramatic architectural change to the JVM 
 ecosystem. It is admittedly a change in thinking, because it demonstrates 
 that the JVM functionality can be significantly enhanced without introducing 
 new bytecode definitions.
 
 Truffle indeed supports JITing C code on the fly. See Chris Seaton’s blog 
 post on how this benefits native Ruby extensions a lot: 
 http://www.chrisseaton.com/rubytruffle/pushing-pixels/. 
 
 - thomas
 
 On 29 Aug 2014, at 19:28, Mark Roos mr...@roos.com wrote:
 
 Thomas stated 
 A successful research project should ultimately also advance the 
 state 
 of the art of what is used in production. 
 
 Thomas one of the reasons many of us are building on the JVM is to take 
 advantage of the entire 
 universe of Java code available.  Truffle, to me at least, appears as a 
 replacement for Java and the 
 JVM not an addition.  Nice if ones goal is to make a new Smalltalk,  not so 
 nice if one wants a 
 Smalltalk DSL. 
 
 It would be interesting if Truffle could be used to create JNI like method 
 handles on the fly.  Then 
 I could do what I do today.  Today I

Re: Truffle and mlvm

[Thomas Wuerthinger]

Mark,

It is possible to use Truffle for parts of the functionality of your language 
while the language itself is implemented with a bytecode generation approach 
(e.g., native extensions or regular expressions). Overall, I still believe that 
sometimes a larger step is needed when current techniques start to reach local 
maxima. 

Regards, thomas

On 29 Aug 2014, at 22:59, Mark Roos mr...@roos.com wrote:

 Moving from the startup thread. 
 
 Thomas has been wondering why using Truffle as a solution is not getting 
 immediate 
 traction.  I was initially, and continue to be, quite interested in Truffle.  
 So how could 
 Truffle help out us non Java on the JVM developers to the point where we 
 could be a 
 driving force behind it.  First note that myself and I would guess all 
 language implementers 
 ( as compared to researchers ) are like Marcus, very pragmatic.  Small 
 changes are welcome 
 but wholesale ones are seen as a barrier.  So to use Truffle I would want to 
 see it as an 
 addition to the jvm which addresses one of my specific issues. 
 
 The issue that I have where the solution is not evident is in the creation of 
 primitive 
 methods.  A primitive method in Smalltalk takes the arguments and some 
 constants 
 and executes object code to deliver the result.  Traditionally written C or 
 assembler 
 I now use Java and JNI.  Since we have the equivalent to value types (wrapped 
 byte[]) 
 primitives can be quite important for our vector math ops performance. 
 
 What would be very nice would be to attach a truffle.jar, pass it some data 
 structure 
 which defines a primitive and get back a method handle wrapping some 
 optimized object code. 
 Given that this MH comes from a known source perhaps the jni like overhead 
 could 
 be much reduced similar to an intrinsic. 
 
 This would be much simpler, I would guess, then the Panama effort to wrap 
 arbitrary code. 
 Plus I would not have to have a pre made object file per external 
 environment. 
 
 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

Re: Truffle and mlvm

[Thomas Wuerthinger]

Jochen,

Yes, interpreter based languages are easier to migrate. It is possible to 
simulate invokedynamic and the method handle chain with Truffle trees. 
Unfortunately, I do not expect this to mitigate the issues of the invokedynamic 
architecture that people have been discussing here. The best tutorial for such 
a migration is to watch our ongoing efforts to make JRuby run with Truffle 
(https://github.com/jruby/jruby/wiki/Truffle). We are going to significantly 
increase our contributions to this open source project. This will also allow 
more meaningful comparisons in the future.

Regarding environments supported by Truffle: Truffle interpreters are regular 
Java programs and therefore run on any JVM. For backwards compatibility, it is 
possible to build a Truffle backend that automatically generates bytecodes.

Regarding the requirement for change: Yes, it is true that adapting to a new 
API requires changes. Changing the compiler and/or the interpreter is however 
happening regularly in larger language implementation projects (e.g., the new 
IR backend for JRuby). This change in the API is required, because it gives you 
the main advantage.

I do *not* believe that the problems with invokedynamic are due to a poor 
implementation by the HotSpot engineers. I also do *not* believe they are due 
to a poor job by the language implementors. They are due to the chosen API 
*between* HotSpot and language implementors.

- thomas

On 30 Aug 2014, at 09:32, Jochen Theodorou blackd...@gmx.org wrote:

 
 Thomas, for me the most easy target for truffle are interpreter based 
 languages.
 
 What would be really nice is to have some kind of migration tutorial, which 
 shows the steps involving the transformation of a bytecode producing runtime 
 to truffle. Almost all language implementors using invokedynamic should fall 
 in this category, unless they have an interpreter ready as well. So the 
 obvious target for that would be kind of an invokedynamic replacement.
 
 But I strongly assume, that the strengths of truffle can't be played out like 
 this. That's what it makes an implementation approach wall. And then there is 
 the problem that you may have to support environments without truffle.
 
 bye Jochen
 
 
 Am 30.08.2014 06:15, schrieb Thomas Wuerthinger:
 Mark,
 
 It is possible to use Truffle for parts of the functionality of your
 language while the language itself is implemented with a bytecode
 generation approach (e.g., native extensions or regular expressions).
 Overall, I still believe that sometimes a larger step is needed when
 current techniques start to reach local maxima.
 
 Regards, thomas
 
 On 29 Aug 2014, at 22:59, Mark Roos mr...@roos.com
 mailto:mr...@roos.com wrote:
 
 Moving from the startup thread.
 
 Thomas has been wondering why using Truffle as a solution is not
 getting immediate
 traction.  I was initially, and continue to be, quite interested in
 Truffle.  So how could
 Truffle help out us non Java on the JVM developers to the point where
 we could be a
 driving force behind it.  First note that myself and I would guess all
 language implementers
 ( as compared to researchers ) are like Marcus, very pragmatic.  Small
 changes are welcome
 but wholesale ones are seen as a barrier.  So to use Truffle I would
 want to see it as an
 addition to the jvm which addresses one of my specific issues.
 
 The issue that I have where the solution is not evident is in the
 creation of primitive
 methods.  A primitive method in Smalltalk takes the arguments and some
 constants
 and executes object code to deliver the result.  Traditionally written
 C or assembler
 I now use Java and JNI.  Since we have the equivalent to value types
 (wrapped byte[])
 primitives can be quite important for our vector math ops performance.
 
 What would be very nice would be to attach a truffle.jar, pass it some
 data structure
 which defines a primitive and get back a method handle wrapping some
 optimized object code.
 Given that this MH comes from a known source perhaps the jni like
 overhead could
 be much reduced similar to an intrinsic.
 
 This would be much simpler, I would guess, then the Panama effort to
 wrap arbitrary code.
 Plus I would not have to have a pre made object file per external
 environment.
 
 regards
 mark___
 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
 
 
 
 -- 
 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

Re: Truffle and mlvm

[Thomas Wuerthinger]

Thanks a lot, Charlie, for this very detailed feedback! In fact, this is 
probably the most comprehensive feedback we’ve received for Truffle so far :).

There are some valid points, some points where I’d like to add a comment, and 
some where Graal and Truffle may have been misunderstood. I’ll try to address 
them in a similarly structured form:

Regarding disadvantage 1 “AST is not enough”:
A. Yes, you need to provide specialisations for your operations for better 
performance. This makes it harder to implement a Truffle AST interpreter than a 
simple AST interpreter. It has however the advantage that it gives you more 
predictable performance for the different usages of your dynamic language 
operation. We are currently working on source code visualisations for Truffle 
ASTs so that users can see what nodes are specialised and to what types.
B. Yes, it is necessary to store your local variables in a Truffle frame 
object. This object can however contain pointers to arbitrary extra data 
necessary for your guest language.
C. We did a lot of improvements to Truffle, Graal, and also TruffleRuby since 
January. Inlining works without any problems and independent of the guest 
language, also in TruffleRuby.

Regarding disadvantage 2 “Long startup and warmup times”:
The benefit of the system is absolutely *not* lost when the compiler (Graal) 
and the Truffle guest language interpreter are AOT compiled. It gives you 
decent startup and high peak. The interpreter is immediately available in 
highly optimized machine code. Hot guest language methods are dynamically 
compiled to machine code by the precompiled Graal.

Regarding disadvantage 3 “Limited concurrency”:
There is no deeper reason why TruffleRuby is single threaded right now. For 
sure none that has to do with the fundamentals of the Truffle approach. We are 
planning to support 100% multi-threading also in TruffleRuby. One of the 
explorations we are currently doing is to support guest language level 
safepoints such that guest language developers themselves can easier deal with 
concurrency without compromising any peak performance.

Regarding disadvantage 4 “Limited availability”:
Yes, this is indeed a chicken and egg problem. Truffle is however not as 
closely tied to Graal as you suggest here. I believe that it is fairly 
straightforward to create a Truffle front-end for C2 (or any other compiler 
supporting deoptimization). There are only 3k LOC in Graal that are specific to 
Truffle. I think that they could be ported in a reasonable time frame. The 
Truffle interpreters themselves run on any Java system even if it has only very 
limited features - this is actually an advantage over a pure bytecode 
generation approach. They can also be AOT compiled for devices that do not 
support a full JVM and have strong footprint requirements. This would of course 
be slower execution than in a full fledged VM, but it would at least run 
correctly. I furthermore think that it is possible to do the Truffle partial 
evaluation via bytecode generation for backwards compatibility.

Regarding disadvantage 5 Unclear benefits for real-world applications”:
This kind of argument can hardly be countered before a system is 100% finished 
and shipped. The term “real world” is also somewhat loosely defined. I would 
very much support the development of a JRuby benchmark suite that tries to 
reflect “real world” as close as possible.
There is absolutely no reason to believe that a Truffle-based Ruby 
implementation would not have benefits for “real-world applications”. Or that 
it would not be able to run a large application for a long time. It is clear 
that the TruffleRuby prototype needs more completeness work both at the 
language and the library level. We are very happy with the results we got so 
far with Chris working for about a year. We are planning to increase the number 
of people working on this, and would also be grateful for any help we can get 
from the Ruby community.

Regarding Graal:  Did you ever try to benchmark JRuby without Truffle with the 
latest Graal binaries available at http://lafo.ssw.uni-linz.ac.at/builds/? We 
would be looking forward to see the peak performance results on a couple of 
workloads. We are not speculating about Graal becoming part of a particular 
OpenJDK release (as experimental or regular option). This is the sovereign 
decision of the OpenJDK community. All we can do is to demonstrate and inform 
about Graal’s performance and stability.

We recognise that there is a long road ahead. But in particular in this 
context, I would like to emphasize that we are looking for more people to 
support this effort for a new language implementation platform. I strongly 
believe that Truffle is the best currently available vehicle to make Ruby 
competitive in terms of performance with node.js. We are happy to try to 
*prove* you wrong - even happier about support of any kind along the road ;). I 
am also looking forward to continue this 

Re: Truffle and mlvm

[Thomas Wuerthinger]

Jochen,

While it is possible to build such a backend for backwards compatibility, we 
have not yet done so. Truffle AST interpreters can run on Android. They run 
several factors faster than regular AST interpreters as the rewriting and 
type-specialisation helps significantly (see Figure 13 in [1]). They come with 
an annotation-based DSL that makes writing specialisations easier (see Figure 9 
in [2]).

I believe it is technically possible to also support the partial evaluation 
(and therefore high performance) on Android, but whether this might happen is a 
question more to ask the Android community or Google. I am not aware that JRuby 
with invokedynamic or Nashorn would run on Android. If so, I would be 
interested to see the performance numbers. From experiences of porting Groovy 
to Android [3]: It should be known that using dynamic code should be limited 
to non CPU intensive parts of the application, since it involves reflection.”

It is possible to gradually use Truffle only for specific parts (e.g., regular 
expressions, FFI, only for performance-critical guest language methods). Within 
one guest language method, it is however not beneficial to mix Truffle with 
bytecode generation, because it increases complexity and will not provide you 
the main benefits.

- thomas

[1] 
http://lafo.ssw.uni-linz.ac.at/papers/2012_DLS_SelfOptimizingASTInterpreters.pdf
[2] http://lafo.ssw.uni-linz.ac.at/papers/2014_GPCE_TruffleDSL.pdf
[3] http://www.infoq.com/news/2014/06/groovy-android

On 30 Aug 2014, at 22:36, Jochen Theodorou blackd...@gmx.org wrote:

 Am 30.08.2014 14:20, schrieb Thomas Wuerthinger:
 [...]
 Regarding environments supported by Truffle: Truffle interpreters are
 regular Java programs and therefore run on any JVM. For backwards
 compatibility, it is possible to build a Truffle backend that
 automatically generates bytecodes.
 
 can you point me to some documentation for that bytecode generation backend? 
 Also... can I make a something with truffle that will run on android? Not 
 exactly a JVM, I know.
 
 Regarding the requirement for change: Yes, it is true that adapting to a
 new API requires changes. Changing the compiler and/or the interpreter
 is however happening regularly in larger language implementation
 projects (e.g., the new IR backend for JRuby). This change in the API is
 required, because it gives you the main advantage.
 
 sure, the problem is more if you can do this change gradual or if you have to 
 do it all at once. For example, if you could still write your bytecode and 
 choose to only replace some method calls with truffle parts, that would help 
 very much
 
 I do *not* believe that the problems with invokedynamic are due to a
 poor implementation by the HotSpot engineers. I also do *not* believe
 they are due to a poor job by the language implementors. They are due to
 the chosen API *between* HotSpot and language implementors.
 
 I really really hope that I didn't say anything that sounded like that. If 
 somebody understood it like that, then I appologize. That was not intended. 
 It's just new.
 
 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: Truffle and mlvm

[Thomas Wuerthinger]

Mark,

The reasons for the various projects building language implementations on top 
of Truffle (Ruby, JavaScript, Python, R, Smalltalk) are very similar to the 
motivations behind other language projects on top of the JVM like Jython, 
JRuby, or your own project of implementing a Smalltalk for the JVM. One 
additional motivation is a strong focus on guest language interoperability [1] 
in addition to Java interoperability. We do not plan to invent any new 
languages. I believe PyPy is a successful project.

We fully understand the challenges behind completeness. We will put a main 
focus in this respect on TruffleRuby. The vast amount of work the JRuby team 
has already done in this respect helps there a lot.

It is accurate that Graal has an HSA and a PTX GPU backend - its relationship 
to Project Sumatra is however currently unclear to us. We will enable usage of 
these backends from Truffle languages in the future.

- thomas

[1] 
http://2014.splashcon.org/event/splash2014-ds-high-performance-language-interoperability-in-multi-language-runtimes___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

Re: Truffle and mlvm

[Thomas Wuerthinger]

Mark,

Yes, I understand that changes always bring both technical challenges and 
unfortunately as you mention also political ones. Truffle offers an incremental 
option (see details in Chris’ mail). It in particular also works exactly like 
you describe below: It is a Java library that makes executing Truffle AST 
(which are pure Java programs) fast. Truffle language implementations can 
gracefully interact with *all* programs on top of the JVM, including language 
implementations that dynamically generate bytecodes.

- thomas

On 31 Aug 2014, at 22:54, Mark Roos mr...@roos.com wrote:

 --PURE OPINION--- 
 Thomas 
 you state: 
 
 Overall, I still believe that sometimes a larger step is needed when 
 current 
 techniques start to reach local maxima. 
 
 Which, as you mention in other posts, only time will tell if your beliefs are 
 correct. 
 I have learned that when proposing such sweeping change that it works better 
 to 
 offer it in smaller bites.  Most of us to not have the luxury of starting 
 over just to 
 try an option however appealing. 
 
 As I and others have posted, a library plus changes to hotspot allowing 
 custom 
 method compilation to object code would be an interesting option.  Low risk 
 with 
 potential high rewards.  Not to mention politically easier. 
 
 in any case keep up the good work 
 mark 
 
 ___
 mlvm-dev mailing list
 mlvm-dev@openjdk.java.net
 http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

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

Re: [9] RFR (L): 8057042: LambdaFormEditor: derive new LFs from a base LF

[Thomas Wuerthinger]

This is why Graal’s inlining heuristics are not based on the number of 
bytecodes, but the complexity of the compiler graph after applying 
canonicalisation. Adding asserts to the bytecodes should not influence peak 
performance when they are disabled. Same for expressing the same logic with a 
different number of bytecodes.

- thomas

On 05 Sep 2014, at 08:59, Remi Forax fo...@univ-mlv.fr wrote:

 
 On 09/03/2014 07:46 PM, John Rose wrote:
 On Sep 3, 2014, at 10:35 AM, Mark Roos mr...@roos.com wrote:
 
 From Morris
 
 All that assert laden code is nice to see.
 
 I just finished watching a video from Doug Lea where he mentioned that 
 having asserts can
 inhibit inlining due to the additional byte codes.  So he sadly does not 
 use them due to
 performance issues.
 
 Does anyone have any insights on this?
 Yep.
 
 http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-August/028450.html
 https://bugs.openjdk.java.net/browse/JDK-6316156
 
 yes, sadly, it's sometimes a real problem, here is a thread on core-lib [1] 
 about removing an assert in Integer.valueOf that allow JDart to have 
 acceptable perf.
 
 
 — John
 
 Rémi
 
 [1] 
 http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-April/010007.html
 
 ___
 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: Truffle and mlvm

[Thomas Wuerthinger]

Welcome to the team of compiler wizardry students at JKU Linz! Reading through 
all the productisation concerns and adoption issues in this thread is probably 
not a good starting point for your PhD. Thinking primarily about opportunities 
and blinding out problems is the only way to make larger steps forward without 
getting distracted. Enjoy the time while you have the privilege to do so :).

- thomas


On 02 Oct 2014, at 07:26, Benoit Daloze erego...@gmail.com wrote:

 I plan to work on concurrency in Truffle during my PhD in Linz.
 Making Truffle thread-safe is a priority and some work is already done for 
 AST replacements.
 I am also interested in supporting different concurrency primitives such as 
 threads and fibers for the guest languages.
  
 Benoit

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

Re: comment from James Gosling on multi-language VM

[Thomas Wuerthinger]

C actually runs very well on the JVM using Java bytecodes as shown by work of 
Matthias Grimmer [1]. This includes interoperability with other languages 
running on top of the JVM like JavaScript [2]. Current direction of this work 
is to extend to LLVM for expanding the support of AOT compiled languages beyond 
C. Also, the work includes a safe execution mode that runs C with security 
guarantees.

The coroutine [3] and continuation [4] work of Lukas Stadler demonstrates 
efficient implementations of those concepts on the JVM as well.

Another major aspect that has changed since 1995 are the advancements in the 
area of escape analysis and partial escape analysis to avoid object allocations 
[5, 6]. This makes modelling numbers as classes a lot more efficient and indeed 
enables the optimization of the calculations into “direct machine instructions” 
even when a lot of temporarily boxed objects are involved.

- thomas

[1] http://dl.acm.org/authorize.cfm?key=N96093 
http://dl.acm.org/authorize.cfm?key=N96093
[2] http://dl.acm.org/authorize.cfm?key=N96005 
http://dl.acm.org/authorize.cfm?key=N96005
[3] http://ssw.jku.at/Research/Papers/Stadler11Master/Stadler11Master.pdf 
http://ssw.jku.at/Research/Papers/Stadler11Master/Stadler11Master.pdf
[4] http://ssw.jku.at/Research/Papers/Stadler09/Stadler09a.pdf 
http://ssw.jku.at/Research/Papers/Stadler09/Stadler09a.pdf
[5] http://ssw.jku.at/Research/Papers/Stadler14/Stadler2014-CGO-PEA.pdf 
http://ssw.jku.at/Research/Papers/Stadler14/Stadler2014-CGO-PEA.pdf
[6] http://ssw.jku.at/Research/Papers/Stadler14PhD/ 
http://ssw.jku.at/Research/Papers/Stadler14PhD/


 On 17 Apr 2015, at 01:19, John Rose john.r.r...@oracle.com wrote:
 
 James made some relevant comments on the JVM as a multi-language engine.
 
 It was just a little while ago, as I noticed going through some old files.
 
 Folks are still working on specialized allocation (aka. value types) and 
 continuations (aka. coroutines  tailcall).
 
 Also, C is no longer right out; see Project Panama.
 
 — John
 
 From: owner-hotjava-interest-dig...@java.sun.com
 To: hotjava-interest-dig...@java.sun.com
 Subject:   hotjava-interest-digest V1 #24
 Date: Sat, 1 Apr 1995 17:34:17 -0800
 Reply-To: hotjava-inter...@java.sun.com
 X-Info: To unsubscribe, send 'unsubscribe' to 
 hotjava-interest-digest-requ...@java.sun.com
 
 hotjava-interest-digestSunday, 2 April 1995Volume 01 : Number 
 024
 
 
 --
 
 From: rich...@cogsci.ed.ac.uk
 Date: Fri, 31 Mar 95 13:30:04 BST
 Subject: How general is the Java bytecode language?
 
 Has anyone looked at the possibility of compiling languages other than
 Java to the Java bytecodes?  In particular, there seem to be many people
 interested in using Scheme as a scripting language, and the ability
 to download Scheme programs into HotJava would be nice.
 
 - -- Richard
 
 --
 ...
 
 --
 
 
 From: j...@scndprsn.eng.sun.com (James Gosling)
 Date: Fri, 31 Mar 1995 20:34:24 +0800
 Subject: Re: How general is the Java bytecode language?
 
 Has anyone looked at the possibility of compiling languages other than
 Java to the Java bytecodes?  In particular, there seem to be many people
 interested in using Scheme as a scripting language, and the ability
 to download Scheme programs into HotJava would be nice.
 
 It's reasonably general, although the security restrictions make some
 languages hard.  C and C++ with general pointer arithmetic are right
 out.  Fortran's pass-by-reference call semantics and common are
 tough.  Pascal is pretty straightforward.  Scheme is easy or hard,
 depending on how good you want the performance to be: the invocation
 model in Java is very C like with no provision for continuations.
 Continuations can be handled as classes  the key trick in a compiler
 would be to decide when a full-blown continuation can be optimized
 away.  The story is similar with datatypes like numbers: in general,
 every number would be an instance of some class  the trick is to
 optimize that into direct machine instructions.  Using the Java
 bytecodes is likely to be somewhat less than optimal because things
 like continuations and general numbers need to be done as classes, the
 underlying engine doesn't have things like specialized allocators for
 boxed integers.
 
 
 Note to Sun employees: this is an EXTERNAL mailing list!
 Info: send 'help' to hotjava-interest-requ...@java.sun.com
 
 ___
 mlvm-dev mailing list
 mlvm-dev@openjdk.java.net
 http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

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

Virtual Machine Meetup 2016 Program

[Thomas Wuerthinger]

The program of the 3rd Virtual Machine Meetup 2016 in Lugano (Switzerland) is 
now online available at http://vmmeetup.github.io/2016/ 
. Topics include the Shenandoah GC, the new 
Scala compiler Dotty, the Graal JIT compiler, execution of LLVM-based languages 
on the JVM, hardware acceleration techniques, and more.

The event is on the 1st and 2nd of September. Registration is free of charge 
and open until 27th of July.

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