It is possible to demonstrate (as you have), that if you request a single large chunk of ram from the C-runtime allocator (malloc() etc), that it will make a separate virtual memory allocation (VirtualAlloc() or platform equivalent) specifically for that request, rather than use or extend the existing heapspace.

And when the CRT free() is called on that allocation, it will in turn call the OS VirtualFree() (or equivalent), which will return the virtual memory pages backing the allocation, back to the OS.

As you see some RAM is given back to the OS (~50%, (99364/197020))

If you consider those numbers carefully, you have 197020*1024 = 201748480 bytes of virtual memory before the undef and 99364*1024 = 101748736 afterward. Meaning that you freed 99,999,744 bytes of space. Which corresponds (give or take the rounding up to 1024 byte pages), the 100,000,000 byte single, extraordinary allocation you made.

Whilst you can make use of this knowledge to cause single huge chunks of ram, (the break point seems to be ~1/2MB or greater using MS CRT (via AS Perl) on my system), it isn't as useful as you might think.

The majority of large volumes of data manipulated in Perl are allocated in arrays or hashes. And whilst these both have a single, largish, contiguous compenent at their core, (the array of pointers), the vast majority of the space they occupy when populated, is allocated in lots of smallish allocations (the SVs Hes and HEKs). These will always be allocated from separate virtual allocations (heaps) and intermingled with other SVs etc. And those virtual allocations will never be released back to the OS until every allocation within them has been freed. Which is unlikely to ever happen.

So, if you're manipulating large chunks of contiguous data, basically big scalars, within your program, and you can cause these to be allocated in one go (as with your 'X' x 1e8; there are other ways also), then you can cause them to be freed back to the OS (rather than just the process memory pool) when you are done with them.

But, the conditions under which that free back to the OS happens are unwritten, vague, and probably vary widely with platform, compiler, CRT version, and maybe even compiler and linker options. It's not something that you can easily codify enough to rely upon.