Viper

Memory Models
-------------


1. Reference Counting (RC)
2. Garbage Collection (GC)


1.1. RC pure:
-	benötigt REFCNT, Objekt wird zerstört, wenn dieser 0 ist:
---	CYCLIC RINGS live for ever
---	PROGRAMMER must take care for this
	-7

1.2. RC mit weak pointern OHNE zus. counter:
-	benötigt REFCNT
--	LANGUAGE SUPPORT for weak pointers required
---	weak pointer may point to VOID OBJECTS in released memory
--	unreachable CYCLIC RINGS still possible
	-8

1.3. RC mit weak pointern MIT zus. counter:
-	benötigt REFCNT
-	benötigt weak refcnt
--	LANGUAGE SUPPORT for weak pointers required
-	weak pointer may point to cleared NULLED OBJECTS
--	unreachable CYCLIC RINGS still possible
	-7

1.4. RC mit GC:
-	benötigt REFCNT für RC
-	benötigt MEMORY ALLOCATION LIST für GC
--	All reachable memory must be KNOWN AND PARSABLE by GC
-	gelegentliche GC-Läufe um unreachable memory zu finden -> BLOCKING
-	bis dahin: TEMPORARILY SOME ALLOCATED UNUSED MEMORY
	-6

2. Garbage collection
-	benötigt MEMORY ALLOCATION LIST für GC
--	All reachable memory must be KNOWN AND PARSABLE by GC
---	HÄUFIGE GC-Läufe um unreachable memory zu finden -> BLOCKING
--	PERMANENTLY LOTS OF UNUSED ALLOCATED MEMORY
	-8


Die Kombination aus Reference Counting mit gelegentlicher Garbage Collection scheint günstig.
Sie hat kein Killerkriterium (permanently lost memory, possible use of free memory, frequent blocking)
und benötigt auch keinen Language-Support oder Aufmerksamkeit des Programmierers.
Sie hat mehr Aufwand als pure RC oder pure GC, nämlich die Kombination aus beidem.
Die GC kann wahrscheinlich voll unter Kontrolle der Anwendung geschehen.