Section 1: Identification

Name of Contact Person: Tim Lindholm

E-Mail Address: Timothy.Lindholm@sun.com

Telephone Number: 408-343-1441

Fax Number: 408-343-1482

Specification Lead: Tim Lindholm

E-Mail Address: Timothy.Lindholm@sun.com

Telephone Number: 408-343-1441

Fax Number: 408-343-1482

Initial Expert Group Membership:
(Please provide company or organization names. Note that expert group members must have signed the JSPA.)

• Sun Microsystems
• Compaq
• IBM
• HP
• William Pugh, Univ. of Maryland
• Doug Lea, SUNY Oswego
• Sarita Adve, Univ. of Illinois at Urbana-Champaign

Section 2: Request

2.1 - Please describe the proposed Specification:

The specification is expected to revise substantially Chapter 17 of "The Java Language Specification" and Chapter 8 of "The Java Virtual Machine Specification". It is not expected to result in changes to existing APIs, but might clarify the semantics of some existing methods in java.lang.Thread and java.lang.Object (java.lang.Object defines the wait and join methods).

2.2 - What is the target Java platform? (i.e., desktop, server, personal, embedded, card, etc.)

Given that the Java programming language and Java virtual machine are affected, the revision must be accepted into an umbrella JSR for the J2SE platform for the changes to be made available.

Not all users of Java technologies will be directly affected by the change. For instance Enterprise Java Beans are constrained to be single threaded, so the revision is not expected to impact EJB developers (but is likely to impact developers of EJB containers, which are typically multithreaded).

2.3 - What need of the Java community will be addressed by the proposed specification?

Java virtual machine (JVM) implementors need to be able to implement high-performance JVMs without violating the JVM specification.

2.4 - Why isn't this need met by existing specifications?

Unfortunately, the current specification has been found to be hard to understand and has subtle, often unintended, implications. Certain synchronization idioms sometimes recommended in books and articles are invalid according to the existing specification. Subtle, unintended implications of the existing specification prohibit common compiler optimizations done by many existing Java virtual machine implementations. Enforcing these aspects of the specification would be prohibitively expensive on many existing processor architectures. It is doubtful that enforcement of these implications would be useful to programmers, regardless of the cost of enforcing them. Several important issues, such as the interaction between synchronization and final fields, simply aren't discussed in the existing specification.

2.5 - Please give a short description of the underlying technology or technologies:

• The semantics of "correctly synchronized" programs should be as simple and intuitive as feasible. Thus, "correctly synchronized" should be defined both formally and intuitively
• The semantics of incompletely or incorrectly synchronized programs should be defined so that such programs cannot be used to attack the security of a system
• Programmers should be able to create multithreaded programs with confidence that they will be reliable and correct
• High performance JVM implementations across a wide range of popular hardware architectures should be possible
• There should be minimal impact on existing code

• Volatile variables
• Final variables
• Immutable objects (objects whose fields are only set in their constructor)
• Thread- and memory-related JVM functionality and APIs such as class initialization, asynchronous exceptions, finalizers, thread interrupts, and the sleep, wait, and join methods of class Thread

• There exist a number of common but dubious coding idioms, such as the double-checked locking idiom, that are proposed to allow threads to communicate without synchronization. Almost all such idioms are invalid under the existing semantics, and are expected to remain invalid under the proposed semantics.
• Most programmers assume that immutable objects such as String do not need synchronization. Unfortunately, in an incorrectly synchronized program it is possible for a thread to observe a unsynchronized immutable object change. In particular, it is possible for a String to first appear to have the value "/tmp", and on later observation appear to have the value "/usr". This has clear and serious implications for security. We propose changing the semantics to allow for efficient immutable objects, even in the presence of data races.
• As part of this effort, we will document the potential implementation impact of proposed semantics. In particular, some proposed semantics may be more expensive to implement on processors with weak memory models or expensive synchronization.
• Some of the proposed revisions, particularly to the semantics of volatile and final variables, may require that JVM implementations be changed in order to be compliant with the new specification. However, some implementations have already been changed in anticipation of the proposed revision, and are likely to remain compliant under it.

2.6 - Is there a proposed package name for the API Specification? (i.e., javapi.something, org.something, com.something, etc.)

2.7 - Does the proposed specification have any dependencies on specific operating systems, CPUs, or I/O devices that you know of?

2.8 - Are there any security issues that cannot be addressed by the current security model?

2.9 - Are there any internationalization or localization issues?

2.10 - Are there any existing specifications that might be rendered obsolete, deprecated, or in need of revision as a result of this work?

Such changes will strive to retain as clearly valid all patterns that are valid according to the existing specification and in significant use in deployed Java software.  Thus, existing binary applications that exclusively make use of currently valid coding idioms should run unchanged. The effort will also attempt to make valid certain currently illegal idioms that are occasionally used nonetheless by the community, if it is possible to do so economically. Where that is impossible, the spec will clarify that the idioms are invalid and should not be used.

2.11 - Please describe the anticipated schedule for the development of this specification.

2.12 - What working style do you anticipate for the working group?

Section 3: Contributions

3.1 - Please list any existing documents, specifications, or implementations that describe the technology. Please include links to the documents if they are publicly available.

1. Fixing the Java memory model, Proceedings of the ACM 1999 conference on Java Grande, 1999 Pages 89-98. (Slides from talk) -- this paper sets out some of the problems with the existing specification, although the solution proposed in this paper has been found to be inadequate and it not recommended for consideration.
2. The Java Memory Model, Section 2.2.7 of Concurrent Programming in Java, 2^nd edition, Doug Lea, Addison Wesley, 1999
3. Proposed revision to Section 17.4, Wait Sets and notification, Doug Lea
4. JavaOne 2000 BOF on revising the Java Thread Spec
5. Improving the Java Memory Model with CRF, Jan-Willem Maessen, Arvind and Xiaowei Shen, Computation Structures Group Memo 428, MIT, 2000.
6. Multithreaded semantics for Java, by Jeremy Manson and William Pugh, available as UMCP CS Tech Report #4215.

A subset of this paper, Core Multithreaded semantics for Java, by Jeremy Manson and William Pugh, will appear at Java Grande 2001.
7. JDC bug # 4329831: Hotspot compiler does not respect existing Memory Model

3.2 - Explanation of how these items might be used as a starting point for the work.