[hipodrom]

#tworczoscwlasna #programowanie #heheszki #humorobrazkowy

mój pierwszy mem.

[S.....i]

@hipodrom pierwszy i s---------y po całości.

[Ponc3k]

@Stulejusz_Wielki no chyba nie chcesz mi powiedzieć że w javie masz jakąkolwiek kontrolę nad pamięcią oprócz xmx i xms

[Antyradek]

@hipodrom Jakie to jest prawdziwe. Ja sam nie znoszę Javy właśnie z tego powodu.

[msichal]

@hipodrom: arduino? ja to wolę mieć kontrolę nad rejestrami

[Wychwalany]

@hipodrom: tylko asembler !!!!1!11!!!!!

[Wyrewolwerowanyrewolwer]

@Ponc3k Ja chce i powiem

Otoz - masz.
Milego wieczoru.

[simperium]

@hipodrom: co ma jazda na motorze do pamięci? ( ಠ_ಠ)

[Flypho]

Jakie to jest prawdziwe. Ja sam nie znoszę Javy właśnie z tego powodu.

@Antyradek:
Że jest mniej kodu do napisania? xD Bo nie rozumiem kompletnie tego argumentu. Mógłbym znaleźć milion powodów dla których można nie lubić Javy (no dobra, może pół, bo sam lubię ten język), ale k---a, że nie trzeba zarządzać pamięcią? xD

[J.....k]

@hipodrom: TAGUJ TĄ S---------Ą MAŁPĘ K---A MAĆ

[Antyradek]

@Flypho: Nie. Że ci się w losowym momencie włącza GC i spada prędkość aplikacji bez żadnej przyczyny. Więc do wielu rzeczy się nie nadaje.

[Flypho]

@Antyradek:
Czyli masz problem po prostu z wydajnością Javy, a nie tym, że sama zwalnia pamięć. To trochę inne kwestie xD.

[P.....3]

@Antyradek: A jak tam cpp, uwielbiam jak system w moim banku smiga full szybko bo nie ma zadnego GC, ktory spowalnia aplikacje... wait.

[Flypho]

@Antyradek:
A i tak w ogóle to GC wcale nie włącza się w 'losowych momentach' i prędkość aplikacji nie spada bez żadnej przyczyny tylko dlatego, że programiści sami często nie ogarniają, które obiekty na którym etapie mogłyby zostać przez GC zwolnione, ale nie zostają, bo trzymają do nich niepotrzebne referencje. W Javie tak samo jak w CPP też się da (i to bardzo łatwo) zrobić wyciek pamięci, ale za to

[s.....a]

@Antyradek:

Że ci się w losowym momencie włącza GC i spada prędkość aplikacji bez żadnej przyczyny. Więc do wielu rzeczy się nie nadaje.

Nie 'do wielu rzeczy' tylko do bardzo nie wielu rzeczy. Jeżeli przeszkadza ci GC to równie dobrze może ci przeszkadzać context switch wymuszony przez OS, też stracisz cenne milisekundy i tym razem naprawdę jest to efektywnie

[afe1]

@Antyradek:
-java potrafi alokowac obiekty na stosie (np. m.in. gdy ich zycie zaczyna i konczy sie w jakiejs metodzie)
-jest cos takiego jak pauseless garbage collector firmy azul

[onionomous]

@Kroomka: @Stulejusz_Wielki: oho

[Ponc3k]

@Wyrewolwerowanyrewolwer show me

[hasztak]

@Wyrewolwerowanyrewolwer: To jak kolega jest taki mądry, to może łaskawie rozwinie temat, a nie robi się z siebie mądrale?

[Wyrewolwerowanyrewolwer]

@Ponc3k: @hasztak: Panowie coledzy, długi sen podstawą dobrego samopoczucia, nie ma co się spinać.

Ale dobra. Skoro xmx i xms uznajemy za pewną kontrolę nad pamięcią to tak samo możemy zmienić rozmiar stref przetrwania, ilość iteracji potrzebnych do wypromowania obiektu do starej generacji, możemy sugerować rozmiar metaspace (kiedyś permgen) czy też procentową zajętość pamięci przy której gc "powinien" odpalić sprzątanie.
A to tylko z garbage collectora i pewnie o połowie innych, fajniejszych zapomniałem.
Świadomie pominąłem sugerowanie G1 maksymalnego czasu sprzątania.
Przy starszych algorytmach wykrywających czy obiekt jest do usunięcia czy nie, sens miało na końcu znullowanie referencji do obiektu (źródlo: Java Performance). Teraz (nie tylko przez to) w G1 i jej C-setach i R-setach to nie ma większego sensu (od dłuższego czasu GC nie ma problemu z wyłapaniem klik). Ale tak całkiem szczerze to nie pamiętam od