WJUG #257 Just-In-Time compiler - ukryty "przyjaciel" - Krzysztof Ślusarski

1. Krzysztof Ślusarski
Just-In-Time compiler - ukryty „przyjaciel”

2. Krótko o mnie
●
Programuję od 1992

3. Krótko o mnie
●
Programuję od 1992
●
Zawodowo:
– Od 10.2006 – 08.2007 – RODO
– Od 09.2007 – Britenet sp z. o. o
Java Programmer /
Team Leader /
System Architect /
Solution Architect

4. Krótko o mnie
●
Poza 8h 5/7:
– Szkolenia

5. Krótko o mnie
●
Poza 8h 5/7:
– Szkolenia
– Diagnoza awarii produkcyjnych + profiling

6. Krótko o mnie
●
Poza 8h 5/7:
– Szkolenia
– Diagnoza awarii produkcyjnych + profiling
– Stolarstwo meblowe

7. Krótko o mnie
●
Poza 8h 5/7:
– Szkolenia
– Diagnoza awarii produkcyjnych + profiling
– Stolarstwo meblowe
●
Prywatnie:

8. Wyłączenie odpowiedzialności
●
Nie tworzę JVM

9. Wyłączenie odpowiedzialności
●
Nie tworzę JVM
●
Wszystko co mówię, może być kłamstwem

10. Wyłączenie odpowiedzialności
●
Nie tworzę JVM
●
Wszystko co mówię, może być kłamstwem
●
Pytania na końcu

11. Wyłączenie odpowiedzialności
●
Nie tworzę JVM
●
Wszystko co mówię, może być kłamstwem
●
Pytania na końcu
●
W 1,5h się nie wyrobię

12. Motto
Nie ma w życiu
nic za darmo

13. Wstęp
●
Konsekwencje

14. Wstęp
●
Konsekwencje
●
Słowniczek

15. Wstęp
●
Konsekwencje
●
Słowniczek
– Local safepoint

16. Wstęp
●
Konsekwencje
●
Słowniczek
– Local safepoint
– Global safepoint

17. Wstęp
●
Konsekwencje
●
Słowniczek
– Local safepoint
– Global safepoint
– Safepoint opperation

18. Wstęp
●
Konsekwencje
●
Słowniczek
– Local safepoint
– Global safepoint
– Safepoint opperation
– Stop the world

19. Wstęp
●
JIT vs AOT

20. Wstęp
●
JIT vs AOT
●
Zależy od implementacji JVM – Oracle Hotspot

21. Wstęp
●
JIT vs AOT
●
Zależy od implementacji JVM – Oracle Hotspot
●
Optymalizuje:
– Metody – ivocation counter
– Pętle – backedge counter, OSR

22. Wstęp
●
JIT vs AOT
●
Zależy od implementacji JVM – Oracle Hotspot
●
Optymalizuje:
– Metody – ivocation counter
– Pętle – backedge counter, OSR
●
Co nie jest zabronione jest dozwolone

23. Wstęp

24. Cykl życia

25. Cykl życia
Interpreter

26. Cykl życia
Interpreter Profiling

27. Cykl życia
Interpreter Profiling
JIT compilation

28. Cykl życia
Interpreter Profiling
Deoptimization JIT compilation

29. Kompilatory
●
C1 – client – 5 razy szybszy
●
C2 – server – 10-100+ razy szybszy

30. Tiered compilation
Interpreter C1
C1 +
counters
C1 +
profiling
C2

31. Tiered compilation
0
Interpreter C1
C1 +
counters
C1 +
profiling
C2
3 4Common

32. Tiered compilation
0
Interpreter C1
C1 +
counters
C1 +
profiling
C2
0
1
3 4
3
Common
Trivial
methods

33. Tiered compilation
0
Interpreter C1
C1 +
counters
C1 +
profiling
C2
0
1
3 4
3
Common
Trivial
methods
0 2 3 4C2 busy

34. -XX:+PrintCompilation
50 37 n 0 java.lang.Object::hashCode (native)
08 167 ! 4 java.lang.ClassLoader::loadClass (122 bytes)
159 376 s 3 java.io.ByteArrayOutputStream::write (32 bytes)
240 388 % 3 bt.AOptCls::run @ 8 (39 bytes)
309 405 3 bt.AOptCls::doSomething (29 bytes) made not entrant
16660 955 2 com.sun.proxy.$Proxy3::run (27 bytes) made zombie
„n” - native
„!” - exception handler
„s” - synchronized
„%” - OSR
Timestamp / ID kompilacji / Tier / Rozmiar metody /
Indeks bytecodu pętli / Info

35. Made not entrant
Calling
method (A)
Compiled called
method (B)
Compiled called
method (B)

36. Made not entrant
Calling
method (A)
Call dispatcher
Compiled called
method (B)
Compiled called
method (B)

37. Made not entrant
Calling
method (A)
Call dispatcher
Compiled called
method (B)
Compiled called
method (B)

38. Made not entrant
Calling
method (A)
Call dispatcher
Compiled called
method (B)
Compiled called
method (B)

39. Made not entrant
Calling
method (A)
Call dispatcher
Compiled called
method (B)
Compiled called
method (B)

40. Made not entrant – variant 1
Calling
method (A)
Call dispatcher
Compiled called
method (B)
Compiled called
method (B)

41. Made not entrant – variant 1
Calling
method (A)
Call dispatcher
Compiled called
method (B)
Compiled called
method (B)

42. Made not entrant – variant 1
Calling
method (A)
Call dispatcher
Compiled called
method (B)
Compiled called
method (B)

43. Made not entrant – variant 2
Calling
method (A)
Call dispatcher
Compiled called
method (B)
Compiled called
method (B)

44. Made not entrant – variant 2
Calling
method (A)
Call dispatcher
Compiled called
method (B)
Compiled called
method (B)
Compiled called
method (B)

45. Made not entrant – variant 2
Calling
method (A)
Call dispatcher
Compiled called
method (B)
Compiled called
method (B)
Compiled called
method (B)

46. Made not entrant – variant 2
Calling
method (A)
Call dispatcher
Compiled called
method (B)
Compiled called
method (B)
Compiled called
method (B)

47. Made not entrant – variant 2
Calling
method (A)
Call dispatcher
Compiled called
method (B)
Compiled called
method (B)
Compiled called
method (B)

48. Made not entrant – variant 2
Calling
method (A)
Call dispatcher
Compiled called
method (B)
Compiled called
method (B)
Compiled called
method (B)

49. Made not entrant – variant 2
Calling
method (A)
Call dispatcher
Compiled called
method (B)
Compiled called
method (B)
Compiled called
method (B)

50. Inlining
●
„Matka wszystkich optymalizacji”

51. Inlining
●
„Matka wszystkich optymalizacji”
●
Zastąpienie wywołania metody jej „ciałem”

52. Inlining
●
„Matka wszystkich optymalizacji”
●
Zastąpienie wywołania metody jej „ciałem”
●
Pozwala na spojrzenie z szerszej perspektywy

53. Inlining
●
„Matka wszystkich optymalizacji”
●
Zastąpienie wywołania metody jej „ciałem”
●
Pozwala na spojrzenie z szerszej perspektywy
●
Można śledzić za pomocą
-XX:+UnlockDiagnosticVMOptions
-XX:+PrintInlining

54. Inlining
final Object mutex
= new Object();
void execute() {
subExecute1(true);
subExecute2(true);
}
void subExecute1(boolean mt) {
if (mt) {
synchronized (mutex) {
// logic 1
}
} else {
// logic 1
}
}
void subExecute2(boolean mt) {
if (mt) {
synchronized (mutex) {
// logic 2
}
} else {
// logic 2
}
}

55. Inlining
void execute() {
if (true) {
synchronized (mutex) {
// logic 1
}
} else {
// logic 1
}
if (true) {
synchronized (mutex) {
// logic 2
}
} else {
// logic 2
}
}

56. Inlining
void execute() {
synchronized (mutex) {
// logic 1
}
synchronized (mutex) {
// logic 2
}
}

57. Inlining
void execute() {
synchronized (mutex) {
// logic 1
// logic 2
}
}

58. Intrinsic
●
Metody wbudowane

59. Intrinsic
●
Metody wbudowane
●
Implementacja podmieniane w:
– Interpreterze
– Kompilatorze C1
– Kompilatorze C2

60. Intrinsic
●
Metody wbudowane
●
Implementacja podmieniane w:
– Interpreterze
– Kompilatorze C1
– Kompilatorze C2
●
Od JDK 9 oznaczone anotacją
@HotSpotIntrinsicCandidate

61. Intrinsic
●
Metody wbudowane
●
Implementacja podmieniane w:
– Interpreterze
– Kompilatorze C1
– Kompilatorze C2
●
Od JDK 9 oznaczone anotacją
@HotSpotIntrinsicCandidate
●
Około 300 metod w JDK

62. Intrinsic
●
Używane do
– Poprawy wydajności
java.lang.System#arraycopy

63. Intrinsic
●
Używane do
– Poprawy wydajności
java.lang.System#arraycopy
– Dodania funkcjonalności spoza języka:
sun.misc.Unsafe#allocateInstance

64. Intrinsic
●
Używane do
– Poprawy wydajności
java.lang.System#arraycopy
– Dodania funkcjonalności spoza języka:
sun.misc.Unsafe#allocateInstance
– Bezpośrednie wywołanie instrukcji CPU:
sun.misc.Unsafe#storeFence

65. Redundancy removal
●
Po co robić 2x to samo?

66. Redundancy removal
●
Po co robić 2x to samo?
static class Value {
int i;
}
private Value value;
void execute() {
int j = value.i + 1;
int k = value.i + 1;
}

67. Implicit checks elimination
●
Ochrona przed zrobieniem „głupstwa”

68. Implicit checks elimination
●
Ochrona przed zrobieniem „głupstwa”
public static int getSize(Collection collection) {
return collection.size();
}

69. Implicit checks elimination
●
Ochrona przed zrobieniem „głupstwa”
public static int getSize(Collection collection) {
return collection.size();
}
To tak na prawdę:
public static int getSize(Collection collection) {
if (collection == null) {
throw new NullPointerException();
}
return collection.size();
}

70. Implicit checks elimination
●
Gdyby ich nie było --> crash JVM (np.
segmentation fault)

71. Implicit checks elimination
●
Gdyby ich nie było --> crash JVM (np.
segmentation fault)
●
Optymalizacje dla
– Dobrych programistów – signal handler

72. Implicit checks elimination
●
Gdyby ich nie było --> crash JVM (np.
segmentation fault)
●
Optymalizacje dla
– Dobrych programistów – signal handler
– Gorszych programistów – check

73. Implicit checks elimination
●
Gdyby ich nie było --> crash JVM (np.
segmentation fault)
●
Optymalizacje dla
– Dobrych programistów – signal handler
– Gorszych programistów – check
– Bardzo złych programistów – exception cache

74. Implicit checks elimination
●
Gdyby ich nie było --> crash JVM (np.
segmentation fault)
●
Optymalizacje dla
– Dobrych programistów – signal handler
– Gorszych programistów – check
– Bardzo złych programistów – exception cache
●
Optymalizacja spekulatywna

75. Unused branch removal
●
Jeżeli w trakcie profilowania nie wchodzisz do
„brancha” to można go usunąć

76. Unused branch removal
●
Jeżeli w trakcie profilowania nie wchodzisz do
„brancha” to można go usunąć
●
Optymalizacja spekulatywna

77. Unused branch removal
public void handle(int i) {
boolean cleanup = false;
if (i >= 0) {
// some logic
} else {
// some other logic
cleanup = true;
}
if (cleanup) {
// cleanup logic
}
}

78. Unused branch removal
public void handle(int i) {
boolean cleanup = false;
if (i >= 0) {
// some logic
} else {
uncommon_trap
}
if (cleanup) {
uncommon_trap
}
}

79. Unused branch removal
public void handle(int i) {
boolean cleanup = false;
if (i >= 0) {
// some logic
} else {
uncommon_trap
}
}

80. Devirtualization
●
Pozbycie się wirtualnych calli

81. Devirtualization
●
Pozbycie się wirtualnych calli
●
Inna optymalizacja dla
– Klas – Class Hierarchy Analysis + Type Profile
– Interfejsów – Type Profile

82. Devirtualization
●
Pozbycie się wirtualnych calli
●
Inna optymalizacja dla
– Klas – Class Hierarchy Analysis + Type Profile
– Interfejsów – Type Profile
●
Optymalizacja spekulatywna

83. Devirtualization – klasy
abstract class AbstractMathFunc {
abstract double apply(double i);
}
class CosFunc extends AbstractMathFunc {
double apply(double i) {
return Math.cos(i);
}
}
class SinFunc extends AbstractMathFunc {
double apply(double i) {
return Math.sin(i);
}
}
class SqrtFunc extends AbstractMathFunc {
double apply(double i) {
return Math.sqrt(i);
}
}

84. Devirtualization – klasy
static double do1(AbstractMathFunc func, double i) {
return func.apply(i);
}

85. Devirtualization – klasy
static double do1(AbstractMathFunc func, double i) {
return func.apply(i);
}
●
Co jeżeli jest tylko SinFunc?

86. Devirtualization – klasy – 1
static double do1(AbstractMathFunc func, double i) {
return Math.sin(i);
}

87. Devirtualization – klasy – 1
static double do1(AbstractMathFunc func, double i) {
return Math.sin(i);
}
●
Co jeżeli jest pojawi się CosFunc?

88. Devirtualization – klasy – 2
static double do1(AbstractMathFunc func, double i) {
if (func.getClass().equals(SinFunc.class)) {
return Math.sin(i);
} else {
uncommon_trap
}
}

89. Devirtualization – klasy – 2
static double do1(AbstractMathFunc func, double i) {
if (func.getClass().equals(SinFunc.class)) {
return Math.sin(i);
} else {
uncommon_trap
}
}
●
Co jeżeli jest CosFunc zacznie być używane?

90. Devirtualization – klasy – 3
static double do1(AbstractMathFunc func, double i) {
if (func.getClass().equals(SinFunc.class)) {
return Math.sin(i);
} else if (func.getClass().equals(CosFunc.class)) {
return Math.cos(i);
} else {
uncommon_trap
}
}

91. Devirtualization – klasy – 3
static double do1(AbstractMathFunc func, double i) {
if (func.getClass().equals(SinFunc.class)) {
return Math.sin(i);
} else if (func.getClass().equals(CosFunc.class)) {
return Math.cos(i);
} else {
uncommon_trap
}
}
●
Co jeżeli jest pojawi się SqrtFunc?

92. Devirtualization – klasy – 3
static double do1(AbstractMathFunc func, double i) {
if (func.getClass().equals(SinFunc.class)) {
return Math.sin(i);
} else if (func.getClass().equals(CosFunc.class)) {
return Math.cos(i);
} else {
uncommon_trap
}
}
●
Co jeżeli jest pojawi się SqrtFunc?
●
Co jeżeli jest SqrtFunc zacznie być używane?

93. Devirtualization – klasy – 4
static double do1(AbstractMathFunc func, double i) {
return func.apply(i);
}

94. Inne optymalizacje
●
Dead code elimination
●
Locks:
– Biased locking
– Lock coarsening
– Lock elision
– Adaptive locking
●
Loops:
– Loop unrolling
– Loop peeling
●
...

95. Konsekwencje
●
Możliwe fazy stop the world

96. Konsekwencje
●
Możliwe fazy stop the world
●
Exception cache

97. Konsekwencje
●
Możliwe fazy stop the world
●
Exception cache
●
Kod ma znaczenie

98. Co lubi JIT?
●
Krótkie metody

99. Co lubi JIT?
●
Krótkie metody
●
Zmienne lokalne

100. Co lubi JIT?
●
Krótkie metody
●
Zmienne lokalne
●
Niemutowalność

101. Co lubi JIT?
●
Krótkie metody
●
Zmienne lokalne
●
Niemutowalność
●
Ładny, przejrzysty kod

102. Co lubi JIT?
●
Krótkie metody
●
Zmienne lokalne
●
Niemutowalność
●
Ładny, przejrzysty kod
●
Typy prymitywne

103. Co lubi JIT?
●
Krótkie metody
●
Zmienne lokalne
●
Niemutowalność
●
Ładny, przejrzysty kod
●
Typy prymitywne
●
Abstrakcje z jedną/dwiema implementacją

104. Co lubi JIT?
●
Krótkie metody
●
Zmienne lokalne
●
Niemutowalność
●
Ładny, przejrzysty kod
●
Typy prymitywne
●
Abstrakcje z jedną/dwiema implementacją
●
Nieprzeciążone metody

105. Jaki kod lubi JIT?
void execute() {
// ... some logic
int result = send();
if (result < 0) {
// handle error
// ... very long logic
}
}

106. Jaki kod lubi JIT?
void execute() {
// ... some logic
int result = send();
if (result < 0) {
// handle error
handleError();
}
}

107. Konsekwencje
●
Możliwe fazy stop the world
●
Exception cache
●
Kod ma znaczenie
●
Składnia vs wydajność,
struktury danych vs wydajność

108. Wydajność

109. Wydajność
Programmers waste enormous amounts of time thinking
about, or worrying about, the speed of noncritical parts
of their programs, and these attempts at efficiency
actually have a strong negative impact when debugging
and maintenance are considered. We should forget
about small efficiencies, say about 97% of the time:
premature optimization is the root of all evil. Yet we
should not pass up our opportunities in that critical 3%.
Donald Knuth

110. Wydajność

111. Wydajność
Programmers waste enormous amounts of time thinking
about, or worrying about, the speed of noncritical parts
of their programs, and these attempts at efficiency
actually have a strong negative impact when debugging
and maintenance are considered. We should forget
about small efficiencies, say about 97% of the time:
premature optimization is the root of all evil. Yet we
should not pass up our opportunities in that critical 3%.
Donald Knuth

112. Wydajność

113. Wydajność

114. Konsekwencje
●
Możliwe fazy stop the world
●
Exception cache
●
Kod ma znaczenie
●
Składnia vs wydajność,
struktury danych vs wydajność
●
Restart JVM --> zaczynamy od nowa

115. Konsekwencje
●
Możliwe fazy stop the world
●
Exception cache
●
Kod ma znaczenie
●
Składnia vs wydajność,
struktury danych vs wydajność
●
Restart JVM --> zaczynamy od nowa
●
Concurrency?

116. Concurrency
●
„Obsługa wielu wątków w Javie to suka ...”

117. Concurrency
●
„Obsługa wielu wątków w Javie to suka ...”
●
„… wszystkiemu winny jest JIT ...”

118. Concurrency
●
„Obsługa wielu wątków w Javie to suka ...”
●
„… wszystkiemu winny jest JIT ...”
●
„… i nowoczesny hardware ...”

119. Concurrency
●
„Obsługa wielu wątków w Javie to suka ...”
●
„… wszystkiemu winny jest JIT ...”
●
„… i nowoczesny hardware ...”

120. Concurrency
An implementation is free to produce any code it likes,
as long as all resulting executions of a program produce
a result that can be predicted by the memory model.
This provides a great deal of freedom for the
implementor to perform a myriad of code
transformations, including the reordering of actions
and removal of unnecessary synchronization.
Java Language Specification (17.4)

121. Concurrency
private int i;
private int j;
private int k;
void execute() {
i = 1;
j = 2;
k = 3;
if (i > 0) {
i = k;
}
}

122. Concurrency
private int i;
private int j;
private int k;
void execute() {
i = 1;
j = 2;
k = 3;
if (i > 0) {
i = k;
}
}
execute() start

123. Concurrency
private int i;
private int j;
private int k;
void execute() {
i = 1;
j = 2;
k = 3;
if (i > 0) {
i = k;
}
}
execute() start
i = 1

124. Concurrency
private int i;
private int j;
private int k;
void execute() {
i = 1;
j = 2;
k = 3;
if (i > 0) {
i = k;
}
}
execute() start
i = 1 k = 3

125. Concurrency
private int i;
private int j;
private int k;
void execute() {
i = 1;
j = 2;
k = 3;
if (i > 0) {
i = k;
}
}
execute() start
i = 1 k = 3 j = 2

126. Concurrency
private int i;
private int j;
private int k;
void execute() {
i = 1;
j = 2;
k = 3;
if (i > 0) {
i = k;
}
}
execute() start
i = 1 k = 3 j = 2
if (i > 0)
false true

127. Concurrency
private int i;
private int j;
private int k;
void execute() {
i = 1;
j = 2;
k = 3;
if (i > 0) {
i = k;
}
}
execute() start
i = 1 k = 3 j = 2
if (i > 0)
false true
i = k

128. Concurrency
private int i;
private int j;
private int k;
void execute() {
i = 1;
j = 2;
k = 3;
if (i > 0) {
i = k;
}
}
execute() start
i = 1 k = 3 j = 2
if (i > 0)
false true
i = k
execute() end

129. Double-checked locking
private Helper helper;
public Helper getHelper() {
if (helper == null) {
synchronized (this) {
if (helper == null) {
helper = new Helper();
}
}
}
return helper;
}

130. Double-checked locking
private Helper helper;
public Helper getHelper() {
if (helper == null) {
synchronized (this) {
if (helper == null) {
local = calloc(sizeof(Helper.class));
local.<init>();
helper = local;
}
}
}
return helper;
}

131. Double-checked locking
synchronized (this) {
if (helper == null) {
local = c(s(Helper.class));
local.<init>();
helper = local;
}
}

132. Double-checked locking
synchronized (this) {
if (helper == null) {
local = c(s(Helper.class));
local.<init>();
helper = local;
}
}
synchronized() start

133. Double-checked locking
synchronized (this) {
if (helper == null) {
local = c(s(Helper.class));
local.<init>();
helper = local;
}
}
synchronized() start
true
If (helper == null)
false

134. Double-checked locking
synchronized (this) {
if (helper == null) {
local = c(s(Helper.class));
local.<init>();
helper = local;
}
}
synchronized() start
true
If (helper == null)
false
local = c(s(Helper.class))

135. Double-checked locking
synchronized (this) {
if (helper == null) {
local = c(s(Helper.class));
local.<init>();
helper = local;
}
}
synchronized() start
true
If (helper == null)
false
local = c(s(Helper.class))
local.<init>()

136. Double-checked locking
synchronized (this) {
if (helper == null) {
local = c(s(Helper.class));
local.<init>();
helper = local;
}
}
synchronized() start
true
If (helper == null)
false
local = c(s(Helper.class))
local.<init>() helper = local

137. Double-checked locking
synchronized (this) {
if (helper == null) {
local = c(s(Helper.class));
local.<init>();
helper = local;
}
}
synchronized() start
true
If (helper == null)
false
local = c(s(Helper.class))
local.<init>() helper = local
synchronized() end

138. Double-checked locking
private Helper helper;
public Helper getHelper() {
if (helper == null) {
synchronized (this) {
if (helper == null) {
helper = new Helper();
}
}
}
return helper;
}

139. Concurrency
The behavior of threads, particularly when not correctly
synchronized, can be confusing and counterintuitive.
The semantics of the Java programming language allow
compilers and microprocessors to perform optimizations
that can interact with incorrectly synchronized code in
ways that can produce behaviors that seem paradoxical.
To some programmers, this behavior may seem
"broken". However, it should be noted thatthis code is
improperly synchronize.
Java Language Specification (17 & 17.4)

140. Spec vs impl
Program

141. Spec vs impl
JMM executionsProgram

142. Spec vs impl
JMM executions JMM resultsProgram

143. Spec vs impl
JMM executions JMM results
Java code
Program

144. Spec vs impl
JMM executions JMM results
BytecodeJava code
Program
JAOT compilation

145. Spec vs impl
JMM executions JMM results
BytecodeJava code
Program
JVM interpreter JVM compilationJAOT compilation

146. Spec vs impl
JMM executions JMM results
Bytecode
JVM results
Java code
Program
JVM interpreter JVM compilationJAOT compilation

147. Spec vs impl
JMM executions JMM results
Bytecode
●
JVM results to podzbiór JMM results
JVM results
Java code
Program
JVM interpreter JVM compilationJAOT compilation

148. Concurrency
An implementation is free to produce any code it likes,
as long as all resulting executions of a program
produce a result that can be predicted by the
memory model. This provides a great deal of freedom
for the implementor to perform a myriad of code
transformations, including the reordering of actions and
removal of unnecessary synchronization.
Java Language Specification (17.4)

149. JMM w pigułce – 1 / 2
●
Obiekt immutable: (Safe construction)

150. JMM w pigułce – 1 / 2
●
Obiekt immutable: (Safe construction)
– Wszystkie pola final

151. JMM w pigułce – 1 / 2
●
Obiekt immutable: (Safe construction)
– Wszystkie pola final
– Nie udostępnia samego siebie w konstruktorze

152. JMM w pigułce – 1 / 2
●
Obiekt immutable: (Safe construction)
– Wszystkie pola final
– Nie udostępnia samego siebie w konstruktorze
●
Pary synchronizacji:

153. JMM w pigułce – 1 / 2
●
Obiekt immutable: (Safe construction)
– Wszystkie pola final
– Nie udostępnia samego siebie w konstruktorze
●
Pary synchronizacji:
Send Receive

154. JMM w pigułce – 1 / 2
●
Obiekt immutable: (Safe construction)
– Wszystkie pola final
– Nie udostępnia samego siebie w konstruktorze
●
Pary synchronizacji:
Send Receive
Monitor unlock Monitor lock

155. JMM w pigułce – 1 / 2
●
Obiekt immutable: (Safe construction)
– Wszystkie pola final
– Nie udostępnia samego siebie w konstruktorze
●
Pary synchronizacji:
Send Receive
Monitor unlock Monitor lock
Volatile write Volatile read

156. JMM w pigułce – 1 / 2
●
Obiekt immutable: (Safe construction)
– Wszystkie pola final
– Nie udostępnia samego siebie w konstruktorze
●
Pary synchronizacji:
Send Receive
Monitor unlock Monitor lock
Volatile write Volatile read
Varhandle release (*) Varhandle acquire (*)

157. JMM w pigułce – 1 / 2
●
Obiekt immutable: (Safe construction)
– Wszystkie pola final
– Nie udostępnia samego siebie w konstruktorze
●
Pary synchronizacji:
Send Receive
Monitor unlock Monitor lock
Volatile write Volatile read
Varhandle release (*) Varhandle acquire (*)
Starting thread New thread started

158. JMM w pigułce – 1 / 2
●
Obiekt immutable: (Safe construction)
– Wszystkie pola final
– Nie udostępnia samego siebie w konstruktorze
●
Pary synchronizacji:
Send Receive
Monitor unlock Monitor lock
Volatile write Volatile read
Varhandle release (*) Varhandle acquire (*)
Starting thread New thread started
Terminating thread (self) Finding terminated thread

159. JMM w pigułce – 2 / 2
Write a
...
Write b
…
Write c
Thread1
Thread2

160. JMM w pigułce – 2 / 2
Write a
...
Write b
…
Write c
Send Receive
Thread1
Thread2

161. JMM w pigułce – 2 / 2
Write a
...
Write b
…
Write c
Send Receive
Read b
…
Read c
…
Read a
Thread1
Thread2
Safe
publication

162. JMM w pigułce – 2 / 2
Write a
...
Write b
…
Write c
Send Receive
Read b
…
Read c
…
Read a
Thread1
Thread2
Write a
...
Write b
…
Write c
Thread3

163. JMM w pigułce – 2 / 2
Write a
...
Write b
…
Write c
Send Receive
Read b
…
Read c
…
Read a
Thread1
Thread2
Read b
…
Read c
…
Read a
Thread4

164. JMM w pigułce – 2 / 2
Write a
...
Send Receive
...
Read a
…
Receive
…
Read aSafe
publication
Thread1
Thread2
Write a
...
Send
Thread3

165. Double-checked locking
private Helper helper;
public Helper getHelper() {
if (helper == null) {
synchronized (this) {
if (helper == null) {
helper = new Helper();
}
}
}
return helper;
}

166. Jak zrozumieć JMM?
●
Aleksey Shipilëv:
– YouTube – GeeCON Conference – Java
Memory Model Unlearning Experience – 2-5
razy

167. Jak zrozumieć JMM?
●
Aleksey Shipilëv:
– YouTube – GeeCON Conference – Java
Memory Model Unlearning Experience – 2-5
razy
– YouTube – v JUG – Java Memory Model
Pragmatics – 2-3 razy

168. Jak zrozumieć JMM?
●
Aleksey Shipilëv:
– YouTube – GeeCON Conference – Java
Memory Model Unlearning Experience – 2-5
razy
– YouTube – v JUG – Java Memory Model
Pragmatics – 2-3 razy
●
Specyfikacja

169. Jak już musisz...
package java.util.concurrent;
package java.util.concurrent.atomic;
package java.util.concurrent.locks;

170. Czy mnie to dotyczy?

171. Spring?

172. Spring?

173. Spring?
https://jira.spring.io/browse/SPR-4307

174. Spring?
https://jira.spring.io/browse/SPR-4307
DefaultSingletonBeanRegistry

175. DefaultSingletonBeanRegistry
public Object getSingleton(String beanName) {
Object singletonObject =
this.singletonObjects.get(beanName);
return (singletonObject != NULL_OBJECT ?
singletonObject : null);
}
https://jira.spring.io/browse/SPR-4672

176. Konsekwencje
●
Możliwe fazy stop the world
●
Exception cache
●
Kod ma znaczenie
●
Składnia vs wydajność,
struktury danych vs wydajność
●
Restart JVM --> zaczynamy od nowa
●
Concurrency?
●
Pamięć

177. Pamięć w JVM – parallel
Heap
Young gen Old gen
Eden
Tenured
Off heap
Metaspace
Code
cache
Thread Native
S0
S1
Runtimeconstantpool
Methodbytecode
Classinfo
Programcounter
Stack
Nativestack
Nonprofiledcode
Profiledcode
Nonmethodcode

178. JIT w pamięci
Off heap
Code
cache
Heap
Young gen Old gen
Eden
Tenured
S0
S1
Metaspace Thread NativeRuntimeconstantpool
Methodbytecode
Classinfo
Programcounter
Stack
Nativestack
Nonprofiledcode
Profiledcode
Nonmethodcode

179. JIT w pamięci – arch. rozp.
Service
A (1)
Service
A (2)
Service
A (3)
Service
A (4)
Service
B (1)
Service
B (2)
Service
B (3)
Service
B (4)
Service
C (1)
Service
C (2)
Service
C (3)
Service
C (4)
Service
D (1)
Service
D (2)
Service
D (3)
Service
D (4)

180. JIT w pamięci – arch. rozp.

181. JIT w pamięci – arch. rozp.
Service
...

182. JIT w pamięci – arch. rozp.
Service
...
●
Max – 240M

183. JIT w pamięci – arch. rozp.
Service
...
●
Max – 240M
●
Used – np. 30M

184. JIT w pamięci – arch. rozp.
Service
...
●
Max – 240M
●
Used – np. 30M
●
Commited – np. 100M

185. JIT w pamięci – arch. rozp.
Service
...
●
Max – 240M
●
Used – np. 30M
●
Commited – np. 100M
●
Wasted – np. 70M

186. JIT w pamięci – arch. rozp.
Service
...
●
Max – 240M
●
Used – np. 30M
●
Commited – np. 100M
●
Wasted – np. 70M
np. x1024

187. JIT w pamięci – arch. rozp.
Service
...
●
Max – 240M
●
Used – np. 30M
●
Commited – np. 100M
●
Wasted – np. 70M
np. x1024

188. JIT w pamięci – arch. rozp.
Service
...
●
Max – 240M
●
Used – np. 30M
●
Commited – np. 100M
●
Wasted – np. 70M
np. x1024

189. JIT w pamięci – monolit
Module
A
Module
B
Module
C
Module
D

190. JIT w pamięci – monolit
Module
A
Module
B
Module
C
Module
D

191. Może coś da się zrobić?

192. Może coś da się zrobić?
Kompilator

193. Może coś da się zrobić?
Kompilator Sweeper

194. Może coś da się zrobić?
Kompilator Sweeper
1 / 14000605
1 / 14000605

195. Sweeper – success story
●
Charakterystyka użycia kodu zmienna w czasie

196. Sweeper – success story
●
Charakterystyka użycia kodu zmienna w czasie
– Start aplikacji / późniejsze użycie

197. Sweeper – success story
●
Charakterystyka użycia kodu zmienna w czasie
– Start aplikacji / późniejsze użycie
– Inne użycie aplikacji w czasie

198. Sweeper – success story
●
Charakterystyka użycia kodu zmienna w czasie
– Start aplikacji / późniejsze użycie
– Inne użycie aplikacji w czasie
●
np. w ciągu dnia biznes, wieczorem klienci
indywidualni

199. Sweeper – success story
●
Charakterystyka użycia kodu zmienna w czasie
– Start aplikacji / późniejsze użycie
– Inne użycie aplikacji w czasie
●
np. w ciągu dnia biznes, wieczorem klienci
indywidualni
●
np. w ciągu dni aplikacja webowa, w nocy
przetwarzanie batchowe

200. Konsekwencje
●
Możliwe fazy stop the world
●
Exception cache
●
Kod ma znaczenie
●
Składnia vs wydajność,
struktury danych vs wydajność
●
Restart JVM --> zaczynamy od nowa
●
Concurrency?
●
Pamięć
●
Nowe zachowanie --> spowolnienie aplikacji

201. Konsekwencje
●
Możliwe fazy stop the world
●
Exception cache
●
Kod ma znaczenie
●
Składnia vs wydajność,
struktury danych vs wydajność
●
Restart JVM --> zaczynamy od nowa
●
Concurrency?
●
Pamięć
●
Nowe zachowanie --> spowolnienie aplikacji
●
Testy wydajnościowe

202. Konsekwencje – mniej ważne

203. Konsekwencje – mniej ważne
Intrinsics...

204. Mniejsza liczba safepointów
App thread
App thread
App thread
App thread
Globalsafepointrequest

205. Mniejsza liczba safepointów
App thread
App thread
App thread
App thread
Globalsafepointrequest
Globalsafepoint

206. Mniejsza liczba safepointów
App thread
App thread
App thread
App thread
Globalsafepointrequest
Globalsafepoint
Time to
safepoint

207. Mniejsza liczba safepointów
App thread
App thread
App thread
App thread
Globalsafepointrequest
JVM thread
JVM thread
Globalsafepoint
Endofsafepointopperation
Time to
safepoint

208. Mniejsza liczba safepointów
App thread
App thread
App thread
App thread
Globalsafepointrequest
JVM thread
JVM thread
Globalsafepoint
Endofsafepointopperation
Time to
safepoint
Safepoint
opperation
time

209. Mniejsza liczba safepointów
App thread
App thread
App thread
App thread
Globalsafepointrequest
JVM thread
JVM thread
Globalsafepoint
Endofsafepointopperation
Time to
safepoint
Safepoint
opperation
time

210. Safepointy – praktyka
●
37 668 safepoint operations / 2h

211. Safepointy – liczba

212. Safepointy – total time + TTS

213. Safepointy – total time + 1ms

214. Safepointy – total time + 10ms

215. Czy ktoś coś z tym robi?

216. Czy ktoś coś z tym robi?

217. Czy ktoś coś z tym robi?
●
ShenandoahGC i ZGC

218. Czy ktoś coś z tym robi?
●
ShenandoahGC i ZGC
●
Np. optymalizacja „loop strip mining” – JDK 10 –
z bugiem :) Bug id: 8220374

219. Czy ktoś coś z tym robi?
●
ShenandoahGC i ZGC
●
Np. optymalizacja „loop strip mining” – JDK 10 –
z bugiem :) Bug id: 8220374
●
Naprawione w JDK 13 (b13) i downport do JDK
12 (u2) i JDK 11 (u4)

220. Czy ktoś coś z tym robi?
●
ShenandoahGC i ZGC
●
Np. optymalizacja „loop strip mining” – JDK 10 –
z bugiem :) Bug id: 8220374
●
Naprawione w JDK 13 (b13) i downport do JDK
12 (u2) i JDK 11 (u4)
●
Tylko dla ZGC, ShenandoahGC i G1

221. Złote rady wujka Krzyśka
●
Monitoruj Code cache

222. Złote rady wujka Krzyśka
●
Monitoruj Code cache
●
Używaj prymitywów

223. Złote rady wujka Krzyśka
●
Monitoruj Code cache
●
Używaj prymitywów
●
Zainteresuj się wydajnością aktualnie pisanego
kodu

224. Złote rady wujka Krzyśka
●
Monitoruj Code cache
●
Używaj prymitywów
●
Zainteresuj się wydajnością aktualnie pisanego
kodu
●
Używaj nowych wersji JDK

225. Złote rady wujka Krzyśka
●
Monitoruj Code cache
●
Używaj prymitywów
●
Zainteresuj się wydajnością aktualnie pisanego
kodu
●
Używaj nowych wersji JDK
●
Używaj metod synchronizacji jak najwyższego
poziomu

226. Złote rady wujka Krzyśka
●
Monitoruj Code cache
●
Używaj prymitywów
●
Zainteresuj się wydajnością aktualnie pisanego
kodu
●
Używaj nowych wersji JDK
●
Używaj metod synchronizacji jak najwyższego
poziomu
●
Koduj zgodnie ze specyfikacją, nie
implementacją

227. Złote rady wujka Krzyśka
●
Monitoruj Code cache
●
Używaj prymitywów
●
Zainteresuj się wydajnością aktualnie pisanego
kodu
●
Używaj nowych wersji JDK
●
Używaj metod synchronizacji jak najwyższego
poziomu
●
Koduj zgodnie ze specyfikacją, nie
implementacją
●
Nie rób optymalizacji które robi JIT

228. Złote rady wujka Krzyśka
●
Monitoruj Code cache
●
Używaj prymitywów
●
Zainteresuj się wydajnością aktualnie pisanego
kodu
●
Używaj nowych wersji JDK
●
Używaj metod synchronizacji jak najwyższego
poziomu
●
Koduj zgodnie ze specyfikacją, nie implementacją
●
Nie rób optymalizacji które robi JIT
●
Nie traktuj kluczowych składowych systemu jako
BlackBox

229. Skills
Hard Soft

230. Skills
CQRS Event sourcing
DDD TDD/BDD
Hexagonal
architecture
Microservices
Hateoas Restful
...
Hard Soft
Machine learning Pipes and filters

231. Skills
JIT Garbage collector CQRS Event sourcing
Classloader Safepoint DDD TDD/BDD
Spring proxy Hibernate caches
Hexagonal
architecture
Microservices
Bytecode Memory layout Hateoas Restful
... ...
Hard Soft
JMM Off heap Machine learning Pipes and filters

232. Skills
JIT Garbage collector CQRS Event sourcing
Classloader Safepoint DDD TDD/BDD
Spring proxy Hibernate caches
Hexagonal
architecture
Microservices
Bytecode Memory layout Hateoas Restful
... ...
Hard Soft
JMM Off heap Machine learning Pipes and filters

233. Dziękuję

234. conf@kś.pl
jug2019@kś.pl
Pytania?