Re: Parse trees (Re: emacs with guile instead of elisp)

[thi <ttn@netcom.com>]

> > > What about maintaining a common heap store which can be memory mapped
> > > read-only into a fixed address space of the process?
> > 
> > Hmmm... I can't claim that I'm not speaking from my ass now, but this
> > sounds like RScheme, assuming their persistent store can hold closures.
> > 
> > OTOH, Rscheme is compiled to pseudo-code (not parse trees AFAIK), and
> > why shouldn't you be able to store arbitrary binary code in persistent
> > store? Need to look at this stuff closer...
> 
> Stop me if I go wrong here...
> 
> Symbols are stored in a common hash table so that the actual symbol string
> value is only stored once. As new code comes in through the `read' parser
> the symbol hash table grows to handle the new symbols comming in
> and all instances of a given symbol get exactly the same SCM value
> (which points to the string value and some properties and things).
> 
> If you have memory mapped chunks, do these chunks store symbols in full
> string form? If they do, then you will have to reparse the memory mapped
> chunks which defeats the purpose. Do they store symbols as references to
> their own hash table? If you do then you must merge the incoming hash table
> with the currently resident hash table or else have multiple system
> hash tables floating around (making it difficult to look up the value
> of a symbol). Do you try and create universal SCM values for all of the
> common symbols? If you do this then you are heading for a versioning
> nightmare with the prospect of maintaining a database of symbol values
> that is set in stone for all time.
> 
> Unless someone has either a way to make one of the above options work
> or some new option, there is no way to handle symbols in these memory
> mapped modules!

as a constant, there will be a string pool.  a table of (relative)
offset and un-normalized hash values can be provided.  this would make
the only process required to be a walk of this table, in the process
normalizing and merging the hash values (and doing whatever normally
is required for system hash table maintenance).  space taken by this
"dehydrated hash" table cannot be reclaimed and every consumer of a
memory mapped module would have to go through the exercise.  still, i
think this is viable.

time to go see how dynl.c works...

thi