Extending a very large array in-place on Windows caused a segfault. This was due to a missed call to commit new pages that were added in the extend.

Added a test for the issue.

What's Changed

• AArch64 has different syscall number for futex by @DmitryOlshansky in #36
• Add noreserve mmap by @schveiguy in #38

New Contributors

• @DmitryOlshansky made their first contribution in #36

Full Changelog: v0.0.4...v0.0.5

What's Changed

• Update sdc changes by @schveiguy in #30
• Add enable/disable functionality support via GC.enable and GC.disable… by @schveiguy in #31
• Add root iteration function (probably never used) by @schveiguy in #32
• Add support for allocatedInCurrentThread by @schveiguy in #33
• Add comments to explain why certain functions are not implemented by @schveiguy in #34
• Add support for GC.stats by @schveiguy in #35

Full Changelog: v0.0.3...v0.0.4

In some cases, metadata bits could be stale from previous allocations that are explicitly freed.

This makes sure the metadata bits are clear on free, such that an accidental usage of garbage data as a finalizer does not occur.

In some systems, the linux kernel does not support huge pages. So this madvise call fails.

Instead of asserting the failure, this changes the result to a boolean (which currently is ignored). This allows such systems to run symgc code.

See also snazzy-d/sdc#425

First release of symgc on Linux and Windows!