FastMM prend-il en charge la réservation de la mémoire virtuelle et appelle-t-il des morceaux pour développer un tableau?

Question

Je sais que je peux réserver de la mémoire virtuelle en utilisant VirtualAlloc.
Par exemple, je peux réclamer 1 Go de mémoire virtuelle, puis appeler le premier MB de cela pour mettre mon tableau croissant.
Lorsque le tableau va au-delà de 1 Mo, j'appelle le 2e MB et ainsi de suite.
De cette façon, je n'ai pas besoin de déplacer le tableau en mémoire lorsqu'il se développe, il reste en place et le gestionnaire de mémoire virtuel Intel / AMD s'occupe de mes problèmes.

Cependant, FastMM prend-il en charge cette structure, donc je n'ai pas à faire ma propre gestion de la mémoire?

Pseudo Code:

type
  PBigarray = ^TBigarray;
  TBigArray = array[0..0] of SomeRecord;

....

begin
  VirtualMem:= FastMM.ReserveVirtualMemory(1GB);
  PBigArray:= FastMM.ClaimPhysicalMemory(VirtualMem, 1MB);
....

procedure GrowBigArray
begin
  FastMM.ClaimMorePhysicalMemory(PBigArray, 1MB {extra});
  //will generate OOM exception when claim exceeds 1GB

Fastmm soutient-il cela?

Answer 1

Non, Fastmm4 (à partir de la dernière version que j'ai regardée) ne le prend en charge explicitement. Ce n'est vraiment pas une fonctionnalité que vous attendez dans un gestionnaire de mémoire à usage général car il est trivialement simple à faire avec les appels virtualalloc.

Nexusmm4 (qui fait partie de NexusDB) fait quelque chose qui vous donne un résultat similaire, mais sans gaspiller tout l'espace d'adressage avant qu'il soit nécessaire en arrière-plan.

Si vous effectuez une allocation initiale (directement via GetMem, ou indirectement via un tableau dynamique ou tel), la mémoire est allouée dans la taille nécessaire, via VirtualAlloc.

Mais si cette allocation est ensuite redimensionnée à une taille plus grande, Nexusmm utilisera une manière différente pour allouer la mémoire qui lui permet de simplement démolir l'allocation de l'espace d'adressage un remapt à nouveau, à une taille plus grande, lorsque d'autres reallocs ont lieu.

Cela empêche les 2 problèmes majeurs des gestionnaires de mémoire à usage le plus général lors de la réaffectation:

• Pendant un Realloc normal, la nouvelle allocation existante doit être présente dans l'espace d'adressage en même temps, doublant temporairement l'espace d'adressage et les exigences de mémoire physique
• Pendant un Realloc normal, tout le contenu de l'allocation existante doit être copié

Donc, avec Nexusmm, vous obtiendrez tous les avantages de ce que vous avez montré dans votre code pseudo (à l'exception que le premier Realloc impliquera une copie, et que la croissance de votre tableau pourrait changer son adresse) en utilisant simplement .