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: <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> A small point about JVM concurrency performance.

I had the pleasure of talking to James Gosling one to one, for a couple of hours, about three years ago, in Bangalore. He was presenting a talk about his current and on-going work on Java. 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

tipsy). Anyway, I don't assume that the normally resource-expensive JVM approach to threads is the only practical solution. There is likely 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>> > Subject: Re: [erlang-questions] Erlang vs Clojure >> The thought of running on the JVM makes me feel both sick and >> 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

> guarantees cheap processes everywhere it exists.  by contrast, > you get whatever your particular JVM gives you, which might not > be much, and it will vary from platform to platform. > 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>