Martin Probst schrieb:
>> The more I think about it the more I am certain that I would not want
>> JVM to have an explicit tail call bytecode instruction
I agree here. The JIT should do that for us.
> The problem is that tail calls like Jon Harrop described them are
> often times not a simple performance optimization, but rather
> something the correctness of your program depends on.
let me tell you what I would like to have... then we can talk about if
that is a tail call optimization or not.
If I have a method f calling a method g and after calling g there will
be no more code to execute in f, then I call this a disposable stack
frame as soon as the call to g is made.
A possible optimization for a JIT would be now, to collect such
disposable stack frames as soon as the maximum number of frames is
reached or as soon as a frame is marked as disposable.
Now there are different tools on the JVM that expect a normal stack.
They use this to get a sender class or to perform lookups for policy
settings. And afaik that is the problem why the JVM can't do this kind
of optimization atm. That does not mean it can not do this at all, but
it is not easily done too.
There is also the compiler based version, but while the VM version could
do that optimization for every method call (any f that fulfills the
requirements calls any g of any class), a compiler based version usually
can only handle it if f and g are the same method. I learned this as
self recursive calls... you might know other words for this. So I think
the VM solution might be the most complete one, but the compiler based
solution actually works for most cases.
For example:
def findFirst(element, toFind) {
if (element==null) return null
if (element.value == toFind) return element
return findFirst(element.next, toFind)
}
This should show an example of iterating a list to find a certain
element with a certain value. This can be compiled as:
def findFirst(element, toFind) {
while (true)
if (element==null) return null
if (element.value == toFind) return element
element = element.next
}
}
well.. maybe that case is a bit too simple, but there are enough papers
out there describing how to compile these things.
And a dynamic language not working with actual method calls, but with
simulated ones has the advantage of being able to do the VM based
optimization at runtime.
> Like if you have Erlang-style actors that use tail recursion for their
> main loop, you need to guarantee that this loop is being tail-call
> optimized, otherwise your program won't work (= not be correct).
does that loop have to be like this? Couldn't they do an iterative version?
bye blackdrag
--
Jochen "blackdrag" Theodorou
The Groovy Project Tech Lead (http://groovy.codehaus.org)
http://blackdragsview.blogspot.com/
http://www.g2one.com/
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "JVM
Languages" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/jvm-languages?hl=en
-~----------~----~----~----~------~----~------~--~---
