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
|