I remember seeing some posts about inroads being made with regard to realtime performance on JVMs lately, on Lambda the Ultimate.<br>On the other hand, listening to Software Engineering Radio (<a href="http://www.se-radio.net/podcast/2007-10/episode-73-real-time-systems-bruce-powel-douglass">
this</a> one I think), the expert being interviewed said that Java is practically nonexistent in the realtime space. So... grains of salt with everything, as usual... :)<br><br><br><div class="gmail_quote">On Nov 28, 2007 4:23 AM, G Bulmer <
<a href="mailto:gbulmer@gmail.com">gbulmer@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>A small point about JVM concurrency performance.
<br>I had the pleasure of talking to James Gosling one to one, for a<br>couple of hours, about three years ago, in Bangalore.<br><br>He was presenting a talk about his current and on-going work on Java.<br>He said he spent much of his time on strategic Java projects.
<br>He very excited about a research JVM which was being built and tested<br>for use in hard realtime, the project he talked about as specifically<br>for process control in a power plant.<br><br>Anyway, in his initial presentation (after which we chatted) he
<br>showed stats from the research JVM that indicated good support for<br>many thousands of threads (I accept, still well behind the Erlang VM,<br>but I'd need more detail to judge how far behind) with interrupt<br>response times with a jitter of less than 4 micro-seconds  (I am sure
<br>this was at least response to timer events, and may have been to<br>other interrupt sources).<br><br>I am certain I asked about garbage collection, and he said that the 4<br>micro-seconds was not an overall average, but was 'realtime', and it
<br>included garbage collection.<br><br>I don't recall many more details other than the company involved in<br>the process control project (who I feel I should not disclose as he<br>was tired, jet lagged, home sick for his kids, and maybe a little
<br>tipsy).<br><br>Anyway, I don't assume that the normally resource-expensive JVM<br>approach to threads is the only practical solution. There is likely<br>significant investment in fixing some of those Java problems.
<br><br>GB<br><br>PS - I apologise that I haven't followed it up. I remember at the<br>time feeling I should not expect to see anything for a year or more.<br>I may try digging some time next week (when I return from my lovely
<br>Thai holiday, the weather is beautiful here, much warmer than<br>Stockholm EUC, and booze and food are cheaper too :-)<br><br><br>> Date: Mon, 26 Nov 2007 09:43:18 +0000<br>> From: Charles Forsyth <<a href="mailto:forsyth@terzarima.net">
forsyth@terzarima.net</a>><br>> Subject: Re: [erlang-questions] Erlang vs Clojure<br>>> The thought of running on the JVM makes me feel both sick and<br>>> bloated...but strangely I am warming up to the idea.
<br>>><br>><br>><br>>> The ErlangVM enables distributed concurrency, Closure on the JVM is<br>>> optimizing for local concurrency.<br>>><br>><br>><br>>> Granted that I am not building fault tolerant telecom switches,
<br>>> but in<br>>> my case, massive local concurrency might be all that I need.  With<br>>><br>><br>> if you expect to get high-performance concurrency from a JVM<br>> i expect you to be disappointed.  the Erlang implementation
<br>> guarantees cheap processes everywhere it exists.  by contrast,<br>> you get whatever your particular JVM gives you, which might not<br>> be much, and it will vary from platform to platform.<br>> if it works for you, though ...
<br>> i'd be particularly interested if you find JVMs that<br>> offer ``massive local concurrency''.<br>><br>_______________________________________________<br>erlang-questions mailing list<br><a href="mailto:erlang-questions@erlang.org">
erlang-questions@erlang.org</a><br><a href="http://www.erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://www.erlang.org/mailman/listinfo/erlang-questions</a><br></blockquote></div><br>