Subject: Re: [linux-audio-dev] LAAGA proposal, part ??
From: Peter Hanappe (peter_AT_hanappe.com)
Date: Mon Jun 11 2001 - 14:56:19 EEST
Jay Ts wrote:
> SH> On Fri, Jun 08, 2001 at 04:08:31PM -0700, Simon Per Soren Kagedal wrote:
>
>>> On Fri, Jun 08, 2001 at 12:05:15PM +0100, Steve Harris wrote:
>>>
>>>> Just incase anyone thinks Java is a stupid example I did a test with gcj.
>>>> It's performance on dsp-type code is withing spitting distance of c++'s.
>>>
>>> Hey, that's excellent! What about gcj's garbage collector? Is it
>>> friendly to realtime stuff?
>>
>
> SH> I doubt it, but it probably doesn't go away and do things unbidden.
>
> The problem with garbage collectors is that in most cases, they are
> implemented in a way that is obscured from the programmer, oh, or
> should I say, "handled automatically". Every garbage collection
> implementation has by design "gone away and done things unbidden".
> Big things that take a lot of time, in fact.
>
> For realtime programming, it would be important that the garbage
> collector be put under control of the programmer.
It's a good thing the collector is hidden. That way the application
doesn't depend on the garbage technique used. It's called modular
programming :)
As a funny anecdote, an article I read (maybe I could find back the
reference) studied the optimizations done by developers to speed up or
improve memory allocation. The conclusion was that in most cases it
slowed down the application (I think Perl was one of them).
> C already
> has a way of doing this: free(). ;-)
The problem with free() is that, depending on the implementation, you
don't know how long the function call might take. The worst case time
of a call to free() might also break your real-time expectations.
So, if your doing alloc() and free() in a real-time thread, you'll
probably want to have your own memory management to assure fixed
upperbounds of the delays. Most hard real-time applications simply
allocate all their data before hand or use fixed-size memory chunks.
The problem is that the interesting applications are mostly dynamic
so they will always have to do some allocation/freeing. Maybe not in
the audio thread but surely in some other thread.
> I don't know as much as I should about Java to be writing this, but
> when I've Java programmers about this in the past, they've said,
> "Oh, sure Java can be used for audio." But when pressed about the
> garbage collection issue, they have told me that it is not possible
> for the programmer to control it explicitly. As far as I'm concerned,
> this disqualifies Java for realtime (incl. audio) programming. It
> simply isn't acceptable to have the runtime system (garbage collector)
> cut in at random moments to perform huge tasks before anything else
> is allowed to happen.
Sun's Java 1.0.2 implementation had a full-stop mark-and-sweep
collector. It basically stopped the application, cleared up
all unused memory before starting the application again.
It has changed quite a bit since then. The garbage collector is
incremental and runs concurrent to the other threads. That means that
if the audio thread doesn't allocate memory, it probably won't get
bothered much by the garbage collector.
As for gcj, I remember I looked and used Boehm's collector for C (the
one used in gcj), but I can't remember the details of the
implementation. I think it's not concurrent but maybe you can limit
the amount of work it does in one cycle.
There are a lot of articles out there that discuss garbage collection
in real-time applications. I wrote an overview about it two years ago.
It has some references to articles if your interested
(http://www.ircam.fr/equipes/repmus/Rapports/PeterHanappe99/ch1/node3.html#SECTION00124000000000000000,
and
http://www.ircam.fr/equipes/repmus/Rapports/PeterHanappe99/ch7/index.html)
Cheers!
Peter
> If anyone knows more, and can tell me for sure that I'm mistaken,
> I'd very much welcome your comments!
>
> - Jay Ts
-- Peter Hanappe peter_AT_hanappe.com
This archive was generated by hypermail 2b28 : Mon Jun 11 2001 - 17:08:50 EEST