Please enable JavaScript.

Coggle requires JavaScript to display documents.

memory in JV (profiling (Java Mission Control (since Java 8, more accurate…

- - - - This type of OOM could be drastic based on the type of load. An application can be performing well under allocated memory for the JVM for 20 users. But if there was a spike for the 100th user, it might have hit a memory spike which leads to the out of memory error. There are two possibilities to tackle this cause.
    - - This is where the memory usage increases over time which is a problem due to a programming issue.
- - - - Parallel collector
        
        throughput or parallel collector - default gc used until java 8
        
        It uses multiple CPUs to perform garbage collector. While serial collector uses 1 thread to perform GC, parallel GC uses several threads to perform GC and it is useful when there is enough memory and good number of cores.
      - Serial collector
        
        It uses single thread to perform all the garbage collection and is suitable for basic application with single processor machines.
      - Concurrent collector
        
        Concurrent collector performs garbage collection with application threads. It is useful for applications which have medium to large datasets and require quick response time.
    - - Mark and Sweep algorithms use conceptually the simplest approach to garbage by just ignoring such objects. What this means is that after the marking phase has completed all space occupied by unvisited objects is considered free and can thus be reused to allocate new objects.
      - The approach requires using the so called free-list recording of every free region and its size. The management of the free-lists adds overhead to object allocation. Built into this approach is another weakness – there may exist plenty of free regions but if no single region is large enough to accommodate the allocation, the allocation is still going to fail (with an OutOfMemoryError in Java).
      - steps
        
        Marking is walking through all reachable objects, starting from GC roots and keeping a ledger in native memory about all such objects
        
        Sweeping is making sure the memory addresses occupied by non-reachable objects can be reused by the next allocations.
      - Different GC algorithms within the JVM, such as Parallel Scavenge, Parallel Mark+Copy or CMS, are implementing those phases slightly differently, but at the conceptual level the process remains similar to the two steps described above.
    - - Jednowątkowy: Wszystkie fazy garbage collection (Young Generation, Old Generation) są wykonywane przy użyciu jednego wątku.
      - Stop-the-world: Podczas działania Serial GC wszystkie wątki aplikacji są zatrzymywane (stop-the-world pause).
      - Prostota: Serial GC jest prosty w implementacji i ma mniejsze wymagania pamięciowe w porównaniu do bardziej złożonych algorytmów GC. Serial GC jest najbardziej efektywny w przypadku małych aplikacji jednowątkowych lub aplikacji działających na systemach z ograniczoną liczbą rdzeni procesora.
    - - Parallel GC, znany również jako Throughput Collector, używa wielu wątków do przeprowadzania garbage collection, co zwiększa wydajność na wielordzeniowych systemach, zaprojektowany, aby maksymalizować przepustowość aplikacji, minimalizując czas spędzony na garbage collection.
      - -XX:+UseParallelGC
      - Parallel Old GC
        
        ozszerzenie Parallel GC na starą generację, również używa wielu wątków. Podobne jak Parallel GC, ale obsługuje również starą generację
    - - Garbage collector minimalizujący pauzy stop-the-world poprzez równoległe skanowanie starych obiektów.
      - Minimalizacja Pauz: CMS stara się minimalizować przestoje aplikacji, wykonując większość pracy GC równolegle.
      - Algorytm: Wykorzystuje algorytm "mark-sweep", który składa się z faz: inicjalne oznaczanie (initial mark), współbieżne oznaczanie (concurrent marking), remark (remark) i współbieżne oczyszczanie (concurrent sweep).
      - Fragmentacja: CMS może prowadzić do fragmentacji pamięci, ponieważ nie wykonuje kompaktacji obiektów.
      - Pamięciochłonność: Wymaga dodatkowej pamięci dla struktur danych używanych podczas współbieżnego oznaczania.
      - Aplikacje wymagające niskich opóźnień (low-latency), gdzie krótkie pauzy są krytyczne.
    - - Garbage collector zaprojektowany do obsługi dużych heap z niskimi opóźnieniami, dzieli heap na regiony.
        Zastosowanie: Aplikacje o dużych heap i wymaganiach dotyczących niskich opóźnień.
      - Regiony: G1 dzieli heap na wiele mniejszych regionów i wykonuje garbage collection na poziomie regionów.
      - Algorytm: Używa techniki "mark-copy" i wykonuje "young" i "mixed" garbage collection, gdzie mixed GC obejmuje zarówno młode, jak i stare regiony.
      - Minimalizacja Pauz: G1 stara się przewidzieć i ograniczyć czas pauz, pozwalając na konfigurację docelowego czasu pauzy.
      - Kompakcja: G1 wykonuje kompaktację pamięci podczas mixed GC, co pomaga w redukcji fragmentacji.
    - - Niskolatencyjny garbage collector zaprojektowany do obsługi bardzo dużych heap, minimalizujący pauzy stop-the-world.
        Zastosowanie: Aplikacje o bardzo dużych heap i wymaganiach dotyczących ultra niskich opóźnień.
    - - Niskolatencyjny garbage collector opracowany przez Red Hat, minimalizujący pauzy GC przez równoległe skanowanie.
  - - - Local variable and input parameters of the currently executing methods
      - Active threads
      - Static field of the loaded classes
      - JNI references
  - - - The application threads need to be stopped for the marking to happen as you cannot really traverse the graph if it keeps changing under your feet all the time. Such a situation when the application threads are temporarily stopped so that the JVM can indulge in housekeeping activities is called a safe point resulting in a Stop The World pause. Safe points can be triggered for different reasons but garbage collection is by far the most common reason for a safe point to be introduced.
      - The duration of this pause depends neither on the total number of objects in heap nor on the size of the heap but on the number of alive objects. So increasing the size of the heap does not directly affect the duration of the marking phase.
  - - - In C++ shared pointers count references, Reference counting
      - With this approach It is quite easy to end up with a detached cycle of objects none of which are in scope yet due to cyclic references the count of their reference is not zero.There are some ways to overcome this, such as using special ‘weak’ references or applying a separate algorithm for collecting cycles. Perl, Python and PHP – all handle cycles in one way or another.
  - - - Write operations become more time-consuming as finding the next free block of sufficient size is no longer a trivial operation.
      - When creating new objects, JVM is allocating memory in contiguous blocks. So if fragmentation escalates to a point where no individual free fragment is large enough to accommodate the newly created object, an allocation error occurs.
    - - most allocations inside applications fall into two categories:
        
        Most of the objects become unused quickly
        
        The ones that do not usually survive for a (very) long time
      - Based on this hypothesis, the memory inside the VM is divided into what is called the Young Generation and the Old Generation. The latter is sometimes also called Tenured.
  - - - Collecting garbage from the Young space is called Minor GC
      - Minor GC is always triggered when the JVM is unable to allocate space for a new object, e.g. Eden is getting full.
      - During a Minor GC event, Tenured Generation is effectively ignored. References from Tenured Generation to Young Generation are considered to be GC roots. References from Young Generation to Tenured Generation are simply ignored during the mark phase.
      - Against common belief, Minor GC does trigger stop-the-world pauses, suspending the application threads. For most applications, the length of the pauses is negligible latency-wise if most of the objects in the Eden can be considered garbage and are never copied to Survivor/Old spaces. If the opposite is true and most of the newborn objects are not eligible for collection, Minor GC pauses start taking considerably more time.
    - - major GC
        
        Zajmuje się czyszczeniem Old Generation i może również uwzględniać Metaspace.
        
        many Major GCs are triggered by Minor GCs, so separating the two is impossible in many cases. On the other hand – modern garbage collection algorithms like G1 perform partial garbage cleaning so, again, using the term ‘cleaning’ is only partially correct.
        
        Usuwa nieużywane obiekty z Old Generation i jest zazwyczaj wywoływany, gdy nie ma wystarczająco dużo miejsca na nowo tworzone obiekty lub gdy stara generacja jest zapełniona.
        
        Podczas Major GC może być przeprowadzana kompakcja (defragmentacja) pamięci w Old Generation, co polega na przenoszeniu obiektów w celu zwolnienia ciągłych bloków pamięci.
        
        Kiedy podczas promocji obiektów z młodej generacji (Young Generation) do starej generacji (Old Generation) brakuje miejsca w Old Generation, może zostać wywołany Full GC.
      - instead of worrying about whether the GC is called Major or Full GC, you should focus on finding out whether the GC at hand stopped all the application threads or was able to progress concurrently with the application threads.
      - full gc
        
        Full GC jest bardziej kompleksowym procesem garbage collection, który obejmuje zarówno młodą generację (Young Generation), jak i starą generację (Old Generation).
- - - - W Javie najczęstszym sposobem korzystania z off-heap memory jest używanie klasy java.nio.DirectByteBuffer, która pozwala na alokowanie dużych bloków pamięci poza stertą JVM. Pamięć ta jest zarządzana przez natywną bibliotekę JNI (Java Native Interface).
      - Off-heap memory to pamięć, która jest zarządzana poza standardową stertą JVM, ale wciąż może być zarządzana przez JVM poprzez specjalne mechanizmy lub biblioteki, takie jak DirectByteBuffer.
    - - Bazy danych: Niektóre nowoczesne bazy danych i systemy pamięci podręcznej, takie jak Apache Cassandra czy Hazelcast, korzystają z off-heap memory do zarządzania dużymi ilościami danych i zmniejszenia obciążenia GC.
      - Bufory sieciowe: Off-heap memory jest często używana do zarządzania dużymi buforami sieciowymi, co pozwala na lepszą kontrolę nad wydajnością operacji I/O.
      - Struktury danych: Aplikacje przetwarzające duże ilości danych mogą używać off-heap memory do zarządzania strukturami danych, takimi jak tablice hash czy drzewa, aby uniknąć problemów z GC.
      - Często używana do zarządzania dużymi blokami danych, które nie powinny być kontrolowane przez garbage collector, aby zmniejszyć przerwy GC.
      - Przydatna w aplikacjach wymagających dużej ilości pamięci, takich jak bufory sieciowe, duże struktury danych czy przetwarzanie strumieniowe.
  - - - All minor GCs are “stop the world” events, so when minor GCs occur, application threads will also stop.
      - Young generation is divided into 3 parts.
        
        Eden space
        
        All newly created objects are allocated in eden space.
        
        When Eden space is completely filled with objects then minor GC will occur. All the objects which are not dead or unreferenced will be moved to one of the survivors spaces.
        
        TLAB
        
        As there are typically multiple threads creating a lot of objects simultaneously, Eden is further divided into one or more Thread Local Allocation Buffer (TLAB for short) residing in the Eden space
        
        These buffers allow the JVM to allocate most objects within one thread directly in the corresponding TLAB, avoiding the expensive synchronization with other threads.
        
        When allocation inside a TLAB is not possible (typically because there’s not enough room there), the allocation moves on to a shared Eden space. If there’s not enough room in there either, a garbage collection process in Young Generation is triggered to free up more space. If the garbage collection also does not result in sufficient free memory inside Eden, then the object is allocated in the Old Generation.
        
        After the marking phase is completed, all the live objects in Eden are copied to one of the Survivor spaces. The whole Eden is now considered to be empty and can be reused to allocate more objects. Such an approach is called “Mark and Copy”: the live objects are marked, and then copied (not moved) to a survivor space.
        
        flagi
        
        -Xms: Ustawia początkowy rozmiar heap.
        
        -Xmx: Ustawia maksymalny rozmiar heap.
        
        Survivor spaces
        
        S0
        
        When Eden space is filled again, then all the live objects in Eden space and survivor space S0 will be moved to Survivor space S1.
        
        S1
        
        Once objects survived multiple cycles of minor GC, they will be moved to old generation. You can control this threshold by MaxTenuringThreshold. The actual tenuring threshold is dynamically adjusted by JVM.
        
        Next to the Eden space reside two Survivor spaces called from and to. It is important to notice that one of the two Survivor spaces is always empty.
        
        The empty Survivor space will start having residents next time the Young generation gets collected. All of the live objects from the whole of the Young generation (that includes both the Eden space and the non-empty ‘from’ Survivor space) are copied to the ‘to’ survivor space. After this process has completed, ‘to’ now contains objects and ‘from’ does not. Their roles are switched at this time.
        
        This process of copying the live objects between the two Survivor spaces is repeated several times until some objects are considered to have matured and are ‘old enough’. Such ‘tenured’ objects can thus be promoted to the Old Generation. When this happens, objects are not moved from one survivor space to another but instead to the Old space, where they will reside until they become unreachable.
        
        To determine whether the object is ‘old enough’ to be considered ready for propagation to Old space, GC tracks the number of collections a particular object has survived. After each generation of objects finishes with a GC, those still alive have their age incremented. Whenever the age exceeds a certain tenuring threshold the object will be promoted to Old space.
        -XX:+MaxTenuringThreshold
        
        Promotion may also happen prematurely if the size of the Survivor space is not enough to hold all of the live objects in the Young generation
    - - It is used to hold old, long surviving objects and is generally larger than the young generation.
      - When tenured space is completely filled(or predefined threshold is met) then Major GC will occur. It will reclaim the memory and free up space.
      - Often, Major GCs are slower and less frequent than minor GC.
      - If you have lots of temporary objects then there will be lot of minor gc. You can provide arguments XX:NewRatio=1 to distribute 50% to young generation and 50% to old. By default, NewRatio=2 hence young Generation is 1/3 of total heap
      - GC in the Old Generation happens less frequently than in the Young Generation. Also, since most objects are expected to be alive in the Old Generation, there is no Mark and Copy happening. Instead, the objects are moved around to minimize fragmentation.
      - gc algorithms used here are a bit different and also have to compact the content of old space by copying the live objects contiguously to the beginning of the Old space
    - - Perm Gen
        
        In JDK 7, interned strings are no longer allocated in the permanent generation of the Java heap. in JDK 8 there is no permanent generation at all.
        
        the permanent generation consists mostly of class declarations loaded and stored into PermGen. This includes the name and fields of the class, methods with the method bytecode, constant pool information, object arrays and type arrays associated with a class and Just In Time compiler optimizations.
        
        why PermGen was removed
        
        The required size of permgen was hard to predict. It resulted in either under-provisioning triggering java.lang.OutOfMemoryError: Permgen size errors or over-provisioning resulting in wasted resources.
        
        GC performance improvements, enabling concurrent class data de-allocation without GC pauses and specific iterators on metadata
        
        Support for further optimizations such as G1 concurrent class unloading.
        
        the interned Strings were stored in a special pool of RAM called the perm gen, where the JVM also loaded classes and stored natively compiled code.
      - -XX:MaxPermSize=384m -XX:MaxMetaspaceSize=64m
      - class unloading
        
        By default classes are loaded by JVM and left forever even if no code is using them anymore, but we can change this behavior with below parameter.
        -XX:+CMSClassUnloadingEnabled
        
        If you enable CMSClassUnloadingEnabled, GC will sweep PermGen too and remove classes which are no longer used. This option will work only when UseConcMarkSweepGC is also enabled using the below option. So when running ParallelGC or, God forbid, Serial GC, make sure you have set your GC to CMS by specifying:
        -XX:+UseConcMarkSweepGC
      - metaspace overflow code
        
        public class Metaspace { static javassist.ClassPool cp = javassist.ClassPool.getDefault(); public static void main(String[] args) throws Exception{ for (int i = 0; ; i++) { Class c = cp.makeClass("eu.plumbr.demo.Generated" + i).toClass(); } } }
      - general
        
        By default, Metaspace size is only limited by the amount of native memory available to the Java process.
        
        It is located in the native memory and does not interfere with the regular heap objects.
        
        W przeciwieństwie do Permanent Generation, Metaspace jest zarządzany dynamicznie, co oznacza, że jego rozmiar może być automatycznie dostosowywany podczas działania aplikacji.
  - - - -Xms: Ustawia początkowy rozmiar heap.
      - -Xmx: Ustawia maksymalny rozmiar heap.
- - - - means that an object has neither strong nor soft references pointing to it. The object can be reached only by traversing a weak reference.
  - - - Soft references can be used for implementing memory-sensitive caches where memory management is a very important factor.
- - - - Pamięć na stosie jest zarządzana automatycznie w trakcie wywoływania i kończenia metod. Dane na stosie są szybkie w dostępie, ale są ograniczone do żywotności metody.
      - Każda metoda uruchomiona w Javie ma własny stos, który przechowuje zmienne lokalne i dane potrzebne do wykonania metody.