Squeak vs. Java

Boyers, Albert albert.boyers at corp.bellsouth.net
Thu Apr 27 21:59:57 UTC 2000


The embrace and extend model works best.  I think that writing
a Java VM in squeak would have far reaching positive implications.
I suspect it would not be that hard (but I'm just a lurker not 
a squeaker, yet).
Squeak would pick up a huge API from Java (not necessarily a
good thing), and Java developers would have access to sophisticated
debug/developing environments.  Smalltalk would always be
there waiting to be used.

The flip side, smalltalk in java (http://www.architur.de/talks2/  
which is truly cool) does nothing for smalltalk.

-al

> -----Original Message-----
> From: Stefan Matthias Aust [mailto:sma at 3plus4.de]
> Sent: Thursday, April 27, 2000 4:09 PM
> To: squeak at cs.uiuc.edu
> Subject: Squeak vs. Java
> 
> 
> Jalapeno is a Java VM by IBM written in Java.  Does this sound 
> familiar?  An interesting paper about this JVM lists 
> arguments why Jalapeno 
> is superior to existing VMs (including HotSpot) on the server 
> side.  Keep 
> reading, I'll explain why I list them in a minute. Here are 
> the topics:
> 
> 1. Exploitation of high performance processors
> 2. SMP scalability
> 3. No Thread limits
> 4. Continuous availability
> 5. Rapid response
> 6. Library usage
> 7. Graceful degradation
> 
> And here are the arguments, slightly rephrased together with 
> my comparison 
> with Squeak.
> 
> ad 1. Current JITs don't do enough optimization.  By using a 
> high-level 
> language to implement their VM, they can handle the complexity and 
> correctly implement more complex optimizations.  This isn't 
> supported by 
> Squeak (yet), but most other arguments are also true for 
> Squeak and that's 
> IMHO amazing.
> 
> ad 2+3. By not using native thread but doing their own 
> simulation they get 
> a better scalability and don't run in operation system thread limit 
> (Windows NT, I think, support only less than 2000 threads for 
> example).  Squeak also has this feature.
> 
> ad 4. Servers must run pretty damn stable, several months (or 
> at least as 
> long as the underlying operation system supports :-) and 
> using Java with no 
> pointers, safe GC, bound checking of arrays and so on helps 
> to omit (the 
> usual) memory leaks.  Squeak also has this feature, at least 
> as long as you 
> test the simulated VM.
> 
> ad 5. A non-incremental GC (as this often is implemented to stop all 
> threads before doing a global collection) may cause long 
> delays.  As I 
> think Squeak as an incremental GC, it doesn't suffer as 
> Jalapeno does not.
> 
> ad 6. Jalapeno optimizes and compiles not only code but also existing 
> libraries including its own normally "native" runtime code 
> which helps to 
> do inlining and type check suppression by better type 
> inference. A similar 
> think is true with Squeak, as all primitives are written in 
> Squeak, you can 
> selectively compile some of them to C or not, the code will 
> always run, 
> although faster or slower.  If this would be automatic, we'd 
> have the same 
> advantages as Jalapeno.
> 
> ad 7. A server should not crash when overloaded but should 
> try to stay 
> alive and at least continue slowly.  Not crashing under all 
> circumstances 
> is also true for Squeak.
> 
> So I'd say, Squeak is a pretty good platform for implementing server 
> applications - especially once we get a Jitter for even better 
> performance.  It's memory footprint is even smaller than for 
> typical JVMs 
> and so probably also for Jalapeno.
> 
> Comments?
> 
> bye
> --
> Stefan Matthias Aust  //  ...dancing on the dark side of moon
> 





More information about the Squeak-dev mailing list