Ron Garret <rNOSPAMon@flownet.com> wrote:
+---------------
| rpw3@rpw3.org (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.
+---------------
Yup.
+---------------
| > +---------------
| > | ...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
-----
Rob Warnock <rpw3@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607