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

Lindenmaier, Goetz goetz.lindenmaier at sap.com
Mon Oct 19 06:45:53 UTC 2015

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