Czy staranne programowanie może wyeliminować potrzebę używania garbage colloector.

0

Pytanie jak w temacie wątku, najbardziej interesuje mnie to odnośnie C++, ale też chętnie dowiem się jak to jest w innych językach.

1

Staranne programowanie w asemblerze może wyeliminować potrzebę używania innych języków.

A bardziej na serio:
Nie rozumiem dlaczego użyłeś słowa "staranne". Ja bym to ujął tak: na upartego bardzo dużo da się zrobić bez automatycznego odśmiecania (czy to działającego w tle czy też przez zliczanie referencji).

Dla przykładu typowy kod Javowy bardzo mocno polega na garbage collectorze. Jednak ci co używają Javy w HFT robią co mogą, by produkować śmiecia jak najmniej - w końcu garbage collection działające w tle ma mocno niedeterministyczne pauzy, a te przesądzają o tym, czy Java się nadaje do HFT czy nie.

PS:
ZTCW to Rust ma mechanizmy takie jak ownership, borrowing i lifetimes, które mają za zadanie eliminować potrzebę używania garbage collectora zachowując jednocześnie pewne gwarancje co do bezpieczeństwa operowania na wskaźnikach.

0

Jeśli chodzi o Javę to oczywiście że się da:
http://www.docjar.com/docs/api/sun/misc/Unsafe.html

freeMemory / allocateMemory i pojechał :)

0

W C++ powinno się pisac tak, by gc nie używać. Jeśli system za Ciebie musi zwalniać pamięć, bo jej nie zwolniłeś Ty, bo nie uzyłeś sprytnych wskaźników, bądź innych rzeczy wspomagających dobre programowanie, to jutro robiąc zmiany w kodzie narażasz ten kod na bum. Dlatego ten język (jak C itp) uzywany jest obecnie częściej w programowaniu embeded, niż w standardzie, bo niestety coraz trudniej w znalezioeniu programistów piszących czysty i w miarę dobry kod...

0

jak prealokujesz wszystko czego uzywasz na starcie to gc jest zbedny, w wypadku javy jest to jak najbardziej mozliwe przy czym oprocz wiekszego rygoru i trudniejszych algororytmow nie obejdzie sie bez samodzielnego zakodowania podstawowych narzedzi typu kolekcje, napisy, i/o

0

Przykładem na programowanie w Javie bez generowania śmieci jest: https://logging.apache.org/log4j/2.x/manual/garbagefree.html

Moim zdaniem jednak przyszłością są garbage collectory z minimalnymi pauzami jak np: https://wiki.openjdk.java.net/display/shenandoah/Main . Jest także działający od dawna Zing od Azul Systems, ale on jest płatny, więc ma dość niszowe (z punktu widzenia typowego Kowalskiego) zastosowania.

Przykład z wiki Shenandoah:

GC(3) Pause Init Mark 1.142ms
GC(3) Concurrent marking 7388M->7624M(8192M) 373.087ms
GC(3) Pause Final Mark 7624M->2832M(8192M) 10.923ms
GC(3) Concurrent evacuation  2836M->3224M(8192M) 115.076ms
GC(3) Pause Init Update Refs 0.028ms
GC(3) Concurrent update references  3224M->3424M(8192M) 210.427ms
GC(3) Pause Final Update Refs 3424M->956M(8192M) 1.150ms
GC(3) Concurrent reset bitmaps 956M->956M(8192M) 0.143ms

W przykładzie najdłuższa pauza to 11 milisekund. Gdyby zjechali np do 2 ms na 20 GB stertę to można by w Javce bez problemu pisać gry FPS :]

Aktualizacja:
GC ułatwia pisanie wydajnych programów wielowątkowych - w porównaniu do użycia sprytnych wskaźników. Te wskaźniki w rzeczywistości są dość upośledzone, wystarczy popatrzeć tutaj: http://www.boost.org/doc/libs/1_64_0/libs/smart_ptr/shared_ptr.htm#ThreadSafety

W Javce nie ma tego problemu, że referencja się gdzieś popsuje. Mogę mieć ten sam obiekt (z referencjami w środku) w N wątkach i każdy wątek może sobie aktualizować pola tego obiektu i nie będzie takiej sytuacji, że któraś referencja się popsuje albo któryś obiekt nie zostanie posprzątany. W C++ jest narzut wydajnościowy na używanie niby-sprytnych wskaźników, a w Javce każdy wskaźnik jest mocno sprytny i to praktycznie za darmo.

1 użytkowników online, w tym zalogowanych: 0, gości: 1