Re: struct environment

[David Carlton <carlton at math dot stanford dot edu>]

On 05 Sep 2002 13:50:40 -0700, David Carlton <carlton@math.Stanford.EDU> said:

> The question remains of how to get from here to there.  I'm pretty
> sure that I can convert 'struct block' over to using environments in
> an incremental fashion.  Describing that process will take a fair
> amount of time, though, so I'll send it in a separate e-mail,
> probably some time tomorrow but maybe Monday.

Here's the basic idea as to how to convert struct block over to
environments incrementally.

As I commented before, environments will have various internal
implementations.  Current candidates for implementations are:

* Fixed-size hash tables.
* Fixed-size lists.
* Some sort of growing implementation (necessary for jv-lang.c,
  alas).

But while we're in the middle of converting over 'struct block', there
will be one more implementation:

* An implementation that keeps a pointer to a struct block, and does
  all lookups by accessing that struct block.

The advantage of that latter implementation is that, given blocks
whose environments use that implementation, all symbol lookups can be
done either by the old-fashioned methods or by the new environment
lookup methods, with identical results.  So, broadly speaking, the
implementation process will have three steps:

1) Convert existing block creators to use environments that are
   implemented via a pointer to 'struct block'.
2) Convert all block symbol lookups from the old accessors to the new
   accessors.
3) Convert the block creators to use one of the implementations other
   than 'struct block'.


That's the basic idea.  Here's the gory details:

** Step 0: Implement environments.

Create a new file 'environment.c' to contain all of the
environment-managing code.  (Side note: I just realized that GDB
already has a (little-used) 'struct environ' and a file 'environ.c'.
Oops.  If anybody thinks that adding 'struct environment' to this
would create confusion and has a better name to suggest, I'm all
ears.)

Implement the various constructors/accessors/etc. for environments,
for each of the various internal implementations mentioned above.
(Actually, at this stage it's only necessary to implement the
constructors for the 'struct block' internal implementation; the
accessors could be deferred until just before step 2, and the other
internal implementations could be deferred until just before step 3,
if desired.)


** Step 1: Convert existing block creators to use environments that are
implemented via a pointer to 'struct block'.

So we start by adding a struct environment * member to struct block.
Then, we have to make sure it gets initialized correctly, via an
environment that points to the block in question.  There are, I
believe, 3 cases here:

* The default case.  This is for blocks allocated via buildsym.c.
  This should be straightforward to implement: the complete list of
  symbols to be added to the blocks is already known.

* mdebugread.c.  Frankly, my brain can't handle that file right now.
  I'll try looking at it again next week, but if somebody familiar
  with that file could give me an indication as to what is proper to
  do with it, I'd appreciate it.  For all I know, it would be easy
  enough to convert it over to using the buildsym.c mechanisms; if
  not, I'll have to do some sort of special-case code for doing
  partially-constructed environments that then get finalized and
  hashed.

* jv-lang.c.  This constructs one separate block that can grow
  indefinitely.  (It contains names of classes, and I see no
  particular reason that we'll ever be able to tell that we're done
  adding classes.)  So this will need to use a special implementation.

Each case should be dealt with by a single patch, and the three
patches should be logically independent of each other.  The first and
third patches should be easy; it seems plausible to me that the
mdebugread.c patch might be a pain in the neck.


** Step 2: Convert all block symbol lookups from the old accessors to
the new accessors.

At the end of step 1, the environment data in blocks should be able to
be accessed in two different ways: either via the old mechanisms
(BLOCK_HASHTABLE, BLOCK_NSYMS, BLOCK_SYM, BLOCK_BUCKETS, BLOCK_BUCKET,
ALL_BLOCK_SYMBOLS, etc.) or via new mechanisms (env_lookup_shallow(),
whatever iterators get decided upon, etc.)

So the goal here is to track down every single reference to the old
mechanisms and convert them to the new mechanisms.  E.g. uses of
ALL_BLOCK_SYMBOLS should be replaced by uses of a new macro which goes
through the new iterators for the environment objects.  Or
lookup_block_symbol() will call env_lookup_shallow().  Indeed, calls
to lookup_block_symbol() might be replaced to calls to
env_lookup_shallow(); note, however, that Daniel Jacobowitz warns that
I'll have to be careful with mangled vs. demangled names there, so
lookup functions will have to handle that (and possibly there will
need to be two different env_lookup_shallow functions).

Also, in the middle of this, I'll probably delete all references to
BLOCK_SHOULD_SORT, and all sorting of linear blocks.  Blocks created
by buildsym.c never satisfy BLOCK_SHOULD_SORT; block created in other
ways can either be rewritten to be created by buildsym.c or just live
with having unsorted linear environments.  (Incidentally, the global
block in jv-lang.c probably satisfies BLOCK_SHOULD_SORT, but I'm
fairly sure it never gets sorted.)

This step can be implemented by lots of patches in almost any order:
either the old methods or the new methods work during this step, so
there's no need to worry about being consistent here.


** Step 3: Convert the block creators to use one of the
implementations other than 'struct block'.

At the end of step 2, all lookups are going through the new
accessors.  So now the old accessors can be deleted; and then the
code from step 1 can be converted over to using one of the permanent
implementations, rather than using implementation via 'struct block'.
Then the members hashtable, nsyms, and sym of 'struct block' can be
removed.


David Carlton
carlton@math.stanford.edu