From: | will@ccs.neu.edu (William D Clinger) |
Newsgroups: | comp.lang.java,comp.compilers,comp.lang.scheme |
Date: | 27 Jan 1996 01:10:54 -0500 |
Organization: | College of CS, Northeastern University |
References: | 96-01-049 96-01-050 |
Keywords: | translator, GC |
basile.starynkevitch@cea.fr writes:
>Explicit continuations (such as those provided by Scheme's
>call-with-current-continuation primitive), when implemented on a stack
>based (virtual or real) machine, nearly requires machine support,
>since the stack (or segments in it) have to be copied elsewhere. An
>alternative is to allocate all activation frames on the heap, hence
>without using any stack. This is actually doable, and work efficiently...
Although this works fairly well with a generational garbage collector
as in SML/NJ, you wouldn't want to do this with the conservative
garbage collector currently used to implement the Java VM. You
wouldn't have to, since nearly all of the standard techniques used to
compile Scheme into C could be used with the Java VM.
Tail recursion is a more serious problem than first class
continuations. But again, the standard techniques used to compile
Scheme-like languages into C could be used with the Java VM, with the
same 2x hit in overall performance. This inefficiency will disappear
if Sun allows for tail recursive calls in some future revision of the
Java VM, as is rumored.
In the long term I think the most serious problem is that the obvious
implementation of a dynamically typed language in the Java VM is to
represent all values as Java objects. You could hack up a special
case for integers, but the strong typing of the Java VM makes it hard
to do that without slowing everything else.
William D Clinger
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.