Subject: Re: Smug scheme weenies?
From: (Rob Warnock)
Date: Tue, 11 Jan 2005 23:55:42 -0600
Newsgroups: comp.lang.lisp
Message-ID: <>
Ron Garret  <> wrote:
| (Rob Warnock) wrote:
| > IIRC hallway conversations at ILC 2003, both Allegro and Corman Lisp
| > use exactly this technique (or minor variations thereof).
| Alas, I was not able to attend ILC2003.  :-(

Reminder: ILC 2005 is at Stanford (SF Bay Area) this year.  ;-}  ;-}

| If I do a DEFVAR while there are already threads running, what
| happens  to the dynvar table in the existing threads?

I dunno, "the right thing"?  ;-}

Seriously, the glovar/dynvar table has to extend: immediately for
the thread that does the DEFVAR, and at least lazily for any threads
that run after that one does the DEFVAR.

| > Yes, but the "extra" memory you touch [one pointer redirection]
| > is almost always cached if you've touched that variable recently.
| Not quite.  It's cached if you've touched that variable IN THAT THREAD 
| recently.

Yup. That's what I meant.

| > And if you're doing accessing the variable multiple times in the
| > same thread-safe region of cade [e.g., for read-modify-write, say],
| > you only pay the "extra" accesses once. The generated code can locally
| > cache the final address for all the accesses.
| Good point.  It seems to me that it doesn't even have to be thread-safe, 
| just known that the variable can't be rebound in that thread (e.g. in a 
| local loop where all calls are known).

Sorry for the imprecision, that's really what I meant by "thread-safe",
that *nobody* [in the same or another thread] could rebind it while
the cached address was being used.

Of course, there's GC-induced relocation to worry about, too...  :-(

| But are any compilers out there actually that clever?

Dunno. [Duane? Roger?]

| Another hidden cost of this method, it seems to me, is that it can 
| consume a lot of memory if you have a lot of dynamic variables and a lot 
| of threads even if you don't actually bind those variables very often.


| > +---------------
| > | ...and it also suffers from the same problem as that solution,
| > | namely, that you have to do a global analysis...
| > +---------------
| > 
| > Not really.
| ...
| > The main inefficiency that I see [and it's probably minor in most
| > applications] is that if a global/special is bound [and notice
| > that I say "bound", rather than "defined" -- it matters!!] in *any*
| > thread, then a slot must be allocated for it in *all* threads
| > [but only allocated, not set].
| That's what I meant.  The only way I can can think of to determine this 
| is to do a global analysis.  (Of course, I've got a pretty bad track 
| record in this regard of late.)

But note that the "global analysis" you're talking about here is not
required to generate correct code, only to do performance profiling
[or equiv.] of an implementation.

The actual compilation using the glovar/dynvar table approach can be
done with no more analysis than is already required for distiguishing
lexical variables from globals/specials. And the slot allocation can
be done lazily as need arises, *without* prior "global analysis".
[Hint: When you switch threads, if the new thread's glovar/dynvar
table is smaller than the one we're switching from, then you need
to extend it before the new thread can run.]


Rob Warnock			<>
627 26th Avenue			<URL:>
San Mateo, CA 94403		(650)572-2607