[himitsu]

So, da haben wir mal meinen Speicher Manager FastX.

Dieser basiert ja zu "größeren" Teilen auf dem FastMM.

Es wäre nett, wenn ihr den kleinen mal Testen könnt.



Der kleine ist(sollte) Multithreadfähig sein und arbeitet auch programmweit, also über DLL's hinweg. (ähnlich wie es die BorlndMM.dll auch macht).


Eingebunden wird der MM genauso, wie jeder "normale" MM auch, indem man die Unit als aller Erste in der Uses-Klausel der DPR einträgt. (siehe Demo)


[Anhang vorrübergehend entfernt 2.7.06]

Und was soll er besser/anders machen als FastMM?

Ich habe nicht gesagt, das der unbedingt besser ist. (weshalb auch noch das FastMM im Namen mit drin ist)

Die Hauptfunktionen sind zu denen von FastMM fast gleich.
Ich hab "nur" meinen alten MM durch diesen ersetzt, weil Fast MM im Grunde genommen nicht schlecht ist.

Allerdings ist diese Version dahingehend einfacher, weil man hier nichts mehr einstellen muß.
Der Kleine ist von haus aus Multithreadfähig, abeitet im kompletten Prozess und über Modulgrenzen hinweg.

Die größten Veränderungen sind aber:
* eine etwas andere Art der Registrierung, und Nutzung der selben Resourcen in verschiedenen Modulen
* die Fehler, welche bei der Vewendung von Packages entstehen könnten, sind bei mir anders gelöst, als bei FastMM
* die reservierten Speicherblöcke des MM's werden bei mir angezeigt ... im FastMM ist die Anzeige nur vorgesehen, aber nicht vorhanden
* dass die Speicherblöcke etwas anders unterteilt sind und 'ne andere (Speicher)Kopierfunktion vorhanden ist, ist ja nicht all zu wichtig
und dann sind da noch ein paar andere winzige Veränderungen mit drin, welche aber nicht so auffallen .

(die komplette Version im UCC auch noch ein paar spezielle Anpassung an's UCC mit drin, allerdings ist dieses erstmal noch nicht so von Bedeutung.)


Ich würde halt gern wissen, ob es irgendwo Probleme mit diesem MM gibt.
Und normaler Weise sollte es keine "Single-Version" davon geben, aber zum Testen hab ich diese Unit mal extrahiert.

Und wie mir dann im nachhinein aufgefallen ist, kann man diese Version dann auch verwenden, um ein(e) Programm/DLL mit UCC und aktiviertem MM mit 'nem anderen Modul (Programm/DLL) ohne UCC zu verbinden.




[add]
Ach ja, ich hab an den Units noch 'ne Kleinigkeit geändert,
unter anderem kann man jetzt auch im Usage Tracker mit den Cursotasten, den Tasten des Nummernblocks, oder den WASD-Tasten navigieren (die 5 springt zur Mitte der Trackers)


[add2]
Hab doch noch 2 "Fehlerchen" entdeckt.

Manchmal ist Delphi's Compiler gemein und seine "eigenwillige" Behandlung von [ ] ist nicht immer das Wahre, vorallem wenn dadurch offentsichliche Fehler von ihm nichtmal erkannt und angezeigt werden.

Ich wollte doch nur InstanceCount ändern und der machte, bei folgendem Code, was anderes -.-''

markieren

Code:

ASM
  MOV    &B, 0
[color=red] LOCK   DEC [&MemoryManagerData].TMemoryManagerData.InstanceCount[/color]
  JNZ    @noFree
  INC    &B
  @noFree:
End;

So ist's besser ^^
(!!! in der Prozedur UninstallMemoryManager entsprechend ändern)

markieren

Code:

ASM
  MOV    &B, 0
[color=red] MOV    EAX, &MemoryManagerData
  LOCK   DEC [EAX].TMemoryManagerData.InstanceCount[/color]
  JNZ    @noFree
  INC    &B
  @noFree:
End;

Ach ja, und dann hatte ich doch tatsächlich zuviel genfernt.
Also, in die Prozedur InstallMemoryManager muß der markierte Teil rein -.-''

markieren

Code:

If MMWindow = 0 Then Begin
  MMWindow := CreateWindowExA(0, 'STATIC', @PIDS, $80000000{WS_POPUP}, 0, 0, 0, 0, 0, 0, PID, nil);
  Initialize;
  MemoryManagerData := @MasterMemoryManagerData;
  SetWindowLongA(MMWindow, -21{GWL_USERDATA}, LongInt(MemoryManagerData));
End Else [color=red]Begin[/color]
  MemoryManagerData := PMemoryManagerData(GetWindowLongA(MMWindow, -21{GWL_USERDATA}));
[color=red] ASM
    MOV    EAX, &MemoryManagerData
    LOCK   INC [EAX].TMemoryManagerData.InstanceCount
  End;
End;[/color]

die neue Version ist natürlich oben drin
Und dass ich jetzt endlich mal die neueren Usage Tracker Funktionen einbauen konnte, erwähne ich ihr auch nur mal ganz kurz. ^^

Gibt es auch eine compiled DLL da ich die Source nicht compilen kann:

Function GetAllocMemSize: LongInt;
Begin Result := GetFastXMemoryState.TotalCommitted; End; //Fehler in dieser Zeile

[Error] BorlndMM.dpr(23): Not enough actual parameters

Anscheindend schon >> click

Das liegt wohl mehr am neuen Delphi ... hatte vorletzte Woche begonnen meine Dateien auch mal D2006-tauglich zu machen ... da gibt's ja einige "neue" Funktionen/Veränderungen im Delphi, die der MM da unterstützen muß.

Außerdem wurde inzwischen vieles umgestellt und mein MM ist jetzt auch schon fast ein "vollwertige" SharedMM also es wird (fast) alles geshared (ist beim FastMM vom Piere allerdings noch nicht so, der hat ja bei dynamisch geladenen DLL's ein echt nettes Problem)

Im Moment kämpfe ich allerdings noch ein bissl mit meiner Defragmentierungsroutine (für'n RAM) und mit'm Exceptionssystem, aber ich hoffe zumindenstend den MM am Wochenende fertigzubekommen.


Falls ich es schaffe, kann ich ja morgen (oder am WE) mal mein Test-Project hochladen ... hab ja aktuell nur D4/D7 zum testen und weiß noch garnicht ob auch der neue Teil in D2005/D2006 überhaupt läuft.

Was die Verbindung zum FastMM angeht ... ich glaub seit FastMM 4.26 sind zwischen den beiden MM's einige Abgrundtiefe Veränderungen eingetreten, so daß sie nur noch in einigen Strukturen miteinander Verwand sind (tja, wir entwickeln uns halt weiter)

Falls Du Bock hast, könntest Du ja Deinen MM auch auf Delphi 2005 PE testen. Da geht imo nur die Debug-Variante von FastMM.
Ich hab mal eine alte Compile von Dir getestet. Gab aber die gleichen Fehlermeldung wie bei der Performance-Variante von FastMM.
Es ist schön zu hören, dass Du Deinen MM weiterentwickeln willst.

Die Personal Edition von D9 wird ja von Borland eh stiefmütterlich behandelt. Sie hätten wie bei D7PE ein update erstellen können und somit paar Fehler zu beseitigen. Auch wenn man sich nur die Personal Edition () leisten kann, sollte diese auch ordnungsgemäß funtzen. Wirft ja ein schlechtes Licht auf Borland ...

Es hilft nichts, in D2006 wurde z.B. TMemoryManager in Delphi durch TMemoryManagerEx ersetzt (es gibt halt neue Schnitttellen.

Was ich aber "schlecht finde, ist, daß alle MemoryManager vor D2006 nicht mehr mit der Schnittstelle ab D2006 kompatiebel sind, so kann man z.B. keine alte BorlndMM.dll mehr verwenden, außerderm wird es wohl auch Probleme zwischen den Modulen geben ... ich würde daher eher abraten DLL's und EXE'en zusammenarbeiten zu lassen, welche jeweils mit DelphiVersionen vor und ab/nach D2006 kompaliert wurden.
Ausßerdem werden jetzt alle Programme, welche noch per INDEX auf die DLL-Funktionen zugreifen abstürzen, sobald sie eine neue BorlndMM.dll finden, da Piere die INDEXe weggelassen hat (ich hab sie z.B. noch drin und an die neuen Bedürfnisse angepasst)

Und was man noch aufpassen sollte (bei Piere's FastMM) man sollte keine Programme und DLLs zusammen arbeiten lassen, welche mit unterschiedlichen Optionen kompiliert wurden, da diese auch oftmals nicht untereinander kompatiebel sind ... das ist/wird bei meinem FastXMM (mir is immernoch kein besserer Name eingefallen) nicht der Fall, da ich zumindestens DummyFunktionen/-Variablen hab, die zumindestens eine Zusammenarbeit gewärleisten, selbst wenn etwas nicht unterstützt werden sollte (bei Piere ist sowas nur in der BorlndMM.dll vorhanden und das, obwohl man Programmintern auch ohne diese auskommen könnte ... er schreibt einem also vor, daß man unbedingt die BorlndMM.ddl installiert haben und verwenden muß, auch wenn's unnötig ist)
Ich stelle die BorlndMM.dll ja auch nur zur Abwärtskompatibilität bereit, falls man halt mal irgendwas einbindet, welches diese benötigt.

Wegen dem Namen, wie währs mit:

RunMM, BetterMM, FasterMM, ExtremeMM, XtremeMM, StableMM, HimitsuMM, GoMM, WorkingMM, ReplacementMM

... wobei XtremeMM ja mein Favorite währe.

Das es incompatibiläten mit FastMM gibt, wusste ich nicht. Ich nimm zu Zeit die Debug-Variante für die IDE von D9PE her.
Das BDS4.0 nun einen anderen MM hat (nähmlich FastMM) ist mir bekannt. Von Stabilitätsproblemen von meinen Programmen
hab ich bis jetzt noch nichts gehört.

Ich würd gern deinen MM mit der D9PE IDE probieren, da die normale Version von FastMM wie gesagt nicht startet. D9PE hat
nur Update1. Erst ab Update3 ist es anscheinend möglich Replacement MM zu nutzen. Warum die Debugversion funktioniert
hab ich bis jetzt aus Pierre noch nicht rausbekommen. Vielleicht klappt ja Deine neue Version besser ...

Phil

OK, hab mir die neue Version mal angesehn ... ein Problem hat Piere jetzt "umgangen".

Früher ging es nicht, da das Modul, welches den FastMM initialisiert, diesen auch wieder freigibt.
Dann würde also in der Demo FastMM schon freigegeben, bevor der letzte SharedMM beendet wurde.

Tja .. ratet mal, wie er das jetzt umgangen hat?
Genau, er shared den MM nicht mehr ... also jede DLL hat trotz eines SharedMMs ihren eigenen MM .. was spaßig wird, sobald man zwischen diesen DLLs Speicher rumschieben will °_°

zusammenfalten · markieren

Delphi-Quellcode:

// TestDLL.dpr > TestDLL1.dll, TestDLL2.dll

Library TestDLL;

// FastMM Options: (muß man aber nicht aktivieren, da es eh ignoriert wird)
// {$DEFINE ShareMM}
// {$DEFINE AttemptToUseSharedMM}

Uses FastMM4;

Function TestAlloc: Pointer;
  Begin
    GetMem(Result, 1024);
  End;

Procedure TestFree(P: Pointer);
  Begin
    FreeMem(P);
  End;

Exports TestAlloc, TestFree;

End.

Hier mal 'ne Demo für den "einfachsten" Fall:
Dieser Code führete mal zu 'nem "netten" Fehler, aber wie gesagt, da jetzt FastMM sich nicht als SharedMM installiert, obwohl man es ihm doch gesagt hat, passiert hier jetzt kein Fehler mehr, es sei denn man versucht Speicher in dem Glauben an einen gemeinsamen MM in der einen DLL zu reservieren und in der anderen freizugeben (siehe nächster Code).

zusammenfalten · markieren

Delphi-Quellcode:

// TestProc.dpr > TestProc.exe

Program TestProc;

Uses Windows;

Var TestDLL1, TestDLL2: THandle;
  TestAlloc1, TestAlloc2: Function: Pointer;
  TestFree1, TestFree2: Procedure(P: Pointer);
  P1, P2: Pointer;

Begin
  TestDLL1 := LoadLibrary('TestDLL1.dll'); // erste Instance initialisiert den FastMM
  @TestAlloc1 := GetProcAddress(TestDLL1, 'TestAlloc');
  @TestFree1 := GetProcAddress(TestDLL1, 'TestFree');

  TestDLL2 := LoadLibrary('TestDLL2.dll'); // weitere Instancen sharen mit dem FastMM der ersten Instance
  @TestAlloc2 := GetProcAddress(TestDLL2, 'TestAlloc');
  @TestFree2 := GetProcAddress(TestDLL2, 'TestFree');

  P1 := TestAlloc1;
  P2 := TestAlloc2;

  TestFree1(P1);
  FreeLibrary(TestDLL1); // ist Owner des initialisierten FastMM und gibt diesen daher auch frei
                          // und meckert auch gleich, weil noch Speicher (P2) reserviert ist (wenn LeakCheck aktiviert)

  TestFree2(P2); // der DelphiMM meckert, weil er P2 nicht kennt
  FreeLibrary(TestDLL2);
End.

Eigntlich sollte man mit TestFree aus der anderen TestDLL*.dll Speicher freigeben können ... schließlich hat man FastMM ja gesagt, daß er nur einen SharedMM initialisieren soll und somit in beiden DLLs die selben FreeMem's aufgerufen würden.

markieren

Delphi-Quellcode:

// TestProc.dpr > TestProc.exe
  ...
  P2 := TestAlloc2;

  TestFree1(P1);
  TestFree1(P2); // hier der Fehler

  FreeLibrary(TestDLL1);
  FreeLibrary(TestDLL2);
End.

oder so:

zusammenfalten · markieren

Delphi-Quellcode:

// TestProc.dpr > TestProc.exe
  ...
  P2 := TestAlloc2;

  FreeLibrary(TestDLL1); // gibt seinen FastMM frei
                          // und meckert auch gleich, weil noch Speicher (P1) reserviert ist (wenn LeakCheck aktiviert)

  TestFree2(P1); // FastMM meckert, weil er P1 nicht kennt und dieser eh schon freigegeben wurde
  TestFree2(P2);

  FreeLibrary(TestDLL2); // gibt seinen FastMM frei
End.

FasterMM: stimmt nicht, vorallem da ich im Moment nur die Pascalversionen hab (kein optimiertes ASM)
StableMM, ReplacementMM: da gibts och schon was, welches so, oder so ähnlich heißt
BetterMM, ExtremeMM, XtremeMM: ich weiß nicht ... so richtig gefällt mir dat och nicht -.-''
und Better klingt so nach ... °_°
HimitsuMM, GoMM, WorkingMM: hmmmm?

Tja, waren halt nur Vorschläge. Ich finds halt doof, das ich immer eine Fehlermeldung bekomme, wenn ich D9PE beende und ich das Project an dem ich gearbeitet hatte nicht geschlossen habe. Wenn ich das tue, kein Problem. Ich denk das hat was mit der History zu tun. Egal wird nun zu offtopic ...

Dir wird schon ein Name einfallen. Falls Du eine lauffähige DLL hast, die man ggf. als MM Replacement für die IDE hernehmen kann, werd ich sie gerne für Dich testen.