Too many Xbyak::Allocator::alloc call produces mprotect failure

[Constellation]

Hi, thank you for your great library.

I found that sometimes mprotect fails it's modification to the page attribues.
For example, in this test, we observe it several times. https://travis-ci.org/Constellation/iv/jobs/37578037.
In this test, the test script requires xbyak's code generation huge times. (16 ** 4 = 65536 times)

After investigating this problem, I've found that mprotect with valid parameters (address and size are valid) fails with ENOMEM, and it seems that this is because the map count becomes zero (Maybe I think).
ref:

• http://stackoverflow.com/questions/4189190/i-dont-understand-the-output-of-electric-fence-and-gdb
  • when map count becomes zero, mprotect can return ENOMEM
• http://stackoverflow.com/questions/11683850/how-much-memory-could-vm-use-in-linux
  • mmap and mprotect consume map count.

Since xbyak's dynamic memory allocator calls mprotect, but doesn't call munmap, map count doesn't released.
To prevent it, I suggest the following plan.

• Allocate memory with mmap instead of posix_memalign
• Manage the allocated size with the address
• Free the allocated memory with munmap

What do you think about it?

[herumi]

そんな制限があったのですね。mprotectがmmapした領域をmunmapできたらいいのですがちょっと調べてみます。posix_memalignの代わりにmmapは互換性を確保できるか気になりますね。

[herumi]

posix_memalignした領域をmprotectした場合は同時に33000個ぐらいのインスタンスを生成するとエラーになるけどmmapした領域に対しては同時にもっと作れるのですね。
mummapがsizeを必要とするのでXbyakMMapAllocatorのようにちょっと余計なmempryを持たないといけないのか。うーむ。
posix_memalignからmmapを使うように変更した場合のデメリットは何かあるでしょうか。システムコールの呼び出し回数が増える?
普通は数万個もインスタンスを作ることはないことを考えるとConstellationさんが作ってくださったようなXbyakMMapAllocatorを提供するのが一番楽ですかね。

[herumi]

I created MmapAllocator branch.
https://github.com/herumi/xbyak/tree/mmap_allocator
You can use MmapAllocator if XBYAK_USE_MMAP_ALLOCATOR is defined.
Could you try it?

[Constellation]

Thank you! Looks good to me.
Nits.
0fc4b9b#commitcomment-8144440

[herumi]

Thank you for your very kind message.

[Constellation]

Thank you for your quick response!!