mono --llvm --compile-all -v -v -v -v(before and after the change) and get a diff (how many and which methods were modified). The CoreCLR folks use such tools for all jit related PRs
-O2set of opt for LLVM JIT
Vector128<T>.Count= 128 / (sizeof(T) * :sunglasses:
Microsoft.CSharp.Core.targetsis not there
/* Try to allocate code chunks next to each other to help the VM */ ptr = NULL; if (last) ptr = codechunk_valloc ((guint8*)last->data + last->size, chunk_size); if (!ptr) ptr = codechunk_valloc (NULL, chunk_size); if (!ptr) return NULL;
The kernel virtual memory manager or the Mono virtual machine?
The kernel virtual memory manager surely will help itself most with NULL there.
I imagine it is the map32bit stuff for amd64, so the Mono virtual machine.
Comments should/could be clearer imho.
As well, only systems that use the map32bit stuff should have this logic, I think.
arm/mips/powerpc, why the 32bit here?
ss_trigger_page = mono_valloc (NULL, mono_pagesize (), MONO_MMAP_READ|MONO_MMAP_32BIT, MONO_MEM_ACCOUNT_OTHER); bp_trigger_page = mono_valloc (NULL, mono_pagesize (), MONO_MMAP_READ|MONO_MMAP_32BIT, MONO_MEM_ACCOUNT_OTHER);
I assume mips implies 32bit.
I know arm does (arm64 is separate).
PowerPC I guess was dual purpose, but is now 64bit only?, so it seems the only user like this (I know amd64 has a different use).
On Windows there could be some hypothetical creation of a truncatable address,
for a 32bit debugger to poke at a 64bit target. Or to push the address
over a transport that truncates to 32bits even if to a 64bit target.
But mono does not target Windows with these architectures (it did/does run on them!).
But still, it is only for powerpc64 seemingly.