Ist es möglich, kleinere speicherabgebildete Ansichten für eine 2 GB+ große Datei zu erstellen?

Question

Ich habe eine C++-Klasse für Windows und Linux geschrieben, die eine speicherabbildende Ansicht für eine Datei beliebiger Größe n erstellt. Der Code für den Klassenkonstruktor kann hier eingesehen werden . Ich teste den Code derzeit unter Windows 32 Bit XP.

Ich habe festgestellt, dass der Konstruktor für die Dateigrößen 0 < n <= 1,7 GB einen gültigen Zeiger auf eine speicherabgebildete Ansicht zurückgibt. Bei einer Dateigröße >= 2 GB gibt MapViewOfFile jedoch einen NULL-Wert und den Fehlercode 8 zurück: "Für die Verarbeitung dieses Befehls ist nicht genügend Speicherplatz verfügbar". Offensichtlich kann Windows keinen verfügbaren Adressraum der Größe 2 GB im Prozess finden.

Daher muss ich möglicherweise den Klassenkonstruktor ändern, um eine Reihe kleinerer speicherabgebildeter Ansichten zu erstellen, die insgesamt >= 2 GB Bytes && < 2 ^ 32 - 1 Bytes umfassen. Die andere Anforderung besteht darin, eine Zuordnung zwischen jeder der kleineren speicherabgebildeten Ansichten und einer Adresse mit zufälligem Zugriff im Adressraum des Prozesses zu erstellen.

Zuvor habe ich den folgenden Code für den wahlfreien Zugriff verwendet:

char* KeyArray;

try {
    mmapFile = new cMemoryMappedFile(n);
}
catch (cException e)
{
    throw;
}

KeyArray = (char *)(mmapFile->GetPointer());
KeyArray[i] = ...

Wie sollte ich die Klasse ändern, um diese Anforderungen zu erfüllen?

Answer 1

Das, was Sie wollen, können Sie mit Repaging erreichen. Sehen Sie sich an, wie das in boost.iostreams gemacht wird aquí .

Answer 2

Nur Sie haben 2 GB (oder 3 GB, mit einigen Optimierungen) Speicherplatz für Benutzerprozesse in einem 32-Bit-Betriebssystem. Punkt. Das ist eine harte Einschränkung, die auch durch die Erstellung vieler kleinerer Mappings nicht umgangen werden kann. Sie müssen Ihre Mappings verschieben, um auf die verschiedenen Teile der Datei zugreifen zu können. Aber es wird immer noch schneller sein als Suchen, Lesen und Schreiben.

Answer 3

Das wird nicht funktionieren. Sie können einfach nicht alle 4 GiB des Adressraums unter 32-Bit-Windows verwenden. Gestalten Sie den Zugriff auf das Array neu, um nur kleine Teile der großen Datei abzubilden.

Answer 4

Ich kann Ihren Pastebin-Link nicht sehen, aber ich kann eine einfache Lösung mit einer C++-Klassendeklaration vorschlagen. Ich denke, die Implementierung sollte aus den Kommentaren ersichtlich sein:

class ShiftingMemMap
{
public:
    // constructs a dynamically shifting memory map of a file...
    ShiftingMemMap ( const char* fileName, size_t view_size = 4096 );

    // retrieve/set a byte at the given file offset. If the offset is not currently in-view,
    // shift the view to encompass the offset. The reference should not be stored for later
    // access because the view may need to shift again...
    byte& operator [] ( unsigned int_64_t offset );

private:
    int_64_t current_offset;
    size_t current_size;
};

Trotzdem könnte man eine Klasse schreiben, die mehrere Ansichten einer Datei zurückgibt, um einen Verweis für später zu speichern und auch verschiedene Teile der Datei gleichzeitig zu bearbeiten, ohne die Ansicht immer wieder hin und her schieben zu müssen.

class MemMap
{
public:
    MemMap ( const char* filename );

    shared_ptr<MemMapView> View ( unsigned int_64_t offset, size_t size = 4096 );
};

class MemMapView
{
public:
    char& operator[] ( size_t offset );
};

Answer 5

Ja, es ist möglich, eine C++-Klasse für Windows, Solaris Unix und Linux zu schreiben, die eine speicherzugeordnete Ansicht für eine Datei beliebiger Größe n erstellt. Wir haben gerade zwei Versionen der Klasse fertiggestellt, eine mit STL und die andere, die mein Chef geschrieben hat und die keine STL verwendet. Beide Versionen sind besser als die Verwendung des Heaps, wenn die Größe der Speicherzuweisung 1 Gigabyte oder mehr unter 32-Bit-Windows, Linux und Solaris Unix beträgt. Beide Versionen sind auch mit 64-Bit-Windows, Linux und Solaris Unix kompatibel. Wenn Sie mehr Details darüber erfahren möchten, senden Sie mir bitte eine E-Mail an frankchang91@gmail.com. Massachusetts, USA. Diese 2 Versionen wurden unabhängig voneinander entwickelt und könnten Teil einer US-Patentanmeldung zur Datenfusion werden.