<div dir="ltr">Hi Volker, Gustavo,<div class="gmail_extra"><br><div class="gmail_quote">On Wed, Nov 2, 2016 at 11:01 AM, Volker Simonis <span dir="ltr"><<a href="mailto:volker.simonis@gmail.com" target="_blank">volker.simonis@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Gustavo,<br>
<br>
one thing you could still check is why mmap fails with errno=16.<br>
According to /usr/include/asm-generic/<wbr>errno-base.h this is EBUSY but<br>
unfortunately the man page for mmap doesn't document EBUSY as a valid<br>
error code for mmap. As you seem to work for a team involved in Linux<br>
development (at least according to you e-mail adress :) maybe you can<br>
find out what EBUSY means for mmap with MAP_HUGETLB.<br>
<br>
But wait, I've just found this old mail thread [1] with Tiago (one of<br>
your former colleagues):<br>
<br>
That time [2] I found out that:<br>
...<br>
if 'UseHugeTLBFS' is active it first mmaps the complete heap with<br>
'MAP_NORESERVE' and later commits parts of the heap as needed with<br>
'MAP_FIXED' but without 'MAP_NORESERVE'.<br>
<br>
Now here's the difference between x86 and ppc. For x86 it makes no<br>
difference that the mmap with 'MAP_NORESERVE'  does not have the<br>
MAP_HUGETLB flag. It is still possible to commit the memory later on with<br>
MAP_HUGETLB. On the other hand, on ppc mmap refuses to commit memory with<br>
MAP_HUGETLB if it was first mapped without MAP_HUGETLB. I don't know why<br>
this is the case but that's how it works:(<br>
...<br>
<br>
In a later mail, Tiago explained why this is so [3]:<br>
...<br>
'On ppc64, you can only have one page size in a "slice".  Slices are<br>
256M below 4G, then 4G-1TB then 1TB slices above that.  Since the<br>
MAP_NORESERVE is not a hugepage mapping, it is not being placed to<br>
accomodate these restrictions. Overmapping with MAP_FIXED is then<br>
failing.'<br>
...<br>
<br>
Re-reading that old mail thread, I'm pretty sure now that this is the<br>
actual reason why you see the problems with UseHugeTLBFS on<br>
Linux/ppc64.<br>
<br>
As I wrote in that thread, this could be fixed [4], but it is probably<br>
not trivial:<br>
...<br>
I think under these circumstances it will be not so easy to make huge<br>
pages work with the current way how the HotSpot VM allocates memory<br>
(i.e mmapping huge memory areas with MAP_NORESERVE and later<br>
committing them partially and independently of each other with<br>
MAP_FIXED|MAP_HUGETLB).<br>
<br>
This would probably require a bigger rework of the allocation code. I<br>
think I have some basic ideas how this can be done - it requires a<br>
bookkeeping for every region to remember if it should use huge pages<br>
or not. Unfortunaltey it's notoriously hard to bring such shared code<br>
changes into the HotSpot main code line, but perhaps this will become<br>
easier once our port is part of the HotSpot main code line.<br>
...<br>
<br></blockquote><div><br></div><div>Volker, excellent find! :)</div><div><br></div><div>Note that we have a workaround for a similar problem in AIX: the problem that you need to keep meta information associated with a block allocated with os::reserve_memory() for later use with the other memory functions. On AIX, it is the question if the memory range has been allocated via shmget or mmap.</div><div><br></div><div>The code in the AIX port is in os_aix.cpp, see the "vmembk_..." functions. Basically, we keep meta information in a linked list inside the porting layer.</div><div><br></div><div>But this is clunky and ugly. The underlying problem is that the os::reserve_memory() API cannot be easily implemented by porters for cases where you need to keep additional meta information for a chunk of memory. To solve this cleanly, this would have to be solved at API level.</div><div><br></div><div>The typical way to do this in C is to hand back to the caller not a raw pointer but a pointer to an opaque structure which the porter then can use to store information in. Caller then hands this structure back in into any subsequent memory functions. Basically, a Handle.</div><div><br></div><div>For instance:</div><div><br></div><div>struct memory_handle_t { char* pointer; .... (opaque porting specific data like mmap flags used for creation) ... };</div><div><br></div><div>memory_handle_t * os_reserve_memory(size); Â  Â  (allocate memory_handle_t structure and fill in pointer and anything else)<br></div><div>bool os::commit_memory(memory_handle_t* memory);</div><div>bool os::release_memory(memory_handle_t* memory); Â ( free memory_handle_t)<br></div><div><br></div><div>Users of os::reserve_memory would have to use memory_handle_t.pointer member to get the raw data pointer. Because that would affect all users of os::reserve_memory, it would make ripples all over shared code, but I think this would be a pragmatic and clean solution. I think this would be a nice enhancement for 10. If you think it makes sense, I can open an issue in jbs.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
You're welcome to try your luck :)<br>
<br>
Regards,<br>
Volker<br>
<br>
[1] <a href="http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2013-April/thread.html#385" rel="noreferrer" target="_blank">http://mail.openjdk.java.net/<wbr>pipermail/ppc-aix-port-dev/<wbr>2013-April/thread.html#385</a><br>
[2] <a href="http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2013-April/000397.html" rel="noreferrer" target="_blank">http://mail.openjdk.java.net/<wbr>pipermail/ppc-aix-port-dev/<wbr>2013-April/000397.html</a><br>
[3] <a href="http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2013-April/000445.html" rel="noreferrer" target="_blank">http://mail.openjdk.java.net/<wbr>pipermail/ppc-aix-port-dev/<wbr>2013-April/000445.html</a><br>
[4] <a href="http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2013-April/000447.html" rel="noreferrer" target="_blank">http://mail.openjdk.java.net/<wbr>pipermail/ppc-aix-port-dev/<wbr>2013-April/000447.html</a><br>
<br></blockquote><div><br></div><div><br></div><div>Kind Regards, Thomas<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
On Mon, Oct 31, 2016 at 1:28 PM, Gustavo Romero<br>
<div class="gmail-HOEnZb"><div class="gmail-h5"><<a href="mailto:gromero@linux.vnet.ibm.com">gromero@linux.vnet.ibm.com</a>> wrote:<br>
> Hi Volker,<br>
><br>
> On 28-10-2016 05:39, Volker Simonis wrote:<br>
>> Hi Gustavo,<br>
>><br>
>> please find my comments inline:<br>
>><br>
>> On Thu, Oct 27, 2016 at 11:12 PM, Gustavo Romero<br>
>> <<a href="mailto:gromero@linux.vnet.ibm.com">gromero@linux.vnet.ibm.com</a>> wrote:<br>
>>> Hi Volker,<br>
>>><br>
>>> On 25-10-2016 05:13, Volker Simonis wrote:<br>
>>>> Just a quick question: do you also get the same warnings if you are<br>
>>>> running without compressed oops (i.e. -XX:-<wbr>UseCompressedClassPointers<br>
>>>> -XX:-UseCompressedOops)? If not maybe this is related to the fact that<br>
>>>> for compressed oops we try to allocate memory in low memory regions.<br>
>>><br>
>>> $ java -XX:+PrintCommandLineFlags -Xms256m -Xmx256m -XX:+UseLargePages -XX:-<wbr>UseCompressedClassPointers -XX:-UseCompressedOops StrictMath_cos<br>
>>> -XX:InitialHeapSize=268435456 -XX:MaxHeapSize=268435456 -XX:+PrintCommandLineFlags -XX:-<wbr>UseCompressedClassPointers -XX:-UseCompressedOops -XX:+UseLargePages -XX:+UseParallelGC<br>
>>> OpenJDK 64-Bit Server VM warning: Failed to reserve large pages memory req_addr: 0x0000000000000000 bytes: 268435456 (errno = 16).<br>
>>> 0.1709843554185943<br>
>>><br>
>>> It fails when trying to allocate 256 MiB starting at 0x0, so definitely a low<br>
>>> memory region. If CompressedClassPointers and CompressedOops are disabled, what<br>
>>> could be trying to allocate that region?<br>
>>><br>
>><br>
>> Could you please run the VM in gdb to analyze where the allocation<br>
>> fails and why?<br>
>> You can also check that way that you really get large pages with -XX:+UseSHM.<br>
>><br>
>> Unfortunately I can't help you much here because I don't have a<br>
>> machine with your 'huge pages' / 'transparent hug pages' setting. But<br>
>> I know that setting up huge pages on Linux such that mmap() +<br>
>> MAP_HUGETLB works is really tricky.<br>
><br>
> Apparently the allocation at no specific address (i.e. 0x0, thanks Thomas!) is<br>
> related to the GC:<br>
><br>
> (gdb) info b<br>
> Num  Â  Â Type  Â  Â  Â  Â  Â Disp Enb Address  Â  What<br>
> 1  Â  Â  Â breakpoint  Â  Â keep y  Â <PENDING>  warn_on_large_pages_failure<br>
> (gdb) c<br>
> Continuing.<br>
> [New Thread 0x3fffb6d9f1a0 (LWP 3626)]<br>
> -XX:InitialHeapSize=268435456 -XX:MaxHeapSize=268435456 -XX:+PrintCommandLineFlags -XX:-<wbr>UseCompressedClassPointers -XX:-UseCompressedOops -XX:+UseLargePages -XX:+UseParallelGC<br>
> [Switching to Thread 0x3fffb6d9f1a0 (LWP 3626)]<br>
><br>
> Breakpoint 1, os::Linux::reserve_memory_<wbr>special_huge_tlbfs_mixed (bytes=268435456, alignment=<optimized out>, req_addr=0x0, exec=<optimized out>) at ./src/hotspot/src/os/linux/vm/<wbr>os_linux.cpp:3505<br>
> 3505  Â  ./src/hotspot/src/os/linux/vm/<wbr>os_linux.cpp: No such file or directory.<br>
> (gdb) bt<br>
> #0  os::Linux::reserve_memory_<wbr>special_huge_tlbfs_mixed (bytes=268435456, alignment=<optimized out>, req_addr=0x0, exec=<optimized out>) at ./src/hotspot/src/os/linux/vm/<wbr>os_linux.cpp:3505<br>
> #1  0x00003fffb796e350 in os::Linux::reserve_memory_<wbr>special_huge_tlbfs (exec=<optimized out>, req_addr=0x0, alignment=<optimized out>, bytes=268435456) at ./src/hotspot/src/os/linux/vm/<wbr>os_linux.cpp:3541<br>
> #2  os::reserve_memory_special (bytes=268435456, alignment=<optimized out>, req_addr=0x0, exec=<optimized out>) at ./src/hotspot/src/os/linux/vm/<wbr>os_linux.cpp:3553<br>
> #3  0x00003fffb7b7651c in ReservedSpace::initialize (executable=false, noaccess_prefix=0, requested_address=0x0, large=true, alignment=<optimized out>, size=268435456, this=0x3fffb6d9def8)<br>
>  Â  Â at ./src/hotspot/src/share/vm/<wbr>runtime/virtualspace.cpp:157<br>
> #4  ReservedSpace::ReservedSpace (noaccess_prefix=0, requested_address=0x0, large=true, alignment=33554432, size=<optimized out>, this=0x3fffb6d9def8) at<br>
> ./src/hotspot/src/share/vm/<wbr>runtime/virtualspace.cpp:79<br>
> #5  ReservedHeapSpace::<wbr>ReservedHeapSpace (this=0x3fffb6d9def8, size=<optimized out>, alignment=33554432, large=<optimized out>, requested_address=0x0) at<br>
> ./src/hotspot/src/share/vm/<wbr>runtime/virtualspace.cpp:344<br>
> #6  0x00003fffb7b2ee00 in Universe::reserve_heap (heap_size=<optimized out>, alignment=33554432) at ./src/hotspot/src/share/vm/<wbr>memory/universe.cpp:942<br>
> #7  0x00003fffb799caf8 in ParallelScavengeHeap::<wbr>initialize (this=0x3fffb0016e70) at ./src/hotspot/src/share/vm/gc_<wbr>implementation/<wbr>parallelScavenge/<wbr>parallelScavengeHeap.cpp:64<br>
> #8  0x00003fffb7b2f8c0 in Universe::initialize_heap () at ./src/hotspot/src/share/vm/<wbr>memory/universe.cpp:843<br>
> #9  0x00003fffb7b2fcf8 in universe_init () at ./src/hotspot/src/share/vm/<wbr>memory/universe.cpp:652<br>
> #10 0x00003fffb76222d4 in init_globals () at ./src/hotspot/src/share/vm/<wbr>runtime/init.cpp:104<br>
> #11 0x00003fffb7b0849c in Threads::create_vm (args=<optimized out>, canTryAgain=0x3fffb6d9e5af) at ./src/hotspot/src/share/vm/<wbr>runtime/thread.cpp:3421<br>
> #12 0x00003fffb76ce19c in JNI_CreateJavaVM (vm=0x3fffb6d9e690, penv=0x3fffb6d9e698, args=<optimized out>) at ./src/hotspot/src/share/vm/<wbr>prims/jni.cpp:5220<br>
> #13 0x00003fffb7ed31dc in InitializeJVM (ifn=<synthetic pointer>, penv=<optimized out>, pvm=<optimized out>) at ./src/jdk/src/share/bin/java.<wbr>c:1215<br>
> #14 JavaMain (_args=<optimized out>) at ./src/jdk/src/share/bin/java.<wbr>c:376<br>
> #15 0x00003fffb7ed87a8 in call_continuation (_args=<optimized out>) at ./src/jdk/src/solaris/bin/<wbr>java_md_solinux.c:1034<br>
> #16 0x00003fffb7f4809c in start_thread (arg=0x3fffb6d9f1a0) at pthread_create.c:335<br>
> #17 0x00003fffb7df1344 in clone () at ../sysdeps/unix/sysv/linux/<wbr>powerpc/powerpc64/clone.S:94<br>
> (gdb) n<br>
> OpenJDK 64-Bit Server VM warning: Failed to reserve large pages memory req_addr: 0x0000000000000000 bytes: 268435456 (errno = 16).<br>
> 3513  Â  in ./src/hotspot/src/os/linux/vm/<wbr>os_linux.cpp<br>
> (gdb) !java -version<br>
> openjdk version "1.8.0_111"<br>
> OpenJDK Runtime Environment (build 1.8.0_111-8u111-b14-2-b14)<br>
> OpenJDK 64-Bit Server VM (build 25.111-b14, mixed mode)<br>
><br>
> Hence, if we use +UseSerialGC:<br>
><br>
> (gdb) c<br>
> Continuing.<br>
> [New Thread 0x3fffb6d9f1a0 (LWP 3842)]<br>
> -XX:InitialHeapSize=268435456 -XX:MaxHeapSize=268435456 -XX:+PrintCommandLineFlags -XX:-<wbr>UseCompressedClassPointers -XX:-UseCompressedOops -XX:+UseLargePages -XX:+UseSerialGC<br>
> [Switching to Thread 0x3fffb6d9f1a0 (LWP 3842)]<br>
><br>
> Breakpoint 1, os::Linux::reserve_memory_<wbr>special_huge_tlbfs_mixed (bytes=268435456, alignment=<optimized out>, req_addr=0x0, exec=<optimized out>) at ./src/hotspot/src/os/linux/vm/<wbr>os_linux.cpp:3505<br>
> 3505  Â  ./src/hotspot/src/os/linux/vm/<wbr>os_linux.cpp: No such file or directory.<br>
> (gdb) bt<br>
> #0  os::Linux::reserve_memory_<wbr>special_huge_tlbfs_mixed (bytes=268435456, alignment=<optimized out>, req_addr=0x0, exec=<optimized out>) at ./src/hotspot/src/os/linux/vm/<wbr>os_linux.cpp:3505<br>
> #1  0x00003fffb796e350 in os::Linux::reserve_memory_<wbr>special_huge_tlbfs (exec=<optimized out>, req_addr=0x0, alignment=<optimized out>, bytes=268435456) at ./src/hotspot/src/os/linux/vm/<wbr>os_linux.cpp:3541<br>
> #2  os::reserve_memory_special (bytes=268435456, alignment=<optimized out>, req_addr=0x0, exec=<optimized out>) at ./src/hotspot/src/os/linux/vm/<wbr>os_linux.cpp:3553<br>
> #3  0x00003fffb7b7651c in ReservedSpace::initialize (executable=false, noaccess_prefix=0, requested_address=0x0, large=true, alignment=<optimized out>, size=268435456, this=0x3fffb6d9ddc8)<br>
>  Â  Â at ./src/hotspot/src/share/vm/<wbr>runtime/virtualspace.cpp:157<br>
> #4  ReservedSpace::ReservedSpace (noaccess_prefix=0, requested_address=0x0, large=true, alignment=33554432, size=<optimized out>, this=0x3fffb6d9ddc8) at<br>
> ./src/hotspot/src/share/vm/<wbr>runtime/virtualspace.cpp:79<br>
> #5  ReservedHeapSpace::<wbr>ReservedHeapSpace (this=0x3fffb6d9ddc8, size=<optimized out>, alignment=33554432, large=<optimized out>, requested_address=0x0) at<br>
> ./src/hotspot/src/share/vm/<wbr>runtime/virtualspace.cpp:344<br>
> #6  0x00003fffb7b2ee00 in Universe::reserve_heap (heap_size=<optimized out>, alignment=33554432) at ./src/hotspot/src/share/vm/<wbr>memory/universe.cpp:942<br>
> #7  0x00003fffb75a83f0 in GenCollectedHeap::allocate (this=0x3fffb0016fb0, alignment=33554432, _total_reserved=<wbr>0x3fffb6d9e0c8, _n_covered_regions=<wbr>0x3fffb6d9e0c4, heap_rs=0x3fffb6d9e0d0)<br>
>  Â  Â at ./src/hotspot/src/share/vm/<wbr>memory/genCollectedHeap.cpp:<wbr>200<br>
> #8  0x00003fffb75aae58 in GenCollectedHeap::initialize (this=0x3fffb0016fb0) at ./src/hotspot/src/share/vm/<wbr>memory/genCollectedHeap.cpp:<wbr>124<br>
> #9  0x00003fffb7b2f8c0 in Universe::initialize_heap () at ./src/hotspot/src/share/vm/<wbr>memory/universe.cpp:843<br>
> #10 0x00003fffb7b2fcf8 in universe_init () at ./src/hotspot/src/share/vm/<wbr>memory/universe.cpp:652<br>
> #11 0x00003fffb76222d4 in init_globals () at ./src/hotspot/src/share/vm/<wbr>runtime/init.cpp:104<br>
> #12 0x00003fffb7b0849c in Threads::create_vm (args=<optimized out>, canTryAgain=0x3fffb6d9e5af) at ./src/hotspot/src/share/vm/<wbr>runtime/thread.cpp:3421<br>
> #13 0x00003fffb76ce19c in JNI_CreateJavaVM (vm=0x3fffb6d9e690, penv=0x3fffb6d9e698, args=<optimized out>) at ./src/hotspot/src/share/vm/<wbr>prims/jni.cpp:5220<br>
> #14 0x00003fffb7ed31dc in InitializeJVM (ifn=<synthetic pointer>, penv=<optimized out>, pvm=<optimized out>) at ./src/jdk/src/share/bin/java.<wbr>c:1215<br>
> #15 JavaMain (_args=<optimized out>) at ./src/jdk/src/share/bin/java.<wbr>c:376<br>
> #16 0x00003fffb7ed87a8 in call_continuation (_args=<optimized out>) at ./src/jdk/src/solaris/bin/<wbr>java_md_solinux.c:1034<br>
> #17 0x00003fffb7f4809c in start_thread (arg=0x3fffb6d9f1a0) at pthread_create.c:335<br>
> #18 0x00003fffb7df1344 in clone () at ../sysdeps/unix/sysv/linux/<wbr>powerpc/powerpc64/clone.S:94<br>
> (gdb) n<br>
> OpenJDK 64-Bit Server VM warning: Failed to reserve large pages memory req_addr: 0x0000000000000000 bytes: 268435456 (errno = 16).<br>
> 3513  Â  in ./src/hotspot/src/os/linux/vm/<wbr>os_linux.cpp<br>
><br>
> and if we use +UseG1GC:<br>
><br>
> Breakpoint 1, os::Linux::reserve_memory_<wbr>special_huge_tlbfs_mixed (bytes=268435456, alignment=<optimized out>, req_addr=0x0, exec=<optimized out>) at ./src/hotspot/src/os/linux/vm/<wbr>os_linux.cpp:3505<br>
> 3505  Â  ./src/hotspot/src/os/linux/vm/<wbr>os_linux.cpp: No such file or directory.<br>
> (gdb) bt<br>
> #0  os::Linux::reserve_memory_<wbr>special_huge_tlbfs_mixed (bytes=268435456, alignment=<optimized out>, req_addr=0x0, exec=<optimized out>) at ./src/hotspot/src/os/linux/vm/<wbr>os_linux.cpp:3505<br>
> #1  0x00003fffb796e350 in os::Linux::reserve_memory_<wbr>special_huge_tlbfs (exec=<optimized out>, req_addr=0x0, alignment=<optimized out>, bytes=268435456) at ./src/hotspot/src/os/linux/vm/<wbr>os_linux.cpp:3541<br>
> #2  os::reserve_memory_special (bytes=268435456, alignment=<optimized out>, req_addr=0x0, exec=<optimized out>) at ./src/hotspot/src/os/linux/vm/<wbr>os_linux.cpp:3553<br>
> #3  0x00003fffb7b7651c in ReservedSpace::initialize (executable=false, noaccess_prefix=0, requested_address=0x0, large=true, alignment=<optimized out>, size=268435456, this=0x3fffb6d9de78)<br>
>  Â  Â at ./src/hotspot/src/share/vm/<wbr>runtime/virtualspace.cpp:157<br>
> #4  ReservedSpace::ReservedSpace (noaccess_prefix=0, requested_address=0x0, large=true, alignment=33554432, size=<optimized out>, this=0x3fffb6d9de78) at<br>
> ./src/hotspot/src/share/vm/<wbr>runtime/virtualspace.cpp:79<br>
> #5  ReservedHeapSpace::<wbr>ReservedHeapSpace (this=0x3fffb6d9de78, size=<optimized out>, alignment=33554432, large=<optimized out>, requested_address=0x0) at<br>
> ./src/hotspot/src/share/vm/<wbr>runtime/virtualspace.cpp:344<br>
> #6  0x00003fffb7b2ee00 in Universe::reserve_heap (heap_size=<optimized out>, alignment=33554432) at ./src/hotspot/src/share/vm/<wbr>memory/universe.cpp:942<br>
> #7  0x00003fffb7557d48 in G1CollectedHeap::initialize (this=0x3fffb001bb70) at ./src/hotspot/src/share/vm/gc_<wbr>implementation/g1/<wbr>g1CollectedHeap.cpp:1975<br>
> #8  0x00003fffb7b2f8c0 in Universe::initialize_heap () at ./src/hotspot/src/share/vm/<wbr>memory/universe.cpp:843<br>
> #9  0x00003fffb7b2fcf8 in universe_init () at ./src/hotspot/src/share/vm/<wbr>memory/universe.cpp:652<br>
> #10 0x00003fffb76222d4 in init_globals () at ./src/hotspot/src/share/vm/<wbr>runtime/init.cpp:104<br>
> #11 0x00003fffb7b0849c in Threads::create_vm (args=<optimized out>, canTryAgain=0x3fffb6d9e5af) at ./src/hotspot/src/share/vm/<wbr>runtime/thread.cpp:3421<br>
> #12 0x00003fffb76ce19c in JNI_CreateJavaVM (vm=0x3fffb6d9e690, penv=0x3fffb6d9e698, args=<optimized out>) at ./src/hotspot/src/share/vm/<wbr>prims/jni.cpp:5220<br>
> #13 0x00003fffb7ed31dc in InitializeJVM (ifn=<synthetic pointer>, penv=<optimized out>, pvm=<optimized out>) at ./src/jdk/src/share/bin/java.<wbr>c:1215<br>
> #14 JavaMain (_args=<optimized out>) at ./src/jdk/src/share/bin/java.<wbr>c:376<br>
> #15 0x00003fffb7ed87a8 in call_continuation (_args=<optimized out>) at ./src/jdk/src/solaris/bin/<wbr>java_md_solinux.c:1034<br>
> #16 0x00003fffb7f4809c in start_thread (arg=0x3fffb6d9f1a0) at pthread_create.c:335<br>
> #17 0x00003fffb7df1344 in clone () at ../sysdeps/unix/sysv/linux/<wbr>powerpc/powerpc64/clone.S:94<br>
> (gdb) n<br>
> OpenJDK 64-Bit Server VM warning: Failed to reserve large pages memory req_addr: 0x0000000000000000 bytes: 268435456 (errno = 16).<br>
> 3513  Â  in ./src/hotspot/src/os/linux/vm/<wbr>os_linux.cpp<br>
><br>
> So there is no way to deal with it I guess...<br>
><br>
> But I tried SPECjbb2005 with THP as Goetz suggested and all went OK. I tried<br>
> also with shared memory allocation (+UseLargePages +UseSHM) and all went OK<br>
> as well.<br>
><br>
> So back to my initial question (given that +UseLargePages is indeed comprised of<br>
> three alternative methods to allocate space with HP - on Linux), I would say<br>
> that Huge Pages on PPC64 JVM is in good shape regarding +UseSHM and<br>
> +UseTransparentHugePages, but +UseHugeTLBFS has some issues not worth to care<br>
> since THP and SHM are OK. Is it sensible?<br>
><br>
> Thank you!<br>
><br>
> Regards,<br>
> Gustavo<br>
><br>
</div></div></blockquote></div><br></div></div>