2013-01-14 10 views
12

Nie wiem zbyt wiele na temat języka programowania Go, ale widziałem kilka twierdzeń, że powiedział, że Go ma bezużyteczną kolekcję śmieci i jest znacznie lepszy niż inne odśmiecacze śmieci (takie jak śmieciarka JVM). Opracowałem aplikację dla JVM i wiem, że narzędzie do usuwania śmieci JVM nie jest wolne od opóźnień (szczególnie w przypadku użycia dużej pamięci).Co to jest podejście do zbierania śmieci języka Go w porównaniu do innych?

Zastanawiam się, jaka jest różnica między podejściem do zbierania śmieci w Go i innych, które powodują, że nie powoduje opóźnień?

Z góry dziękuję.


Edit: @All I edytowane to pytanie całkowicie, proszę głosować ponownie otworzyć na to pytanie, jeśli okaże się to konstruktywne.

+6

W grach w Javie nigdy nie pozwolę, aby garbage collector działał, dopóki nie zostanie osiągnięty odpowiedni punkt w grze (np. Menu pauzy). Aby to osiągnąć, zawsze miałbym jakąś klasę menedżerską, która zachowuje referencje do wszystkich utworzonych obiektów i zwalnia je wszystkie po osiągnięciu menu pauzy lub końca poziomu. –

+0

Może Ci się to podobać w porównaniu. http://code.google.com/p/jgo/ Jeśli program Go obsługuje strukturę 'struct', może to potencjalnie całkowicie uniknąć GC zamiast mieć nadzieję, że JIT zrobi to za Ciebie. –

+0

@ JonTaylor Dlaczego to zrobiłeś? z powodu wydajności śmieciarek JVM lub czegoś innego? –

Odpowiedz

14

Go nie ma zbierania śmieci bez opóźnień. Jeśli możesz wskazać, gdzie są te roszczenia, chciałbym spróbować je poprawić.

Jedną z zalet, którą uważamy, że Go ma na Javie, jest większa kontrola nad układem pamięci. Na przykład prosty pakiet grafiki 2D może zdefiniować:

type Rect struct { 
    Min Point 
    Max Point 
} 

type Point struct { 
    X int 
    Y int 
} 

W programie Go, prostokąt jest tylko czterema liczbami całkowitymi ciągłymi w pamięci. Nadal możesz przekazać & r.Max do funkcji oczekującej * Point, to tylko wskaźnik do środka zmiennej Rect r.

W języku Java, równoważnym wyrażeniem byłoby utworzenie klas Rect i Point, w którym to przypadku pola Min i Max w Rect byłyby wskaźnikami do oddzielnie przydzielonych obiektów. Wymaga to większej ilości przydzielonych obiektów, zajmowania większej ilości pamięci i dawania garbage collectorowi więcej możliwości śledzenia i więcej zadań do wykonania. Z drugiej strony unika się konieczności tworzenia wskaźnika na środku obiektu.

W porównaniu z Javą, program Go zapewnia programistom większą kontrolę nad układem pamięci i można go użyć do zmniejszenia obciążenia kolektora. Może to być bardzo ważne w programach z dużą ilością danych. Kontrola układu pamięci może być również ważna dla wydobywania wydajności ze sprzętu ze względu na efekty pamięci podręcznej i takie, ale jest to styczne do pierwotnego pytania.

Kolekcjoner w bieżących dystrybucjach Go jest rozsądny, ale w żadnym razie nie najnowocześniejszy. Mamy plany, aby wydać więcej wysiłku, aby poprawić go w ciągu następnego roku lub dwóch. Żeby było jasne, śmieciarz z firmy Go nie jest tak dobry jak współczesne śmieciarki Java, ale uważamy, że w Go łatwiej jest pisać programy, które nie wymagają tak dużej ilości odśmieceń, aby efekt netto był nadal możliwy. to usuwanie śmieci jest mniejszym problemem w programie Go niż w równoważnym programie Java.

+0

Widziałem go w programie faq: http://golang.org/doc/faq#garbage_collection –

+1

Myślę, że jest to bardziej związane z językiem java niż z samym jvm ... scala, język jvm ma klasy wartości robi podobna praca http://docs.scala-lang.org/overviews/core/value-classes.html Życzę więcej zasobów porównujących jvm z gc, oba są całkiem interesujące i czuję, że obaj są otoczeni wiele mitów i nieporozumień ..... – CocoOS

+0

@ SaeedZarinfam, być może błędnie przeczytałeś. Nie widzę tam roszczenia "bezużytecznego zbierania śmieci" (ani w [szybkim przeszukiwaniu jego historii] (https://github.com/golang/go/blame/master/doc/go_faq.html# L1867)). Podaje tylko "[...] pewność, że możemy ** zrealizować ** to z [...] nie ** znaczącym ** opóźnieniem" (podkreślenie dodane). Zwykle następowało po nim nawiasie notatkę na temat implementacji * current * (od tego czasu notatka została przeniesiona do własnego akapitu). Dla mnie "bez znacznego opóźnienia"! = "Bez opóźnień" i odnosi się również do * przyszłych * ulepszeń. –

Powiązane problemy