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

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 globalslinuxppc.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 globalsppc.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 oslinux.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 vmpagesize() > vmdefaultpagesize(), 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 oslinux.cpp:4649. PPC issue I will have to comment on later.

http://cr.openjdk.java.net/~gziemski/8078556rev2/src/cpu/sparc/vm/glob alssparc.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/8078556rev2/src/share/vm/runtime/ globals.hpp.udiff.html You might want to use SIZEMAX for MaxDirectMemorySize: _product(sizet, MaxDirectMemorySize, 0, _ _+ range(0, (sizet)maxuintx) _ I like that. I will see if all the platforms are happy with SIZEMAX This lower bound setting crashes the VM on linuxx8664 and seems pointless: _productpd(intx, ThreadStackSize, _ _+ range(0, maxintx-os::vmpagesize()) _ bin/java -XX:ThreadStackSize=0 # Internal Error (.../src/os/linux/vm/oslinux.cpp:720), pid=47259, tid=47260 # assert(JavaThread::stacksizeatcreate() > 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 linuxx8664: 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/ppc9-1/bin/java - XX:MaxRAM=18446744073709551615 OpenJDK 64-Bit Server VM warning: INFO: os::commitmemory(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