Go vs Rust


Gå til bund
Gravatar #2 - larsp
4. mar. 2020 21:11
Det skyldtes, at Go's garbage collector som minimum aktiveres hvert andet minut

Java, C# og Go's nemesis er tydeligvis garbage collection. Hvorfor er det egentlig så svært at lave en garbage collector der ikke forstyrrer performance med slow downs og tab af realtidsperformance?

Er opgaven ikke "bare" at have en reference counter på alle allokeringer og en super low priority task der løber allokeringerne igennem og laver free på dem ikke længere bruges? Det kræver da ikke at man låser systemet med global locks og lignende? (jvf. java's problemer med realtidsgarantier)

Gravatar #3 - arne_v
4. mar. 2020 23:43
#2

Ref count GC er kendt for at lave memory leaks.

A a = new A();
B b = new B();
a.B = b;
b.A = a;
a = null;
b = null;
Gravatar #4 - arne_v
4. mar. 2020 23:57
#2

Men ja de normale GC i JVM og .NET er gode for generel performance men skidt for realtids-egenskaberne - der kommer pauser aka drop i performance når GC sker.

De eneste som kan lave pause fri GC er Azul Zing C4.

Gravatar #5 - arne_v
5. mar. 2020 00:54
Gravatar #6 - arne_v
5. mar. 2020 01:05
#3

Bemærk at der er sprog som bruger reference counting: PHP, Python og Swift.

Python har en cycle detection mekanisme (grundliggende bruger den samme mekanisme som Java og .NET GC til at GC'e cycles som har undgået at blive nedlagt med reference counting).

Og Swift har et weak keyword som kan bruges til at undgå problemerne.

Gravatar #7 - CBM
5. mar. 2020 04:19
Man kan jo også bare bruge et sprog hvor man explicit skal free den memory man bruger
Gravatar #8 - arne_v
5. mar. 2020 12:58
#7

Absolut.

Der er bare en rimelig solid erfaring for at der er en vis sandsynlighed P > 0 for at udviklere ikke håndterer det korrekt.

Det går næsten aldrig galt i de simple tilfælde hvor allokering og frigivning sker i samme funktion.

Men i mere komplicerede tilfælde hvor noget allokeres dybt nede i et kalde træ og en pointer så kopieres rundt i programmet i flere kopier, så kan det godt være svært at sikre at der sker en frigivelse.
Gravatar #9 - CBM
5. mar. 2020 14:18
arne_v (8) skrev:
#7

Absolut.

Der er bare en rimelig solid erfaring for at der er en vis sandsynlighed P > 0 for at udviklere ikke håndterer det korrekt.

Det går næsten aldrig galt i de simple tilfælde hvor allokering og frigivning sker i samme funktion.

Men i mere komplicerede tilfælde hvor noget allokeres dybt nede i et kalde træ og en pointer så kopieres rundt i programmet i flere kopier, så kan det godt være svært at sikre at der sker en frigivelse.

Så må man jo analysere sin kode
Gravatar #10 - arne_v
5. mar. 2020 15:10
#9

Ja.

Manuelt er næsten umuligt med store code bases.

Men tools som Coverity, Klocwork, SonarCube etc. kan meget. Desværre er de ikke så udbredte.

Og der er stadig et problem hvis allokering sker i en ekstern binary og man kun har kildekoden som skal frigive.
Gravatar #11 - CBM
5. mar. 2020 16:31
#10

Klockwork er rigtig smart

Til Delphi er der også plugins som EurekaLog
Gå til top

Opret dig som bruger i dag

Det er gratis, og du binder dig ikke til noget.

Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.

Opret Bruger Login