>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. 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
___________________________________________________________________