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 is now

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 no

Re: 答复: Enhanced HotSwapping

- 发件人: 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

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

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

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

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

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

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

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

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

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

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

Re: The Great Startup Problem

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

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

Re: Truffle and mlvm

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

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

Re: Truffle and mlvm

/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

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

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

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

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

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

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