Hello all,
I am the editor for the J Consortium's real-time core specification, and
I'm trying to make sure the core builds on all of the good work that's being
done by the participants of the Java Memory Model mailing list. (RTJWG
members, you might want to look at
http://www.cs.umd.edu/~pugh/java/memoryModel/workshop/ to get some
background on the issues that are being discussed here.) To offer a little
perspective on what the real-time core is all about, here's a brief
overview:
- the core is like a sidecar to a traditional Java virtual machine.
objects are strictly partitioned between the core domain and the traditional
Java domain. particular methods of core objects may be invoked from the
traditional Java domain, but not vice versa.
- core programmers use traditional Java syntax. however, the core
libraries are slightly different, though similar, to the traditional Java
libraries. in some cases (e.g. class initialization), the semantics of core
features is different than the semantics of traditional Java.
- there is no legacy of core java programs, since the core specification is
not yet final. this means we don't have to worry about breaking existing
code.
- the core is designed for high performance, high determinism, and very low
latency (e.g. tens of microseconds).
- the core does not support any garbage collection. it provides certain
explicit memory management capabilities that Java purists might find
objectionable (e.g. the equivalent of free()).
- the target audience for the core is low-level software, such as device
drivers and infrastructure for higher level real-time services. examples of
higher level real-time services that might be supported by infrastructure
implemented in the core are deadline scheduling, memory partitioning, and
quality-of-service enforcement.
Additional information on the core is available at www.j-consortium.org.
In the remainder of this message, I am going to outline my thoughts
regarding how the core ought to generalize/specialize on the new Java Memory
Model. I am taking as a base document the January 30, 2001 draft of
"Semantics of Multithreaded Java", authored by Jeremy Manson and William
Pugh. I am sharing these thoughts in hopes that members of this group might
offer constructive criticism and insights that I might have overlooked.
1. The core should implement the semantics described in this paper, with the
following exceptions.
2. The core verifier will prevent a constructor from leaking the value of
"this". The effect of this verification requirement is defined to be the
same as declaring this to be a "stackable" variable within each constructor.
(A core stackable variable is a reference variable which may refer to a
stack-allocated object. The core verifier enforces that the values of these
variables are never assigned to a field of a heap object.)
3. The core API does not have System.in, System.out, or System.err. Thus,
we don't need to introduce the concept of write-protected fields.
4. The core does not support garbage collection or finalization. Thus, we
don't have to specify any constraints for finalizers.
5. The core supports asynchronous transfer of control, which is like a
C/Unix kill(). Under the topic of "Explicit Thread Communication", the core
spec would clarify that:
"When thread T2 sends an asynchronous signal to thread T1, it is as
though T2 writes to a hidden volatile signaled field of T1, that is read by
T1 when it begins handling the asynchronous signal"
6. All of the optimizations described in section 8 would be forbidden in
implementation of the core. (Real-time programmers go to great lengths to
carefully design and analyze the real-time behavior of synchronization
locks. We don't want the compiler to second guess us.)
7. In the core, all class initialization is done aggressively, at earliest
opportunity. For this purpose, we adopt the following protocols:
a) A class is not "visible" to arbitrary Java methods until it has been
fully initialized, meaning that all of its final fields have been assigned,
all static initialization code has completed, and the contents of the class'
static fields have been committed to shared memory.
b) Class initializers have special backdoor visibility to the final fields
of classes, even before those classes have been fully initialized. All such
access is conditioned upon dynamic dependency analysis (i.e. I am assuming
the run-time system performs a topological sort on final fields and makes
sure that no final value is consulted until after that final variable has
been assigned). Within class initializers, all accesses to static final
fields are treated as volatile variables. (An implementation of this
behavior may create two versions of all methods that are potentially invoked
from within a static initializer. One of the versions would use the
traditional class lookup service and the other would use the backdoor
service and would treat all static final variables as if they were
volatile.)
7.
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:30 EDT