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

[Lindenmaier, Goetz]

Hi Gerard, 

it's ok.  
The >8k issue is that stacks get very big with the default behavior:
e.g. x86:  1 red + 2 yellow + 20 shadow.  With 64K pages this 
makes a stack of at least 23*64K = 1472K 'wasted' space. Therefore
number of pages are reduced.
  
But I'll open a bug and send a mail to discuss it.

Best regards,
  Goetz.

> -----Original Message-----
> From: gerard ziemski [mailto:gerard.ziemski at oracle.com]
> Sent: Freitag, 16. Oktober 2015 16:42
> 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,
> 
> 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