A. Gontmakher and A. Schuster. Java consistency: non-operational characterizations for Java memory behavior. ACM Transactions on Computer Systems, 18(4), 2000.  Home/Search   Document Details and Download   Summary   Related Articles   Check

....should be the semantics for multithreaded Java Instead, it argues that multithreaded Java semantics (the current one or any future improvement) should be incorporated into Java program verification. Since the inception of the JMM, several formalizations of Java concurrency have been proposed, [5, 8, 15, 17] to name a few. Some of these [5] focus only on language level concurrency constructs without considering the memory model. Some others [8, 15] construct non executable specifications of the memory model. Most importantly, the goal of all these works is to have a clear understanding of Java ....

....be incorporated into Java program verification. Since the inception of the JMM, several formalizations of Java concurrency have been proposed, 5, 8, 15, 17] to name a few. Some of these [5] focus only on language level concurrency constructs without considering the memory model. Some others [8, 15] construct non executable specifications of the memory model. Most importantly, the goal of all these works is to have a clear understanding of Java concurrency (via formal specification) and then perform human reasoning. Our goal is di#erent. We have developed an executable formal JMM ....

A. Gontmakher and A. Schuster. Java consistency: non-operational characterizations for Java memory behavior. ACM Transactions on Computer Systems, 18(4), 2000.

....threads to keep locally cached copies of objects. Consistency is provided by requiring that a thread s object cache be flushed upon entry to a monitor and that local modifications made to cached objects be transmitted to the central memory when a thread exits a monitor. Gontmakher and Schuster [9] have shown that the JMM provides Release Consistency for synchronized access to non volatile variables and stricter forms of consistency for the other cases. That is, Java Consistency is equivalent to Release Consistency in most cases. The concept of main memory is implemented with DSM PM2 via a ....

A. Gontmakher and A. Schuster. Java consistency: Non-operational characterizatons for Java memory behavior. In Proc. of the Workshop on Java for High-Performance Computing, Rhodes, June 1999.

....focus on the language s safety properties. There have been comparatively few attempts to formalize Java s memory model. The problems of the Java memory model are characterized succinctly by Pugh [13] Others formalize these problems, and compare Java s properties to those of extant memory models [7]. DAG Consistency and Location Consistency are two memory models that can be applied to the semantics of multithreaded programs. DAG Consistency [3] is a memory model that is defined using the directed acyclic graph (DAG) of user level threads that make up a parallel computation. Intuitively, ....

A. Gontmakher and A. Schuster. Java consistency: Non-operational characterizations for java memory behavior. Technion/CS Technical Report CS0922, Computer Science Department, Technion, Nov. 1997.

....a weak memory model poses some implementation challenges not previously considered. 1 Introduction The Java memory model, as described in chapter 17 of the Java Language Specification [GJS96] is very hard to understand. Research papers that analyze the Java memory model interpret it di#erently [GS97, CKRW97, CKRW98] Guy Steele (one of the authors of [GJS96] was unaware that the memory model prohibited common compiler optimizations, but after several days of discussion at OOPSLA98 agrees that it does. Given the di#culty of understanding the memory model, there may be disagreements as to ....

....stores (with prescient stores, delete orderings from assign actions to store actions) 2 Features of the Memory Model Due to the double indirection in the Java memory model, it is very hard to understand. What features does it provide Consider the example in Figure 1. Gontmakher and Schuster [GS97] state that this is an execution trace that is illegal for Java, but they are incorrect because they do not consider prescient stores [GJS96, 17.8] Without prescient stores, the actions and ordering constraints required by the JMM are shown in Figure 2. Since the write of y is required to come ....

[Article contains additional citation context not shown here]

Alex Gontmakher and Assaf Schuster. Java consistency: Non-operational characterizations for the java memory behavior. Technical Report CS0922, Dept. of Computer Science, Technion, November 1997.

....Java imposes on the outcomes of the read and write operations used by the programmer. This work was supported in part by research grant OGP0041900 and a post graduate scholarship both from the Natural Sciences and Engineering Research Council of Canada. Previous work by Gontmakher and Schuster [5, 6] provides such a definition (henceforth denoted Java 1 ) of Java memory consistency (Section 4.1) Java 1 captures the possible outcomes of any terminating Java computation. However, as will be seen, for terminating computations it is possible to circumvent dealing explicitly with the ....

....a stale value rather than seeing a newly written value. We use the term fixate for this kind of invisibility. To define the memory consistency model of Java, the obstacles that arise from covert and fixate invisibilities can be cleanly and elegantly finessed as long as computations are finite [5, 6] as shown in Section 4.1. Those ideas, however, do not suffice for non terminating Java computations. After resolving exactly what is meant by a consistency condition for a non terminating system in Section 4.2, we provide a new definition of consistency that is correct for both terminating and ....

[Article contains additional citation context not shown here]

A. Gontmakher and A. Schuster. Java consistency: Non-operational characterizations of Java memory behavior. Technical Report CS0922, Computer Science Department, Technion, November 1997.

....This paper reviews these issues and suggests replacement memory models for Java. 1 Introduction The Java memory model, as described in chapter 17 of the Java Language Specification [GJS96] is very hard to understand. Research papers that analyze the Java memory model interpret it di#erently [GS97, CKRW97, CKRW98] Guy Steele (one of the authors of [GJS96] was unaware that the memory model prohibited common compiler optimizations, but after several days of discussion at OOPSLA98 agrees that it does. Given the di#culty of understanding the memory model, there may be disagreements as to ....

....cached writes out to main memory before starting a new thread. This has been acknowledged as a bug. 2.2 Interpretation Due to the double indirection in the Java memory model, it is very hard to understand. What features does it provide Consider the example in Figure 1. Gontmakher and Schuster [GS97] state that this is an execution trace that is illegal for Java, but they are incorrect because they do not consider prescient stores [GJS96, 17.8] Without prescient stores, the actions and ordering constraints required by the JMM are shown in Figure 2. Since the write of y is required to come ....

[Article contains additional citation context not shown here]

Alex Gontmakher and Assaf Schuster. Java consistency: Non-operational characterizations for the java memory behavior. Technical Report CS0922, Dept. of Computer Science, Technion, November 1997.

....with a formal and precise definition of the memory behavior of JVM. The definition should be given in the programmer s terms, by specifying the constraints that Java imposes on the outcomes of the read and write operations used by the programmer. Previous work by Gontmakher and Schuster [5, 6] provides such a definition (henceforth denoted Java 1 ) of Java memory consistency (Section 4.1) Java 1 captures the possible outcomes of any terminating Java computation. However, as will be seen, for terminating computations it is possible to circumvent dealing explicitly with the invisibility ....

....a stale value rather than seeing a newly written value. We use the term fixate for this kind of invisibility. To define the memory consistency model of Java, the obstacles that arise from covert and fixate invisibilities can be cleanly and elegantly finessed as long as computations are finite [5, 6] as shown in Section 4.1. Those ideas, however, do not suffice for non terminating Java computations. After resolving exactly what is meant by a consistency condition for a non terminating system in Section 4.2, we provide a new definition of consistency that is correct for both terminating and ....

[Article contains additional citation context not shown here]

A. Gontmakher and A. Schuster. Java consistency: Non-operational characterizations of Java memory behavior. Technical Report CS0922, Computer Science Department, Technion, November 1997.

....of objects. Consistency is provided by requiring that a thread s object cache be flushed upon entry to a monitor and that local modifications made to cached objects be transmitted to the central memory when a thread exits a monitor. Therefore Java provides a variant of release consistency [5] See [6] for a detailed discussion. Therefore, in the above code example another possibility is that Thread 1 will print out its message, but Thread 0 will still loop forever. This is because Thread 1 s setting of the flag may only be made to its local copy of the object and without the use of a monitor ....

A. Gontmakher and A. Schuster. Java consistency: Non-operational characterizatons for Java memory behavior. Technical Report CS0922, Technion, 1997.

No context found.

A. Gontmakher and A. Schuster. Java consistency: non-operational characterizations for Java memory behavior. ACM Transactions on Computer Systems, 18(4), 2000.

No context found.

A. Gontmakher and A. Schuster. Java consistency: Non-operational characterizations for Java memory behavior. In the Workshop on Java for High-Performance Computing, Rhodes, June 1999.

No context found.

A. Gontmakher and A. Schuster. Java consistency: Non-operational characterizations for Java memory behavior. In the Workshop on Java for High-Performance Computing, Rhodes, June 1999.

No context found.

Gontmakher, A., Schuster, A.: Java consistency: Non-operational characterizations for Java memory behavior. ACM Trans. on Comp. Sys. 18(4) (2000) 333-386

No context found.

A. Gontmakher and A. Schuster. Java consistency: non-operational characterizations for Java memory model. In ACM Transactions On Computer Systems, vol. 18, No. 4, pages 333-386, November 2000.

No context found.

A. Gontmakher and A. Schuster. Java consistency: Non-operational characterizations for Java memory behavior. In the Workshop on Java for HighPerformance Computing, Rhodes, June 1999.

No context found.

Gontmakher, A., Schuster, A.: Java consistency: Non-operational characterizations for Java memory behavior. ACM Trans. on Comp. Sys. 18(4) (2000) 333-386

Online articles have much greater impact   More about CiteSeer.IST   Add search form to your site   Submit documents   Feedback  

CiteSeer.IST - Copyright Penn State and NEC