Subject: Re: lifo closures
From: Craig Chambers (chambers@cs.washington.edu)
Date: Tue Apr 10 2001 - 11:43:44 PDT
The LIFO closure stuff allows environments to be stack-allocated w/o any
analysis effort. Vortex does do additional work to see if the closure itself
can be stack-allocated.
In the early days of Vortex, before we had many optimizations implemented, we
elected not to support full non-LIFO closures because things would be too slow
for too long. Nowadays we might be able to get rid of the distinction, with
some additional effort to rework some implementation strategies. But it's not
high on anyone's list, given that it's not research.
-- Craig
Matthai Philipose wrote:
>
> Thanks, Vass and Todd for your replies. I've appended them below. I
> guess I had the "functional" view of a closure hard-wired in my brain,
> and didn't consider that you could provide language-level support for
> the other kind. Has there been any attempt to do
> region-inference/automatic stack allocation in Cecil?
> Matthai
>
> -------------- Todd said:
> Not sure if Vass's response answered your question. The basic
> distinction
> is whether the closure can escape the context in which it was created.
> You need to do extra work in this case, allocating an environment that
> goes around with the closure, so that free variable accesses will work
> even after the activation record where the closure was created has been
> removed from the stack, or whatever. For speed reasons, the compiler
> doesn't do this extra work unless you use the && syntax for closures.
>
> ------------ Vass said:
>
> >From a readme file:
>
> The implementation distinguishes between fully-functional (but
> slower) non-LIFO closures (identified with a leading && prefix) and
> regular LIFO closures (identified with a leading & prefix, or if the
> prefix is omitted altogether). If a LIFO closure turns out to be
> non-LIFO and accesses a variable from a lexically-enclosing (but not
> global) scope that has returned already, bad things can happen. Note
> that some bad things include fatal errors during compilation; we
> should fix things so that at least a warning message is displayed
> whenever we detect statically that a closure is non-LIFO.
>
> Vass
>
> _______________________________________________
> Cecil mailing list
> Cecil@cs.washington.edu
> http://majordomo.cs.washington.edu/mailman/listinfo/cecil
_______________________________________________
Cecil mailing list
Cecil@cs.washington.edu
http://majordomo.cs.washington.edu/mailman/listinfo/cecil
This archive was generated by hypermail 2b25 : Tue Apr 10 2001 - 11:44:04 PDT