langsamer als regelmäßig den kompletten speicher durchzuscannen nach zufällig in einen bereich fallende zahlen? ich weiß ja nicht, welche prozessorarchitekturen dein universum hat, aber...

Wenn's schneller wäre, dann würde es ja wohl gemacht werden. Es gibt aber keine einzige große JVM, die es tut. Genausowenig macht es .NET.

es wird deswegen nicht gemacht, weil es wahnsinnig fehleranfällig ist und außerdem noch so probleme wie zirkuläre referenzen beinhaltet. für gc braucht der programmierer nichts selber machen, deswegen isses so beliebt bei java und .net, die beide einfachheit als oberstes ziel haben (allerdings nicht so verquert wie bei php zum glück)

Die zirkulären Referenzen hat man aber bei GC genauso. Wieso fehleranfällig? Ist ja ein sehr einfaches Prinzip.

Zitat von Ringding

Die zirkulären Referenzen hat man aber bei GC genauso. Wieso fehleranfällig? Ist ja ein sehr einfaches Prinzip.

bei gc hat man wenigstens die chance, es runtimeseitig aufzulösen (solange man nicht den speicher nach zufallszahlen scannt).
fehleranfällig isses dann, wenn der programmierer selber den counter beachten muss. viele viele noobs vergessen immer auf das inkrement (jammern dann, warum die referenz auf irgendwas komplett anderes zeigt), oder aufs dekrement (memory leak, das bemerken sie erst gar nicht)