RFR rev1 (M): 8078556: Runtime: implement ranges (optionally constraints) for those flags that have them missing
Coleen Phillimore
coleen.phillimore at oracle.com
Fri Oct 16 13:17:29 UTC 2015
Hi Goetz,
This was my fault. The change was getting unwieldy so I encouraged
Gerard to check it in. I didn't notice the additional changes to the
ppc parts in it.
I'd be happy to review and sponsor another fix for the StackShadowPage
issue.
Coleen
On 10/16/15 9: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
More information about the hotspot-runtime-dev
mailing list