thinking about proper implementation of tail calls

[BGB]

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 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.
>
in my case, I can't say exactly.

the most likely case I would think would be cases involving very large 
switch statements, or generating bytecode which implements similar 
constructions, or similar. I would not otherwise expect this to be a 
common occurrence, but I could be wrong.

mentioned previously off-list, but I can't say for certain how well this 
would work out:
a tweak could possibly be made to the JVM, such that a 'wide' prefix 
could be used with instructions with addresses (ifnull, ifeq, ...), and 
would then extend the address operands to 32 bits.

in the off-chance that a method wont fit in 64k, this would probably at 
least allow encoding the larger methods.
(nevermind any issues of making the VM itself support larger methods).


elsewhere the idea of breaking apart larger methods and jumping between 
them, but personally (from the POV of a casual/external observer) this 
looks a bit like an ugly hack.

I am not aware if there is any good way to allow larger methods in the 
class files, but then carve them up prior to feeding them into the JIT 
or similar, which could at least allow for cleaner-looking external 
interface.

nevermind if none of this will work.


> thanks
> mark
>
>
> _______________________________________________
> 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/7b569268/attachment.html