e Java Memory Model . Jesper qvist . . . e Java Environment . . - - PowerPoint PPT Presentation

e java memory model
SMART_READER_LITE
LIVE PREVIEW

e Java Memory Model . Jesper qvist . . . e Java Environment . . - - PowerPoint PPT Presentation

. e Java Memory Model . Jesper qvist . . . e Java Environment . . . 2 . . e Java Environment . . . 3 . . Java Execution . Possible reordering due to Compiler, JVM, or CPU! Plus visibility problems due to CPU caches! .


slide-1
SLIDE 1

.

e Java Memory Model

. Jesper Öqvist .

slide-2
SLIDE 2

. .

e Java Environment.

. . 2

slide-3
SLIDE 3

. .

e Java Environment.

. . 3

slide-4
SLIDE 4

. .

Java Execution.

Possible reordering due to Compiler, JVM, or CPU! Plus visibility problems due to CPU caches!

. . 4

slide-5
SLIDE 5

. .

Reordering.

Q: Why are operations reordered? A: To increase performance! Doing the add after the mul can avoid a couple stall cycles in the CPU, depending on what follows.

. . 5

slide-6
SLIDE 6

. .

Caches.

Q: What about the visibility? Why do we need caches? A:

. . 6

slide-7
SLIDE 7

. .

Caches.

Main memory is large and cheap. How slow? Typically 100-300 clock cycles slow. We really really want to avoid main memory, but how? Store commonly used stuff in smaller, cheaper memory called caches! An L1 read takes only about 3-5 cycles!

. . 7

slide-8
SLIDE 8

. .

Caches.

Main memory is large and cheap. How slow? Typically 100-300 clock cycles slow. We really really want to avoid main memory, but how? Store commonly used stuff in smaller, cheaper memory called caches! An L1 read takes only about 3-5 cycles!

. . 7

slide-9
SLIDE 9

. .

Caches.

Main memory is large and cheap. How slow? Typically 100-300 clock cycles slow. We really really want to avoid main memory, but how? Store commonly used stuff in smaller, cheaper memory called caches! An L1 read takes only about 3-5 cycles!

. . 7

slide-10
SLIDE 10

. .

Caches, cont..

Each core has it's own cache, so now we have cache coherence problems! These nitty gritty details we leave to the hardware and JVM!

. . 8

slide-11
SLIDE 11

. .

e Java Memory Model.

To avoid the headache of knowing what is happening beneath our application, the JMM provides simple rules. Most importantly: what happens in a single thread is visible in sequential order!

. . 9

slide-12
SLIDE 12

. .

Synchronization -- unlock of an intrinsic lock happens before the locking of the same lock. Volatile fields -- writing to a volatile field always happens before reading from it.

. . 10

slide-13
SLIDE 13

. .

Publication.

Q: Is this safe publication?

class Point { public int x; public int y; public Point(int x, int y) { this.x = x; this.y = y; } }

A: It depends on how objects of the class are used!

. . 11

slide-14
SLIDE 14

. .

Publication.

Q: Is this safe publication?

class Point { public int x; public int y; public Point(int x, int y) { this.x = x; this.y = y; } }

A: It depends on how objects of the class are used!

. . 11

slide-15
SLIDE 15

. .

class A { public static Point p = null; public void init() { p = new Point(2, 3); } public int sum() { if (p == null) { init(); } return p.x + p.y; } }

It is possible that one thread at some point sees the value 3

  • f sum, meaning that only the y value was initialized, even

though x should have been initialized first!

. . 12

slide-16
SLIDE 16

. .

Publication.

Obviously the previous example had other problems too. There was no synchronization around the null check and call to init, allowing several threads to attempt to initialize the point simultaneously.

. . 13

slide-17
SLIDE 17

. .

Synchronization often solves visibility problems. Had we used synchronization in the Point example then all threads acquiring the intrinsic lock (Point.class could act as lock) would have seen the fully initialized point because the locking happened before the unlocking which happened before the initialization.

. . 14

slide-18
SLIDE 18

. .

. . 15

slide-19
SLIDE 19

. .

Initialization Safety.

Final fields have special initialization privileges. Their initialized value is always visible regardless of how their enclosing objects are published. * * IF the constructor does not leak references to them.

. . 16

slide-20
SLIDE 20

. .

Questions?.

Questions?

. . 17

slide-21
SLIDE 21

. .

Exercises.

  • 1. Create a class with a static lazily initialized field that is

safely published. The field is accessed through a method which can initialize it.

  • 2. Is there any other way to safely initialize the static

field? Possibly without the initialization method?

. . 18