Virtual Machine Meetup 2016 Program

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 t

Re: comment from James Gosling on multi-language VM

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 lan

Re: Truffle and mlvm

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 st

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

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 dif

Re: Truffle and mlvm

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 execu

Re: Truffle and mlvm

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 th

Re: Truffle and mlvm

14/06/groovy-android On 30 Aug 2014, at 22:36, Jochen Theodorou 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 >>

Re: Truffle and mlvm

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

Re: Truffle and mlvm

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 i

Re: Truffle and mlvm

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 techniq

Re: The Great Startup Problem

ny clarification on this would > be great. > > -Tom > > > > On Fri, Aug 29, 2014 at 1:24 PM, Thomas Wuerthinger > 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 Jav

Re: The Great Startup Problem

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 suppor

Re: The Great Startup Problem

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

Re: The Great Startup Problem

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 branc

Re: The Great Startup Problem

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

Re: The Great Startup Problem

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

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

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 hat geschrieben

Re: TaggedArrays (Proposal)

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 nigh

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

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 th

Re: Hotspot loves PHP.reboot / stack capturing exception

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 remainin

Re: Hotspot loves PHP.reboot / stack capturing exception

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

Re: Hotspot loves PHP.reboot / stack capturing exception

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

Re: Hotspot loves PHP.reboot

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

Re: Hotspot loves PHP.reboot

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 v

Re: Hotspot loves PHP.reboot

On 07.09.2011 22:38, John Rose wrote: > For example, at the Summit Remi pointed out an optimization problem > associated with this pattern: > > Object l0, l1, l2, ...; > l0 = l1 = l2 = ... null; // these are required only for definite > assignment in the catch body > try { > ...do fast

Re: Hotspot loves PHP.reboot

On 9/7/11 1:10 AM, John Rose wrote: That's true, except that exceptions tend to be imprecise: It's hard to tell which sub-expression cause the exception, out of a complex statement. Addressing both the precision and pre-allocation problems, you could ask the application to create the excep

Re: Status of Anno Class loader with constant patches?

> 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

Re: 答复: Enhanced HotSwapping

。 > > 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 en

Re: Enhanced HotSwapping

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 > wrote: >> The source code for t

Enhanced HotSwapping

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

Re: Hotswap patch?

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 n

Re: Hotswap patch?

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