Ship it!
On Fri, Dec 18, 2009 at 1:18 PM, Rémi Forax fo...@univ-mlv.fr wrote:
I've written an entry on how to enable tail call on JVM:
http://weblogs.java.net/blog/forax/archive/2009/12/18/tailcall-anyone
I have do some tests and it works very well :)
Rémi
--
You received this message
Le 18 déc. 2009 à 20:18, Rémi Forax a écrit :
I've written an entry on how to enable tail call on JVM:
http://weblogs.java.net/blog/forax/archive/2009/12/18/tailcall-anyone
I have do some tests and it works very well :)
Great piece of news !
Sorry to ask such a naive question, but why is
Sorry to ask such a naive question, but why is it the responsibility
of the bytecode emitter to mark a call as tail ?
It seems fairly easy for HotSpot to decide whether a call is tail or not.
Does this mean that some language implementers would like to have
their calls unoptimized even when
Le 18 déc. 2009 à 21:01, Patrick Wright a écrit :
Sorry to ask such a naive question, but why is it the responsibility
of the bytecode emitter to mark a call as tail ?
It seems fairly easy for HotSpot to decide whether a call is tail or not.
Does this mean that some language implementers
On 12/18/2009 12:22 PM, fo...@x9c.fr wrote:
While ensuring that the optimization is actually performed is very important,
it seems to be a novelty in the JVM: to the best of my knowledge, there is no
other way to guarantee that any optimization will actually occur.
Is this correct ?
Tail-call
On Fri, Dec 18, 2009 at 3:28 PM, Per Bothner p...@bothner.com wrote:
Tail-call optimization is not a pure optimization, as it changes the
semantics in a fundamental way: It removes stack traces, which are
part of both observable behaviour (stack traces) and the Java security
architecture.
Le 18 déc. 2009 à 22:46, John Cowan a écrit :
On Fri, Dec 18, 2009 at 3:28 PM, Per Bothner p...@bothner.com wrote:
Tail-call optimization is not a pure optimization, as it changes the
semantics in a fundamental way: It removes stack traces, which are
part of both observable behaviour
On Fri, Dec 18, 2009 at 6:21 PM, fo...@x9c.fr fo...@x9c.fr wrote:
I do wholeheartedly agree ; indeed for (direct) tail recursion, we need
nothing new: a goto with the first instruction of the method as the
destination
does the trick.
Unless you are generating Java source rather than
Hi John and group.
Given the new timelines announced for milestone releases for 7, what are the
chances of getting tail calls back on the table for that release?
If the answer is basically no chance, then what are the roadblocks?
If it could be done, then what would be required and who could
On Tuesday 08 December 2009 12:58:22 Ben Evans wrote:
Hi John and group.
Given the new timelines announced for milestone releases for 7, what are
the chances of getting tail calls back on the table for that release?
If the answer is basically no chance, then what are the roadblocks?
If it
On Tue, Dec 8, 2009 at 9:53 AM, Jon Harrop j...@ffconsultancy.com wrote:
If you want JVM+TCO then you should already be able to use OpenJDK. Another
forthcoming option may be VMKit, which is a JVM and CLR built upon LLVM
(which provides TCO so it should be relatively easy to add if it has not
On Wed, Dec 9, 2009 at 7:24 AM, John Cowan johnwco...@gmail.com wrote:
LLVM provides it only on certain hardwares, and I believe it optimizes
only tail recursion, not general tail calls.
There are platform restrictions, but I believe it can work with any
tail call that uses the fastcc calling
On Tuesday 08 December 2009 18:24:30 John Cowan wrote:
On Tue, Dec 8, 2009 at 9:53 AM, Jon Harrop j...@ffconsultancy.com wrote:
If you want JVM+TCO then you should already be able to use OpenJDK.
Another forthcoming option may be VMKit, which is a JVM and CLR built
upon LLVM (which provides
On Tuesday 08 December 2009 20:19:53 Attila Szegedi wrote:
I think it would be really valuable to have it. Since JVM has now
definitely moved away from the Java-as-the-only-language, availability of
TCO would allow languages that semantically assume it to be ported to JVM.
You can already port
14 matches
Mail list logo
