🚀 go-pugleaf

In article <43688@ames.arc.nasa.gov> lamaster@ames.arc.nasa.gov (Hugh
LaMaster) writes:

   Arbitrary object lengths, on the other hand, look like an unsolved
   problem to me.

Tell that to Burroughs... :-). There have been studies (Smalltalk: bits
of history, words of advice) in object memory *with* pages; you have
object memory in core (which is good), and then secondary storage
transactions are done in pages, and you try to stuff a page with many
small objects, hopefully related. A compacting garbage collector helps
here, of course.

   BTW, why is "making the working set smallest" a primary goal?  Working set
   is a performance question, and the overall best performance is the goal.

For general purpose applications/architectures, minimizing the working
set gives the overall best performance.

   >A large page size implies coarse, static grouping of objects, and
   >approximates the correct policy, and poorly, only in the case of sequential
   >access, 

   It also approximates correct policy on array dominated simulations where you
   can, on some systems, require touching 24 bytes or more of data for every 
   CPU cycle.

As usual: if we are talking about special purpose architectures, then
things may dramtically change. After all Cray is fond of base+limit, and
for good reason, for his vector machines. We were discussing 64 bit
machines; not all machines with 64 bit addressing will be used for
vector processing. Somebody said that they may well be used for
hypermedia, or databases, or many other things that resemble the classic
timesharing computer utility concept.

What I really don't like is SUN having large (8KByte) pages on machines
that are rarely used for sequential access, and their only excuse being
having misdesigned the MMU architecture. :-(.
--
Piercarlo "Peter" Grandi           | ARPA: pcg%cs.aber.ac.uk@nsfnet-relay.ac.uk
Dept of CS, UCW Aberystwyth        | UUCP: ...!mcvax!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk