JVM towarzyszy mi w projektach od prawie 15 lat. Łączą nas dobre chwile i złe wspomnienia, którymi będę się chciał z Wami podzielić. Opowiem o 4 jeźdźcach apokalipsy którzy zamieszkują maszynę wirtualną i od czasu do czas dają znać o swojej obecności. Podstępnie zakradają się do zakamarków waszego systemu operacyjnego, procesorów i obszarów pamięci RAM, powodując że wasza aplikacja na produkcji zachowuje się jak wygłodniałe, acz powolne zombie.
Kim są Ci odrażający jeźdźcy? To GC, operacje I/O, wątki i interpretowany bytecode. Postaram się na przykładach pokazać narzędzia dostępne w JDK jak i w Waszym systemie operacyjnym, które pozwolą Wam rozpoznać, z którym z nich macie do czynienia, a także techniki radzenia sobie ze spadkiem wydajności. Prezentacja będzie pokazywać ekstremalne przypadki, które wymagać będą nietypowych technik, jednak wszystko odbędzie się zgodnie z zasadami sztuki, a pokazane rozwiązania oparte będą na API i technikach dostępnym w każdym JDK.
Więc o czym tak naprawdę będzie?
Usłyszycie słów kilka o "off-heap memory", gdy wszystkie rozsądne techniki optymalizacji GC zawiodły.
A także o "non-blocking IO" i "zero-copy buffers", gdy już klasyczne IO zawiodło.
Nie obędzie się bez łagodnego wstępu do java.util.concurrent.atomic.* i "lock free programming", gdy już nie radzicie sobie z ilością wątków.
A na koniec opowiem o "just-in time compilation" i jak pisać kod, który jest "JIT friendly".
To wszystko i więcej o wydajności i optymalizacji JVM, dla Waszej radości i uciechy przyszłych pokoleń.
Tysiące użytkowników, miliony zapytań HTTP, miliardy odwołań do bazy danych, dziesiątki tysięcy osobogodzin inwestowanych przez firmy na optymalizacje aplikacji webowych, miliony dolarów (czy też euro) wydawanych na infrastrukturę, wszystko to po aby nasz system zapewniał użytkownikom odpowiedni komfort pracy i zadowalający czas odpowiedzi.
I gdy już wszystkie optymalizacje zapytań do bazy danych zostaną zastosowane, indeksy wypolerowane na wysoki połysk, czasowa złożoność obliczeniowa wszystkich metod będzie dążyć do O(1), a system dalej nie będzie spełnił wyśrubowanych warunków SLA, zawsze pozostaje wyprawa na "ostatni przylądek dobrej nadziei", czyli pełne niebezpieczeństw i ekscytujących przygód krainy, gdzie wasze dane będą na was czekać w ultra wydajnych, skalowalnych i stabilnych serwerach cache.
Chciałbym was, drodzy słuchacze, łagodnie wprowadzić w świat cache. Cache dla aplikacji webowych, opowiedzieć o stosowanych topologiach, wykorzystaniach cache w poszczególnych warstwach aplikacji, świat algorytmów "cache eviction", rozproszonych serwerów cache (i "data grids") oraz znanych i też przemilczanych "sekretów" i problemów, z którymi się spotkacie podczas implementacji cache w waszym systemie. Wszystko z wykorzystaniem takich rozwiązań jak memcached, redis, infinispan i ehcache.
Be full of respect for the past generations,
because the way you talk about
old code today, will be the same way people will be talking
about your code years from now.
Be full of care about future generations, they will have to live with your legacy code
Be full of childish curiosity, embrace failures, be open, experiment and share
Systematyczny architekt na drodze ku planowanemu postarzaniuJaroslaw Palka
Czym jest planowane postarzanie produktu? Zapewne wielu z was spotkało się z tym określeniem, oznaczającym planowane działania mające na celu skrócenie czasu życia produktu na rynku, w mniej lub bardziej szczytnym celu. Jak to się ma do tworzenia oprogramowania?
Być może nie tak planowane, jak często chaotyczne, jednak ciągle mamy do czynienia z nieustannym procesem postarzania naszych bibliotek, kontenerów aplikacji, języków, narzędzi i API. oprócz sil wywieranych przez biznes na naszą aplikację, jest ona też po wpływem potężnych ruchów technologicznych, wynikających z nieustannych zmian w trendach tworzenia oprogramowania. Jak efektywnie uniknąć powolnego postarzania się technologicznego naszej aplikacji? Jak uniknąć wysokich kosztów, odkładanych w nieskończoność modernizacji technologicznych aplikacji? Jak uzasadnić wartość biznesową kolejnego "big up front total next generation rewrite"?
A może by tak uwolnić się od hegemoni frameworków, bibliotek i kontenerów i oddać całą władzę w ręce programistów?
Podczas prezentacji opowiem jak ważnym elementem tej strategi są właściwe "abstrakcje w kontekście", jak efektywnie oddzielić "software construction" od "infrastructure code" i "business logic" i dlaczego właściwa architektura, która pozwala podjąć decyzje technologicznie jak najpóźniej, lub nawet odłożyć je na jutro, które nie nadejdzie, może pomóc wam i przyszłym pokoleniom, tych którzy będą musieli pracować z kodem odziedziczonym po was.
In recent years we have seen explosion of languages which run on Java Virtual Machine. We also have seen existing languages getting their implementations being rewritten to JVM. With all of the above we have seen rapid development of tools like parsers, bytecode generators and such, even inside JVM we saw initiatives like Da Vinci Machine Project, which led to invoke dynamic in JDK 7 and recent development of Graal and Truffle projects.
Is it really hard to write new programming language running on JVM? Even if you are not going to write your own I think it is worth to understand how your favorite language runs undercover, how early decisions can impact language extensibility and performance, what JVM itself and JVM ecosystem has to offer to language implementors.
During the session I will try to get you familiar with options you have when choosing parsers and byte code manipulation libraries. which language implementation to consider, how to test and tune your "new baby". Will you be able after this session to develop new and shiny language, packed with killer features language? No. But for sure you will understand difference between lexers and parsers, how bytecode works, why invoke dynamic and Graal and Truffle are so important to the future of JVM platform. Will we have time to write simple, compiled language?
Tysiące użytkowników, miliony zapytań HTTP, miliardy odwołań do bazy danych, dziesiątki tysięcy osobogodzin inwestowanych przez firmy na optymalizacje aplikacji webowych, miliony dolarów (czy też euro) wydawanych na infrastrukturę, wszystko to po aby nasz system zapewniał użytkownikom odpowiedni komfort pracy i zadowalający czas odpowiedzi.
I gdy już wszystkie optymalizacje zapytań do bazy danych zostaną zastosowane, indeksy wypolerowane na wysoki połysk, czasowa złożoność obliczeniowa wszystkich metod będzie dążyć do O(1), a system dalej nie będzie spełnił wyśrubowanych warunków SLA, zawsze pozostaje wyprawa na "ostatni przylądek dobrej nadziei", czyli pełne niebezpieczeństw i ekscytujących przygód krainy, gdzie wasze dane będą na was czekać w ultra wydajnych, skalowalnych i stabilnych serwerach cache.
Chciałbym was, drodzy słuchacze, łagodnie wprowadzić w świat cache. Cache dla aplikacji webowych, opowiedzieć o stosowanych topologiach, wykorzystaniach cache w poszczególnych warstwach aplikacji, świat algorytmów "cache eviction", rozproszonych serwerów cache (i "data grids") oraz znanych i też przemilczanych "sekretów" i problemów, z którymi się spotkacie podczas implementacji cache w waszym systemie. Wszystko z wykorzystaniem takich rozwiązań jak memcached, redis, infinispan i ehcache.
Be full of respect for the past generations,
because the way you talk about
old code today, will be the same way people will be talking
about your code years from now.
Be full of care about future generations, they will have to live with your legacy code
Be full of childish curiosity, embrace failures, be open, experiment and share
Systematyczny architekt na drodze ku planowanemu postarzaniuJaroslaw Palka
Czym jest planowane postarzanie produktu? Zapewne wielu z was spotkało się z tym określeniem, oznaczającym planowane działania mające na celu skrócenie czasu życia produktu na rynku, w mniej lub bardziej szczytnym celu. Jak to się ma do tworzenia oprogramowania?
Być może nie tak planowane, jak często chaotyczne, jednak ciągle mamy do czynienia z nieustannym procesem postarzania naszych bibliotek, kontenerów aplikacji, języków, narzędzi i API. oprócz sil wywieranych przez biznes na naszą aplikację, jest ona też po wpływem potężnych ruchów technologicznych, wynikających z nieustannych zmian w trendach tworzenia oprogramowania. Jak efektywnie uniknąć powolnego postarzania się technologicznego naszej aplikacji? Jak uniknąć wysokich kosztów, odkładanych w nieskończoność modernizacji technologicznych aplikacji? Jak uzasadnić wartość biznesową kolejnego "big up front total next generation rewrite"?
A może by tak uwolnić się od hegemoni frameworków, bibliotek i kontenerów i oddać całą władzę w ręce programistów?
Podczas prezentacji opowiem jak ważnym elementem tej strategi są właściwe "abstrakcje w kontekście", jak efektywnie oddzielić "software construction" od "infrastructure code" i "business logic" i dlaczego właściwa architektura, która pozwala podjąć decyzje technologicznie jak najpóźniej, lub nawet odłożyć je na jutro, które nie nadejdzie, może pomóc wam i przyszłym pokoleniom, tych którzy będą musieli pracować z kodem odziedziczonym po was.
In recent years we have seen explosion of languages which run on Java Virtual Machine. We also have seen existing languages getting their implementations being rewritten to JVM. With all of the above we have seen rapid development of tools like parsers, bytecode generators and such, even inside JVM we saw initiatives like Da Vinci Machine Project, which led to invoke dynamic in JDK 7 and recent development of Graal and Truffle projects.
Is it really hard to write new programming language running on JVM? Even if you are not going to write your own I think it is worth to understand how your favorite language runs undercover, how early decisions can impact language extensibility and performance, what JVM itself and JVM ecosystem has to offer to language implementors.
During the session I will try to get you familiar with options you have when choosing parsers and byte code manipulation libraries. which language implementation to consider, how to test and tune your "new baby". Will you be able after this session to develop new and shiny language, packed with killer features language? No. But for sure you will understand difference between lexers and parsers, how bytecode works, why invoke dynamic and Graal and Truffle are so important to the future of JVM platform. Will we have time to write simple, compiled language?
PLNOG 13: Robert Ślaski: NFV, Virtualise networks or die – the voice of the r...PROIDEA
Robert Ślaski – Chief network consultant at Atende S.A., with 15 years experience in ICT, responsible for most demanding and challenging company projects within operator networks and mobile technologies – i.e. for ATMAN, T-Mobile, Polkomtel, OST112. The Cisco Certified Internetwork Expert CCIE #10877 (Routing & Switching and Security).
Topic of Presentation: NFV, Virtualise networks or die – the voice of the realist
Language: Polish
Abstract: Currently we are on the leading edge of NFV (Network Function Virtualization) hype, but what does it entirely mean? Is the network element virtualization concept a quite new one? Does it mean the same as SDN? When it makes sense, when it is a salvation, and when it would probably fail? For the SP or for the enterprise? An introduction to the topic and a couple of unanswered questions.
JDD2014: JAVA.util.concurrent czyli wielowątkowość z różnych perspektyw, tych...PROIDEA
Wielowątkowość to temat przewijający się często w aplikacjach. Czasem tworzona ręcznie, czasem przykryta przez frameworki. Omówione zostaną niektóre elementy pakietu java.util.concurrent, które można wykorzystać zarówno do implementacji wielowątkowości w swoich aplikacjach jak i bezpiecznego wykorzystywania jej w gotowych projektach opartych na gotowych frameworkach. Przyglądniemy się również sposobom wykorzystania wielowątkowości w JavaEE np w komponentach EJB.
Docker jest wspaniałą technologią. Przy pomocy Dockera w prosty sposób możemy rozwiązać jeden problem, a na jego miejsce stworzyć dwa inne, nowe, bardziej skomplikowane... Co jest powodem takiego stanu rzeczy? Czy przyczyną jest architektura Dockera? Brak zrozumienia? A może coś więcej?
Piątek z XSolve - TravisCI & Continuous DeliveryXSolve
Maciej Papież, Software Developer w XSolve, w prezentacji na temat jak najprostszej implementacji Continuous Delivery/Deployment.
W prezentacji znajdują się informacji na temat prostego pipeline'u CD, TravisCI i praktycznego podejścia do AWS CodeDeploy.
Złam zasady i stwórz wydajny stos IP przy użyciu DPDKSemihalf
W prezentacji znajdziesz opis zagadnienia przetwarzania pakietów w wysokowydajnych sieciach światłowodowych. Koncepcja przetwarzania ruchu sieciowego w przestrzeni użytkownika oparta jest na zastosowaniu frameworku DPDK na platformie Linux/x86.
CPU GHOST BUSTING. Semihalf Barcamp Special. Semihalf
Z prezentacji dowiesz się jak działają nowoczesne procesory, jakich technik używają (Speculative Execution, Branch Prediction) aby zwiększyć wydajność i jak to się stało, że niektóre z tych usprawnień mogą być sprytnie wykorzystane do pozyskania poufnych danych. Omawiamy przykład złośliwego kodu wykorzystującego te luki i skutki jego działania. Pokazujemy mechanizmy obrony i wyjaśniamy jakie mogą przynosić ograniczenia.
PLNOG 13: Robert Ślaski: NFV, Virtualise networks or die – the voice of the r...PROIDEA
Robert Ślaski – Chief network consultant at Atende S.A., with 15 years experience in ICT, responsible for most demanding and challenging company projects within operator networks and mobile technologies – i.e. for ATMAN, T-Mobile, Polkomtel, OST112. The Cisco Certified Internetwork Expert CCIE #10877 (Routing & Switching and Security).
Topic of Presentation: NFV, Virtualise networks or die – the voice of the realist
Language: Polish
Abstract: Currently we are on the leading edge of NFV (Network Function Virtualization) hype, but what does it entirely mean? Is the network element virtualization concept a quite new one? Does it mean the same as SDN? When it makes sense, when it is a salvation, and when it would probably fail? For the SP or for the enterprise? An introduction to the topic and a couple of unanswered questions.
JDD2014: JAVA.util.concurrent czyli wielowątkowość z różnych perspektyw, tych...PROIDEA
Wielowątkowość to temat przewijający się często w aplikacjach. Czasem tworzona ręcznie, czasem przykryta przez frameworki. Omówione zostaną niektóre elementy pakietu java.util.concurrent, które można wykorzystać zarówno do implementacji wielowątkowości w swoich aplikacjach jak i bezpiecznego wykorzystywania jej w gotowych projektach opartych na gotowych frameworkach. Przyglądniemy się również sposobom wykorzystania wielowątkowości w JavaEE np w komponentach EJB.
Docker jest wspaniałą technologią. Przy pomocy Dockera w prosty sposób możemy rozwiązać jeden problem, a na jego miejsce stworzyć dwa inne, nowe, bardziej skomplikowane... Co jest powodem takiego stanu rzeczy? Czy przyczyną jest architektura Dockera? Brak zrozumienia? A może coś więcej?
Piątek z XSolve - TravisCI & Continuous DeliveryXSolve
Maciej Papież, Software Developer w XSolve, w prezentacji na temat jak najprostszej implementacji Continuous Delivery/Deployment.
W prezentacji znajdują się informacji na temat prostego pipeline'u CD, TravisCI i praktycznego podejścia do AWS CodeDeploy.
Złam zasady i stwórz wydajny stos IP przy użyciu DPDKSemihalf
W prezentacji znajdziesz opis zagadnienia przetwarzania pakietów w wysokowydajnych sieciach światłowodowych. Koncepcja przetwarzania ruchu sieciowego w przestrzeni użytkownika oparta jest na zastosowaniu frameworku DPDK na platformie Linux/x86.
CPU GHOST BUSTING. Semihalf Barcamp Special. Semihalf
Z prezentacji dowiesz się jak działają nowoczesne procesory, jakich technik używają (Speculative Execution, Branch Prediction) aby zwiększyć wydajność i jak to się stało, że niektóre z tych usprawnień mogą być sprytnie wykorzystane do pozyskania poufnych danych. Omawiamy przykład złośliwego kodu wykorzystującego te luki i skutki jego działania. Pokazujemy mechanizmy obrony i wyjaśniamy jakie mogą przynosić ograniczenia.
4. Celem tej prezentacji jest pokazanie
Technik, których na co dzień nie będziecie
Stosować
Ten materiał zakłada, że na co dzień nie
zgłębiacie terenów przygranicznych
System operacyjny/maszyna wirtualna
Zaprezentowane poniżej informacje i fakty
mogą trwale odmienić wasze postrzeganie
rzeczywistości
5. Dopiero zaczynasz z JVM?
Zachwycisz się złożonością
Masz już za sobą pierwszy pad produkcji?
Przeklniesz złożoność JVM
Chcesz wiedzieć więcej jak to wszystko
działa?
Ta prezentacja łagodnie wprowadzi Cię w
terminologię i podstawy
6. Moją opowieść będę snuł wokół
OpenJDK 8
i
systemu operacyjnego Linux
Część z tych rzeczy może być
prawdą dla innych
JDK i OS
17. Wiele zrobiono i napisano o automatycznym
zarządzaniu pamięcią w JVM
Gdy już ustawisz wszystkie parametry
i
przełączniki
A
GC nadal będzie zniewalało twój CPU
Jedyne co pozostaje to „off heap memory”
19. Allocation and deallocation
is really expensive
Mostly because of costly
JNI calls
and
NMT (native memory tracking)
Mail thread@hotspot-dev
Unsafe allocate
Calls OS malloc function
hotspot/src/share/vm/prims/unsafe.cpp
21. Because it uses malloc
You can „easily” provide your own allocator
export LD_PRELOAD=mylib.so
jemalloc (look cassandra case)
Anyway, it all can end up with
„core dump”
So be carefull
Or use wrappers
22. Tools to play with
github:alexkasko/unsafe-tools
github:peter-lawrey/Java-Chronicle
apache-directmemory
Who depends on unsafe
ehcache (with BigMemory)
hazelcast (with ElasticMemory)
infinispan
lucene
cassandra
25. … and then Jigsaw came
And changed the game
C-Heap API
because
people are actually using it
(broken window)
Unsafe at any Speed
Public sun.misc.Unsafe Replacement API
No plans for JDK9 so far
26. I ziemia się rozstąpiła
I ogień piekielny z ziemi wypełzać począł
drugi jeździec się wyłonił
A imię jego
30. avgqusz
average queue length for this device
await
average response time (ms) of IO requests to a
device.
svctim
average time (ms) a device was servicing requests.
qutim = await svctim
35. sun.nio.ch.DefaultSelectorProvider
if ("Linux".equals(osname)) {
String osversion = AccessController.doPrivileged(
new GetPropertyAction("os.version"));
String[] vers = osversion.split(".", 0);
if (vers.length >= 2) {
try {
int major = Integer.parseInt(vers[0]);
int minor = Integer.parseInt(vers[1]);
if (major > 2 || (major == 2 && minor >= 6)) {
return new sun.nio.ch.EPollSelectorProvider();
}
} catch (NumberFormatException x) {
// format not recognized
}
}
}
return new sun.nio.ch.PollSelectorProvider();
50. Non blocking algorithms
Wait-freedom
Każda operacja zakończy się w z góry określonej
ilości kroków/ instrukcji
Lock-freedom
Pozwala na zagłodzienie wybranych wątków,
Przynajmniej jeden wątek wykonuje operacje
Obstruction-freedom (optimistic concurrency)
58. Inlining
mother of all optimizations
C1 compiler
inlines small methods
-XX:MaxInlineSize=35
-XX:InlineSmallCode=2000
C2 compiler
inlines „hot” methods
-XX:FreqInlineSize=325
59. public class Inline{
public int doubleAndSum(int x,y){
return makeDouble(x)+makeDouble(y);
}
private int makeDouble(int x){
return x+x;
}
//after inlining
public int doubleAndSum(int x,y){
return (x+x)+(y+y);
}
}
60. The easy part
private, static and final
The hard part
Polimorphism
Class hierarchy analisys
Deoptimization
Beware of megamorph
61. const char* StackWalkCompPolicy::shouldInline(methodHandle m, float freq, int cnt) {
// Allows targeted inlining
// positive filter: should send be inlined? returns NULL (--> yes)
// or rejection msg
int max_size = MaxInlineSize;
int cost = m->code_size();
// Check for too many throws (and not too huge)
if (m->interpreter_throwout_count() > InlineThrowCount && cost <
InlineThrowMaxSize ) {
return NULL;
}
// bump the max size if the call is frequent
if ((freq >= InlineFrequencyRatio) || (cnt >= InlineFrequencyCount)) {
if (TraceFrequencyInlining) {
tty->print("(Inlined frequent method)n");
m->print();
}
max_size = FreqInlineSize;
}
if (cost > max_size) {
return (_msg = "too big");
}
return NULL;
}
69. What Every Programmer Should Know About Memory
Cpu Caches and Why You Care
Lock-Free Programming (or, Juggling Razor Blades)
brain food for hackers
Linux Device Drivers