Re: thinking about proper implementation of tail calls

I added some implementation notes to the wiki page: https://wiki.openjdk.java.net/display/mlvm/TailCalls See the last section, "Stack walking and frame elision". Members of the JSR 292 EG may recall a conversation we had on this a few Summits ago. — John __

Re: thinking about proper implementation of tail calls

(Moving the tail call conversation forward a notch since last August.) A belated thanks to Rene Sugar for forwarding this link on tail calls and stack-based permission checking. On Feb 14, 2013, at 11:44 AM, Rene Sugar wrote: > > Regarding: > http://mail.openjdk.java.net/pipermail/mlvm-dev/20

Re: thinking about proper implementation of tail calls

It is dependant on the language. If the language paradigm is one of large methods or large non method like systems then you will get mega methods at the bytecode level. COBOL for example, can produce methods of arbitrary size because it does not naturally have a method based syntax. I would expect

Re: thinking about proper implementation of tail calls

nt this > today? > > thanks > mark > > > > From:Charles Oliver Nutter 'cvml', 'head...@headius.com');> > > > To:Da Vinci Machine Project > 'mlvm-dev@openjdk.java.net');> > > > Date:09/02/2012

Re: thinking about proper implementation of tail calls

Hi, Other than overcoming the limits of the size of the dispatch trampoline method, it is not clear to me what benefits for method splitting tail calls gives one. The challenges of method splitting are working out an appropriate size to which to split for maximum performance, processing nested and

Re: thinking about proper implementation of tail calls

Charles, I understand your challenge but it is not at all clear why tail calls would be required. They might be elegant but not necessary. Cheers - AJ On 2 September 2012 17:35, Charles Oliver Nutter wrote: > The classfile limit is only part of the problem. In JRuby we frequently > have larger

Re: thinking about proper implementation of tail calls

test case that John is looking for? by the way what do you use as the byte code size limit to prevent this today? thanks mark From: Charles Oliver Nutter To: Da Vinci Machine Project Date: 09/02/2012 09:37 AM Subject:Re: thinking about proper implementation of tail calls

Re: thinking about proper implementation of tail calls

On 9/1/2012 6:30 PM, Mark Roos wrote: I am looking to learn something here that I haven't seen in my code yet. John mentioned Suppose you are compiling your favorite high-level language to the JVM, and you start running into the various size limits in class files To which ther

Re: thinking about proper implementation of tail calls

The classfile limit is only part of the problem. In JRuby we frequently have larger Ruby methods fall over in the compilation process because Hotspot bails out on the whole thing. If we could easily break it up, we would at least get things to compile, even if they needed a CALL here and there to s

Re: thinking about proper implementation of tail calls

I am looking to learn something here that I haven't seen in my code yet. John mentioned Suppose you are compiling your favorite high-level language to the JVM, and you start running into the various size limits in class files To which there seemed to be some agreement that this

Re: thinking about proper implementation of tail calls

* Remi Forax: >> I would be surprised if tail calls give more flexibility. Usually >> it's the opposite, the mini-interpreter wins in terms of flexibility: >> >> > > This trick can work with a lexer because usually you don't keep states > between e

Re: thinking about proper implementation of tail calls

On 09/01/2012 01:26 PM, Florian Weimer wrote: > * John Rose: > >> As I recall, Doug Lea noted at the 2010 JVM Language Summit that >> tail calls would seem to allow work-stealing algorithms to be >> implemented somewhat more cleanly or efficiently. (How's that for >> tentative?) A worker thread g

Re: thinking about proper implementation of tail calls

* John Rose: > As I recall, Doug Lea noted at the 2010 JVM Language Summit that > tail calls would seem to allow work-stealing algorithms to be > implemented somewhat more cleanly or efficiently. (How's that for > tentative?) A worker thread goes from task to task in a data-driven > way, similar

Re: thinking about proper implementation of tail calls

Am 31.08.2012 02:39, schrieb John Rose: [...] > Suppose you are compiling your favorite high-level language to the > JVM, and you start running into the various size limits in class > files. (Usually they come from the 16-bit indexes in various > places.) What do you do, dear? (H/T to Maurice Se

Re: thinking about proper implementation of tail calls

An interesting idea! Comments below. On Thu, Aug 30, 2012 at 7:39 PM, John Rose wrote: > I have been looking for a "killer application" for tail calls on the JVM. > Doug's example may turn out to one. Here's another candidate: Overcoming > class file size limits. > > Suppose you are compilin

thinking about proper implementation of tail calls

I haven't given up on "hard tail calls" aka "proper implementation of tail calls". Other things are more pressing—as always, it seems. Here's a quick update, so we can mull this over as we look for an opportune time to warm up the project. Michael Haupt passed me this useful link to Guy Steel