jrate-devel Mailing List for jRate

Hello all,

Beta version 0.3.8beta-3.3.3 of jRate is now available for download.

This release of jRate has some requested features and bugfixes.
One-shot timers have been implemented, RealtimeThreads have more
stable release times, cost-overrun and full deadline-miss handling is
now implemented, and AsyncEventHandlers are more RTSJ-like.  Some
segfaults have been cleaned up.  Also, the compiler emits heap checks
so that you'll get the right exception when touching the heap in a
NoHeapRealtimeThread context.  (At present the heap checks are only
performed when compiling from bytecode though.)

(Don't get too excited about the ATC note below---ATC isn't yet
functional.)

Download jRate:      http://jrate.sourceforge.net/Download.php

jRate home page:     http://jrate.sourceforge.net
jRate project page:  http://jrate.sourceforge.net/project

User-visible changes to jRate from 0.3.7-3.3.3 to 0.3.8beta-3.3.3:

* RealtimeThreads now honor the correct "start" time in
  ReleaseParameters.  Also, periodic releases now correct for period
  drift on non-RTOSes.

* Cost overrun handling implementation.  Still needs work to be
  compliant to spec.

* Preemptive deadline miss handler implementation (handle deadline
  misses *before* the end of the period).

* RealtimeThread.waitForNextPeriod() is now a static method in
  accordance with the spec.

* Regular (non-realtime) Java threads now take the allocation context
  that the java.lang.Thread was allocated in (Heap or Immortal, or
  MethodArea).  This is in accordance with the clarification posted at
  http://www.rtsj.org/specInterpretation.html.

* OneShotTimers implemented.

* AsyncEventHandlers overhauled.  ThreadedAsyncEventHandler no longer
  exists (it was off-spec and its functionality is the same as the new
  AsyncEventHandler implementation).

* NoHeapRealtimeThreads fully implemented with heap checks.  Specify
  the new -fno-heap-check compiler flag to elide the heap checks.
  (LIMITATION: For now, these checks are only generated when compiling
  from bytecode.)

* Rudimentary Asynchronous Transfer of Control (ATC) support, and
  checks for pending AIEs at interruptibility boundaries.  Specify the
  new -fno-interruptible-check compiler flag to elide the checks.
  (LIMITATION: Incomplete support; work in progress.)

* In PeriodicParameters, a null start time means start immediately (as
  if it were RelativeTime(0, 0)).  Previously crashes were possible on
  null values.

* Added MITViolationException and ResourceLimitError classes (still
  aren't hooked up though)

* Increased RTSJ compliance

Thanks for your interest in jRate!

Morgan
-- 
Morgan Deters
md...@mo...

Hello Morgan,

Morgan Deters wrote:
> Hi -
> 
> jrate.net, jrate.com, and jrate.org are all registered (though none
> appears to have any public web content).  Were any of these registered
> on behalf of jRate?

No :-/

> If so, we *could* direct it to jrate.sourceforge.net.  But I'm even
> more interested right now in having a permanent home for jRate's
> extensions to the RTSJ.  It would be convenient if we had a
> "net.jrate" Java package to put jRate-specific classes in, etc.
> It would be best if this namespace mirrored a jRate-related domain.

We could register it as jrate.eu. I checked and this
is indeed free.

What do you think?

Ciao,
    Angelo

Hi -

jrate.net, jrate.com, and jrate.org are all registered (though none
appears to have any public web content).  Were any of these registered
on behalf of jRate?

If so, we *could* direct it to jrate.sourceforge.net.  But I'm even
more interested right now in having a permanent home for jRate's
extensions to the RTSJ.  It would be convenient if we had a
"net.jrate" Java package to put jRate-specific classes in, etc.
It would be best if this namespace mirrored a jRate-related domain.

Morgan
-- 
Morgan Deters
md...@mo...

Hi all,

Since the release of 0.3.7-3.3.3 a week ago, I have made some
enhancements to jRate that I believe are of use to the general jRate
user base.  I plan to release a somewhat-stable development snapshot
with these features soon, since CVS versions of jRate are likely to be
quite *unstable* in the near future.

New features/bugfixes since 0.3.7-3.3.3 include:

* Implementation of one shot timers (as noted by Damien, jRate's one
  shot timers were previously unusable)

* Proper first-release behavior for periodic tasks (previously the
  periodic releases were perfect, but the first release could be too
  soon or too late)

* Heap checks for NoHeapRealtimeThreads (currently only performed when
  you compile from Java bytecode; I'm still working on inserting heap
  checks when compiling from Java source).  As mandated by the spec,
  not only is heap pointer dereference illegal, but even pointer
  *copy*.  Thus, explicit checks must be inserted by the compiler on
  field and array accesses, and this will result in some overhead even
  for regular RealtimeThreads that can touch the heap.  In the future
  I hope to measure and minimize this overhead.  There is also a
  compiler option to elide the checks entirely.

I'm currently tracking down a segfault in the jRate initialization
code that only seems to pop up on a new toy of mine (a ppc405 board).
When this is finished, I'll try to cut the snapshot release.  When I
do so, I'll post a note on the jrate-devel and jrate users mailing
lists.

Morgan
-- 
Morgan Deters
md...@mo...