RTSJ or JSR-000001

[zingbat]

What is this stuff exactly? It looks like a bunch of good ideas for real-time applications that were never implemented by any jvm in pratice.

http://jcp.org/aboutJava/communityprocess/first/jsr001/index.html

http://java.sun.com/javase/technologies/realtime.jsp

[shawnkendall]

What is this stuff exactly? It looks like a bunch of good ideas for real-time applications that were never implemented by any jvm in pratice.

http://jcp.org/aboutJava/communityprocess/first/jsr001/index.html

http://java.sun.com/javase/technologies/realtime.jsp

It is good stuff...
And it did get fully implemented.... in the JVM in MY MIND! WAHAHAHAHHA!

[zingbat]

Actualy i noticed this RTSJ thing when you put a link to Javolution in the Tools forum. That api claims to be RTJS compliant .

    *   Safe/transparent object recycling (faster than memory recycling, aka GC).
    * Fast/easy parallel computing support with concurrent contexts.
    * High performance and real-time compliant util / lang / text / io / xml base classes.
    * Struct and Union base classes for direct interfacing with native applications.
    * Java fastest xml parsing and marshalling/unmarshalling facility.

The safe transparency object recycling thing is suposed to be some trick that works as if we were allocating objects on the stack in C++.

Games published by our own members! Check 'em out!

[CaptainJester]

Sun has implemented a JVM with this.  However, you have to pay for it.

[zingbat]

Bastards!

[CommanderKeith]

But these Real-Time programmers are more concerned with determinism/predictability as a priority, rather than just performance- that's what I read in the 'Dreams' section.

So they wouldn't like the GC-pauses or hotpsot dynamic compilation pauses, but so long as they're really short, isn't it better for us to have better over-all performance with a small startup time?  As far as I know that's the way the client JVM has gone - dynamic hotspot compilation at bottlenecks only & dynamic GC'ing (I imagine that static GC'ing is possible too - ie without a GC thread).

It's interesting how they say that a hardware JVM is possible.  It's a one-liner in the 'Dreams' section.  That would be awesome, imagine a hardware JVM console - the JBox or the JayStation! 

[Mr_Light]

don't forget the Jii sounds very urban like: ey, what up Jii!

[zingbat]

"(I imagine that static GC'ing is possible too - ie without a GC thread)"

To make the JVM deterministic the only thing we need is an option control the gc programaticaly but this isn't a big issue since the gc already does a good job by itself.

There are other issues like the latency time that occurs when switching a thread. Aparently this is affected by the os kernel the jvm runs on and theres not much to do about it. It affects c++ games and java games equaly.

The thing that i miss more are structs/unions and stack allocated objects.