Søppelsamling

Animasjon av en automatisk søppelinnsamling. Den minneområdet er fylt med forskjellige gjenstander (vist med farger), hvorav noen også er ødelagt igjen og la hullene i minneområdet. Hvis det (som i dette eksemplet) ikke er nok ledig plass "på slutten", eller hvis automatisk søppeloppsamling bestemmer, blir minnet "komprimert", med alle gjenstander som fortsatt er i bruk, i begynnelsen og alle hukommelseskap konsolidert ved slutt. Dette gjør et stort minneområde tilgjengelig igjen for fremtidig oppretting av objekter.

Den søppelrydding , kort GC ( engelsk for renovasjon , selv søppelrydding eller haug samling heter) i det angitte programvare og informasjonsteknologi , en automatisk minnehåndtering , noe som bidrar til å unngå problemer med hukommelsen; fordelen er kjøpt med økt ressursforbruk. Blant annet minimeres minnekravet til et dataprogram . Ved kjøretid blir det forsøkt å identifisere minneområder som ikke lenger er nødvendige for å frigjøre dem automatisk. Noen automatiske minneoppryddinger smelter også sammen minneområdene som fremdeles er i bruk ( defragmentering ).

motivasjon

I mange programvaresystemer er nødvendig (arbeids) minne reservert dynamisk (når det er nødvendig) . Hvis det ikke lenger brukes etter at en del av programmet er behandlet, bør minnet frigjøres igjen for å gjøre det mulig å gjenbruke denne ressursen. I tilfelle eksplisitt, manuell minnestyring, gjøres dette ved å spesifisere minnereservasjon og frigjøring i programmet av programmereren , en prosedyre som raskt blir kompleks og dermed potensielt utsatt for feil . I tillegg til å glemme en utgivelse, som kan føre til mangel på minne på lang sikt, fører det vanligvis raskt til et programkrasj å frigjøre minne som fortsatt er nødvendig (andre steder) for tidlig. Glemte minneutgivelser fører ofte ikke umiddelbart til abnormiteter i programflyten - i det minste ikke i løpet av de typiske korte programkjøringene under utviklingen, men bare når det ferdige programmet drives av sluttbrukeren uten avbrudd i timer og dager.

Med manuell minnestyring er det ofte ikke mulig eller veldig tidkrevende å defragmentere minnet. Tungt fragmentert minne kan føre til at programmet ikke tildeler minne fordi det ikke er et tilstrekkelig stort sammenhengende område tilgjengelig.

beskrivelse

Ideen med automatisk søppeloppsamling er å la en rutine kalt en søppeloppsamler gjøre denne jobben automatisk, uten at programmereren trenger å gjøre noe. DVS. minnestyringen flyttes fra en eksplisitt definisjon av programopprettelsestiden ( kompileringstid ) til en dynamisk analyse av minnekravene i løpet av programmet.

En slik automatisk søppeloppsamling kjører vanligvis i bakgrunnen (eller samtidig ) med mer eller mindre regelmessige tidsintervaller (f.eks. Under pauser i programflyten) og utløses ikke eksplisitt av programmet. Imidlertid kan GC ofte også utløses direkte for å gi programmet en viss kontroll over oppryddingen, f.eks. B. i en situasjon med utilstrekkelig minne ( uten minne ).

nærmer seg

Det er flere tilnærminger for å implementere automatisk søppeloppsamling. Ønskede krav kan være så lavt minnetverrsnitt som mulig , maksimal allokeringshastighet , reduksjon i minnefragmentering og mange flere, som også kan motsette hverandre og føre til motstridende mål . DVS. Avhengig av applikasjon kan automatisk søppeloppsamling se veldig annerledes ut og absolutt oppfylle mange krav, men noen ikke.

Vanligvis er imidlertid alle disse variantene assosiert med to grunnleggende typer søppelinnsamling: konservativ og ikke-konservativ søppelinnsamling.

Konservativ automatisk søppelinnsamling

En konservativ automatisk søppeloppsamler er en som ikke pålitelig kan oppdage alle objekter som ikke er referert til. Dette har vanligvis ingen informasjon om hvor referanser til andre objekter ligger i minnet. For å rydde opp i minnet, må det søke i minnet etter mulige referanser. Enhver bitsekvens som kan være en gyldig referanse i minnet blir tatt som en referanse. Det kan ikke avgjøres om dette tross alt ikke er et tilfeldig mønster. Derfor gjenkjenner konservative samlere av og til gjenstander som referert når de faktisk ikke er det. Siden en automatisk søppelsamler må ikke fjerne gjenstander som fortsatt kan brukes, det må konservativt anta at den gjenkjennes bitsekvens er en referanse.

En konservativ samler kan være en risiko, spesielt når automatisk søppeloppsamling må frigjøre mer presserende ressurser enn minne (se sluttføring ). Generelt kan konservative GC-er finnes der interne pekere (dvs. pekere til forskjellige deler av et objekt) er tillatt, noe som gjør det vanskelig å implementere automatisk minnestyring. Eksempler på dette er språkene C og C ++. Det skal bemerkes her at dette ikke gjelder for de "administrerte typene" i C ++ / CLI , siden deres egne referansetyper er introdusert der for automatisk søppeloppsamling, som ikke tillater at adressen til et objekt kan leses opp direkte.

Ikke-konservativ automatisk søppeloppsamling

En ikke-konservativ automatisk søppelinnsamling (noen ganger kalt "eksakt søppelinnsamling" ) er en som har metadata som gjør det mulig å finne alle referanser i objekter og stabelrammer . Med ikke-konservativ søppelinnsamling skilles det mellom å spore søppeloppsamlere og referansetelling .

Sporingsalgoritmer

Merk-og-fei-algoritme

Med denne metoden for søppeloppsamling følges gjenstander som er kjent for å fortsatt brukes av alle referanser til andre gjenstander. Hvert objekt som nås på denne måten er merket. Alle umerkede gjenstander blir deretter frigitt for gjenbruk.

Utgivelsen kan føre til fragmentering av minnet. Problemet her er noe mindre enn med manuell minnestyring. Mens manuell minnestyring alltid finner sted umiddelbart, blir flere objekter nesten alltid fjernet samtidig med mark-and-sweep, noe som frigjør større sammenhengende minneområder.

Merk og kompakt algoritme

Den mark-og-kompakt algoritme , som mark-and-sweep, bruker prinsippet om reachability i grafer for å gjenkjenne objekter som fortsatt er referert. Den kopierer dette til et annet sted i minnet. Hele området som de fremdeles henviste til (man snakker også om "levende") gjenstander ble kopiert fra, blir nå sett på som et fritt minneområde.

Ulempen med denne metoden er at de "levende" objektene selv flyttes, fordi pekepinner til dem blir ugyldige og må tilpasses. Det er i utgangspunktet minst to metoder for dette:

  1. Hvert objekt adresseres via to retninger (avledninger) (via en peker til en peker til objektet ), slik at kun pekeren som peker direkte mot objektet som må justeres når du beveger deg.
  2. Alle referanser refererer direkte til objektet for å unngå tidkrevende dereferanse og er passende tilpasset etter et trekk.

Å flytte gjenstandene har imidlertid fordelen at de som "overlevde" oppryddingen nå er alle komprimert og minnet er praktisk talt defragmentert. Det er også mulig å tildele veldig raskt fordi det ikke blir søkt på ledig lagringsplass på en møysommelig måte. Clear: Hvis de refererte objektene flyttes til "begynnelsen" av minnet, kan nytt minne ganske enkelt tildeles på "slutten", bak det siste levende objektet. Tildeling fungerer relativt enkelt, i likhet med stabelen .

Generasjon

Generasjons-GC-er forkorter varigheten av minneutgivelsen. For dette formål utnyttes situasjonen at i praksis er gjenstanders levetid vanligvis veldig annerledes: På den ene siden er det objekter som overlever hele applikasjonens kjøretid. På den annen side er det et stort antall objekter som bare trengs midlertidig for å utføre en enkelt oppgave. Med generasjons-GCer er minnet delt inn i flere underområder (generasjoner). Levetiden kvantifiseres av en teller som økes med hver søppeloppsamling. For hver applikasjon av frigjøringsalgoritmen (f.eks. Mark-and-Compact eller Stop-And-Copy), flyttes objekter med lang levetid til en høyere generasjon. Fordelen er at søppeloppsamling kan utføres oftere og raskere i lavere generasjoner, siden bare noen av gjenstandene trenger å flyttes og pekerne endres. Det er stor sannsynlighet for at høyere generasjoner bare inneholder levende (eller svært få døde) gjenstander og derfor må ryddes opp sjeldnere.

GC generasjoner i Java HotSpot

Antall generasjoner bestemmes heuristisk (for eksempel tre i .NET, to for unge objekter (også kalt ung generasjon) og en for gamle objekter (fast generasjon) i Java VM fra Sun). I tillegg kan forskjellige algoritmer brukes for hver generasjon. I Java brukes for eksempel en modifisert stopp-og-kopier-algoritme for den laveste generasjonen og mark-and-compact for den høyere generasjonen.

Referansetall

Med denne metoden holder hvert objekt en teller med antall referanser som peker til dette objektet. Hvis referansetelleren til et objekt faller til null, kan det frigjøres.

Et spesielt problem med haugsamling med referansetelling er det som er kjent som sykliske referanser , der objekter holder referanser til hverandre, men ellers ikke lenger brukes av noen forbrukere i systemet. La oss anta for eksempel at objekt A har en referanse til objekt B og omvendt, mens resten av systemet ikke lenger trenger tjenestene. Dermed refererer begge objektene til hverandre (syklisk) , og det er derfor den automatiske søppeloppsamlingen ikke lett kan gjenkjenne at de ikke lenger blir brukt. Konsekvensen av dette er at minnet forblir opptatt i løpet av programutførelsen. Det er forskjellige algoritmer som kan gjenkjenne og løse slike situasjoner, hovedsakelig i henhold til prinsippet om tilgjengelighet i grafer .

eiendommer

Med en søppelsamling kan noen vanlige programmeringsfeil, som ofte gjøres når du arbeider med dynamisk minnestyring , unngås helt eller i det minste delvis. Spesielt bemerkelsesverdig her er minnelekkasjer , dobbel frigjøring av ressurser og dereferanse av ressurser ved et uhell frigitt for tidlig ( hengende pekere ). Å slippe refererte objekter fører til hengende pekere , som ofte fører til programkrasj og ubestemt oppførsel.

Som en konsekvens av Rices teori kan det ikke bestemmes om refererte objekter noen gang vil bli brukt igjen. Dette er grunnen til at automatisk søppeloppsamling bare frigjør objekter som det ikke lenger refereres til i programmet; det forhindrer ikke " minnelekkasjer " av den typen at programmet fremdeles har en referanse til minneområdet, men aldri bruker innholdet igjen. Slike minnelekkasjer representerer vanligvis logiske feil eller designfeil (feil i grunnkonseptet, feil krav til programvaren, programvaredesignfeil) og kan også forekomme med ikke-automatisk minnestyring.

I tillegg løser søppeloppsamling problemet med minnefragmentering , som ikke er en programmeringsfeil i streng forstand, men kan være basert på dårlig programdesign. Dette problemet kan føre til programkrasj som er vanskelig å reprodusere. Problemet med minnefragmentering løses vanligvis ikke ved eksplisitt / manuell minnestyring.

Effektivitet

Om automatisk søppeloppsamling fremskynder eller bremser programmene som helhet er kontroversielt. I noen sammenhenger, for eksempel For eksempel, hvis minne bare frigjøres når systemkravene for øyeblikket er lave, eller hvis minnestyringen til systemet blir avlest ved defragmentering, kan det føre til økt ytelse. Det er mikrobenker som beviser at i programmeringsspråk med automatisk minne- rengjøring er oppretting / frigjøring av objekter raskere generelt enn uten, men også mikrobenker som ser en overveiende negativ innvirkning på ytelsen generelt. En publikasjon fra 2005 sier at søppeloppsamling bare er like god som eller litt bedre enn eksplisitt minnehåndtering hvis søppeloppsamling har krav på fem ganger så mye minne som faktisk er nødvendig. Med tre ganger så mye minne vil søppeloppsamlingen i gjennomsnitt gå 17% tregere, med dobbelt så mye minne 70% tregere enn med eksplisitt minnestyring.

Minnebruk

Når det gjelder minneforbruk, fører automatisk minnestyring og tømming til en overhead sammenlignet med eksplisitt, manuell minnestyring på grunn av tidsforsinket sletting. En vitenskapelig publikasjon fra 1993 anslår overhead for konservativ søppeloppsamling (som tilgjengelig for eksempel for C-språket) til typisk 30–150%. På den annen side er en korrekt implementering av manuell minneutgivelse i ikke-trivielle programmer komplisert å implementere, noe som skaper feilkilder for minnelekkasjer i manuell minneutgivelse. For eksempel kan metoden for referansetelling , som ofte brukes, ikke gjenkjenne sykliske referanser og fører til minnelekkasjer hvis den ikke suppleres av komplekse algoritmer.

determinisme

Ved ikke eksplisitt å definere avgjørelsen om utgivelsestid, avgir programmereren også en del av kontrollen over programflyten. Siden automatisk søppeloppsamling i. d. R. foregår samtidig , selve programmet har ingen informasjon om når minneområder som faktisk frigjøres eller gjenstander som er fullført, er. Som et resultat er programflyten potensielt ikke lenger deterministisk .

Spesielt kan følgende former for ikke-deterministisk oppførsel forekomme:

  • Tidspunktet for sluttføring er ubestemt: Selv om et objekt gjenkjennes som ikke lenger nødvendig og er valgt for rengjøring, er sluttidspunktet for ubestemt tid, noe som betyr at programflyten ikke lenger er deterministisk. Dette er spesielt et problem når objektet bruker delte ressurser eller utfører endelige beregninger. Å gjøre dette i løpet av sluttbehandlingen betraktes som et antimønster i programmeringen .
  • Kjøretiden - både i hele programmet og bare i enkelte seksjoner - kan bli ikke-deterministisk på grunn av forstyrrelser fra søppeloppsamleren. Dette er et problem spesielt for sanntidssystemer . I sanntidssystemer er det for eksempel uakseptabelt at programutførelse blir avbrutt på uforutsigbare tider ved å utføre søppeloppsamling. For sanntidssystemer, for eksempel Real-Time Java , fungerer en automatisk søppeloppsamling forebyggende (for eksempel i inaktiv prosess ) og trinnvis. Enkle trinnvise metoder fungerer for eksempel med såkalt trefarget markering.

Defragmentering

Ved hjelp av komprimeringsalgoritmer kan søppeloppsamling forhindre fragmentering av minnet. Se også Mark and Compact . Dette unngår hull i minnet som ikke kunne fylles på grunn av nye objekter som er for store. Defragmentering resulterer i en lengre forsinkelse i frigjøring av minne, men det reduserer tildelingstiden. For å kunne frigjøre minnet så raskt som mulig, må man passe på at store minneområder må ryddes så sjelden som mulig. Derfor brukes disse algoritmene fortrinnsvis i kombinasjon med generasjonsmetoder .

Defragmentering av minnet har følgende fordeler:

  • Hele tilgjengelig minne brukes.
  • Tildeling av minne tar kortere tid fordi datastrukturene som administrerer dyngen blir mindre komplekse. Det er lettere å finne en ledig minneplassering av passende størrelse.
  • Objekter som er tildelt etter hverandre, ligger vanligvis ved siden av hverandre i minnet (dette kalles god minneplassering ). Studier har vist at objekter som er opprettet etter hverandre ofte brukes samtidig til en bestemt operasjon. Hvis de er nær nok til hverandre, får du tilgang til hurtigbufferminnet og ikke langsommere minne bak det.

Finalisering

Ettersom finalisering ( engelsk finalisering ) er kjent på objektorienterte programmeringsspråk, en spesiell metode som kalles når et objekt fra søppeloppsamleren frigjøres.

I motsetning til destruktører , er ikke finaliseringsmetoder deterministiske: En destruktør kalles når et objekt eksplisitt frigjøres av programmet. Fullføringsmetoden kalles imidlertid ikke før søppeloppsamleren bestemmer seg for å frigjøre gjenstanden. Avhengig av søppeloppsamleren, kan dette skje når som helst når det blir bestemt at programmet ikke lenger bruker objektet - muligens aldri eller på slutten av kjøretiden (se også avsnittet Bestemmelse ).

Avslutning kan føre til problemer i praksis hvis det er ansvarlig for frigjøring av ressurser:

  • Objekter som administrerer ressurser, bør ikke bare frigjøre dem i løpet av sluttbehandlingen. Ellers kan dette føre til blokkerte tilstander i programflyten, siden tidspunktet for sluttføring ikke kan forutsies.
  • Finalisering skaper ekstra prosessbelastning for den automatiske søppeloppsamlingen, som skal utføres så raskt som mulig og uten å forstyrre resten av programflyten.
  • Det er ingen definert rekkefølge for sluttføring. Det kan derfor skje at andre objekter er tilgjengelige under finaliseringen som også er gjenstand for finalisering, men ikke lenger eksisterer i det hele tatt på dette tidspunktet.
  • Avhengig av implementeringen (for eksempel på Java- programmeringsspråket ), er det ingen garanti for at fullføringsrutinen i det hele tatt blir anropet av den automatiske søppeloppsamleren.

I programmeringsspråket Java har objekter en spesiell metode som kalles finalize()som kan overstyres for dette formålet . Av årsakene nevnt ovenfor, anbefales det at Java fullstendig dispenserer med finalisering og i stedet bruker en eksplisitt avslutningsmetode. Den automatiske minnerensingen faller da utelukkende til oppgaven med minnestyring.

fordeling

Noen eldre ( APL , LISP , BASIC ) og mange nyere programmeringsspråk har innebygd automatisk søppeloppsamling.

For programmeringsspråk som C , hvor programmereren må utføre minnestyring for hånd, er det noen ganger biblioteker som gir automatisk minneopprydding, som lett kan omgåes under programmering, eller til og med må omgåes i systemrelatert programmering. . Av denne grunn kan på noen programmeringsspråk programmerte moduler på systemnivå ekskluderes fra automatisk søppeloppsamling ved å eksplisitt merke dem (for eksempel i C # med alternativet / usikre eller i komponent Pascal med den obligatoriske IMPORT SYSTEM- setningen ).

Ytterligere eksempler på programmeringsspråk med automatisk minnestyring er Smalltalk , Haskell , Oberon , Python , Ruby , OCaml , Perl , Visual Objects , ABAP , Objective-C (fra versjon 2.0), D og alle språk som er basert på den Java Virtual Machine (JVM) ( Java , Groovy , Clojure , Scala , ...) samt som ble utviklet for Common language runtime av .NET (for eksempel C # eller VB.NET ).

Apples økosystem

Apple introduserte Garbage Collection i 2007 med utgivelsen av Mac OS X Leopard (10.5) som den "viktigste endringen" for Objective-C 2.0, som ifølge Apple brakte "Objective-C den samme enkle minnehåndteringen som andre moderne språk ". 2012 OS X Mountain Lion ble imidlertid søppeloppsamling (10.8) erklært foreldet, og bruken av med Mac OS X Lion introduserte (10.7) automatisk referansetellingmekanisme (Engl. Automatic reference counting, ARC) på kompileringstidspunkt basert på den rettferdige introduserte CLANG / LLVM 3.0 kompilatorer tvunget. Med denne automatiserte referansetellingen inneholder kompilatoren kode for å gjenkjenne og fjerne gjenstander som ikke lenger er nødvendig ved hjelp av referansetelling på passende punkter. I motsetning til GC-er med referansetelling, kjører den automatiserte referansetellingen serielt og til tider spesifisert på kompileringstidspunktet og er derfor deterministisk. ARC inneholder imidlertid ingen midler for å gjenkjenne sykliske referanser; Programmører må derfor eksplisitt administrere levetiden til objektene sine og manuelt løse sykluser eller jobbe med svake eller usikre referanser.

I følge Apple har mobilapper uten GC bedre og mer forutsigbar ytelse. GC-fri iOS som grunnlag gjør det mulig for Apple å bygge mobile enheter med mindre minne enn den GC-baserte konkurransen, som fremdeles har samme eller bedre ytelse og batterilevetid. en tilnærming som også er beskrevet i fagpressen som en arkitektonisk fordel.

litteratur

  • Richard Jones, Rafael Lins: Garbage Collection. Algoritmer for automatisk dynamisk minnehåndtering. John Wiley, Chichester 1996, ISBN 0-471-94148-4 .
  • Richard Jones, Anthony Hosking, Eliot Moss: The Garbage Collection Handbook. Kunsten om automatisk minnehåndtering. (Chapman & Hall Applied algoritmer og datastrukturserier). CRC Press, Boca Raton, Fla. 2011, ISBN 978-1-4200-8279-1 .

weblenker

Individuelle bevis

  1. ↑ Satish Chandra Gupta, Rajeev Palanki: Java-minne lekker - Ta meg hvis du kan. IBM DeveloperWorks, 16. august 2005, arkivert fra originalen 22. juli 2012 ; åpnet 2. april 2015 .
  2. ↑ Hvordan fikse minnelekkasjer i Java ( Memento fra 5. februar 2014 i Internet Archive ) av Veljko Krunic (10. mars 2009)
  3. ↑ Opprette en minnelekkasje med Java på stackoverflow.com (engelsk)
  4. ↑ Microbenchmarking C ++, C # og Java: Objektoppretting / ødeleggelse og metodeanrop. Dr. Dobb's Journal , 1. juli 2005, åpnet 11. april 2014 .
  5. ↑ Arne Schäpers, Rudolf Huttary: Daniel Düsentrieb - C #, Java, C ++ og Delphi i effektivitetstesten, del 2. c't , desember 2003, s. 222-227 , åpnet 26. oktober 2009 : "" Resultatene viser for det første at en søppeloppsamler (under ødeleggelse) ikke ser ut til å medføre merkbare ulemper når det gjelder kjøretidsoppførsel "og" Noen ganger nesten dobbelt tid som kreves av C ++ for bygging sammenlignet med de andre kandidatene ... ""
  6. ^ Robert Hundt: Loop Recognition i C ++ / Java / Go / Scala. (PDF; 318 kB) Scala Days 2011, 27. april 2011, åpnet 17. november 2012 (engelsk, Stanford, California): “ Java viser en stor GC-komponent, men en god kodeytelse. [...] Vi finner at når det gjelder ytelse, vinner C ++ med stor margin. [...] Java-versjonen var sannsynligvis den enkleste å implementere, men den vanskeligste å analysere for ytelse. Spesielt var effektene rundt søppeloppsamlingen kompliserte og veldig vanskelig å stille "
  7. ^ Matthew Hertz, Emery D. Berger: Kvantifisere ytelsen til søppelinnsamling vs. eksplisitt minnehåndtering. OOPSLA 2005, 2005, åpnet 15. mars 2015 (engelsk): " Spesielt når søppeloppsamling har fem ganger så mye minne som kreves, samsvarer ytelsen for kjøretiden eller overstiger den eksplisitte minnestyringen. Søppeloppsamlingens ytelse forringes imidlertid betydelig når den må bruke mindre dynger. Med tre ganger så mye minne går det i gjennomsnitt 17% tregere, og med dobbelt så mye minne går det 70% tregere. "
  8. ↑ Benjamin Zorn: De målte kostnadene ved konservativ søppelinnsamling. Institutt for informatikk, University of Colorado Boulder , 22. januar 1993, åpnet 18. november 2012 : “ Konservativ søppeloppsamling kommer ikke uten kostnad. I de målte programmene brukte søppeloppsamlingsalgoritmen 30–150 prosent mer adresseplass enn den mest plasseffektive eksplisitte administrasjonsalgoritmen. I tillegg reduserte den konservative søppelsamlingsalgoritmen betydelig referanselokaliteten til programmene, noe som økte sidefeilhastigheten og hurtigbufferfrekvensen for applikasjonene for et stort utvalg av cache- og minnestørrelser. Dette resultatet antyder at ikke bare den konservative søppeloppsamlingsalgoritmen øker størrelsen på adresseområdet, men også ofte refererer til hele plassen det krever. "
  9. ↑ Rotssøking med konstant tid for deterministisk søppelinnsamling (PDF; 375 kB): Søppelinnsamling [...] bringer vanligvis en høy grad av ubestemmelighet til utførelsesmiljøet.
  10. ^ Søppelinnsamling for parallelle og distribuerte systemer , Frank Joachim Frey, 7. mai 2002
  11. ↑ Josuah Bloch: Effektiv Java, s. 31: Unngå sluttbehandlere
  12. ↑ Objective-C 2.0 Oversikt ( Memento fra 24. juli 2010 i Internet Archive )
  13. ↑ Mac OS X 10.7 Lion: the Ars Technica anmeldelse John Siracusa (20. juli 2011)
  14. ↑ Rob Napier, Mugunth Kumar: iOS 6 Programmering skyve grensen. John Wiley & Sons, 20. november 2012, åpnet 30. mars 2015 (engelsk): " " ARC er ikke søppeloppsamling [...] dette får koden til å oppføre seg slik programmereren hadde ment det, men uten en ekstra søppeloppsamling trinn. Minne blir gjenvunnet raskere enn med søppelinnsamling, og avgjørelse blir gjort på kompileringstidspunkt i stedet for på kjøretid, noe som generelt forbedrer total ytelse. " "
  15. ↑ Minnehåndtering
  16. ^ ARC vs. GC
  17. ^ Clang-teamet: AutomaticReferenceCounting. I: Clang 3.7. Dokumentasjon. Hentet 31. mai 2015 : “Det gir ikke en syklusfanger; Brukere må eksplisitt administrere levetiden til objektene sine, bryte sykluser manuelt eller med svake eller usikre referanser. "
  18. ↑ Utviklerverktøy Kickoff - økt 300. I: WWDC 2011. Apple, Inc. , 24. juni 2011, åpnet 27. mars 2015 (engelsk): "" Øverst på ønskelisten din med ting vi kan gjøre for deg, kommer med søppeloppsamling til iOS. Og det er akkurat det vi ikke skal gjøre ... Dessverre har søppeloppsamling en suboptimal innvirkning på ytelsen. Søppel kan bygge seg opp i applikasjonene dine og øke høyt vannmerke for minnebruk. Og samleren har en tendens til å sparke inn på ubestemte tider, noe som kan føre til svært høy CPU-bruk og stammere i brukeropplevelsen. Og det er derfor GC ikke har vært akseptabelt for oss på våre mobile plattformer. Til sammenligning er manuell minnestyring med beholder / frigjøring vanskeligere å lære, og helt ærlig er det litt vondt i rumpa. Men det gir bedre og mer forutsigbar ytelse, og det er derfor vi har valgt det som grunnlag for vår minnehåndteringsstrategi. Fordi der ute i den virkelige verden, er høy ytelse og stammerfrie brukeropplevelser det som betyr noe for brukerne våre. ”“
  19. ↑ José RC Cruz: Automatisk referansetelling på iOS. (Ikke lenger tilgjengelig online.) Dr. Dobbs, 22. mai 2012; arkivert fra originalen 16. august 2012 ; åpnet 30. mars 2015 (engelsk): "" Endelig får [Garbage collection] -tjenesten fremdeles en ytelseshit til tross for at den er konservativ. Dette er en av årsakene til at søppeloppsamling ikke finnes på iOS. [...] ARC er en innovativ tilnærming som har mange av fordelene med søppeloppsamling, men uten ytelseskostnadene. Internt er ARC ikke en kjøretidstjeneste. Det er faktisk en deterministisk todelt fase levert av den nye clang front-enden. "" Info: Arkivkoblingen ble automatisk satt inn og ennå ikke sjekket. Vennligst sjekk originalen og arkivlenken i henhold til instruksjonene, og fjern deretter denne meldingen. @1@ 2Mal: Webachiv / IABot / www.drdobbs.com
  20. ↑ Felix Disselhoff: Bare 1 GB RAM?! Hvorfor iPhone 6 etterlater androider. curved.de, 17. november 2014, tilgjengelig 22. september 2018 : “Hvorfor er iPhone med bare 1 GB RAM raskere enn Android-konkurransen med 2 eller 3 GB RAM? Forklaringen er enkel og har med "søppel" å gjøre. [...] Android trenger et mangfold av minnet som brukes "
  21. ↑ Oliver Haslam: Hvorfor fungerer iPhone med 1 GB RAM bedre enn Android-enheter med 2 GB eller mer RAM? redmondpie.com, 16. november 2014, åpnet 25. mars 2015 .
  22. ↑ Precious Silva: iOS 8 vs Android 5.0 Lollipop: Apple dreper Google med minneeffektivitet. (Ikke lenger tilgjengelig online.) International Business Times , 18. november 2014, arkivert fra originalen 3. april 2015 ; åpnet 7. april 2015 . Info: Arkivkoblingen ble satt inn automatisk og har ennå ikke blitt sjekket. Vennligst sjekk originalen og arkivlenken i henhold til instruksjonene, og fjern deretter denne meldingen. @1@ 2Mal: Webachiv / IABot / au.ibtimes.com