mboost-dp1
Go vs Rust
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)
#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.
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.
#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.
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.
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
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.
- Forside
- ⟨
- Forum
- ⟨
- Tagwall
Gå til bund