FastMM grotten langsam ?!

[negaH]

Zitat:

Denn wie Hagen schon sagte, es ist unmöglich für den MM festzustellen ob ein Speicherblock noch benötigt wird, selbst wenn der Thread, welcher diesen hat allocieren lassen längst beendet ist, denn es kann ja durchaus sein, daß der Speicherblock an einen anderen Thread übergeben wurde, was der MM ja nicht wissen kann.

Dies trifft das Problem leider nicht exakt.

RecyclerMM alloziert quasi für jeden Thread einen eigenen unabhängigen Speichermanager. Nun stellen wir uns mal vor dieser Thread übergibt tatsächlich einen für ihn allozierten Speicherbereich einem anderen Thread.
Was soll passieren wenn der allozierende Thread nun terminiert wird ? Reagiert RecyclerMM darauf und zerstört den threadeigenen Speichermanager so zerstört er für den anderen Thread diesen übergebenen Speicherblock. Reagiert RecyclerMM aber nicht auf die Termination des Threads so bleiben Speicherleichen übrig.

Dieses Verhalten kann mit einem threadübergreifenden MM, wie dem BorlandMM oder FastMM4 nicht auftreten.

Man kann aber durch eine ausführliche Dokumentation und eventuell vorhanden spezielle Kopierfunktionen dieses Problem umgehen.

Wichtiger ist einfach die Frage ob es einen allgemeingültigen und immer funktionierenden Weg gibt das RecyclerMM auf die Terminierung eines beliebigen Threads reagieren kann. Und diese Frage muß man auf API Ebene ganz klar mit "nicht möglich" beantworten. Der einzisgte Ausweg wäre ein virtueller Treiber der sich in das Kernel einklinkt und auf die Termierung eines beliebigen Threads reagiert.

Gruß Hagen