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

Fri Oct 16 14:41:59 UTC 2015

hi Goetz,

Sorry for breaking the PPC build.

I will be happy to do this myself, but it sounds like you know exactly what's needed here to support platforms with >8K 
pages, and are in position to test out the required fix. Would you mind then taking charge of this please? If not, then 
at least please file an issue and assign it to me.

cheers

On 10/16/2015 08:11 AM, Lindenmaier, Goetz wrote:
> Hi Gerard,
>
> I would have appreciated to see another webrev, especially as you edited
> the fixes I proposed.
>
> The patch removing the flags from globals_linux_ppc.hpp was missing.
> This breaks the build. Martin was so friendly to fix this.
>
> You moved setting lower bound of StackShadowPages etc to '1'  to globals_ppc.hpp.
> This helps with our tests running on our ppc machine with 64K pages. But Linux systems
> on other cpus can also be configured to have >8K pages, and will run into
> the error at os_linux.cpp:4648.  I guess you should open a follow-up bug for
> this.  Or is there another workaround for this I oversee?
>
> Nevertheless, still thanks for incorporating my changes.
>
> Best regards,
>    Goetz.
>
>
>
>> -----Original Message-----
>> From: gerard ziemski [mailto:gerard.ziemski at oracle.com]
>> Sent: Mittwoch, 14. Oktober 2015 17:32
>> To: Lindenmaier, Goetz; Dmitry Dmitriev; hotspot-runtime-
>> dev at openjdk.java.net; Coleen Phillimore
>> Subject: Re: RFR rev1 (M): 8078556: Runtime: implement ranges (optionally
>> constraints) for those flags that have them missing
>>
>> 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/glob
>> als_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