Re: real-time Java

Re: real-time Java

[Kent Paul Dolan]

18k11tm001@sneakemail.com (Russ) wrote:

> I've been hearing a lot lately about real-time Java. I must confess
> I'm baffled about the motivation behind this endeavor. Would someone
> please tell me what real-time Java will be able to do that Ada can't
> do? Or what it will be able to do better than Ada? Thanks.

Sure: bring a popular, thriving, employer-demanded language with a
wealth of libraries and a robust built-in GUI into the real time
arena.

xanthian.

How the heck you do that with a language subject to garbage collection
is going to be an interesting thing to watch happen.  Some complaints
in comp.lang.java.programmer mention Java going off to stew for whole
minutes at a time.

Re: real-time Java

[Dr. Michael Paus]

Kent Paul Dolan wrote:
> 18k11tm001@sneakemail.com (Russ) wrote:
> 
> 
>>I've been hearing a lot lately about real-time Java. I must confess
>>I'm baffled about the motivation behind this endeavor. Would someone
>>please tell me what real-time Java will be able to do that Ada can't
>>do? Or what it will be able to do better than Ada? Thanks.
> 
> 
> Sure: bring a popular, thriving, employer-demanded language with a
> wealth of libraries and a robust built-in GUI into the real time
> arena.
> 
> xanthian.
> 
> How the heck you do that with a language subject to garbage collection
> is going to be an interesting thing to watch happen.  Some complaints
> in comp.lang.java.programmer mention Java going off to stew for whole
> minutes at a time.

If you are interested in how this can be achieved, have a look at
http://www.aicas.com/

They sell a real-time capable VM. Of course you cannot expect real-time
behaviour from a standard VM from Sun on a non-real-time OS like Windows.
Nevertheless the statement that Java stops for minutes to do some
garbage collection is simply wrong for modern VMs.

Michael

Re: real-time Java

[Tum]

Check out wonka.

http://wonka.acunia.com/

It's free.

"Kent Paul Dolan" <xanthian@well.com> wrote in message
news:a3eaa964.0304102210.3875f527@posting.google.com...
> 18k11tm001@sneakemail.com (Russ) wrote:
>
> > I've been hearing a lot lately about real-time Java. I must confess
> > I'm baffled about the motivation behind this endeavor. Would someone
> > please tell me what real-time Java will be able to do that Ada can't
> > do? Or what it will be able to do better than Ada? Thanks.
>
> Sure: bring a popular, thriving, employer-demanded language with a
> wealth of libraries and a robust built-in GUI into the real time
> arena.
>
> xanthian.
>
> How the heck you do that with a language subject to garbage collection
> is going to be an interesting thing to watch happen.  Some complaints
> in comp.lang.java.programmer mention Java going off to stew for whole
> minutes at a time.

Re: real-time Java

[Darren Winsper]

In <a3eaa964.0304102210.3875f527@posting.google.com>, Kent Paul Dolan
wrote:

> How the heck you do that with a language subject to garbage collection
> is going to be an interesting thing to watch happen.

By using things like immortal and scoped memory.  Check out the Memory
classes in the RTJ spec.

-- 
A wise man learns from his mistakes.              |ICQ:8899775
A sage learns from the mistakes of others.        |JID:darren@rooter.dyndns.org
My own incompetence shall lead to a better world. |MSN:punjabpete@hotmail.com

Re: real-time Java

[Mark Thornton]

"Darren Winsper" <dw133@cs.york.ac.uk.go.away> wrote in message
news:pan.2003.04.15.08.17.02.790560@cs.york.ac.uk.go.away...
> In <a3eaa964.0304102210.3875f527@posting.google.com>, Kent Paul Dolan
> wrote:
>
> > How the heck you do that with a language subject to garbage collection
> > is going to be an interesting thing to watch happen.
>
> By using things like immortal and scoped memory.  Check out the Memory
> classes in the RTJ spec.
>

And also by choosing an appropriate garbage collector. Some real time tasks
can tolerate the delays introduced by a garbage collector.

Mark Thornton

Re: real-time Java

[Wesley Groleau]

>>>How the heck you do that with a language subject to garbage collection
>>>is going to be an interesting thing to watch happen.

Don't know much about it, but I read more than a year ago
that some company had a JVM with "guaranteed deterministic"
timing.

> And also by choosing an appropriate garbage collector. Some real time tasks
> can tolerate the delays introduced by a garbage collector.

How about a garbage collector in a lower priority
task that runs continuosly for some percentage of
CPU time instead of hogging the machine only when
desperately needed?

(Another thing that would be nice is a JVM that is
a shared library or resident in the OS or something,
instead of--this is for multi-user environments, BTW--
having every Java program running its own copy of the JVM.)

Re: real-time Java

[Mark Thornton]

"Wesley Groleau" <wesgroleau@despammed.com> wrote in message
news:Jj6dnZQ3ZIVegAGjXTWcpg@gbronline.com...
> >>>How the heck you do that with a language subject to garbage collection
> >>>is going to be an interesting thing to watch happen.
>
> Don't know much about it, but I read more than a year ago
> that some company had a JVM with "guaranteed deterministic"
> timing.
>
> > And also by choosing an appropriate garbage collector. Some real time
tasks
> > can tolerate the delays introduced by a garbage collector.
>
> How about a garbage collector in a lower priority
> task that runs continuosly for some percentage of
> CPU time instead of hogging the machine only when
> desperately needed?
>
> (Another thing that would be nice is a JVM that is
> a shared library or resident in the OS or something,
> instead of--this is for multi-user environments, BTW--
> having every Java program running its own copy of the JVM.)
>

In addition to the standard garbage collector the current Sun JVM has 3
other collectors:
1) an incremental collector
2) a concurrent collector
3) a parallel collector

http://java.sun.com/j2se/1.4.1/changes.html#vm

Mark Thornton

Re: real-time Java

[Robert A Duff]

Wesley Groleau <wesgroleau@despammed.com> writes:

> Don't know much about it, but I read more than a year ago
> that some company had a JVM with "guaranteed deterministic"
> timing.

I wonder if the machine it runs on (I mean the real one, not the virtual
one) has a cache.

Also, I don't think "deterministic" is quite what you want.
You want some practical way of predicting a worst-case (bounded)
time during which GC locks out other tasks.

> How about a garbage collector in a lower priority
> task that runs continuosly for some percentage of
> CPU time instead of hogging the machine only when
> desperately needed?

That sort of thing can be done, but any GC is going to need *some*
amount of time to do stuff that can't be interrupted.  Designs that
reduce such times often increase the overall overhead, so there's
a tradeoff.

- Bob

Re: real-time Java

[Wojtek Narczynski]

Wesley Groleau <wesgroleau@despammed.com> wrote in message news:<Jj6dnZQ3ZIVegAGjXTWcpg@gbronline.com>...
> >>>How the heck you do that with a language subject to garbage collection
> >>>is going to be an interesting thing to watch happen.
> 
> Don't know much about it, but I read more than a year ago
> that some company had a JVM with "guaranteed deterministic"
> timing.

Yes, garbage collector can be deterministic thus realtime.

But in practice my experience with java libraries is that the
developers relieved of the necessity to free memory explicitly, tend
to forget about memory management completely (i.e. not clear stale
references). You're stuck with OutOfMemoryError even though there is
no "garbage" per se in the running app, and you really cannot do much.
You cannot contact the vendor and say - "your library leaks".

> How about a garbage collector in a lower priority
> task that runs continuosly for some percentage of
> CPU time instead of hogging the machine only when
> desperately needed?

This is how it works in current JVMs, stop-the-world collectors are
past.

> (Another thing that would be nice is a JVM that is
> a shared library or resident in the OS or something,
> instead of--this is for multi-user environments, BTW--
> having every Java program running its own copy of the JVM.)

Unix and Windows will load only one copy of a binary no matter if it's
an executable or shared library. So there is only one copy of the
garbage collector code. I don't see how collector data could be shared
though.

Something that could be shared is the bytecodes loaded from .class
files. This really is way redundant, for example eats extra 128MB of
on my server. Unfortunately you cannot fork() a JVM as it is (usually)
threaded.

Having said all that, I'd stay away from real time java :-). I already
imagine those ads "Parse your XML metadata schema transformation UML
digital assets in realtime!". Hmm, I didn't know I'd constitute such a
good marketing manager.

(Sorry for an offtopic post.)

Regards,
Wojtek

Re: real-time Java

[Wesley Groleau]

>>(Another thing that would be nice is a JVM that is
>>a shared library or resident in the OS or something,
>>instead of--this is for multi-user environments, BTW--
>>having every Java program running its own copy of the JVM.)
> 
> Unix and Windows will load only one copy of a binary no matter if it's
> an executable or shared library. So there is only one copy of the
> garbage collector code. I don't see how collector data could be shared
> though.

I can't speak for windows, but this is not true
of Solaris.  The project I recently left had a
problem reporting/tracking tool in Java.  Everybody
used it.  That mean that at any given time, the
physical memory and swap space had twenty to thirty
copies of the JVM running, and each copy had additional
memory allocated to all the same classes.

Re: real-time Java

[Wesley Groleau]

> But in practice my experience with java libraries is that the
> developers relieved of the necessity to free memory explicitly, tend
> to forget about memory management completely (i.e. not clear stale
> references). You're stuck with OutOfMemoryError even though there is
> no "garbage" per se in the running app, and you really cannot do much.
> You cannot contact the vendor and say - "your library leaks".

I was amused at JBuilder one day.  I pulled down an
"info" menu option.  At the bottom of the little widget
that popped up was the amount of memory in use.  Even though
I was doing absolutely nothing, the number kept slowly rising.
When it hit some threshold, GC was triggered and it started over.

Re: real-time Java

[Samuel Tardieu]

>>>>> "Wes" == Wesley Groleau <wesgroleau@despammed.com> writes:

>> Unix and Windows will load only one copy of a binary no matter if
>> it's an executable or shared library. So there is only one copy of
>> the garbage collector code. I don't see how collector data could be
>> shared though.

Wes> I can't speak for windows, but this is not true of Solaris.  The
Wes> project I recently left had a problem reporting/tracking tool in
Wes> Java.  Everybody used it.  That mean that at any given time, the
Wes> physical memory and swap space had twenty to thirty copies of the
Wes> JVM running, and each copy had additional memory allocated to all
Wes> the same classes.

"All the same classes" are data. Wojtek was talking about the virtual
machine itself (including the garbage collector), not about all the
loaded classes. Fortunately, only read-only pages are shared, not data :-)

  Sam
-- 
Samuel Tardieu -- sam@rfc1149.net -- http://www.rfc1149.net/sam

Re: real-time Java

[Kent Paul Dolan]

Wesley Groleau <wesgroleau@despammed.com> wrote (and
butchered the attributions on):

>>> (Another thing that would be nice is a JVM that is a
>>> shared library or resident in the OS or something,
>>> instead of--this is for multi-user environments, BTW--
>>> having every Java program running its own copy of the
>>> JVM.)

>> Unix and Windows will load only one copy of a binary no
>> matter if it's an executable or shared library. So there
>> is only one copy of the garbage collector code. I don't
>> see how collector data could be shared though.

> I can't speak for windows, but this is not true of
> Solaris.

Since when? Normal Unix behavior is that a virtual memory
page from a disk image of an executable is only physically
replicated if one or another of the referring routines makes
it "dirty"; otherwise, while it is being used "read-only",
all referring routines thread through a single virtual
memory copy. If it is made dirty, the reference count to the
clean copy is reduced, and the routine attempting to write
to it gets a private copy on which to scribble.

So long as the compiler and linker provide a clean division
between executing code and its mutable data, most of the
code image should be shared.

Since I used to run _many_ executables with 100 megabyte
codespace footprints in Solaris on UltraSparcs
simultaneously without running out of memory, your claim
seems suspect, but I'm not privy to Solaris internals to
refute it.

> The project I recently left had a problem reporting /
> tracking tool in Java.  Everybody used it.  That mean that
> at any given time, the physical memory and swap space had
> twenty to thirty copies of the JVM running, and each copy
> had additional memory allocated to all the same classes.

Hmm, that does raise an interesting point, though.  Even if
the JVM code space were shared, the classes are JVM _data_,
not underlying OS _code_, and so might not be sharable,
unless the clean page/dirty page rules above hold for _any_
disk page images (which might well be the case).  Even then,
there is next to no way the JIT native code could be shared,
but perhaps it is a relatively small item compared to the
classes from which it is compiled, since it is only the hot
loops of those classes.

xanthian.

Re: real-time Java

[Tor Iver Wilhelmsen]

Wesley Groleau <wesgroleau@despammed.com> writes:

> I was amused at JBuilder one day.  I pulled down an
> "info" menu option.  At the bottom of the little widget
> that popped up was the amount of memory in use.  Even though
> I was doing absolutely nothing, the number kept slowly rising.

Welcome to the wonderful world of non-immutable events leading to tons
of events created and discarded in any given Swing application as it
runs. Even if you did absolutely nothing, Swing (and possibly
JBuilder's "virtual file system") was generating events like asking
itself if it needed to repaint etc.

Re: real-time Java

[Thomas Maslen]

In <wccllybiwu2.fsf@shell01.TheWorld.com> Robert A Duff <bobduff@shell01.TheWorld.com> writes:
>Wesley Groleau <wesgroleau@despammed.com> writes:
>
>> Don't know much about it, but I read more than a year ago
>> that some company had a JVM with "guaranteed deterministic"
>> timing.
>
>I wonder if the machine it runs on (I mean the real one, not the virtual
>one) has a cache.

Dunno about that JVM, but aJile's aJ-80 and aJ-100 Java CPU chips were
designed with realtime Java in mind and don't have caches in the normal
sense.  (They do have on-chip RAM, and I think that current versions of
the firmware for J2ME use some of it as a stack cache, but that's not
quite the same).


Thomas Maslen
maslen@pobox.com

Re: real-time Java

[Kent Paul Dolan]

"Dr. Michael Paus" <paus@ib-paus.com> wrote:
> Kent Paul Dolan wrote:

>> How the heck you do [hard real time
>> execution] with a language subject to
>> garbage collection is going to be an
>> interesting thing to watch happen.
>> Some complaints in
>> comp.lang.java.programmer mention
>> Java going off to stew for whole
>> minutes at a time.

> If you are interested in how this can
> be achieved, have a look at
> http://www.aicas.com/

Thanks for that. Their software would
probably achieve faster acceptance if
the book convincing people it was
possible at all were freely available
online, but I cannot make their business
decisions for them, and my viewpoint may
be biased by poverty.

> Nevertheless the statement that Java
> stops for minutes to do some garbage
> collection is simply wrong for modern
> VMs.

I'm not quite sure how you can
categorize as "wrong" the experiences
reported by many programmers.

What they are reporting certainly
_happens_.

Whether what they are reporting is due
to the conceptual difficulty of
programming for a garbage collecting
language implementation,

  [GC, it should be emphasized, was
  created mostly to overcome the
  conceptual difficulty of programming
  with explict new/dispose commands, and
  if conceptual difficulty is still the
  main problem, then garbage collection
  is not yet a programming tool which
  satisfies its design goal.]

or whether what they are reporting is
due to inherent limitations of garbage
collection technology today as a
mechanism, or whether what they are
reporting is the result of flawed GC
implementations today, the problem still
certainly exists.

Solving it in all three forms needs to
be a priority issue for Java Virtual
Machine implementors, Java language
design mavins, and Java tutorial
writers, since GC problems are one of
the most frequent causes of criticisms
of Java and slowness of Java programming
language acceptance.

xanthian.

Re: real-time Java

[Robert A Duff]

xanthian@well.com (Kent Paul Dolan) writes:

> Whether what they are reporting is due
> to the conceptual difficulty of
> programming for a garbage collecting
> language implementation,
> 
>   [GC, it should be emphasized, was
>   created mostly to overcome the
>   conceptual difficulty of programming
>   with explict new/dispose commands, and
>   if conceptual difficulty is still the
>   main problem, then garbage collection
>   is not yet a programming tool which
>   satisfies its design goal.]
> 
> or whether what they are reporting is
> due to inherent limitations of garbage
> collection technology today as a
> mechanism, or whether what they are
> reporting is the result of flawed GC
> implementations today, the problem still
> certainly exists.

Part of the problem is that Java wants to put (almost) everything in the
heap.  The GC would be faster if more data could be allocated in the
stack, or in registers.  Many GC'ed languages share this problem.

The C# language is nearly identical to Java, but one important
difference is that you can have stack-allocated structs.

- Bob