spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Dann hätte man ja ein maximales Alignment angeben können, z.B. 256 Bytes, oder eben ab solch einem Alignment auf einen anderen Algorithmus zurückfallen können. Bei Intel wird in der BPU immer zuerst erwartet, dass ein test im if als false ausfällt, würde also nicht gerade nennenswerte Einbuße in der Leistung bringen.

Nun, eine Arena ist in 65536 Zellen zerlegt, die z.B. im Falle LuaJITs 16 Bytes groß sein könnten. Das macht insgesamt 20 Bits an Adresse für die Zellen. Jetzt kann ein GC sehr schnell die Arena finden, die fürs Deallokieren zuständig wäre, indem einfach die entsprechenden Adress-Bits eines Objekts wegmaskiert werden. Ebenso fix gelangt man an den Zell-Index. Oder in Code:

Mit Addition/Subtraktion meinst du wohl das Offset, wie weit die Arena aus der Reihe des Alignments tanzt? An sich wäre das kein Drama, bloß stellt sich die Frage, wie ich an dieses Offset gelange. Es könnte jedes Vielfache der Page-Größe des Betriebssystems sein, völlig willkürlich. Dann müsste ich diese Offset-Information in jedem Objekt unterbringen, was diese nur unnötig aufbläht. Man könnte auch andersrum eine Tabelle anlegen, die "aligned" Arena-Adressen auf ihre tatsächlichen mapped. Dann allerdings wäre der (Cache-)Vorteil der fixen Maskierung völlig hinüber.

Nö, das weiß ich ja nicht wirklich. Der GC bekommt von den zig Arenen nicht viel mit. Er schaut auf das Root-Objekt, rattert durch dieses durch, und findet die zuständigen Arenen über die Objekt-Adressen. Er führt keine zusätzliche Tabelle darüber, welche Arena welches Offset hat. Aber selbst wenn er das täte... Für jedes Objekt nach dem richtigen Offset zu schauen könnte ganz schön ziehen. D;

Edit:

Zitat

If the dwFreeType parameter is MEM_RELEASE, this parameter must be the base address returned by the VirtualAlloc function when the region of pages is reserved.

Zitat

If the dwFreeType parameter is MEM_RELEASE, this parameter must be 0 (zero). The function frees the entire region that is reserved in the initial allocation call to VirtualAlloc.

Meh... Mit ::VirtualAlloc werde ich die Speicher-Verschwendung also nicht los.

Danke für die ausführliche Antwort. °^°
Allerdings hat sie leider nicht wirklich weiter geholfen. Deine Allokierungs-Funktion macht genau das, was auch _aligned_malloc tut: Extra-Speicher für Alignment verschwenden, was bei der beachtlichen Größe wie von mir gewünscht nicht mehr ganz so knorke erscheint. Das rentiert sich erst, wenn man mehrere Arenas auf einmal allokiert, so dass der Anteil an ungenutztem Speicher fix schrumpft.

Zum Algorithmus im Nachtrag:
Nehmen wir mal ein ganz simples Mini-Beispiel. Eine Arena sei 16 Bytes groß und eine Zelle 1 Byte. Die Pages des Betriebssystems seien 2 Bytes groß. Die durch z.B. ::VirtualAlloc erhaltene Basis-Adresse der Arena A ist 0x12. Das Offset um korrektes Alignment vorzutäuschen wäre also 0x02. Nehmen wir mal an, dass ein Objekt a an der Adresse 0x15 allokiert wurde. Der Algorithmus muss jetzt a:0x15 auf A:0x12 mappen. Das geht fix: A = (a - 0x02) & -16
Nun nehmen wir eine zweite Arena B:0x26 und ein Objekt b:0x31. Jetzt ist das Offset 0x05. Jetzt haben wir eine etwas andere Korrektur-Funktion: B = (b - 0x05) & -16
Das Blöde ist jetzt, dass ich aus keinem der Objekt-Pointer eindeutig die Offset-Informationen herausziehen kann, wo genau ihre Arenas anfangen. Dein kleiner Algorithmus sagt bloß, wie ich von misaligned nach aligned komme, und das ist nur für die Implementierung genau solcher Funktionen interessant, wie oben bemängelt.


Edit:
Da Recherche nach Recherche nichts ergab, grübelte ich immer mehr an Möglichkeiten, dieses Leck zu kompensieren, oder eben gar zu meinen Gunsten zu nutzen. Und mir schwebt tatsächlich eine nicht uninteressante Idee vor, die ein bis zwei riesigen Lecks zu nutzen. Viele Objekte wie Strings und Listen brauchen eben zusätzliche Speicher-Blöcke, falls ihre Daten nicht mehr in die Zellen der Objekt-Arena passen. Dazu habe ich eine zweite Art von Arenen vorgesehen, die lediglich für solche Extra-Daten da sind und entsprechend keine so hohen Effizienz-Kriterien für den GC erfüllen müssen.
Wenn ich an meine Ruby-Zeit zurück denke, so fällt mir ein, dass z.B. die meisten irgendwo in einer Größenordnung liegen, dass sie in der Objekt-Arena inlined werden können, oder nur wenig zu groß für die Zellen sind. Anstatt sofort auf eine Daten-Arena zurück zu greifen, könnte ich also zwei Mini-Daten-Arenen auf die ein bis zwei riesigen Leaks verteilen, die ausschließlich von Objekten der zugehörigen Objekt-Arena genutzt werden. Sind sie überfüllt, wird auf die "richtigen" Daten-Arenen zurückgegriffen. Ich muss mir noch überlegen, wie ich die Meta-Daten gestalte, dass sie am besten in eine halbe Page passen und variabel-große Blöcke verwalten, aber das würde das Problem recht elegant lösen.
Keine Ahnung, warum mir diese Möglichkeit nicht früher in den Sinn kam.