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 <head...@headius.com>
To: Da Vinci Machine Project <mlvm-dev@openjdk.java.net>
Date: 09/02/2012 09:37 AM
Subject: Re: thinking about proper implementation of tail calls
Sent by: mlvm-dev-boun...@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" <mr...@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@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
