The Java Memory Model and Simulator ppt.
#1



[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



Reply

Important Note..!

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

ASK HERE

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
Popular Searches: qualnet simulator ppt, routing simulator java, seminar on memory handling in java, cocomo model ppt, ppt for holograhic memory, zeroizing memory in java, ddr 2 ddr3 memory ppt,

[-]
Quick Reply
Message
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
  Resistive random-access memory (RRAM) project topics 4 3,216 13-04-2017, 10:49 AM
Last Post: jaseela123d
  Direct Memory Access computer science crazy 2 3,695 29-01-2015, 02:00 AM
Last Post: Guest
  E-COMPILER FOR JAVA WITH SECURITY EDITOR smart paper boy 7 11,749 27-07-2013, 01:06 PM
Last Post: computer topic
  E-COMPILER FOR JAVA WITH SECURITY EDITOR seminar class 9 13,521 24-06-2013, 11:44 AM
Last Post: Guest
  Java Cryptography Architecture (JCA) seminar projects crazy 1 2,563 17-12-2012, 01:51 PM
Last Post: seminar details
Lightbulb Java Cryptography Architecture (JCA) computer science crazy 1 2,611 17-12-2012, 01:51 PM
Last Post: seminar details
  Hydra: A Block-Mapped Parallel Flash Memory Solid-State Disk Architecture summer project pal 3 2,922 01-12-2012, 12:40 PM
Last Post: seminar details
  A survey of usage of Data Mining and Data Warehousing in Academic Institution and Lib seminar class 1 2,118 29-11-2012, 12:56 PM
Last Post: seminar details
  FLASH MEMORY seminar surveyer 3 3,431 27-11-2012, 01:40 PM
Last Post: seminar details
  Intelligent Electronic Devices (IEDs) and Supervisory Control and Data Acquisition computer girl 0 1,141 09-06-2012, 06:01 PM
Last Post: computer girl

Forum Jump: