Sun JavaFx

[Shawn Rutledge]

On 5/10/07, Jim Thompson <jim at netgate.com> wrote:
> Terrence Barr - Evangelist, Java Mobile & Embedded wrote:
> > Shawn,
> >
> > I have been very involved in this area at Sun now for a couple of
> > years. Let me add come comments:
> >
> > Hardware accelerated Java is actually fairly common already, at
> > least in the Java ME space using ARM's Jazelle technology. It does
> > have some benefits in very constrained platforms but in general
> > advanced VMs with dynamic adaptive optimizations, compilation,
> > and improved garbage collection perform better than H/W acceleration
> > and at reasonable incremental cost (memory footprint, in particular).
> >
> > I think what we are seeing here is a general trend in the IT industry
> > as general-purpose processors become more and more powerful they
> > displace dedicated hardware solutions because software solutions are
> > more flexible and lower cost. A notable exception, of course, is
> > graphics acelleration but Java implementations typically use those
> > when available.
> >
> > Specifically to Sun's Java chips (picoJava/microJava): I worked on them
> > and the performance was quite good. But it is very hard, if not
> > impossible, to keep up with performance improvements of general
> > purpose processors together with the increasing amount of memory
> > available. That technology evolution relegates Java hardware
> > acceleration to niche status. Many companies have invested in Java
> > H/W acceleration and fell into that trap.
>
> It turns out to be difficult to make Java go really fast on specialized
> hardware.  Java wasn't designed to be fast, it was designed to be 'safe'

Why is it so hard?  What are the tough problems that are always going
to be slow?

What's wrong with taking some shortcuts, like the way KVM depends on
pre-verified bytecodes so that it doesn't have to do the verification
at load time?

> for large groups of programmers to use.  You can get single order of
> magnitude speed-ups for some bytecode streams, but you won't see two.
>
> I (too) looked at doing a Java chip (very early, back in 1996 or so).
>
> Moore's law continues to march on, only now instead of (super)-linear
> speed-up on a single core, we're getting multiple cores.  Java will be
> OK with 'multi-core', but won't survive the transition to 'manycore' (>
> 100 cores), nor will Python, PHP or Perl.
>
> This may not matter on a phone platform, but the desktop and server will
> distance themselves from co-operating sequential processes before too
> much longer.

I think you are saying that the thread model of concurrency has
limits, right?  Or just that programmers will balk at having to manage
hundreds of threads?  Well what do you think is the future then, to
get more parallelism?

> The only question is if the rest of the industry 'woke up' enough to see
> the light of cracking the phone wide-open.  If not, they are doomed.

Yeah that's a big one.  I think Apple's view is that their
applications are always best-of-breed anyway, and they can satisfy 90%
of the users' needs themselves, so why be open to having third-party
security holes, usability problems, bugs and so on, which will sully
the reputation of the phone.  But I also think a lot of the success of
the early Palms was the wide variety of extra software you could
install on them.  I doubt that Apple will really keep the iPhone
closed forever, but we'll see.  Nowadays it's not like it was in the
Palm era though... there are so many choices for development platform.
 Java, Brew, Windows Mobile, Palm, Symbian, Linux/QT, Linux/X, etc.
Java has not been the unifying force that it should have been.  I'm
not very optimistic that is suddenly going to happen; the window has
probably been missed.  But I guess it's worth a try.  If nothing else
at least OpenMoko might be able to run Java games or something.

I think one unsolved problem, which has probably hampered Java a lot,
is the lack of a process model.  If a Java VM was pre-loaded, and all
of the Java applications could run in one VM, the overhead for each
one would be much less, right?  I know, I've heard the excuse... well,
the OS is caching files anyway, each class's instructions are only
being loaded once, and a separate VM increases security.  But if a
phone's top priority at bootup was to just to get all of the necessary
classes into memory as fast as possible, and get the VM running, get
the UI up and be ready to do the basic phone stuff (calls, phonebook
etc.) maybe it could be fast.  But Java has always been an adjuct.  On
the desktop, first you have all the overhead of the OS and its own UI,
and then there is Java.  Anytime I run a desktop Java app my reaction
is ugh, you can always recognize a Java app by the startup time, the
amount of memory it's taking up, and the paint idiosyncracies and the
way the UI looks.  And the installer typically put its own VM in place
along with the app.  So you will be running a different VM for every
app.  This is not a platform!  And the phones I have worked with are
just limited to one Java app at a time because they can't afford the
system resources for more than one.  Whereas if the emphasis 10 years
ago had been to make Java into a real platform, keep the VM thin and
light, pre-load and re-use as much as possible, have the security be
good enough that you can actually run multiple apps in one VM without
worrying about them stepping on each other.... then pipe dreams like
the Java OS, JavaStation, and 100% Java cell phones would be
practical.