RFR rev1 (M): 8078556: Runtime: implement ranges (optionally constraints) for those flags that have them missing

gerard ziemski gerard.ziemski at oracle.com
Wed Oct 14 15:31:41 UTC 2015


hi Goetz,

Great work, thank you for all the feedback, please see my answers inline:


On 10/14/2015 04:00 AM, Lindenmaier, Goetz wrote:
> Hi Gerald,
>
> I had a closer look at your change now, especially on the settings of the
> stack protection zone sizes.
>
> You set the lower bounds of the stack protection pages > 1. Because of that
> the VM on PPC does not start up, it immediately fails with:
>    intx StackYellowPages=1 is outside the allowed range [ 6 ... 11 ]
>    intx StackShadowPages=1 is outside the allowed range [ 8 ... 38 ]
>    Error: Could not create the Java Virtual Machine.
>    Error: A fatal exception has occurred. Program will exit.
>
> The lower bounds of these flags must be '1'.  If vm_page_size() > vm_default_page_size(),
> the numbers of pages are reduced.  This is necessary
> on systems with page size 64K, else stacks get too big.  We have such
> systems on ppc.  See also os_linux.cpp:4649.
>

PPC issue I will have to comment on later.


> http://cr.openjdk.java.net/~gziemski/8078556_rev2/src/cpu/sparc/vm/globals_sparc.hpp.udiff.html
> Why do you need to special-case for !LP64 on sparc?  As I understand,
> this is no more supported in jdk9.
>

I'd prefer to keep the code in for completeness for those who will be reading that header.


> in globals.hpp:
> http://cr.openjdk.java.net/~gziemski/8078556_rev2/src/share/vm/runtime/globals.hpp.udiff.html
>
> You might want to use SIZE_MAX for MaxDirectMemorySize:
>     product(size_t, MaxDirectMemorySize, 0,                                   \
> +           range(0, (size_t)max_uintx)                                      \
>

I like that. I will see if all the platforms are happy with SIZE_MAX


> This lower bound setting crashes the VM on linuxx86_64 and seems pointless:
>      product_pd(intx, ThreadStackSize,                                         \
> +           range(0, max_intx-os::vm_page_size())                             \
> bin/java -XX:ThreadStackSize=0
> #  Internal Error (.../src/os/linux/vm/os_linux.cpp:720), pid=47259, tid=47260
> #  assert(JavaThread::stack_size_at_create() > 0) failed: this should be set
>

Yes, this is a follow-up issue tracked by https://bugs.openjdk.java.net/browse/JDK-8136766


> More crashes I see on linuxx86_64:
> bin/java -XX:MallocMaxTestWords=1
> # There is insufficient memory for the Java Runtime Environment to continue.
> # Native memory allocation (malloc) failed to allocate 18 bytes for AllocateHeap
>

Right, this flag will be disabled from testing by the runtime/CommandLine/OptionsValidation as the valid values are in 
fact allowed to crash the VM for testing purposes, which is a behavior that can not be captured by the testing framework 
at the moment.


> bin/java -XX:VMThreadStackSize=9007199254740991 / 4294967296 / 2147483648
> # There is insufficient memory for the Java Runtime Environment to continue.
> # Cannot create worker GC thread. Out of system resources.
>

"Out of system resources" errors are in fact allowed. Still, is this a crash that dumps an error log? I do not see this 
issue in our internal testing, but I will verify on my local 64bit Linux (Ubuntu 14.04)


> and on linuxppc64:
> /sapmnt/home/d045726/oJ/vms/ppc_9-1/bin/java -XX:MaxRAM=18446744073709551615
> OpenJDK 64-Bit Server VM warning: INFO: os::commit_memory(0x0000000082000000, 32178700288, 0) failed; error='Cannot allocate memory' (errno=12)
> # There is insufficient memory for the Java Runtime Environment to continue.
> # Native memory allocation (mmap) failed to map 32178700288 bytes for committing reserved memory.
>

PPC issue I will have to comment on later.


> I saw these errors trying to run
> runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java
> with a debug build.
>
> If you need any more input, especially on ppc, I'm happy to help out!

That would be great! I will reach out to you regarding PPC support after I look into it more.

Big thank you for the review!


cheers


More information about the hotspot-runtime-dev mailing list