FastXMM - Speicher Manager

[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]

[Bernhard Geyer]

Und was soll er besser/anders machen als FastMM?

[himitsu]

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 -.-''

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)

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 -.-''

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. ^^

[Amnon82]

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

[himitsu]

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) :mrgreen:

[Amnon82]

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 (:P) leisten kann, sollte diese auch ordnungsgemäß funtzen. Wirft ja ein schlechtes Licht auf Borland ...

[himitsu]

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.

[Amnon82]

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

[himitsu]

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 °_°

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).

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.

Delphi-Quellcode:

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

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

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

oder so:

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?

[Amnon82]

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.

[himitsu]

Ich werd dann auf dich zukommen ... es sollte zwar jetzt soweit lauffähig sein, aber ich überarbeitet auch im Moment noch ein paar Teile ^^

PS: das DLL-Problem von oben ... hab da gerade mal as gefunden, also er hat es genau richtig bemerkt
und daher auch ein paar neue Compilerschalter eingeführt AttemptToUseSharedMM und ShareMMIfLibrary.

Zitat:

{Share the MM with other DLLs? - if this DLL is unloaded, then
dependent DLLs will cause a crash.}

PSS:
wer sich schonmal die FastMM4Options.inc angesehn hat, der wird sich freuen, daß mein MM nur 2 dieser Schalter benötigt und dazu noch zwei Variablen für's Debugging :)

[DGL-luke]

Kann man mit deinem MM dann

- Strings rundrumschieben
- Objekte rundrumschieben

?

EDIT: Intermodular mein ich natürlich...

[himitsu]

Es kann kann im Grunde alles rumgeschoben werden, was einen eigenen Speicherblock besitzt.

Wobei einiges speziell behandelt wird ... so müssen z.B. dynamischen Arrays und AnsiStrings (WideStrings werden ja von der OLE32 verwaltet) extra gehandhabt werden, weil da der Pointer nicht direkt auf den Speicherblock zeigt.

Was genau verschoben werden darf, gibt der Programmierer selber an, wobei in meinem Gesamtprojekt auch schon einige Dinge (unteranderem einige Klassen) sind, welche selber sagen was bei ihnen erlaubt ist.
So ist z.B. in der Exceptionbehandlung das OutOfMemory-Exception-Objekt, welches beim Programmstart initialisiert wird und welches zwar nicht selber verschben werden kann, aber zumindestens der darin enthaltenen String wird von ihm zum verschieben freigegeben.

[Amnon82]

Jo ich freu mich schon auf die erste Release Deiner Überarbeitung. Lass Dir Zeit ...

[Gruber_Hans_12345]

Also ich wollte den auch mal testen.

Aber leider bekomme ich eine Fehlermeldung nach der anderen.
Jetzt werde ich wohl den "normalen" FastMM4 verwenden, der funktioniert bis jetzt ohne Probleme.

Das einzige was mich noch stört sind die Meldungen der Speicherleeks vom Delphi selbst (Hilfssystem usw.)
und das die Auflistung der Leeks usw. nicht so schön wie bei MemCheck ist.

[himitsu]

Wie gesagt, die neue Version ist noch nicht ganz fertig ... eine erste "unfertige" Testversionist an Amnon82 zwar raus, aber selbst wenn die ohne Probleme läuft brauch ich noch ''nen Weilchen.

[Amnon82]

Hab Deine zweite unfertige Version getestet. Der Port von D10 auf D9 und D7 klappt super. Läuft alles rund.
Wann gedenkst Du mit einem Borlndmm.dll-Ersatz? Debug-Mode ist noch buggy. FastMM hat probs mit D9PE. Könnte ja sein, dass Dein MM dieses Problem nicht hat.

[himitsu]

Ich werd' wohl ab ende nächster Woche für ein/zwei Wochen genug Zeit haben, um richtig "viel" proggen zu können ... vielleicht schaff ich es da ja ._.

Wie gesagt, ein paar Probleme gibt es ja noch.

Der DebugMode läuft nicht ... wäre schon Nett, wenn man die LogFunktion zur Fehlersuche nutzen könnte, aber leider ist die (noch) mit dem DebugMode verknüpft.

Und dann halt das Problem mit dem UsageTracker ... ich weiß daß es da einen Fehler gib ... nur sieht es bisher danach aus, als wenn der im MemoryManager (GetMem/ReallocMem) liegt und nicht in den Funktionen für diesen Tracker. :wall:
Obwohl es natürlich auch an ein paar Komponenten auf der Form liegen könnte.
TStringGrid und Co., obwohl die da zwar demnächt eh rausfliegen, aber der Fehler ist ja dennoch vorhanden. -.-''

Kannst den ja mal aktivieren - bei mir stürtzt der jedenfalls beim Aufruf von := TFastXUsageTracker.Create(nil) (FNS_MemoryUT.pas) ab.

Delphi-Quellcode:

// TestU.pas
Procedure TForm1.FormCreate(Sender: TObject);
  Begin
    ...
    FastXUsageTracker_Show;
  End;

[Amnon82]

http://img384.imageshack.us/img384/5711/stack4ij.png

Zu Deiner Frage aus der PM. Ich bin in Bayern geboren. English hatte ich nur getextet, da ich öfter in englishen Foren schreibe und halt grad so drin war. Ich merk es fast nicht mehr ob ich english oder deutsch schreibe. Ist für mich fast gleich. Passiert mir öfter, dass ich mal english denke und deutsch ausspreche und mich somit verhaue (rechnen). So zurück zum Thema.

Wie du im Screenshot siehts kann ichs auch nicht compilen. Eine Fehlermeldung kommt in dem Sinn nicht bei mir. Delphi weigert sich einfach.

[himitsu]

Also ein Problem hab ich jetzt endeckt ... da suche sich Wochenlang nach 'nem Fehler in meinem MM und dann war der ganz wo anders :wall:

Hab mich beim Auslesen der ResourceStrings an den Code aus der System.pas gehalten (nur halt alles nach Unicode umgestellt und jetzt stellte sich raus, daß dieser Code nicht funktioniert und in der System.dcu von Borland wieder alles nach LoadString umgeleitet wurde, weil die es selbst nicht hinbekommen hatten den Code in der System.pas um laufen zu bringen (in D7 wohlgemerkt und ich hab mal in die System.dcu von D2006 geguckt, da haben die das Problem auch noch nicht hinbekommen ... na ja, jetzt hab ich das mal hinbekommen und zumindestens ein Fehler ist weg ^^)

[Amnon82]

... mal sehen wies wird ...

[himitsu]

Ich bin och gespannt ... hänge seit vorgestern an der Datenrettung.
Windoof hat mir 2 Festplatten zerrepariert ... checkdisk meinte es müse was in Ordnung bringen und danach waren sehr viele Dateien mit falschem Inhalt, oder eine Dateikleine von 0 Byte zu entdecken.

Der MM ist ja zum Glück noch vorhanden (auch wenn bisher nicht in der aktuellsten Version, aber 'ne menge andere inge sind derzeit noch futsch :wall:
(jaja, 's is auch meine eigene Schuld, hatte aus Steß/Zeitmangel/Anderem keine Backups davon gemacht -.-'')

[add]
soeben ein wieder einige Wichtige gefunden :firejump:

[Amnon82]

... time flyes by.

[himitsu]

Ja leider ... hab ja jetzt durch checkdisk nur fat 'ne Woche verloren ... aber zumindestens hab ich von fast allen Dateien 'ne nutzbare Version gefunden ... jetzt muß nur noch fertiginstalliert werden und das WLAN laufen ... bis um Dienstag hab ich ja vermutlich noch genug Zeit zum Proggen :angel2:

Und dank Vista hab ich jetzt sogar endlich 'ne 64-Bit Umgebung auf meinem Rechner ... kann also auch mal die 4 GB-Grenze antesten :mrgreen:

[Amnon82]

Ich hab grad Urlaub. Relax mal ;)

[pertzschc]

Zitat:

Zitat von himitsu

Also ein Problem hab ich jetzt endeckt ... da suche sich Wochenlang nach 'nem Fehler in meinem MM und dann war der ganz wo anders :wall:

Hab mich beim Auslesen der ResourceStrings an den Code aus der System.pas gehalten (nur halt alles nach Unicode umgestellt und jetzt stellte sich raus, daß dieser Code nicht funktioniert und in der System.dcu von Borland wieder alles nach LoadString umgeleitet wurde, weil die es selbst nicht hinbekommen hatten den Code in der System.pas um laufen zu bringen (in D7 wohlgemerkt und ich hab mal in die System.dcu von D2006 geguckt, da haben die das Problem auch noch nicht hinbekommen ... na ja, jetzt hab ich das mal hinbekommen und zumindestens ein Fehler ist weg ^^)

Postest Du das genaue Problem und die Lösung mal hier bei Gelegenheit?

Gruß,
Christoph

[himitsu]

So, Codes scheinen alle (zumindestens die Wichtigsten) wieder dazu sein ... muß es nur wieder richtig zum Laufen bringen und bei den Problemchen vor'm Chrash fortsetzt.

@pertzschc: was würde dich denn vorallem interessieren? ... vielleicht kann ich's meine aktivitäten ja in dieser Richtung erstmal mehr bündeln ^^

[DGL-luke]

moin moin... gibts was neues von der mm-front?

[himitsu]

Also ich balstle zwar abundzu etwas dran rum, aber derzeit bin ich mehr mit NonVCL beschäftigt.

Vorallem da ich aus "Sicherheitsgründen" die ganzen Dialoge und andere Dinge von der VCL abtrennen sollte/muß und mich da gleich in dem SubProject komplett von allen Delphi-Units (außer System und SysInit) trenne.

Abgesehen davon, daß ich vieles komplett neugeschrieben hab :stupid:,
speziell in Hinsicht auf BSD2006.

[OldGrumpy]

Wie waers mit HiMMeX als Name? ;)