thinking about proper implementation of tail calls

[Mark Roos]

So then the issue is making the methods small enough for HotSpot to 
compile and not fall back to the interpreter.
If that is the case why not find the means to have Hotspot not do that? It 
seems that would be less effort than
adding hard tail calls to the jvm.  In other words is this really the 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 <headius at headius.com>
To:     Da Vinci Machine Project <mlvm-dev at openjdk.java.net>
Date:   09/02/2012 09:37 AM
Subject:        Re: thinking about proper implementation of tail calls
Sent by:        mlvm-dev-bounces at openjdk.java.net



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 stitch the bits together. But except for trivial cases (chaining 
along root statements) we need tail calls for this to work well.
- Charlie (mobile)
On Sep 1, 2012 6:31 PM, "Mark Roos" <mroos at roos.com> 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 there seemed to be some agreement that this was an issue. 
 Running over my Smalltalk 
code base my largest method is 12000 bytes with only about a dozen that 
are more than 
10k bytes.  The corresponding class file is 16k bytes ( I only do one 
method + blocks per class file) 

So my question is what is causing these mega methods.  Is it just an 
artifact of the language being 
implemented or is it from some language side optimization (such as trace 
optimization)?  Perhaps 
I am just lucky to not see it yet. 

thanks 
mark
_______________________________________________
mlvm-dev mailing list
mlvm-dev at openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
_______________________________________________
mlvm-dev mailing list
mlvm-dev at openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20120902/63b91d6c/attachment.html