Re: JVM News

[Craig Carey <research@ijs.co.nz>]

On Fri, 07 Feb 2003 14:57:01 -0800, achrist@easystreet.com wrote:

>Here is some info about the JVM from Sun that may give a clue why JGnat
>never became a successful product for ACT:
>
>http://www.internalmemos.com/memos/memodetails.php?memo_id=1321
>
>

It seems like Sun has decided that Java won't be debugged which would
cause irreparable damage to the sellability of that product item.

A summary of the memo follows. It is about the JVM in the Solaris OS.


Subject:  Sun says 22% of JVM bugs left unfixed (apparently)

>
>A website hosting some internal memorandums, & a [leaked] Sun memo:
>
>http://www.internalmemos.com/memos/memodetails.php?memo_id=1321
>
(The date of the leaked Sun memo seems to be 2001 or 2002.)
...
>
>| Sun Microsystems
>|
>| The Java Problem
>| Author: Julian S. Taylor
>| Reviewed by: Steve Talley, Mark Carlson, Henry Knapp,
>|    Willy (Waikwan) Hui, Eugene Krivopaltsev, Peter
>|    Madany, Michael Boucher
>|
>...
>| This document ... represents a consensus of several
>| senior engineers within Sun Microsystems. ... Our
>| experience in filing bugs against Java has been to see
>| them rapidly closed as "will not fix". 22% of accepted
>| non-duplicate bugs against base Java are closed in this
>| way as opposed to 7% for C++. Key examples include:
>|
>| 4246106 Large virtual memory consumption of JVM
>| 4374713 Anonymous inner classes have incompatible
>|         serialization
>| 4380663 Multiple bottlenecks in the JVM
>| 4407856 RMI secure transport provider doesn't timeout
>|         SSL sessions
>| 4460368 For jdk1.4, JTable.setCellSelectionEnabled()
>|         does not work
>| 4460382 For Jdk1.4, the table editors for JTable do not
>|         work.
>| 4433962 JDK1.3 HotSpot JVM crashes Sun Management
>|         Center Console
>| 4463644 Calculation of JTable's height is different for
>|         jdk1.2 and jdk1.4
>| 4475676 [under jdk1.3.1, new JFrame launch causes
>|         jumping]
>|
>| In personal conversations with Java engineers and
>| managers, it appears that Solaris is not a priority and
>| the resource issues are not viewed as serious. Attempts
>| to discuss this have not been productive and the
>| message we hear routinely from Java engineering is that
>| new features are key and improvements to the foundation
>| are secondary. ...
>...
>| dependencies for deployment". Following is an excerpt:
>|
>| - Large footprint of applications when run on Solaris.
>|   A simple application ("hello world" type) has a total
>|   footprint of 35-40 megs on Solaris 9 (build 48, using
>|   Java 1.4 build 82) on both Intel and Sparc machines.
>|   Sparc machines, by far, have a much higher resident
>|   footprint then Intel machines (~30 megs, compared to
>|   ~11 megs). The same program run on a Windows machine
>|   has a footprint of ~5 megs, resident footprint being
>|   ~3.5 megs.
>...
>| SMC, Sun's flagship system admin console, takes between
>| one and two minutes to reach the point that it can be
>| used. ...
>|
>| Given this data, it appears that the JRE can actually
>| be simpler than the Python RE since Java does at least
>| some of this work at compile time. ... Hello World
>| written in Java2 requires 9M for this most basic
>| support infrastructure. ... Further examples of what is
>| possible include the compiling OO languages Eiffel and
>| Sather which fit their garbage collector, exception
>| processor and other infrastructure into roughly 400K of
>| resident set.
>|
>| ... It is impractical to run it as a non-terminating
>| daemon. ... Java applications cannot be executed at
>| boot time since the loading of the VM introduces an
>| unacceptable performance degradation. ...
>...
>| We strongly recommend that management require Java to
>| conform to the Software Development Framework
>| especially from the standpoint of ARCreview
>| [Architecture Review Committees]
>...
>| What is perhaps more important is that the perception
>| of Java as an unstable platform is widespread. This
>| perception is restated with every Java-based project to
>| come to ARC. Within Sun, Java is not viewed as a
>| satisfactory language for the construction of
>| commercial applications.
>
...

>Java is compared with Ada 95 here:
>   http://www.gnat.com/texts/products/prod_java.htm
>
>Sun does not seem to have the word Ada in its corporate
>vocabulary. They got the word "Eiffel" into their memo though,
>a near miss.
...


A similar problem is occurring at the Gcc project as it gets slower.
There was talk of forking the project. Mr Dewar said that Gcc could be
faster.

__________________________________________________________________________
At 03\02\12 09:15 -0800 Wednesday, Linus Torvalds wrote to gcc-at-gnu.org
...
>That said, at least some comparisons with the Intel compiler on an older 
>kernel imply that the Intel compiler improves things like UDP and TCP 
>latency by 10-25% on 2.4.18 (in fact, the UDP path was apparently 
>magically improved by up to 30%, which is damn impressive):
>
>	http://marc.theaimsgroup.com/?l=linux-kernel&m=103559880923586&w=2
>
>So compiler code generation quality still _does_ matter. It's not as if 
>the [gcc] code is unoptimizable.
>
>So: 50% slower compiles from 2.95 to 3.2. With no noticeable improvement.
>
>			Linus
__________________________________________________________________________


Actually the Gcc project was forked in about August 2002:
__________________________________________________________________________

At 03\02\11 23:32 +0000 Tuesday, Joseph S. Myers wrote:
...
>We *have* the faster-compiler-branch, created at the same time as
>gcc-3_4-basic-improvements-branch
><http://gcc.gnu.org/ml/gcc/2002-08/msg01575.html>.  It just hasn't been
>used, whereas BIB was extensively used.
__________________________________________________________________________




Craig Carey
http://www.ijs.co.nz/ada_95.htm : Mailing lists