![]() |
The Java Memory Model and Simulator ppt. - Printable Version +- Free Academic Seminars And Projects Reports (https://easyreport.in) +-- Forum: Seminars Topics And Discussions (https://easyreport.in/forumdisplay.php?fid=30) +--- Forum: Engineering Seminars Topics (https://easyreport.in/forumdisplay.php?fid=7) +---- Forum: Computer Science Seminar Topics (https://easyreport.in/forumdisplay.php?fid=12) +---- Thread: The Java Memory Model and Simulator ppt. (/showthread.php?tid=16969) |
The Java Memory Model and Simulator ppt. - acp - 08-16-2017 [attachment=8484] Jeremy Manson, William Pugh Univ. of Maryland, College Park Java Memory Model and Thread Specification Defines the semantics of multithreaded programs When is a program correctly synchronized? What are the semantics of an incorrectly synchronized program? e.g., a program with data races How Can This Happen? Compiler can reorder statements or keep values in registers On multiprocessors, values not synchronized in global memory Writes go into write buffer Are bypassed by reads Must use synchronization to enforce visibility and ordering as well as mutual exclusion Java Thread Specification Chapter 17 of the Java Language Spec Chapter 8 of the Virtual Machine Spec Very, very hard to understand not even the authors understood it doubtful that anyone entirely understands it has subtle implications that forbid standard compiler optimizations all existing JVMs violate the specification some parts should be violated Revising the Thread Spec JSR 133 will revise the Java Memory Model http://cs.umd.edu/ pugh/java/memoryModel Goals Clear and easy to understand Foster reliable multithreaded code Allow for high performance JVMs Will affect JVMs and badly written existing code including parts of Sun s JDK Proposed Changes Make it clear Allow standard compiler optimizations Remove corner cases of synchronization enable additional compiler optimizations Strengthen volatile make easier to use Strengthen final Enable compiler optimizations Fix security concerns no time to talk about this in this talk Incorrect synchronization Incorrectly synchronized program must have well defined semantics Much other work in the field has avoided defining any semantics for incorrectly synchronized programs Synchronization errors might be deliberate to crack security of a system just like buffer overflows VM Safety Type safety Not-out-of-thin-air safety (except for longs and doubles) No new VM exceptions Only thing lack of synchronization can do is produce surprising values for getfields/getstatics/array loads e.g., arraylength is always correct Synchronization Programming model is (lazy) release consistency A lock acts like an acquire of data from memory An unlock acts like a release of data to memory New Optimizations Allowed Turning synchronizations into no-ops locks on objects that aren t ever locked by any other threads reentrant locks Lock coarsening merging two calls to synchronized methods on same object need to be careful about starvation issues Existing Semantics of Volatile No compiler optimizations Can t hoist read out of loop reads/writes go directly to memory Reads/writes of volatile are sequentially consistent and can not be reordered but access to volatile and non-volatile variables can be reordered makes volatiles much less useful Reads/writes of long/doubles are atomic Proposed New, Additional Semantics for Volatile Write to a volatile acts as a release Read of a volatile acts as an acquire If a thread reads a volatile all writes done by any other thread, before earlier writes to the same volatile, are guaranteed to be visible Conflicting and unclear goals/constraints Three different goals, often in conflict what VM implementers need what Java programmers need for efficient, reliable software for security making the spec clear and simple None of these are clearly or formally specified Immutable Objects Many Java classes represent immutable objects e.g., String Creates many serious security holes if Strings are not truly immutable probably other classes as well should do this in String implementation, rather than in all uses of String Why aren t Strings immutable? A String object is initialized to have default values for its fields then the fields are set in the constructor Thread 1 could create a String object pass it to Thread 2 which calls a sensitive routine which sees the fields change from their default values to their final values Final = Immutable? Existing Java memory model doesn t mention final no special semantics Would be nice if compiler could treat final fields as constant Don t have to reload at memory barrier Don t have to reload over unknown function call Proposed Semantics for Final Read of a final field always sees the value set in constructor unless object is not constructed properly allows other threads to view object before completely constructed Can assume final fields never change Makes string immutable? Problems JNI code can change final fields System.setIn, setOut, setErr Propose to remove this ability hack for setIn, setOut, setErr Objects that can be seen by other threads before constructor is complete Doesn t suffice to make strings immutable Doesn t make Strings immutable No way for elements of an array to be final For Strings, have to see final values for elements of character array So Read of final field is treated as a weak acquire matching a release done when object is constructed weak in that it only effects things dependent on value read no compiler impact Implementation Two implementations Haskell and Java Haskell for rapid prototyping The rules translate easily into Haskell Java for efficiency Much easier to write efficient Java code Helps to ensure understanding of semantics conflicts are sometimes broken implementation, sometimes because semantics are unclear Conclusions PL memory models more complicated than architecture models Have to consider compiler and architecture optimizations balance usability, security and implementability understandable (limited) model for programmers this is how you should program full details understandable by VM implementers and authors of thread tutorials |