some not-so-random questions

Eliot & Linda elcm at pacbell.net
Thu Nov 5 02:54:01 UTC 1998


Michael S. Klein wrote:
> 
> > Yesterday I did a quick hack on Unix (HP-UX) to use mmap instead of
> > allocating memory
> > by malloc. It seems to work very well. I can start squeak with 300 MByte
> > and
> > it comes up very quickly. What's interesting is that "top" shows only
> > the Megabytes
> > actually used. So mmap seems to use a "lazy" mechanism  on HP-UX.
> 
> I heard that VW uses mmap with copy-on-write so that if you start the
> same image multiple times, you only pay the image memory cost once.
> (Is this true, Elliot?)

We used to support "shared perm-spacve" where perm-space was
memory-mapped.  Alas HPUX 9.x implemented _copy-on-read_ not
copy-on-write.  HP was the platform customers wanted the facility on
most so we dropped it.

> I suppose that this could work for Squeak also.  You would want to make
> sure that the byte sex got written out to the image the same as your
> platforms, otherwise you'd have to pay that cost too.

Look at VisualAge for Smalltalk's shared Smalltalk libraries.  The map
Smalltalk compoenents read-only and sharable.  George Bosworht and I did
a paper design for such a scheme but never got a chance to implement
it.  Talking with IBM people at an x3j20 standards meeting I discovered
that the approach VWST takes is very similar.  The idea is that one
develops components using normal techniques (e.g. BOSS, Parcels, Ted's
scheme) and then "publishes" them in sharable form.  When published each
component chooses a range of virtual addresses it occupies, and uses an
external symbol table to discover thge addresses of objects it imports.

One would maintain a copy of the published form for each OS, since OSs
differ in how they allocate address space, and in their endian-ness.  A
sharable component should require as little modification as possible to
load, otherwise sharing is lost.  E.g. one would try to arrange that
adding/removing methods and adding/removing subclasses, the common kinds
of modifications, have as little impact on sharing as possible.  Imagine
arranging that all the method dictionaries and subclasses sets in a
published component are clustered together in a small set of pages.

However, this whole approach is aimed at deploying fairly fixed
applications on SMP hardware.  I think its an old idea that's dying the
death.  SMP boxes are relatively *very* expensive.  See what LLNL are
doing with Linux clusters to see you can produce networked systems an
order of magnitude cheaper than Sun and SGI offerings.  For example, the
LLNL guys spend about 75% of the cost of a node on the *ethernet card*,
and use low-end pentium boards and cheap boxes.  In this kind of context
sharing just isn't important.

The hoops you have to go through to get real sharing are difficult, and
the result lacks dynamism.  I think an interesting part of e.g.
VisualWorks' future is dynamic 24x7 applications running on networks of
commodity processors.  The emphasis needs to be on how to manage the
network, i.e. supporting dynamic updating of programs across the
network, allowing the network to grow when adding new nodes, and keeping
running when nodes die, etc, etc.
_______________,,,^..^,,,_______________
Eliot Miranda, ParcPlace Aspect, ObjectShare





More information about the Squeak-dev mailing list