thinking about proper implementation of tail calls

[Alexander Turner]

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 <headius at headius.com>wrote:

> 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/891c4e8f/attachment-0001.html