RFR rev1 (M): 8078556: Runtime: implement ranges (optionally constraints) for those flags that have them missing
Coleen Phillimore
coleen.phillimore at oracle.com
Mon Oct 19 17:24:39 UTC 2015
Ok, Yes, I'll sponsor that change.
Coleen
On 10/19/15 2:45 AM, Lindenmaier, Goetz wrote:
> Hi Coleen,
>
> It's ok, after all we could fix it right away as we can submit to the ppc files
> ourselves.
> Unfortunately I'm unclear about your constraints for these flags. But
> I'll open a bug and send a mail to discuss it.
>
> Best regards,
> Goetz.
>
> (Would you mind to sponsor my other change?
> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2015-October/016005.html
> http://cr.openjdk.java.net/~goetz/webrevs/8139040-init/webrev.04/
> Roland had a look at the compiler changes. Than would be great!)
>
>
>
>> -----Original Message-----
>> From: Coleen Phillimore [mailto:coleen.phillimore at oracle.com]
>> Sent: Freitag, 16. Oktober 2015 15:17
>> To: Lindenmaier, Goetz; gerard ziemski; Dmitry Dmitriev; hotspot-runtime-
>> dev at openjdk.java.net
>> Subject: Re: RFR rev1 (M): 8078556: Runtime: implement ranges (optionally
>> constraints) for those flags that have them missing
>>
>>
>> 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