I had similar thoughts. This is flying in the dark a bit as I've no real idea if the CRT malloc uses the process heap or another heap or heaps. I tried using the following apis to try and compact the heap after the AoH is undef'd:

use Win32::API::Prototype;

ApiLink( 'Kernel32', q[ HANDLE GetProcessHeap(void) ] ) or die $^E;
ApiLink( 'kernel32', q[ DWORD HeapCompact( HANDLE hHeap, DWORD dwFlags
+ ) ] ) or die $^E;

my @idsMap;
my @AoH;
my $cnt = 1;

$|++;

for my $i ( 1 .. 40 ) {
    my $start = "aaa";
    my %hash; keys %hash = 250_000;
    printf "\r$i\t";
    for my $j ( 1 .. 250000 ) {
        $hash{ "$cnt $i $j $start" } = $cnt;

        $cnt++;
        $start++;
    }
    $AoH[$i] = \%hash;
}

print "Total size: ", total_size( \@AoH );

undef @AoH;

print "did undef of array\n";

<>;

print HeapCompact( GetProcessHeap( 0 ), 0 ) or die $^E;

...
[download]

It does something, and takes quite a while doing it, but the result is that the largest contiguous chunk after compaction (of the process heap) is a little over 1MB which isn't enough to make any difference.

Looking at the process memory map, there appear to be multiple heaps, but I haven't worked out a way of determining which is the process heap.

One possibility is to enumerate all the heaps and run HeapCompact() on them all. Besides being slow, I'm not sure that it would achieve very much?