On Fri, May 21, 2010 at 11:01:44PM +0200, Arnout Engelen wrote: > On Fri, May 21, 2010 at 11:42:13AM -0700, Niels Mayer wrote: > > On Fri, May 21, 2010 at 8:33 AM, torbenh <[email protected]> wrote: > > > On Thu, May 20, 2010 at 10:37:30AM -0700, Niels Mayer wrote: > > > > "hard realtime" often precludes the use of Garbage collectors. Of > > > > course Java has RT garbage collectors available: > > > > http://java.sun.com/developer/technicalArticles/Programming/rt_pt2/ > > > > > > Java RTS has an innovative pricing model that starts at $6500 per > > > socket/CPU for development or internal deployment. > > > > > > well... thanks :S > > > > Java is open source. > > Well, indeed a big part of the Sun JVM has been open-sourced under the name > 'OpenJDK'. That does not mean the Java RTS is open-sourced - I'm pretty > sure it isn't. But I'm not even sure RTS provides the kind of RT we're looking > for in the LAD world.
that statement about the pricing model was a quote from the java RTS FAQ. opensourcing something of that price would be a bit dumb :) > > > There are people using embedded and sometimes RT java, > > to varying degrees of effectiveness, in all sorts of everyday devices, like > > your cable company-provided DVR and set top box (which I've worked on) and > > sometimes even your credit card verification devices (which i've also > > worked on). > > What kind of 'real time' are we talking about here, exactly? I think the > definition relevant for the LAD world is basically: "it can be guaranteed that > no non-RT-safe calls (like anything that may block, including malloc) will > take place while handling the JACK process() callback". > > Can OpenJDK provide that guarantee? This never has been quite clear to me. i doubt it can. > > The JACK thread can be run at a higher priority than the other Java process > threads (including the GC thread), so as long as there's no non-RT-safe calls > I think we should be safe from being interrupted by the GC (right?). Probably > the jack process() callback would call some Java code though JNI (like > JJack[1] > does). *If* JNI doesn't do anything non-RT-safe, and *if* it is possible to > avoid doing non-RT-safe stuff at the Java side (by adhering to some rules in > your Java code, much like you'll have to do when writing C code), it'd be > possible to write RT-safe code in Java. there is another if: *if* the jvm can guarantee me that it will only execute jit compiled code in my process callback. without such a guarantee the whole jit compiler is irelevant, since we are only interested in maximum execution times. > > It sounds possible, but there are some big 'ifs' there. > > Of course the more interesting features of Java would probably still be > forbidden to be used in the JACK process() callback. > > > > i dont understand... are you seriously arguing that dynamic languages > > > are always better ? > > > > No! (...) However programming in those languages, prototyping UI's in those > > languages is really tedious. Changing and updating and adapting applications > > for new uses is very frustrating in those environments. > > I tend to disagree: actually I find changing/updating/adapting things in a > dynamic language is more frustrating and tedious because there's no compiler > to tell me which bits I missed. But perhaps we shouldn't rehash the old static > vs dynamic typing debate here ;). no we shouldnt. thats pretty much the point i was referring to. for just quick prototypes dynamic languages are naturally better. -- torben Hohn _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/listinfo/linux-audio-dev
