The Java Memory Model and Simulator ppt.
Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
seminar surveyer
Active In SP

Posts: 3,541
Joined: Sep 2010
27-01-2011, 03:02 PM

.ppt   MemModel.ppt (Size: 201.5 KB / Downloads: 75)

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
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


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?


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
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


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


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


Important Note..!

If you are not satisfied with above reply ,..Please


So that we will collect data for you and will made reply to the request....OR try below "QUICK REPLY" box to add a reply to this page

Quick Reply
Type your reply to this message here.

Image Verification
Please enter the text contained within the image into the text box below it. This process is used to prevent automated spam bots.
Image Verification
(case insensitive)

Possibly Related Threads...
Thread Author Replies Views Last Post
  Computer Memory Based on the Protein Bacteriorhodopsin seminar projects crazy 16 9,050 06-09-2015, 04:54 PM
Last Post: Larbaski
  Wireless Sensor Network Security model using Zero Knowledge Protocol seminar ideas 2 1,449 31-03-2015, 09:08 AM
Last Post: Guest
  credit card fraud detection using hidden markov model project download jaseelati 0 295 10-01-2015, 01:34 PM
Last Post: jaseelati
  Java EE seminar ideas 6 4,215 14-11-2014, 06:59 PM
Last Post: alokigorRob
  Object Oriented Programming with Java seminar paper 2 1,079 18-09-2014, 03:24 PM
Last Post: Radhika.m
Video Random Access Memory ( Download Full Seminar Report ) computer science crazy 2 2,417 10-05-2014, 09:44 AM
Last Post: seminar project topic
  E-COMPILER FOR JAVA WITH SECURITY EDITOR seminar class 18 9,992 08-10-2013, 09:07 PM
Last Post: Guest
  E-COMPILER FOR JAVA PPT seminar projects maker 0 573 27-09-2013, 02:38 PM
Last Post: seminar projects maker
  Building Java Web services with NetBeans 7 seminar projects maker 0 431 24-09-2013, 12:44 PM
Last Post: seminar projects maker
  Memory Management: Overlays and Virtual Memory ppt seminar projects maker 0 490 20-09-2013, 04:57 PM
Last Post: seminar projects maker