The Java memory model is fatally flawed
The work
| Authors | William Pugh |
|---|---|
| Editors | |
| Type | article |
| Year | 2000 |
| Citekey | pugh2000java |
Where it appeared
| Published in | Concurrency Practice and Experience |
|---|---|
| Publisher | Wiley |
| Volume | 12 |
| Issue | 6 |
| Pages | 445--455 |
Identifiers
| DOI | 10.1002/1096-9128(200005)12:6<445::aid-cpe484>3.0.co;2-a |
|---|---|
| OpenAlex | W2033818578 |
Access
| Landing page | https://doi.org/10.1002/1096-9128(200005)12:6<445::aid-cpe484>3.0.co;2-a |
|---|
From OpenAlex, which stores abstracts as an index of words and their positions: what is shown is rebuilt from that, and reads fluently whether or not it is what the author wrote.
Abstract
The Java memory model described in Chapter 17 of the Java Language Specification gives constraints on how threads interact through memory. This chapter is hard to interpret and poorly understood; it imposes constraints that prohibit common compiler optimizations and are expensive to implement on existing hardware. Most JVMs violate the constraints of the existing Java memory model; conforming to the existing specification would impose significant performance penalties. In addition, programming idioms used by some programmers and used within Sun's Java Development Kit is not guaranteed to be valid according to the existing Java memory model.Furthermore, implementing Java on a shared-memory multiprocessor that implements a weakmemory model poses some implementation challenges not previously considered. Copyright © 2000 John Wiley & Sons, Ltd.
How it got here
| How it got here | agent via openalex |
|---|---|
| Added | 2026-10-26 13:12 UTC |
| Not denied by | a person 2026-10-29 17:12 UTC |
Cite it as
@article{pugh2000java,
title = {The Java memory model is fatally flawed},
author = {William Pugh},
year = {2000},
journal = {Concurrency Practice and Experience},
publisher = {Wiley},
volume = {12},
number = {6},
pages = {445--455},
doi = {10.1002/1096-9128(200005)12:6<445::aid-cpe484>3.0.co;2-a},
}
This record lives at https://refs.drheap.org/pugh2000java/ and will keep doing so.