자바 메모리 모델에 대하여

Java Memory Model Under The Hood

http://gvsmirnov.ru/blog/tech/2014/02/10/jmm-under-the-hood.html

-> 위의 내용에 대한 간단 요약

1. 하드웨어 레벨에서의 자바 메모리 모델에 대한 설명

메인 메모리를 직접 사용하는 것은 매우 느리므로 캐시를 사용한다.  캐시는 하나의 프로세서에서는 문제없이 잘 동작하지만 프로세서가 여러개(실행이 동시에 여러군데서 되는 경우)인 경우 문제가 매우 복잡해진다(한쪽에서 캐시한 것을 다른 쪽에서 값을 바꾸어 버린다던지 하는 경우가 있을 수 있다.).

cach에 대한 설명: http://arstechnica.com/gadgets/2002/07/caching/2/

- Cache Coherency Protocols

MESI에서 모든 캐시는 아래의 상태를 가진다.
Invalid: 캐시가 메모리의 값을 가지고 있지 않다.
Exclusive: 값이 캐시에 있지만 변경되지 않았다.
Modified: 값이 변경되었지만 메인 메모리에 다시 쓰여지지 않았다.
Shared: 하나 이상의 프로세서가 같은 메모리의 값을 캐시에 가지고 있다.

Shared 상태에 있는 값을 바꾸고 싶으면 Invalidate 메시지를 다른 프로세서에 보내고 ack를 받으면 값을 변경한다. 이것은 시간이 매우 많이 걸리는 문제가 있다. -> Store Buffer를 사용해서 시간 낭비문제를 해결한다: 값을 버퍼에 넣어두고 모든 invalidate 메시지가 오면 값을 commit한다.
- Store Buffer의 두가지 문제점
1. store buffer에 있는 값이 완전히 commit 되지 않았는데 이를 읽어가는 문제가 있을 수 있다: Store Forwarding
2. 값이 버퍼를 떠나는 순서가 보장되지 않는다.

Invalidate Queues: invalidation을 처리하기 위해 도입

- Invalidate 요청이 들어오면 Invalidate Acknowledge 메시지는 바로 보내진다.
- Invalidate는 바로 적용되는 것이 아니라 special queue에 있다가 편리한 때 실행된다.
- 프로세서는 Invalidate를 모두 처리하고 나서야 캐시에 있는 메시지를 처리한다.

* Store Memory Barrier
store buffer에 있는 모든 것들을 다 적용한 후 이후에 오는 것들을 적용한다.
* Load Memory Barrier
invalidate queue에 있는 모든 invalidate들을 적용한 후
2. OpenJDK 소스 레벨에서의 자바 메모리 모델에 대한 설명