Java memory model - Revision history

GhostInTheMachine: Reverting edit(s) by 103.20.125.4 (talk) to rev. 1247703872 by Kvng: Vandalism (RW 16.1)

2024-11-14T11:48:48Z

Reverting edit(s) by 103.20.125.4 (talk) to rev. 1247703872 by Kvng: Vandalism (RW 16.1)

← Previous revision		Revision as of 11:48, 14 November 2024
Line 3:		Line 3:
	The '''Java memory model''' describes how [[thread (computer science)\|threads]] in the [[Java (programming language)\|Java programming language]] interact through memory. Together with the description of single-threaded execution of code, the memory model provides the [[formal semantics of programming languages\|semantics]] of the Java programming language.		The '''Java memory model''' describes how [[thread (computer science)\|threads]] in the [[Java (programming language)\|Java programming language]] interact through memory. Together with the description of single-threaded execution of code, the memory model provides the [[formal semantics of programming languages\|semantics]] of the Java programming language.

	The original Java memory model developed in 1995, was widely perceived as broken,<ref>{{cite journal \|last1=Pugh \|~~fjirst1~~=William \|title=The Java memory model is fatally flawed \|journal=Concurrency: Practice and Experience \|date=2000 \|volume=12 \|issue=6 \|pages=445–455 \|doi=10.1002/1096-9128(200005)12:6<445::AID-CPE484>3.0.CO;2-A \|url=https://www.cs.tufts.edu/~nr/cs257/archive/bill-pugh/jmm2.pdf \|access-date=15 July 2021}}</ref> preventing many runtime optimizations and not providing strong enough guarantees for code safety. It was updated through the [[Java Community Process]], as Java Specification Request 133 (JSR-133), which took effect back in 2004, for [[Java version history#Java SE 5\|Tiger (Java 5.0)]].<ref>{{cite web		The original Java memory model developed in 1995, was widely perceived as broken,<ref>{{cite journal \|last1=Pugh \|first1=William \|title=The Java memory model is fatally flawed \|journal=Concurrency: Practice and Experience \|date=2000 \|volume=12 \|issue=6 \|pages=445–455 \|doi=10.1002/1096-9128(200005)12:6<445::AID-CPE484>3.0.CO;2-A \|url=https://www.cs.tufts.edu/~nr/cs257/archive/bill-pugh/jmm2.pdf \|access-date=15 July 2021}}</ref> preventing many runtime optimizations and not providing strong enough guarantees for code safety. It was updated through the [[Java Community Process]], as Java Specification Request 133 (JSR-133), which took effect back in 2004, for [[Java version history#Java SE 5\|Tiger (Java 5.0)]].<ref>{{cite web
	\| url=https://www.ibm.com/developerworks/library/j-jtp03304/j-jtp03304-pdf.pdf		\| url=https://www.ibm.com/developerworks/library/j-jtp03304/j-jtp03304-pdf.pdf
	\| title=Fixing the Java Memory Model, Part 2		\| title=Fixing the Java Memory Model, Part 2

103.20.125.4 at 09:26, 14 November 2024

2024-11-14T09:26:12Z

← Previous revision		Revision as of 09:26, 14 November 2024
Line 3:		Line 3:
	The '''Java memory model''' describes how [[thread (computer science)\|threads]] in the [[Java (programming language)\|Java programming language]] interact through memory. Together with the description of single-threaded execution of code, the memory model provides the [[formal semantics of programming languages\|semantics]] of the Java programming language.		The '''Java memory model''' describes how [[thread (computer science)\|threads]] in the [[Java (programming language)\|Java programming language]] interact through memory. Together with the description of single-threaded execution of code, the memory model provides the [[formal semantics of programming languages\|semantics]] of the Java programming language.

	The original Java memory model developed in 1995, was widely perceived as broken,<ref>{{cite journal \|last1=Pugh \|~~first1~~=William \|title=The Java memory model is fatally flawed \|journal=Concurrency: Practice and Experience \|date=2000 \|volume=12 \|issue=6 \|pages=445–455 \|doi=10.1002/1096-9128(200005)12:6<445::AID-CPE484>3.0.CO;2-A \|url=https://www.cs.tufts.edu/~nr/cs257/archive/bill-pugh/jmm2.pdf \|access-date=15 July 2021}}</ref> preventing many runtime optimizations and not providing strong enough guarantees for code safety. It was updated through the [[Java Community Process]], as Java Specification Request 133 (JSR-133), which took effect back in 2004, for [[Java version history#Java SE 5\|Tiger (Java 5.0)]].<ref>{{cite web		The original Java memory model developed in 1995, was widely perceived as broken,<ref>{{cite journal \|last1=Pugh \|fjirst1=William \|title=The Java memory model is fatally flawed \|journal=Concurrency: Practice and Experience \|date=2000 \|volume=12 \|issue=6 \|pages=445–455 \|doi=10.1002/1096-9128(200005)12:6<445::AID-CPE484>3.0.CO;2-A \|url=https://www.cs.tufts.edu/~nr/cs257/archive/bill-pugh/jmm2.pdf \|access-date=15 July 2021}}</ref> preventing many runtime optimizations and not providing strong enough guarantees for code safety. It was updated through the [[Java Community Process]], as Java Specification Request 133 (JSR-133), which took effect back in 2004, for [[Java version history#Java SE 5\|Tiger (Java 5.0)]].<ref>{{cite web
	\| url=https://www.ibm.com/developerworks/library/j-jtp03304/j-jtp03304-pdf.pdf		\| url=https://www.ibm.com/developerworks/library/j-jtp03304/j-jtp03304-pdf.pdf
	\| title=Fixing the Java Memory Model, Part 2		\| title=Fixing the Java Memory Model, Part 2

Kvng: grammar

2024-09-25T14:33:11Z

grammar

← Previous revision		Revision as of 14:33, 25 September 2024
Line 1:		Line 1:
	{{Short description\|~~Interact~~ of threads in Java software}}		{{Short description\|Interaction of threads in Java software}}

	The '''Java memory model''' describes how [[thread (computer science)\|threads]] in the [[Java (programming language)\|Java programming language]] interact through memory. Together with the description of single-threaded execution of code, the memory model provides the [[formal semantics of programming languages\|semantics]] of the Java programming language.		The '''Java memory model''' describes how [[thread (computer science)\|threads]] in the [[Java (programming language)\|Java programming language]] interact through memory. Together with the description of single-threaded execution of code, the memory model provides the [[formal semantics of programming languages\|semantics]] of the Java programming language.

GhostInTheMachine: Fixed ref with reFill 2

2024-09-22T19:25:25Z

Fixed ref with reFill 2

← Previous revision		Revision as of 19:25, 22 September 2024
Line 46:		Line 46:
	For the execution of a single thread, the rules are simple. The [[Java Language Specification]] requires a [[Java virtual machine]] to observe ''within-thread as-if-serial'' semantics. The runtime (which, in this case, usually refers to the dynamic compiler, the processor and the memory subsystem) is free to introduce any useful execution optimizations as long as the result of the thread in isolation is guaranteed to be exactly the same as it would have been had all the statements been executed in the order the statements occurred in the program (also called program order).<ref>{{cite web\|last1=Manson\|first1=Jeremy\|title=JSR-133 FAQ\|url=http://www.cs.umd.edu/~pugh/java/memoryModel/jsr-133-faq.html#reordering}}</ref>		For the execution of a single thread, the rules are simple. The [[Java Language Specification]] requires a [[Java virtual machine]] to observe ''within-thread as-if-serial'' semantics. The runtime (which, in this case, usually refers to the dynamic compiler, the processor and the memory subsystem) is free to introduce any useful execution optimizations as long as the result of the thread in isolation is guaranteed to be exactly the same as it would have been had all the statements been executed in the order the statements occurred in the program (also called program order).<ref>{{cite web\|last1=Manson\|first1=Jeremy\|title=JSR-133 FAQ\|url=http://www.cs.umd.edu/~pugh/java/memoryModel/jsr-133-faq.html#reordering}}</ref>

	The major caveat of this is that ''as-if-serial'' semantics do not prevent different threads from having different views of the data. The memory model provides clear guidance about what values are allowed to be returned when the data is read. The basic rules imply that individual actions can be reordered, as long as the ''as-if-serial'' semantics of the thread are not violated, and actions that imply communication between threads, such as the acquisition or release of a [[lock (computer science)\|lock]], ensure that actions that happen prior to them are seen by other threads that see their effects. For example, everything that happens before the release of a lock will be seen to be ordered before and visible to everything that happens after a subsequent acquisition of that same lock.<ref>{{~~cite~~ web~~\|title=JLS Happens-before Order~~\|url=~~http~~://docs.oracle.com/javase/specs/jls/se8/html/jls-17.html~~#jls-~~17.4.5}}</ref>		The major caveat of this is that ''as-if-serial'' semantics do not prevent different threads from having different views of the data. The memory model provides clear guidance about what values are allowed to be returned when the data is read. The basic rules imply that individual actions can be reordered, as long as the ''as-if-serial'' semantics of the thread are not violated, and actions that imply communication between threads, such as the acquisition or release of a [[lock (computer science)\|lock]], ensure that actions that happen prior to them are seen by other threads that see their effects. For example, everything that happens before the release of a lock will be seen to be ordered before and visible to everything that happens after a subsequent acquisition of that same lock.<ref>{{Cite web\|url=https://docs.oracle.com/javase/specs/jls/se8/html/jls-17.html\|title=Chapter 17. Threads and Locks\|website=docs.oracle.com}}</ref>

	Mathematically, there is a [[partial order]] called the [[happened-before\|''happens-before'']] order over all actions performed by the program. The ''happens-before'' order subsumes the program order; if one action occurs before another in the program order, it will occur before the other in the ''happens-before'' order. In addition, releases and subsequent acquisitions of locks form edges in the happens-before graph. A read is allowed to return the value of a write if that write is the last write to that variable before the read along some path in the ''happens-before'' order, or if the write is not ordered with respect to that read in the ''happens-before'' order.		Mathematically, there is a [[partial order]] called the [[happened-before\|''happens-before'']] order over all actions performed by the program. The ''happens-before'' order subsumes the program order; if one action occurs before another in the program order, it will occur before the other in the ''happens-before'' order. In addition, releases and subsequent acquisitions of locks form edges in the happens-before graph. A read is allowed to return the value of a write if that write is the last write to that variable before the read along some path in the ''happens-before'' order, or if the write is not ordered with respect to that read in the ''happens-before'' order.

GhostInTheMachine: CN

2024-09-22T19:23:48Z

← Previous revision		Revision as of 19:23, 22 September 2024
Line 17:		Line 17:

	==Context==		==Context==
			{{Unreferenced section\|date=September 2024}}

	The [[Java (programming language)\|Java programming language]] and platform provide [[Thread (computer science)\|thread]] capabilities. Synchronization between threads is notoriously difficult for developers; this difficulty is compounded because Java applications can run on a wide range of [[Processor (computing)\|processors]] and [[operating system]]s. To be able to draw conclusions about a program's behavior, Java's designers decided they had to clearly define possible behaviors of all Java programs.		The [[Java (programming language)\|Java programming language]] and platform provide [[Thread (computer science)\|thread]] capabilities. Synchronization between threads is notoriously difficult for developers; this difficulty is compounded because Java applications can run on a wide range of [[Processor (computing)\|processors]] and [[operating system]]s. To be able to draw conclusions about a program's behavior, Java's designers decided they had to clearly define possible behaviors of all Java programs.

GhostInTheMachine: Changing short description from "how threads in the Java programming language interact through memory" to "Interact of threads in Java software"

2024-09-22T19:22:26Z

Changing short description from "how threads in the Java programming language interact through memory" to "Interact of threads in Java software"

← Previous revision		Revision as of 19:22, 22 September 2024
Line 1:		Line 1:
	{{Short description\|~~how~~ threads in ~~the~~ Java ~~programming language interact through memory~~}}		{{Short description\|Interact of threads in Java software}}
	The '''Java memory model''' describes how [[thread (computer science)\|threads]] in the [[Java (programming language)\|Java programming language]] interact through memory. Together with the description of single-threaded execution of code, the memory model provides the [[formal semantics of programming languages\|semantics]] of the Java programming language.		The '''Java memory model''' describes how [[thread (computer science)\|threads]] in the [[Java (programming language)\|Java programming language]] interact through memory. Together with the description of single-threaded execution of code, the memory model provides the [[formal semantics of programming languages\|semantics]] of the Java programming language.

Kvng: Changing short description from "Java programming language specification" to "how threads in the Java programming language interact through memory"

2024-09-22T14:55:58Z

Changing short description from "Java programming language specification" to "how threads in the Java programming language interact through memory"

← Previous revision		Revision as of 14:55, 22 September 2024
Line 1:		Line 1:
	{{Short description\|Java programming language ~~specification~~}}		{{Short description\|how threads in the Java programming language interact through memory}}
	The '''Java memory model''' describes how [[thread (computer science)\|threads]] in the [[Java (programming language)\|Java programming language]] interact through memory. Together with the description of single-threaded execution of code, the memory model provides the [[formal semantics of programming languages\|semantics]] of the Java programming language.		The '''Java memory model''' describes how [[thread (computer science)\|threads]] in the [[Java (programming language)\|Java programming language]] interact through memory. Together with the description of single-threaded execution of code, the memory model provides the [[formal semantics of programming languages\|semantics]] of the Java programming language.

Rublov: Adding short description: "Java programming language specification"

2024-08-25T15:52:57Z

Adding short description: "Java programming language specification"

← Previous revision		Revision as of 15:52, 25 August 2024
Line 1:		Line 1:
			{{Short description\|Java programming language specification}}
	The '''Java memory model''' describes how [[thread (computer science)\|threads]] in the [[Java (programming language)\|Java programming language]] interact through memory. Together with the description of single-threaded execution of code, the memory model provides the [[formal semantics of programming languages\|semantics]] of the Java programming language.		The '''Java memory model''' describes how [[thread (computer science)\|threads]] in the [[Java (programming language)\|Java programming language]] interact through memory. Together with the description of single-threaded execution of code, the memory model provides the [[formal semantics of programming languages\|semantics]] of the Java programming language.

Kvng: better disambig

2024-07-20T16:48:30Z

better disambig

← Previous revision		Revision as of 16:48, 20 July 2024
Line 17:		Line 17:
	==Context==		==Context==

	The [[Java (programming language)\|Java programming language]] and platform provide [[Thread (computer science)\|thread]] capabilities. Synchronization between threads is notoriously difficult for developers; this difficulty is compounded because Java applications can run on a wide range of [[~~central~~ ~~processor~~]]s and [[operating system]]s. To be able to draw conclusions about a program's behavior, Java's designers decided they had to clearly define possible behaviors of all Java programs.		The [[Java (programming language)\|Java programming language]] and platform provide [[Thread (computer science)\|thread]] capabilities. Synchronization between threads is notoriously difficult for developers; this difficulty is compounded because Java applications can run on a wide range of [[Processor (computing)\|processors]] and [[operating system]]s. To be able to draw conclusions about a program's behavior, Java's designers decided they had to clearly define possible behaviors of all Java programs.

	On modern platforms, code is frequently not executed in the order it was written. It is reordered by the compiler, the processor and the memory subsystem to achieve maximum performance. On [[multiprocessor]] architectures, individual processors may have their own local caches that are out of sync with main memory. It is generally undesirable to require threads to remain perfectly in sync with one another because this would be too costly from a performance point of view. This means that at any given time, different threads may see different values for the same shared data.		On modern platforms, code is frequently not executed in the order it was written. It is reordered by the compiler, the processor and the memory subsystem to achieve maximum performance. On [[multiprocessor]] architectures, individual processors may have their own local caches that are out of sync with main memory. It is generally undesirable to require threads to remain perfectly in sync with one another because this would be too costly from a performance point of view. This means that at any given time, different threads may see different values for the same shared data.

Kvng: disambig

2024-07-20T16:36:47Z

disambig

← Previous revision		Revision as of 16:36, 20 July 2024
Line 17:		Line 17:
	==Context==		==Context==

	The [[Java (programming language)\|Java programming language]] and platform provide [[Thread (computer science)\|thread]] capabilities. Synchronization between threads is notoriously difficult for developers; this difficulty is compounded because Java applications can run on a wide range of [[~~processors~~]] and [[operating ~~systems~~]]. To be able to draw conclusions about a program's behavior, Java's designers decided they had to clearly define possible behaviors of all Java programs.		The [[Java (programming language)\|Java programming language]] and platform provide [[Thread (computer science)\|thread]] capabilities. Synchronization between threads is notoriously difficult for developers; this difficulty is compounded because Java applications can run on a wide range of [[central processor]]s and [[operating system]]s. To be able to draw conclusions about a program's behavior, Java's designers decided they had to clearly define possible behaviors of all Java programs.

	On modern platforms, code is frequently not executed in the order it was written. It is reordered by the compiler, the processor and the memory subsystem to achieve maximum performance. On [[multiprocessor]] architectures, individual processors may have their own local caches that are out of sync with main memory. It is generally undesirable to require threads to remain perfectly in sync with one another because this would be too costly from a performance point of view. This means that at any given time, different threads may see different values for the same shared data.		On modern platforms, code is frequently not executed in the order it was written. It is reordered by the compiler, the processor and the memory subsystem to achieve maximum performance. On [[multiprocessor]] architectures, individual processors may have their own local caches that are out of sync with main memory. It is generally undesirable to require threads to remain perfectly in sync with one another because this would be too costly from a performance point of view. This means that at any given time, different threads may see different values for the same shared data.

← Previous revision		Revision as of 19:25, 22 September 2024
Line 46:		Line 46:
	For the execution of a single thread, the rules are simple. The [[Java Language Specification]] requires a [[Java virtual machine]] to observe ''within-thread as-if-serial'' semantics. The runtime (which, in this case, usually refers to the dynamic compiler, the processor and the memory subsystem) is free to introduce any useful execution optimizations as long as the result of the thread in isolation is guaranteed to be exactly the same as it would have been had all the statements been executed in the order the statements occurred in the program (also called program order).<ref>{{cite web\|last1=Manson\|first1=Jeremy\|title=JSR-133 FAQ\|url=http://www.cs.umd.edu/~pugh/java/memoryModel/jsr-133-faq.html#reordering}}</ref>		For the execution of a single thread, the rules are simple. The [[Java Language Specification]] requires a [[Java virtual machine]] to observe ''within-thread as-if-serial'' semantics. The runtime (which, in this case, usually refers to the dynamic compiler, the processor and the memory subsystem) is free to introduce any useful execution optimizations as long as the result of the thread in isolation is guaranteed to be exactly the same as it would have been had all the statements been executed in the order the statements occurred in the program (also called program order).<ref>{{cite web\|last1=Manson\|first1=Jeremy\|title=JSR-133 FAQ\|url=http://www.cs.umd.edu/~pugh/java/memoryModel/jsr-133-faq.html#reordering}}</ref>

	The major caveat of this is that ''as-if-serial'' semantics do not prevent different threads from having different views of the data. The memory model provides clear guidance about what values are allowed to be returned when the data is read. The basic rules imply that individual actions can be reordered, as long as the ''as-if-serial'' semantics of the thread are not violated, and actions that imply communication between threads, such as the acquisition or release of a [[lock (computer science)\|lock]], ensure that actions that happen prior to them are seen by other threads that see their effects. For example, everything that happens before the release of a lock will be seen to be ordered before and visible to everything that happens after a subsequent acquisition of that same lock.<ref>{{~~cite~~ web~~\|title=JLS Happens-before Order~~\|url=~~http~~://docs.oracle.com/javase/specs/jls/se8/html/jls-17.html~~#jls-~~17.4.5}}</ref>		The major caveat of this is that ''as-if-serial'' semantics do not prevent different threads from having different views of the data. The memory model provides clear guidance about what values are allowed to be returned when the data is read. The basic rules imply that individual actions can be reordered, as long as the ''as-if-serial'' semantics of the thread are not violated, and actions that imply communication between threads, such as the acquisition or release of a [[lock (computer science)\|lock]], ensure that actions that happen prior to them are seen by other threads that see their effects. For example, everything that happens before the release of a lock will be seen to be ordered before and visible to everything that happens after a subsequent acquisition of that same lock.<ref>{{Cite web\|url=https://docs.oracle.com/javase/specs/jls/se8/html/jls-17.html\|title=Chapter 17. Threads and Locks\|website=docs.oracle.com}}</ref>

	Mathematically, there is a [[partial order]] called the [[happened-before\|''happens-before'']] order over all actions performed by the program. The ''happens-before'' order subsumes the program order; if one action occurs before another in the program order, it will occur before the other in the ''happens-before'' order. In addition, releases and subsequent acquisitions of locks form edges in the happens-before graph. A read is allowed to return the value of a write if that write is the last write to that variable before the read along some path in the ''happens-before'' order, or if the write is not ordered with respect to that read in the ''happens-before'' order.		Mathematically, there is a [[partial order]] called the [[happened-before\|''happens-before'']] order over all actions performed by the program. The ''happens-before'' order subsumes the program order; if one action occurs before another in the program order, it will occur before the other in the ''happens-before'' order. In addition, releases and subsequent acquisitions of locks form edges in the happens-before graph. A read is allowed to return the value of a write if that write is the last write to that variable before the read along some path in the ''happens-before'' order, or if the write is not ordered with respect to that read in the ''happens-before'' order.