RFR rev1 (M): 8078556: Runtime: implement ranges (optionally constraints) for those flags that have them missing
Lindenmaier, Goetz
goetz.lindenmaier at sap.com
Tue Oct 20 11:58:47 UTC 2015
Thanks a lot!
Best regards,
Goetz.
> -----Original Message-----
> From: Coleen Phillimore [mailto:coleen.phillimore at oracle.com]
> Sent: Montag, 19. Oktober 2015 19:25
> 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
>
>
> 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