Be aware of NUMA when your application needs to run fast

if they don't give you access to the numa syscalls then you are kind of up shit creek. you could ask them to run the tests with: '--cap-add SYS_NICE'. that would give you access to the numa syscalls. java needs access to these syscalls in order to manage its numa strategy. have you tried running '-XX:+UseNUMA' with '--cap-add SYS_NICE' or '--privileged'? if the unrestricted '-XX:+UseNUMA' option doesn't fix your issue then you could try writing your own bitset implementation using ByteBuffer.allocateDirect(). this way the memory should be allocated on the native heap using the java 'local' numa policy and the memory won't be moved by the garbage collector to a different node.

the ByteBuffer strategy is potentially an option if they won't give you access to the numa syscalls. if you are able to test what numa node the memory is allocated on then you can just keep allocating memory until it is assigned to the correct node. the problem is working out when the allocation is on the correct node. linux has a syscall for this move_pages() which can also be used to move the memory to where you want it but this is blocked by docker as well. but at a minimum there is a difference in timing that is observable so potentially you could exploit that to try to allocate to an optimal numa node.

here is the list of syscalls you have access to by default on docker: https://github.com/moby/moby/blob/master/profiles/seccomp/de...

unfortunately, all the useful numa ones are not on the whitelist.