Sun's HotSpot

lex at cc.gatech.edu lex at cc.gatech.edu
Thu Oct 15 22:00:02 UTC 1998


Jan Bottorff <janb at pmatrix.com> wrote:
> >Sun has published the specifications for their new second generation Java
> >virtual machine, these are some of its characteristics.
> >
> >Interesting Aspects
> >
> >-Handleless. Object references are direct pointers, just like in Squeak.
> 
> Personally, I view this as a bug. Not having an object indirection pointer
> makes doing "Object become:" highly inefficent.

It doesn't have to.  Suppose one does "A become: B".  The system could overwrite A with an "indirection object" which points to B; call it I(B).  Whenever the system sends a message to the object that used to be A, it will see an I(B) sitting there, and forward the message on to B.  

The efficiency should be about that of using an indirection table for all objects, but it would only take effect for objects that have had a "become:" done to them.  Furthermore, a compacting garbage collector could remove the indirection objects when it rewrites pointers after a compaction; thus you can't fill up memory with just indirections.

Another small point would be that it may take more than one hop to get to the actual destination object; consider for instance someone doing "B become: C" after the above example.  But this cost is only paid once: the system can overwrite I(B) with C (or whatever the final destination is) and thus references to the original A now get to C with only one indirection step.

Even the VM code shouldn't get that bad.  Simply, whenever code wants to access an object, it runs a macro on it to find the "real" object being pointed to, before doing any operations on it.  

Are there any holes in this scheme?  It seems like one can eat the cake (efficient execution) and still have most of it (pretty efficient become:).


Lex



> # Without a very efficent
> "become:" it's gets MUCH harder to do transparent proxying, which is real
> handy for distributing your objects across networks or storage devices. I
> agree that removing the memory indirection is a performance win. If
> performance were not an issue, I think an architecture where things are
> doubly indirect would be cool. You could then control security/protection
> of arbitrary sets of objects. For Smalltalk to be a full OS, I think this
> protection would be appropriate. Squeak is not really targeted as a OS
> replacement though.
> 
> >- Object Headers of 2 words (3 in some cases). Squeak is the only Object
> >Environment where 83% (tipically) of the objects have a header with JUST
> >ONE WORD.
> 
> This really confuses me. It seems like the reason for using direct object
> pointers is to eliminate the performance hit from the indirection, so
> instead you have to mask the header and do table indirections, is this
> really better? Memory is REALLY cheap now. I can remember when I first
> heard about Self requiring a 64 meg SparcStation, and though only lunatic
> fringe researches had that much memory. My 2 main Intel boxes now have 128
> and 256 meg of RAM, even my laptop has 40 meg.
> 
> >Being Smalltalk-like more than ever, this new VM could allow us to generate
> >Java bytecodes from a Smalltalk environment.
> >Modifying Squeak object headers (from 1, 2 or 3 words) to use only 2 or 3
> >words, and surelly several other modifications , it should be possible to
> >run the Squeak environment on a Java VM. This would allow an Internet
> >browser to run Squeak without any plugin.
> 
> A BIG difference between Smalltalk and Java execution environments is the
> handling of context's. In Java, contexts allways have stack like lifetimes.
> In Smalltalk, contexts need to be garbage collectable with arbitrary
> lifetimes. The Java VM architecture is not prepared to cope with this (at
> least in the past). A significant area of Smalltalk VM development is
> efficent implementaion of contexts.
> 
> >- JIT compiler just for havily used code fragments.
> >- Method Inlining.
> 
> Isn't the Java HotSpot technology the evolution of the Self
> compiler/run-time. My understanding is some of the Self developers formed a
> company called Anamorphic Systems, which produced a Java/Smalltalk product.
> Sun then purchased Anamorphic to produce the HotSpot technology. Can
> anybody confirm or debunk this is how things happened? I'm not sure where I
> heard this.
> 
> It's real painful to watch the Java community relearn many of the same
> things the Smalltalk community learned MANY years ago. It's really
> disturbing to think the world has turned into a giant channel of reruns,
> and somebody misplaced the remote. 
> 
> A few months back, I went to a demo at Parc of the Xerox Star (I first saw
> the Star in '81 at NCC). It was real interesting to be reminded that
> hardware has improved a few orders of magnitude in the last 17 years, but
> software mabey hasn't improved very much. So what can we do to get back on
> track for the next decade or two? In 20 years will software be 40 years
> behind hardware? Or will software be dramatically better than it is now.
> 
> Jan Bottorff, President
> Paradigm Matrix, Inc.
> 
> 
> ___________________________________________________________________
>             Paradigm Matrix Inc., San Ramon California
>    "video products and development services for Win32 platforms"
> Internet: Jan Bottorff janb at pmatrix.com
>           WWW          http://www.pmatrix.com
> Phone: voice  (925) 803-9318
>        fax    (925) 803-9397
> PGP: public key  <http://www-swiss.ai.mit.edu/~bal/pks-toplev.html>
>      fingerprint  52 CB FF 60 91 25 F9 44  6F 87 23 C9 AB 5D 05 F6
> ___________________________________________________________________





More information about the Squeak-dev mailing list