Obszar pamięci natywnej (off heap) podzielony jest na wiele mniejszych fragmentów. Z punktu widzenia początkującego programisty najważniejszy będzie stos i sterta.
Stos(Stack) jest tworzony dla każdego działającego wątku w aplikacji. Wątek zaś to ciąg instrukcji wykonywanych sekwencyjnie jedna za drugą. Aplikacje, które potrafią wykonywać kilka operacji równolegle, są szczególnie użyteczne w przypadku procesorów wielordzeniowych i środowisk wieloprocesorowych.
Na stosie odkładane są ramki, które reprezentują wywoływane w programie metody. Każda ramka zawiera zmienne lokalne, parametry danej metody, a także adres powrotu wskazujący miejsce, z którego metoda została wywołana. Jeśli zmienne te są typów prostych, to na stos trafia odpowiednia wartość, jeśli jest to zmienna obiektowa, to na stosie przechowywana jest jedynie referencja (adres w pamięci), która wskazuje na odpowiedni obiekt na stercie. Jeżeli w ramach programu wywoływana jest kolejna metoda, to na stosie zostanie utworzona kolejna ramka. Jeżeli metoda się wykona, to odpowiadająca jej ramka jest zdejmowana ze stosu.
Stos jest typem kolekcji LIFO (Last In First Out), czyli ramka, która pojawiła się na stosie najpóźniej, zostanie z niego najwcześniej zdjęta.
Stos zajmuje dużo mniej pamięci niż stera i jest to różnica kilku MB dla stosu vs kilkaset MB lub nawet GB dla sterty.
Sterta (Heap) – Najczęściej stanowi największy wycinek pamięci. To tutaj przechowywane są wszystkie obiekty, które tworzymy w programie. Sterta dzieli się na dwie główne części:
- młodą generację (young generation),
- starą generację (tenured space / old generation).
Obiekty zaraz po utworzeniu trafiają do obszaru w młodej generacji o nazwie Eden. Jeżeli przetrwają kilka cyklów odśmiecania przez Garbage Collector, czyli nadal będą używane w ramach programu, to przejdą do przestrzeni obiektów pozostałych przy życiu (survivor space). Jeśli obiekt przeżyje odpowiednio długo w obszarze survivor space to trafi do ostatniego „worka” ze starą generacją obiektów (tenured space), gdzie będzie do końca swojego wirtualnego życia.
Wynika to z tego, że Garbage Collector może dzięki temu zoptymalizować swoją pracę przy odśmiecaniu pamięci. Młodych obiektów tworzy się zazwyczaj dużo, ale szybko stają się też niepotrzebne, natomiast obiekty, które istnieją w pamięci już przez długi czas, prawdopodobnie będą tam jeszcze dłużej i nie trzeba tej pamięci tam tak często sprawdzać. Dzięki czemu, Garbage Collector może wykorzystywać dodatkowe algorytmy optymalizujące.
I ponieważ String jest typem obiektowym, to takie pola jak: firstName i lastName np: obiektu Employee są referencjami na kolejne obiekty na stercie. Również parametr args metody main jest on referencją na obiekt – a właściwie tablicę.