RFR(M): 8169373: Work around linux NPTL stack guard error.
Lindenmaier, Goetz
goetz.lindenmaier at sap.com
Sat Dec 3 17:50:51 UTC 2016
Hi,
I made a final webrev adding Vladimir to reviewers and with the errno->error
fixes:
http://cr.openjdk.java.net/~goetz/wr16/8169373-ppc-stackFix/webrev.08/
I hope this does not invalidate the testing you already did.
Will the closed port issue go away if arm is submitted to openJdk?
Best regards,
Goetz.
> -----Original Message-----
> From: Daniel D. Daugherty [mailto:daniel.daugherty at oracle.com]
> Sent: Saturday, December 03, 2016 1:03 AM
> To: Vladimir Kozlov <vladimir.kozlov at oracle.com>; Lindenmaier, Goetz
> <goetz.lindenmaier at sap.com>; David Holmes <david.holmes at oracle.com>;
> hotspot-compiler-dev at openjdk.java.net; 'hotspot-runtime-
> dev at openjdk.java.net' <hotspot-runtime-dev at openjdk.java.net>
> Subject: Re: RFR(M): 8169373: Work around linux NPTL stack guard error.
>
> Getting JPRT job failures on non-OpenJDK platforms.
> I'll have to look at this more on Monday...
>
> Dan
>
>
> On 12/2/16 4:46 PM, Daniel D. Daugherty wrote:
> > OK... kicked off the usual JPRT -testset hotspot pre-push job...
> > Also kicked off a "full rbt run". JPRT should be done in < 2 hours
> > and RBT should finish by the end of the weekend...
> >
> > Dan
> >
> >
> > On 12/2/16 2:04 PM, Daniel D. Daugherty wrote:
> >> Vladimir, Thanks for the review!
> >>
> >> OK, the ball is in my court (as sponsor) and I need to figure out what
> >> kind of RBT testing David H wants to see on the patch before I push
> >> it...
> >> It's the weekend already for David so I'm guessing he's out mowing the
> >> lawn... :-)
> >>
> >> Dan
> >>
> >>
> >> On 12/2/16 11:12 AM, Vladimir Kozlov wrote:
> >>> I read through whole tread and you guys did good job with review :)
> >>>
> >>> I agree with changes (and keeping guard pages for compiler threads).
> >>>
> >>> Thanks,
> >>> Vladimir
> >>>
> >>> On 12/1/16 2:32 AM, Lindenmaier, Goetz wrote:
> >>>> Hi David,
> >>>>
> >>>> I fixed the comment:
> >>>> http://cr.openjdk.java.net/~goetz/wr16/8169373-ppc-
> stackFix/webrev.07/
> >>>>
> >>>> We run a lot of tests with this change:
> >>>> Hotspot jtreg, jck, spec, SAP applications
> >>>> On these platforms:
> >>>> Windows_x86_64, linux_x86_64, solaris_sparc, mac_x86_64,
> >>>> Linux_ppc64, linux_ppc64le, aix_ppc64, linux_s390
> >>>> I did not spot a problem there.
> >>>>
> >>>> Best regards,
> >>>> Goetz.
> >>>>
> >>>>> -----Original Message-----
> >>>>> From: David Holmes [mailto:david.holmes at oracle.com]
> >>>>> Sent: Mittwoch, 30. November 2016 22:51
> >>>>> To: daniel.daugherty at oracle.com; Lindenmaier, Goetz
> >>>>> <goetz.lindenmaier at sap.com>; hotspot-compiler-
> dev at openjdk.java.net;
> >>>>> 'hotspot-runtime-dev at openjdk.java.net' <hotspot-runtime-
> >>>>> dev at openjdk.java.net>
> >>>>> Subject: Re: RFR(M): 8169373: Work around linux NPTL stack guard
> >>>>> error.
> >>>>>
> >>>>> On 1/12/2016 1:20 AM, Daniel D. Daugherty wrote:
> >>>>>>> Would you mind sponsoring this change?
> >>>>>>
> >>>>>> Yes, I will sponsor this change. However, I would like to get a
> >>>>>> thumbs up from David H. on the latest version and I don't see
> >>>>>> any review from someone on the Compiler Team.
> >>>>>
> >>>>> I'm okay with proposed changes - but also want to hear from compiler
> >>>>> team and I'd want to see this put through some advance testing
> >>>>> before it
> >>>>> gets pushed (full rbt run).
> >>>>>
> >>>>> I have one minor nit in the wording of the fatal error messages
> >>>>> "failed
> >>>>> with errno" - these methods don't touch errno so I'd prefer it if it
> >>>>> said error.
> >>>>>
> >>>>> Thanks,
> >>>>> David
> >>>>> -----
> >>>>>
> >>>>>> Vladimir! We need someone on the Compiler Team to look at these
> >>>>>> CompilerThread stack size changes...
> >>>>>>
> >>>>>> Dan
> >>>>>>
> >>>>>>
> >>>>>> On 11/30/16 12:57 AM, Lindenmaier, Goetz wrote:
> >>>>>>> Hi Dan,
> >>>>>>>
> >>>>>>>> Thumbs up! I don't need to see a new webrev if you choose
> >>>>>>>> to fix the minor comments above.
> >>>>>>> I anyways did a new one fixing the comments:
> >>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8169373-ppc-
> stackFix/webrev.06/
> >>>>>>>
> >>>>>>> Would you mind sponsoring this change?
> >>>>>>>
> >>>>>>> I took the minimum stack sizes from my experimental runs where
> >>>>>>> I had removed the automatic resizing to find the really needed
> >>>>>>> space.
> >>>>>>> If I put something smaller there, I could as well put '0' ... as
> >>>>>>> _java_thread_min_stack_allowed =
> >>>>> MAX2(_java_thread_min_stack_allowed,
> >>>>>>>
> >>>>>>> JavaThread::stack_guard_zone_size() +
> >>>>>>>
> >>>>>>> JavaThread::stack_shadow_zone_size() +
> >>>>>>> (4 * BytesPerWord
> >>>>>>> COMPILER2_PRESENT(+ 2)) * 4 * K);
> >>>>>>> will fix it.
> >>>>>>> This code effectively limits the usable stack size to
> >>>>>>> (4 * BytesPerWord COMPILER2_PRESENT(+ 2)) * 4 * K)
> >>>>>>> which makes the initialization of _java_thread_min_stack_allowed
> >>>>>>> with
> >>>>>>> platform
> >>>>>>> values pointless.
> >>>>>>>
> >>>>>>> I'll open a new bug for the follow-up stack issue, probably
> >>>>>>> tomorrow.
> >>>>>>> I don't feel like addressing testing all the possible error
> >>>>>>> codes, as
> >>>>>>> they probably should be fixed in more places, and there is no issue
> >>>>>>> pending currently. Maybe it should be fixed in jdk10 at some
> >>>>>>> point.
> >>>>>>>
> >>>>>>> Best regards,
> >>>>>>> Goetz
> >>>>>>>
> >>>>>>>
> >>>>>>>> -----Original Message-----
> >>>>>>>> From: Daniel D. Daugherty [mailto:daniel.daugherty at oracle.com]
> >>>>>>>> Sent: Dienstag, 29. November 2016 20:04
> >>>>>>>> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>;
> >>>>>>>> hotspot-compiler-
> >>>>>>>> dev at openjdk.java.net; 'hotspot-runtime-dev at openjdk.java.net'
> >>>>>>>> <hotspot-
> >>>>>>>> runtime-dev at openjdk.java.net>
> >>>>>>>> Subject: Re: RFR(M): 8169373: Work around linux NPTL stack
> >>>>>>>> guard error.
> >>>>>>>>
> >>>>>>>> On 11/29/16 2:30 AM, Lindenmaier, Goetz wrote:
> >>>>>>>>> Hi Dan,
> >>>>>>>>>
> >>>>>>>>> see my replies inline ...
> >>>>>>>>> New webrev:
> >>>>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8169373-ppc-
> stackFix/webrev.05/
> >>>>>>>>>
> >>>>>>>> src/os/aix/vm/os_aix.cpp
> >>>>>>>> L887: // libc guard page
> >>>>>>>> nit - You made other existing comments into sentences
> >>>>>>>> (leading
> >>>>>>>> capital and trailing '.'), but not this new
> >>>>>>>> comment.
> >>>>>>>> Why?
> >>>>>>>>
> >>>>>>>> src/os/aix/vm/os_aix.hpp
> >>>>>>>> No comments.
> >>>>>>>>
> >>>>>>>> src/os/linux/vm/os_linux.cpp
> >>>>>>>> L6096: // | |/ 1 page glibc
> >>>>>>>> guard.
> >>>>>>>> nit - "1 page glibc guard" -> "1 glibc guard page."
> >>>>>>>>
> >>>>>>>> src/os/posix/vm/os_posix.cpp
> >>>>>>>> No comments.
> >>>>>>>>
> >>>>>>>> src/os_cpu/aix_ppc/vm/os_aix_ppc.cpp
> >>>>>>>> No comments.
> >>>>>>>>
> >>>>>>>> src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp
> >>>>>>>> L875: // | |/ 1 page glibc guard.
> >>>>>>>> nit - "1 page glibc guard" -> "1 glibc guard page."
> >>>>>>>>
> >>>>>>>> src/os_cpu/linux_aarch64/vm/os_linux_aarch64.cpp
> >>>>>>>> No comments.
> >>>>>>>>
> >>>>>>>> src/os_cpu/linux_ppc/vm/os_linux_ppc.cpp
> >>>>>>>> No comments.
> >>>>>>>>
> >>>>>>>> src/os_cpu/linux_s390/vm/os_linux_s390.cpp
> >>>>>>>> No comments.
> >>>>>>>>
> >>>>>>>> src/os_cpu/linux_sparc/vm/os_linux_sparc.cpp
> >>>>>>>> No comments.
> >>>>>>>>
> >>>>>>>> src/os_cpu/linux_x86/vm/os_linux_x86.cpp
> >>>>>>>> No comments.
> >>>>>>>>
> >>>>>>>> src/os_cpu/linux_zero/vm/os_linux_zero.cpp
> >>>>>>>> No comments.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> Thumbs up! I don't need to see a new webrev if you choose
> >>>>>>>> to fix the minor comments above.
> >>>>>>>>
> >>>>>>>> Some replies embedded below.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>> -----Original Message-----
> >>>>>>>>>> From: Daniel D. Daugherty
> [mailto:daniel.daugherty at oracle.com]
> >>>>>>>>>> Sent: Dienstag, 29. November 2016 01:38
> >>>>>>>>>> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>;
> hotspot-
> >>>>> compiler-
> >>>>>>>>>> dev at openjdk.java.net; 'hotspot-runtime-
> dev at openjdk.java.net'
> >>>>> <hotspot-
> >>>>>>>>>> runtime-dev at openjdk.java.net>
> >>>>>>>>>> Subject: Re: RFR(M): 8169373: Work around linux NPTL stack
> guard
> >>>>>>>>>> error.
> >>>>>>>>>>
> >>>>>>>>>> On 11/28/16 2:08 AM, Lindenmaier, Goetz wrote:
> >>>>>>>>>>> Hi,
> >>>>>>>>>>>
> >>>>>>>>>>> I'm working on a fix for OS guard pages on stacks. I
> >>>>>>>>>>> figured there
> >>>>>>>>>>> are VM guard pages (reserved, yellow, red) on the compiler
> >>>>>>>>>>> stacks
> >>>>>>>>>>> _and_ OS guard pages. For Java threads, the OS guard pages
> >>>>>>>>>>> are left
> >>>>>>>>>>> out. I think this should be done for compiler threads, too.
> >>>>>>>>>>> Please
> >>>>>>>>>>> confirm.
> >>>>>>>>>>> Webrev:
> >>>>>>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8169373-ppc-
> >>>>> stackFix/webrev.04/
> >>>>>>>>>>>
> >>>>>>>>>> src/os/aix/vm/os_aix.cpp
> >>>>>>>>>> L888: pthread_attr_setguardsize(&attr,
> >>>>>>>>>> os::Aix::default_guard_size(thr_type));
> >>>>>>>>>> No check or assert on the return status of this call.
> >>>>>>>>>> Is one needed?
> >>>>>>>>> I implemented this as the existing code on linux which has
> >>>>>>>>> no check either. I think a failure is quite theoretical.
> >>>>>>>>> Because of your comment below I'll leave it as-is.
> >>>>>>>> OK.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>> L3044: // guard pages, so only enable libc guard
> >>>>>>>>>> pages for
> >>>>>>>>>> non-Java threads.
> >>>>>>>>>> src/os/linux/vm/os_linux.cpp also has this comment:
> >>>>>>>>>> // (Remember: compiler thread is a Java thread, too!)
> >>>>>>>>> Fixed.
> >>>>>>>>>
> >>>>>>>>>> L3051: return ((thr_type == java_thread || thr_type ==
> >>>>>>>>>> compiler_thread) ? 0 : 4*K);
> >>>>>>>>>> nit - please add spaces around the '*' so '4 * K'.'
> >>>>>>>>> Fixed.
> >>>>>>>>>
> >>>>>>>>>> src/os/aix/vm/os_aix.hpp
> >>>>>>>>>> No comments.
> >>>>>>>>>>
> >>>>>>>>>> src/os/linux/vm/os_linux.cpp
> >>>>>>>>>> L729: // is not implemented properly. The posix
> >>>>>>>>>> standard
> >>>>>>>>>> requires
> >>>>>>>>>> to add
> >>>>>>>>>> Typo: 'to add' -> 'adding'
> >>>>>>>>> Fixed.
> >>>>>>>>>
> >>>>>>>>>> L738: pthread_attr_setguardsize(&attr,
> >>>>>>>>>> os::Linux::default_guard_size(thr_type));
> >>>>>>>>>> No check or assert on the return status of this call.
> >>>>>>>>>> Is one needed?
> >>>>>>>>> See above.
> >>>>>>>>>
> >>>>>>>>>> L2851: // Creating guard page is very expensive. Java
> >>>>>>>>>> thread has
> >>>>>>>>>> HotSpot
> >>>>>>>>>> L2852: // guard page, only enable glibc guard page for
> >>>>>>>>>> non-Java
> >>>>>>>>>> threads.
> >>>>>>>>>> L2853: // (Remember: compiler thread is a java
> >>>>>>>>>> thread, too!)
> >>>>>>>>>> Typo: "java thread" -> "Java thread" (consistency)
> >>>>>>>>>>
> >>>>>>>>>> This comment block should be common to all the
> >>>>>>>>>> platforms
> >>>>>>>>>> that
> >>>>>>>>>> define default_guard_size(). Yes, I can see that AIX
> >>>>>>>>>> needs to
> >>>>>>>>>> add another paragraph, but we should make the core
> >>>>>>>>>> comment
> >>>>>>>> common
> >>>>>>>>>> if possible.
> >>>>>>>>> I made the first three lines look alike.
> >>>>>>>>>
> >>>>>>>>>> L6090: // Java/Compiler thread:
> >>>>>>>>>> Thanks for making this common in os_linux.cpp.
> >>>>>>>>>>
> >>>>>>>>>> L6095: // | glibc guard page | - guard,
> >>>>>>>>>> attached Java
> >>>>>>>>>> thread usually has
> >>>>>>>>>> Clarity: "guard," -> "guard page,"
> >>>>>>>>> Fixed.
> >>>>>>>>>
> >>>>>>>>>> Typo: "Java thread" -> "JavaThread" (consistency)
> >>>>>>>>> I changed both to Java thread as at the other locations.
> >>>>>>>>>
> >>>>>>>>>> L6099: // | HotSpot Guard Pages | - red and
> >>>>>>>>>> yellow pages
> >>>>>>>>>> The fairly recently added reserved page should be
> >>>>>>>>>> mentioned
> >>>>>>>>>> here also?
> >>>>>>>>> Yes. Fixed. Also fixed it to say
> >>>>>>>>> JavaThread::stack_reserved_zone_base().
> >>>>>>>>> Also fixed comment on bsd.
> >>>>>>>> Thanks for also fixing BSD.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>> L6120 // ** P1 (aka bottom) and size ( P2 = P1 - size)
> >>>>>>>>>> are the
> >>>>>>>>>> address and stack size returned from
> >>>>>>>>>> Typo: "( P2 = ..." -> "(P2 = ..."
> >>>>>>>>> Fixed.
> >>>>>>>>>
> >>>>>>>>>> L6148: fatal("Can not locate current stack attributes!");
> >>>>>>>>>> Typo: "Can not" -> "Cannot"
> >>>>>>>>> Fixed.
> >>>>>>>>>
> >>>>>>>>>> L6175: // stack size includes normal stack and HotSpot
> >>>>>>>>>> guard pages
> >>>>>>>>>> Perhaps add to the comment:
> >>>>>>>>>> "for the threads that have HotSpot guard pages."
> >>>>>>>>> Fixed. I also checked my comments for "OS guard pages" and
> >>>>>>>>> replaced it by "glibc guard pages" which is used in several
> >>>>>>>>> places
> >>>>>>>>> already, same for "VM guard page" --> "HotSpot guard page". I
> >>>>>>>>> think this is also more consistent.
> >>>>>>>> I agree!
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>> src/os/posix/vm/os_posix.cpp
> >>>>>>>>>> L1097: pthread_attr_getstacksize(attr, &stack_size);
> >>>>>>>>>> L1098: pthread_attr_getguardsize(attr, &guard_size);
> >>>>>>>>>> Do these two calls need to have their result checked?
> >>>>>>>>>>
> >>>>>>>>>> Now I'm starting to wonder if all the uses of these
> >>>>>>>>>> two APIs need to be checked? Separate bug?
> >>>>>>>>> It would be more consistent with the specification of the
> >>>>>>>>> methods,
> >>>>>>>>> On the other side it's quite unlikely that these fail if attr
> >>>>>>>>> != NULL.
> >>>>>>>> So should we file a new bug? Or does this fall into the realm of
> >>>>>>>> other OS/libc code that we call and assume never fails? :-)
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>> src/os_cpu/aix_ppc/vm/os_aix_ppc.cpp
> >>>>>>>>>> L540: size_t
> >>>>>>>>>> os::Posix::_compiler_thread_min_stack_allowed =
> >>>>>>>>>> 512 * K;
> >>>>>>>>>> L541: size_t os::Posix::_java_thread_min_stack_allowed
> >>>>>>>>>> = 512
> >>>>>>>>>> * K;
> >>>>>>>>>> So prior to the fix for 8140520,
> >>>>>>>>>> src/os/aix/vm/os_aix.cpp had
> >>>>>>>>>> this single min_stack_allowed value:
> >>>>>>>>>>
> >>>>>>>>>> L3601: os::Aix::min_stack_allowed =
> >>>>>>>>>> MAX2(os::Aix::min_stack_allowed,
> >>>>>>>>>> L3602: JavaThread::stack_guard_zone_size() +
> >>>>>>>>>> L3603: JavaThread::stack_shadow_zone_size() +
> >>>>>>>>>> L3604: (4*BytesPerWord
> >>>>>>>>>> COMPILER2_PRESENT(+2)) * 4 * K);
> >>>>>>>>>>
> >>>>>>>>>> and the fix for 8140520 changed that for *NIX
> >>>>>>>>>> platforms to
> >>>>>>>>>> three mins in src/os/posix/vm/os_posix.cpp:
> >>>>>>>>>>
> >>>>>>>>>> L1108: _java_thread_min_stack_allowed =
> >>>>>>>>>> MAX2(_java_thread_min_stack_allowed,
> >>>>>>>>>> L1109: JavaThread::stack_guard_zone_size() +
> >>>>>>>>>> L1110: JavaThread::stack_shadow_zone_size() +
> >>>>>>>>>> L1111: (4 *
> >>>>>>>>>> BytesPerWord COMPILER2_PRESENT(+ 2)) * 4 * K);
> >>>>>>>>>>
> >>>>>>>>>> L1150: _compiler_thread_min_stack_allowed =
> >>>>>>>>>> align_size_up(_compiler_thread_min_stack_allowed,
> >>>>>>>>>> vm_page_size());
> >>>>>>>>>>
> >>>>>>>>>> L1161 _vm_internal_thread_min_stack_allowed =
> >>>>>>>>>> align_size_up(_vm_internal_thread_min_stack_allowed,
> >>>>> vm_page_size());
> >>>>>>>>>>
> >>>>>>>>>> Which means that the compiler_thread no longer
> >>>>>>>>>> benefits
> >>>>>>>>>> from
> >>>>>>>>>> the extra space for quard and shadow pages. The
> >>>>>>>>>> thinking in
> >>>>>>>>>> 8140520 was that the compiler_thread and
> >>>>>>>>>> vm_internal_threads
> >>>>>>>>>> don't need the quard and shadow pages since they
> >>>>>>>>>> don't run
> >>>>>>>>>> Java code (ignoring JVMCI for now).
> >>>>>>>>>>
> >>>>>>>>>> So I can see bumping
> >>>>>>>>>> _compiler_thread_min_stack_allowed
> >>>>>>>>>> from
> >>>>>>>>>> 128 -> 512 as one solution for getting that extra
> >>>>>>>>>> space
> >>>>>>>>>> back.
> >>>>>>>>>> However, I don't understand why
> >>>>>>>>>> _java_thread_min_stack_allowed
> >>>>>>>>>> has changed from 128 -> 512.
> >>>>>>>>> Because it was never correct before.
> >>>>>>>> OK. That sounds like the new test that I included with 8140520
> >>>>>>>> would
> >>>>>>>> have failed with JavaThread stack sizes even before the product
> >>>>>>>> code
> >>>>>>>> changes from 8140520 were made.
> >>>>>>>>
> >>>>>>>> Since the size calculation for JavaThread stack sizes wasn't
> >>>>>>>> changed
> >>>>>>>> for any platform in 8140520, that tends to indicate that the more
> >>>>>>>> limited JDK test (test/tools/launcher/TooSmallStackSize.java)
> >>>>>>>> should
> >>>>>>>> also have failed before the fix for 8140520.
> >>>>>>>>
> >>>>>>>> Please clarify the need for the _java_thread_min_stack_allowed
> >>>>>>>> change
> >>>>>>>> from 128 -> 512. Unless
> test/tools/launcher/TooSmallStackSize.java
> >>>>>>>> is never run in your testing, I'm having troubling seeing why the
> >>>>>>>> _java_thread_min_stack_allowed increase is needed.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>> I had previously made this comment:
> >>>>>>>>>> > To put it another way, I'd like to see us add extra
> >>>>>>>>>> space to
> >>>>>>>>>> > solve the 64K page issue directly instead of as
> >>>>>>>>>> a side
> >>>>>>>>>> effect
> >>>>>>>>>> > of the red/yellow page addition.
> >>>>>>>>>> And Goetz replied with:
> >>>>>>>>>> > I don't understand. What do you mean by
> >>>>>>>>>> 'directly'?
> >>>>>>>>>>
> >>>>>>>>>> So prior to the fix for 8140520,
> >>>>>>>>>> src/os/solaris/vm/os_solaris.cpp
> >>>>>>>>>> had a block like this:
> >>>>>>>>>>
> >>>>>>>>>> L4468: // For 64kbps there will be a 64kb page
> >>>>>>>>>> size,
> >>>>>>>>>> which makes
> >>>>>>>>>> L4469: // the usable default stack size quite a
> >>>>>>>>>> bit less.
> >>>>>>>>>> Increase the
> >>>>>>>>>> L4470: // stack for 64kb (or any > than 8kb)
> >>>>>>>>>> pages, this
> >>>>>>>>>> increases
> >>>>>>>>>> L4471: // virtual memory fragmentation (since
> >>>>>>>>>> we're not
> >>>>>>>>>> creating the
> >>>>>>>>>> L4472 // stack on a power of 2 boundary. The
> >>>>>>>>>> real fix
> >>>>>>>>>> for this
> >>>>>>>>>> L4473 // should be to fix the guard page mechanism.
> >>>>>>>>>> L4474
> >>>>>>>>>> L4475 if (vm_page_size() > 8*K) {
> >>>>>>>>>> L4476 threadStackSizeInBytes =
> >>>>>>>>>> (threadStackSizeInBytes != 0)
> >>>>>>>>>> L4477 ? threadStackSizeInBytes +
> >>>>>>>>>> L4478 JavaThread::stack_red_zone_size() +
> >>>>>>>>>> L4479 JavaThread::stack_yellow_zone_size()
> >>>>>>>>>> L4480 : 0;
> >>>>>>>>>> L4481 ThreadStackSize = threadStackSizeInBytes/K;
> >>>>>>>>>> L4482 }
> >>>>>>>>>>
> >>>>>>>>>> The above is an example of what I mean by solving
> >>>>>>>>>> the 64K
> >>>>>>>>>> page issue directly. In the fix for 8140520, that
> >>>>>>>>>> code
> >>>>>>>>>> block
> >>>>>>>>>> was moved to os::Posix::set_minimum_stack_sizes() in
> >>>>>>>>>> src/os/posix/vm/os_posix.cpp and put in a "#ifdef
> >>>>>>>>>> SOLARIS...
> >>>>>>>>>> #endif // SOLARIS" block. Coleen filed a bug to
> >>>>>>>>>> determine
> >>>>>>>>>> whether that code can be deleted:
> >>>>>>>>>>
> >>>>>>>>>> JDK-8161093 Solaris for >8k pagesize adds extra
> >>>>>>>>>> guard pages
> >>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8161093
> >>>>>>>>>>
> >>>>>>>>>> but perhaps this bug shows that the code is needed?
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> OK so this is probably the longest code review
> >>>>>>>>>> comment
> >>>>>>>>>> I have ever written, but the summary is:
> >>>>>>>>>>
> >>>>>>>>>> - I understand bumping
> >>>>>>>>>> _compiler_thread_min_stack_allowed,
> >>>>>>>>>> but should it be solved in a different way?
> >>>>>>>>>> - I don't understand bumping
> >>>>>>>>>> _java_thread_min_stack_allowed
> >>>>>>>>> I plan to do a follow up change to fix this. Let's leave this
> >>>>>>>>> discussion
> >>>>>>>>> to that review. Here I just want to fix the NPTL issue and
> >>>>>>>>> the basic
> >>>>>>>>> sizing that is needed to pass the new test on ppc/s390.
> >>>>>>>> Same question here about the simpler JDK version of the test.
> >>>>>>>>
> >>>>>>>> Does test/tools/launcher/TooSmallStackSize.java get run in
> >>>>>>>> your test environments?
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>> src/os_cpu/linux_aarch64/vm/os_linux_aarch64.cpp
> >>>>>>>>>> No comments.
> >>>>>>>>>>
> >>>>>>>>>> src/os_cpu/linux_ppc/vm/os_linux_ppc.cpp
> >>>>>>>>>> L538: size_t
> >>>>>>>>>> os::Posix::_compiler_thread_min_stack_allowed =
> >>>>>>>>>> 384 * K;
> >>>>>>>>>> L539: size_t os::Posix::_java_thread_min_stack_allowed
> >>>>>>>>>> = 384
> >>>>>>>>>> * K;
> >>>>>>>>>>
> >>>>>>>>>> Same monster comment as
> >>>>>>>>>> src/os_cpu/aix_ppc/vm/os_aix_ppc.cpp
> >>>>>>>>>> and the same summary:
> >>>>>>>>>>
> >>>>>>>>>> - I understand bumping
> >>>>>>>>>> _compiler_thread_min_stack_allowed,
> >>>>>>>>>> but should it be solved in a different way?
> >>>>>>>>>> - I don't understand bumping
> >>>>>>>>>> _java_thread_min_stack_allowed
> >>>>>>>>>>
> >>>>>>>>>> src/os_cpu/linux_s390/vm/os_linux_s390.cpp
> >>>>>>>>>> L478: size_t
> >>>>>>>>>> os::Posix::_compiler_thread_min_stack_allowed =
> >>>>>>>>>> 128 * K;
> >>>>>>>>>> L479: size_t os::Posix::_java_thread_min_stack_allowed
> >>>>>>>>>> = 236
> >>>>>>>>>> * K;
> >>>>>>>>>> Bumping _java_thread_min_stack_allowed but not
> >>>>>>>>>> bumping
> >>>>>>>>>> _compiler_thread_min_stack_allowed. I'm confused
> >>>>>>>>>> here.
> >>>>>>>>> The numbers are what I need to startup on the machines. 128
> >>>>>>>>> is just
> >>>>>>>>> fine on the machines we have. (That's the problem of the
> >>>>>>>>> current setup: you have to tune this compile time constant for
> >>>>>>>>> the
> >>>>>>>>> page size of the machine you are running on. But let's discuss
> >>>>>>>>> this
> >>>>>>>>> in the follow up change.)
> >>>>>>>> OK about discussing this with a follow-up change. I guess I see
> >>>>>>>> the compile time initialization as a "minimum setting assuming the
> >>>>>>>> smallest page size". If we discover (at runtime) that the page
> >>>>>>>> size is bigger, then we adjust the minimum that we need...
> >>>>>>>>
> >>>>>>>> Again, defer to another bug. Do we have a bug ID yet?
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>> src/os_cpu/linux_sparc/vm/os_linux_sparc.cpp
> >>>>>>>>>> No comments.
> >>>>>>>>>>
> >>>>>>>>>> src/os_cpu/linux_x86/vm/os_linux_x86.cpp
> >>>>>>>>>> No comments.
> >>>>>>>>>>
> >>>>>>>>>> src/os_cpu/linux_zero/vm/os_linux_zero.cpp
> >>>>>>>>>> No comments.
> >>>>>>>>>>
> >>>>>>>>>> Sorry it took me so long to write this up...
> >>>>>>>>> No matter, thanks for this thorough review!
> >>>>>>>> You are very welcome. Thanks for being willing to dive into such
> >>>>>>>> a complicated area (thread stack sizes)...
> >>>>>>>>
> >>>>>>>> Dan
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>> Best regards,
> >>>>>>>>> Goetz.
> >>>>>>>>>
> >>>>>>>>>> Dan
> >>>>>>>>>>
> >>>>>>>>>>> The change affecting the compier threads is in os_linux.cpp,
> >>>>>>>>>> default_guard_size(),
> >>>>>>>>>>> where '|| thr_type == compiler_thread' has been added. The
> >>>>>>>>>>> function
> >>>>>>>>>>> was also moved from the os_cpu files, as it's identical on
> >>>>>>>>>>> all cpus.
> >>>>>>>>>>>
> >>>>>>>>>>> Best regards,
> >>>>>>>>>>> Goetz.
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>> -----Original Message-----
> >>>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com]
> >>>>>>>>>>>> Sent: Montag, 28. November 2016 00:25
> >>>>>>>>>>>> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>;
> >>>>>>>>>>>> 'daniel.daugherty at oracle.com'
> <daniel.daugherty at oracle.com>;
> >>>>>>>> 'hotspot-
> >>>>>>>>>>>> runtime-dev at openjdk.java.net' <hotspot-runtime-
> >>>>> dev at openjdk.java.net>
> >>>>>>>>>>>> Subject: Re: RFR(M): 8169373: Work around linux NPTL stack
> >>>>>>>>>>>> guard
> >>>>>>>>>>>> error.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Hi Goetz,
> >>>>>>>>>>>>
> >>>>>>>>>>>> On 24/11/2016 10:15 PM, Lindenmaier, Goetz wrote:
> >>>>>>>>>>>>> Hi,
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> I now edited the stuff I had proposed below:
> >>>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8169373-ppc-
> >>>>>>>> stackFix/webrev.03/
> >>>>>>>>>>>>> This includes
> >>>>>>>>>>>>> - the NPTL fix from webrev.02
> >>>>>>>>>>>> Okay in principle. As discussed this only impacts
> >>>>>>>>>>>> non-JavaThreads
> >>>>>>>>>>>> so the
> >>>>>>>>>>>> change should be minimal.
> >>>>>>>>>>>>
> >>>>>>>>>>>>> - merging code on linux
> >>>>>>>>>>>> Went a bit further than I had expected but if this truly
> >>>>>>>>>>>> isn't CPU
> >>>>>>>>>>>> dependent code then great!
> >>>>>>>>>>>>
> >>>>>>>>>>>>> - not adding OS guard to compiler threads.
> >>>>>>>>>>>> Okay in principle. IIUC we will now save the OS guard page
> for
> >>>>>>>>>>>> compiler
> >>>>>>>>>>>> thread stacks. Is that the only impact? The
> >>>>>>>>>>>> hotspot-compiler-dev
> >>>>>>>>>>>> folk
> >>>>>>>>>>>> may want to sign off on this part.
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> A few minor comments:
> >>>>>>>>>>>>
> >>>>>>>>>>>> src/os/linux/vm/os_linux.cpp
> >>>>>>>>>>>>
> >>>>>>>>>>>> 2854 return ((thr_type == java_thread || thr_type ==
> >>>>>>>>>>>> os::compiler_thread) ...
> >>>>>>>>>>>>
> >>>>>>>>>>>> os:: should be used for both types or none.
> >>>>>>>>>>>>
> >>>>>>>>>>>> 6153 pthread_attr_getguardsize(&attr, &guard_size);
> >>>>>>>>>>>>
> >>>>>>>>>>>> Can you at least verify a zero return code in an
> >>>>>>>>>>>> assert/assert_status
> >>>>>>>>>>>> please.
> >>>>>>>>>>>>
> >>>>>>>>>>>> ---
> >>>>>>>>>>>>
> >>>>>>>>>>>> src/os_cpu/aix_ppc/vm/os_aix_ppc.cpp
> >>>>>>>>>>>> src/os_cpu/linux_ppc/vm/os_linux_ppc.cpp
> >>>>>>>>>>>> src/os_cpu/linux_s390/vm/os_linux_s390.cpp
> >>>>>>>>>>>>
> >>>>>>>>>>>> Are the changes to min_stack_allowed just fixing an
> >>>>>>>>>>>> existing bug?
> >>>>>>>>>>>>
> >>>>>>>>>>>> ---
> >>>>>>>>>>>>
> >>>>>>>>>>>> Thanks,
> >>>>>>>>>>>> David
> >>>>>>>>>>>> -----
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>> I think this should be pushed for this bug ID. For the other
> >>>>>>>>>>>>> changes I'll
> >>>>>>>>>>>>> make another bug.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Best regards,
> >>>>>>>>>>>>> Goetz.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> -----Original Message-----
> >>>>>>>>>>>>>> From: Lindenmaier, Goetz
> >>>>>>>>>>>>>> Sent: Wednesday, November 23, 2016 8:11 AM
> >>>>>>>>>>>>>> To: David Holmes <david.holmes at oracle.com>;
> >>>>>>>>>>>>>> daniel.daugherty at oracle.com; hotspot-runtime-
> >>>>> dev at openjdk.java.net
> >>>>>>>>>>>>>> Subject: RE: RFR(M): 8169373: Work around linux NPTL
> >>>>>>>>>>>>>> stack guard
> >>>>>>>> error.
> >>>>>>>>>>>>>> Hi,
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Bzzzt! Sorry Goetz and Dan but that is no longer correct
> >>>>>>>>>>>>>>> with
> >>>>>>>>>>>>>>> JVMCI.
> >>>>>>>> The
> >>>>>>>>>>>>>>> ability for a CompilerThread to execute Java code
> >>>>>>>>>>>>>>> (can_call_java()) is
> >>>>>>>>>>>>>>> now a dynamic property depending on whether the
> current
> >>>>> compiler
> >>>>>>>> is
> >>>>>>>>>> the
> >>>>>>>>>>>>>>> JVMCI compiler.
> >>>>>>>>>>>>>> Ah, then I should also leave space for shadow pages in
> >>>>>>>>>>>>>> the minimal
> >>>>>>>> stack
> >>>>>>>>>>>> size
> >>>>>>>>>>>>>> of comiler threads.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Do we agree on the cleanup and on leaving out the OS
> >>>>>>>>>>>>>> guard page
> >>>>> on
> >>>>>>>>>>>>>> compiler threads?
> >>>>>>>>>>>>>> Then I would edit a change comprising the NPTL
> workaround
> >>>>>>>>>>>>>> and
> >>>>>>>>>>>>>> these
> >>>>>>>>>>>>>> additional changes, and split the other issue into a new
> >>>>>>>>>>>>>> bug?
> >>>>>>>>>>>>>> I think this
> >>>>>>>>>>>>>> will easy the reviewing.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Best regards,
> >>>>>>>>>>>>>> Goetz.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> -----Original Message-----
> >>>>>>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com]
> >>>>>>>>>>>>>>> Sent: Mittwoch, 23. November 2016 02:50
> >>>>>>>>>>>>>>> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>;
> >>>>>>>>>>>>>>> daniel.daugherty at oracle.com; hotspot-runtime-
> >>>>> dev at openjdk.java.net
> >>>>>>>>>>>>>>> Subject: Re: RFR(M): 8169373: Work around linux NPTL
> stack
> >>>>> guard
> >>>>>>>>>> error.
> >>>>>>>>>>>>>>> On 22/11/2016 11:19 PM, Lindenmaier, Goetz wrote:
> >>>>>>>>>>>>>>>> Hi Dan,
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> -----Original Message-----
> >>>>>>>>>>>>>>>>> From: Daniel D. Daugherty
> >>>>> [mailto:daniel.daugherty at oracle.com]
> >>>>>>>>>>>>>>>>> Sent: Dienstag, 22. November 2016 14:01
> >>>>>>>>>>>>>>>>> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>;
> David
> >>>>>>>> Holmes
> >>>>>>>>>>>>>>>>> <david.holmes at oracle.com>; hotspot-runtime-
> >>>>>>>> dev at openjdk.java.net
> >>>>>>>>>>>>>>>>> Subject: Re: RFR(M): 8169373: Work around linux NPTL
> >>>>>>>>>>>>>>>>> stack
> >>>>>>>>>>>>>>>>> guard
> >>>>>>>>>>>>>> error.
> >>>>>>>>>>>>>>>>> On 11/22/16 3:55 AM, Lindenmaier, Goetz wrote:
> >>>>>>>>>>>>>>>>>> Hi Dan,
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> I ran into a row of issues, some errors on the
> >>>>>>>>>>>>>>>>>> platforms.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> What I meant with that comment is that
> >>>>>>>>>>>>>>>>>> os::Linux::min_stack_allowed =
> >>>>>>>> MAX2(os::Linux::min_stack_allowed,
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> JavaThread::stack_guard_zone_size() +
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> JavaThread::stack_shadow_zone_size() +
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> (4*BytesPerWord
> >>>>>>>>>> COMPILER2_PRESENT(+2)) *
> >>>>>>>>>>>> 4
> >>>>>>>>>>>>>> *
> >>>>>>>>>>>>>>> K);
> >>>>>>>>>>>>>>>>>> was executed, and min_stack_allowed used for all
> >>>>>>>>>>>>>>>>>> stacks. Now,
> >>>>>>>>>>>>>> compiler
> >>>>>>>>>>>>>>>>> and
> >>>>>>>>>>>>>>>>>> vm minimum stack sizes are not increased by these
> sizes.
> >>>>>>>>>>>>>>>>> Now I see what you mean. Thanks for clearing this up.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> I should have remembered that part of the change
> >>>>>>>>>>>>>>>>> because we
> >>>>>>>> went
> >>>>>>>>>>>>>> back
> >>>>>>>>>>>>>>>>> and forth about removing the red/yellow zone pages
> >>>>>>>>>>>>>>>>> from the
> >>>>>>>>>>>>>>>>> other
> >>>>>>>>>>>>>>>>> threads. In particular, we discussed the compiler thread
> >>>>>>>>>>>>>>>>> because it
> >>>>>>>>>>>>>>>>> is-a JavaThread. Our conclusion was that a compiler
> >>>>>>>>>>>>>>>>> thread
> >>>>>>>>>>>>>>>>> doesn't
> >>>>>>>>>>>>>>>>> execute Java bytecode so we could remove the
> red/yellow
> >>>>>>>>>>>>>>>>> pages...
> >>>>>>>>>>>>>>>> Yes, it does not execute java byte code.
> >>>>>>>>>>>>>>> Bzzzt! Sorry Goetz and Dan but that is no longer correct
> >>>>>>>>>>>>>>> with
> >>>>>>>>>>>>>>> JVMCI.
> >>>>>>>> The
> >>>>>>>>>>>>>>> ability for a CompilerThread to execute Java code
> >>>>>>>>>>>>>>> (can_call_java()) is
> >>>>>>>>>>>>>>> now a dynamic property depending on whether the
> current
> >>>>> compiler
> >>>>>>>> is
> >>>>>>>>>> the
> >>>>>>>>>>>>>>> JVMCI compiler.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> David
> >>>>>>>>>>>>>>> -----
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Therefore you can remove the shadow pages. There is
> no
> >>>>>>>>>>>>>>>> code
> >>>>>>>>>>>>>>>> that
> >>>>>>>>>>>>>>>> will bang.
> >>>>>>>>>>>>>>>> But red/yellow pages are protected right during thread
> >>>>>>>>>>>>>>>> startup.
> >>>>>>>>>>>>>>>> Therefore you must have enough space for them.
> >>>>>>>>>>>>>>>> On ppc, we try to protect three 64K pages out of the
> 128K
> >>>>>>>>>>>>>>>> compiler
> >>>>>>>>>> stack.
> >>>>>>>>>>>>>>>> That obviously fails.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Therefore I propose:
> >>>>>>>>>>>>>>>> size_t
> >>>>>>>>>>>>>>>> os::Posix::_java_thread_min_stack_allowed = 48
> >>>>>>>>>>>>>>>> * K; //
> >>>>>>>> Set
> >>>>>>>>>>>>>>> platform dependent.
> >>>>>>>>>>>>>>>> in os::Posix::set_minimum_stack_sizes():
> >>>>>>>>>>>>>>>> _java_thread_min_stack_allowed =
> >>>>>>>> _java_thread_min_stack_allowed
> >>>>>>>>>> +
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> JavaThread::stack_guard_zone_size() +
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> JavaThread::stack_shadow_zone_size();
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> (Similar for _compiler_thread_min_stack_allowed).
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> The minimal stack size is made up of three components:
> >>>>>>>>>>>>>>>> 1. Sizes of interpreter/C1/C2 frames. Depends on
> >>>>>>>>>>>>>>>> HotSpot
> >>>>>>>>>>>>>>> implementation/platform/os.
> >>>>>>>>>>>>>>>> 2. Sizes of C++ frames: depends on C++ compiler.
> >>>>>>>>>>>>>>>> These are fixed at compile time.
> >>>>>>>>>>>>>>>> 3. Sizes of red/yellow/reserved/shadow pages.
> >>>>>>>>>>>>>>>> Depends
> >>>>>>>>>>>>>>>> on the
> >>>>>>>>>> system
> >>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>> VM is used on. This is not fixed at compile
> >>>>>>>>>>>>>>>> time.
> >>>>>>>>>>>>>>>> (Our ppc
> >>>>>>>>>> machines
> >>>>>>>>>>>>>>> differ
> >>>>>>>>>>>>>>>> in page size.)
> >>>>>>>>>>>>>>>> Therefore 3. should not be included in a compile time
> >>>>>>>>>>>>>>>> constant.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> And that decision allowed us to be exposed to the 64K
> >>>>>>>>>>>>>>>>> page
> >>>>>>>>>>>>>>>>> issue
> >>>>>>>>>>>>>>>>> because the "extra" space isn't there anymore.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> At least the _compiler_thread_min_stack_allowed
> >>>>>>>>>>>>>>>>>> should be
> >>>>>>>>>> increased
> >>>>>>>>>>>>>>>>>> similarly by red/yellow zone size. The compiler
> >>>>>>>>>>>>>>>>>> thread is
> >>>>>>>>>>>>>>>>>> a Java
> >>>>>>>>>>>>>>>>>> thread and must have space for these zones.
> >>>>>>>>>>>>>>>>> I'm not sure that I completely agree (yet). To me, the
> >>>>>>>>>>>>>>>>> red/yellow
> >>>>>>>>>>>>>>>>> pages are there for Java thread stack overflow
> semantics.
> >>>>>>>>>>>>>>>>> Yes, the
> >>>>>>>>>>>>>>>>> compiler thread needs extra space when 64K pages are
> >>>>>>>>>>>>>>>>> used,
> >>>>>>>>>>>>>>>>> but I
> >>>>>>>>>>>>>>>>> would prefer that we add that space via a different
> >>>>>>>>>>>>>>>>> calculation.
> >>>>>>>>>>>>>>>> Yes they are. But compiler threads happen tob e a
> >>>>>>>>>>>>>>>> subclass of
> >>>>>>>>>>>>>>>> Java threads and use the same run() method that puts
> >>>>>>>>>>>>>>>> the pages
> >>>>>>>>>>>>>>>> There.
> >>>>>>>>>>>>>>>> I agree that they are not needed for Compiler threads,
> >>>>>>>>>>>>>>>> nor for
> >>>>>>>>>>>>>>>> CodeCacheSweeperThreads. I don't really now about
> >>>>>>>>>>>>>>>> JvmtiAgentThreads and ServiceThreads, but all of
> >>>>>>>>>>>>>>>> the get
> >>>>>>>>>>>>>>>> the guard
> >>>>>>>>>>>>>> pages
> >>>>>>>>>>>>>>>> because they are derived from JavaThread.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> To put it another way, I'd like to see us add extra
> >>>>>>>>>>>>>>>>> space to
> >>>>>>>>>>>>>>>>> solve
> >>>>>>>>>>>>>>>>> the 64K page issue directly instead of as a side
> >>>>>>>>>>>>>>>>> effect of the
> >>>>>>>>>>>>>>>>> red/yellow page addition.
> >>>>>>>>>>>>>>>> I don't understand. What do you mean by 'directly'?
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Also, the change added a test that is failing now.
> >>>>>>>>>>>>>>>>> And that's a "good thing" (TM), right? :-)
> >>>>>>>>>>>>>>>> Yes, it showed a bug and thus raised the need to fix
> >>>>>>>>>>>>>>>> it! :)
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Best regards,
> >>>>>>>>>>>>>>>> Goetz.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Again, thanks for clarifying 8140520's role in this
> >>>>>>>>>>>>>>>>> issue.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Dan
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Best regards,
> >>>>>>>>>>>>>>>>>> Goetz.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> -----Original Message-----
> >>>>>>>>>>>>>>>>>>> From: Daniel D. Daugherty
> >>>>>>>> [mailto:daniel.daugherty at oracle.com]
> >>>>>>>>>>>>>>>>>>> Sent: Montag, 21. November 2016 17:28
> >>>>>>>>>>>>>>>>>>> To: David Holmes <david.holmes at oracle.com>;
> >>>>>>>>>>>>>>>>>>> Lindenmaier,
> >>>>>>>> Goetz
> >>>>>>>>>>>>>>>>>>> <goetz.lindenmaier at sap.com>; hotspot-runtime-
> >>>>>>>>>>>>>>> dev at openjdk.java.net
> >>>>>>>>>>>>>>>>>>> Subject: Re: RFR(M): 8169373: Work around linux
> NPTL
> >>>>>>>>>>>>>>>>>>> stack
> >>>>>>>> guard
> >>>>>>>>>>>>>>> error.
> >>>>>>>>>>>>>>>>>>> Sorry for the delayed responses to this thread. I've
> >>>>>>>>>>>>>>>>>>> been on
> >>>>>>>>>> vacation...
> >>>>>>>>>>>>>>>>>>> One comment/query embedded below...
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> On 11/10/16 8:40 PM, David Holmes wrote:
> >>>>>>>>>>>>>>>>>>>> Hi Goetz,
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> On 11/11/2016 8:00 AM, Lindenmaier, Goetz wrote:
> >>>>>>>>>>>>>>>>>>>>> Hi David,
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> This issue is different to 6675312, see also my
> >>>>>>>>>>>>>>>>>>>>> comment
> >>>>>>>>>>>>>>>>>>>>> in the
> >>>>>>>>>> bug.
> >>>>>>>>>>>>>>>>>>>>> It appears running jtreg test
> >>>>>>>>>>>>>>> runtime/Thread/TooSmallStackSize.java,
> >>>>>>>>>>>>>>>>>>>>> with my patch below you can reproduce it on
> >>>>>>>>>>>>>>>>>>>>> linuxx86_64.
> >>>>>>>>>>>>>>>>>>>>> You
> >>>>>>>>>> can
> >>>>>>>>>>>>>>> not
> >>>>>>>>>>>>>>>>>>>>> do that with 6675312. Also, I would assume there
> are
> >>>>>>>>>>>>>>>>>>>>> systems
> >>>>>>>> out
> >>>>>>>>>>>>>>> there
> >>>>>>>>>>>>>>>>>>>>> on x86 that uses 64-K pages, did you run the tests
> on
> >>>>>>>>>>>>>>>>>>>>> these? I
> >>>>>>>>>>>>>> would
> >>>>>>>>>>>>>>>>>>>>> assume you get hard crashes with stack overflows
> >>>>>>>>>>>>>>>>>>>>> in the
> >>>>>>>>>>>>>>>>>>>>> first
> >>>>>>>> C2
> >>>>>>>>>>>>>>>>>>>>> compilation if there is only 64K usable
> >>>>>>>>>>>>>>>>>>>>> CompilerThreadStack.
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> My fix does not affect Java threads, which are the
> >>>>>>>>>>>>>>>>>>>>> largest
> >>>>>>>> amount
> >>>>>>>>>>>>>>>>>>>>> of threads used by the VM. It affects only the
> >>>>>>>>>>>>>>>>>>>>> non-Java
> >>>>>>>>>>>>>>>>>>>>> threads.
> >>>>>>>>>>>>>>>>>>>>> It adds one page to these threads. The page does
> not
> >>>>>>>>>>>>>>>>>>>>> require
> >>>>>>>>>>>>>>> memory,
> >>>>>>>>>>>>>>>>>>>>> as it's protected. The stack will only require more
> >>>>>>>>>>>>>>>>>>>>> space if the
> >>>>>>>>>>>>>> thread
> >>>>>>>>>>>>>>>>>>>>> ran into a stack overflow before the fix as else the
> >>>>>>>>>>>>>>>>>>>>> pages are
> >>>>>>>> not
> >>>>>>>>>>>>>>>>>>>>> mapped.
> >>>>>>>>>>>>>>>>>>>>> This are stack overflows that cause hard crashes,
> at
> >>>>>>>>>>>>>>>>>>>>> least on
> >>>>>>>> ppc
> >>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>> VM
> >>>>>>>>>>>>>>>>>>>>> does not properly catch these stack overflows, so
> >>>>>>>>>>>>>>>>>>>>> any setup
> >>>>>>>>>>>>>> working
> >>>>>>>>>>>>>>>>> now
> >>>>>>>>>>>>>>>>>>>>> will not run into the additional space. Altogether
> >>>>>>>>>>>>>>>>>>>>> there
> >>>>>>>>>>>>>>>>>>>>> should
> >>>>>>>> be
> >>>>>>>>>>>>>> no
> >>>>>>>>>>>>>>>>>>>>> effect on running systems besides requiring one
> more
> >>>>>>>>>>>>>>>>>>>>> entry in
> >>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>>>> page table per non-Java thread.
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> The problem is caused by a rather recent change
> >>>>> (8140520:
> >>>>>>>>>>>>>> segfault
> >>>>>>>>>>>>>>> on
> >>>>>>>>>>>>>>>>>>>>> solaris-amd64
> >>>>>>>>>>>>>>>>>>>>> with "-XX:VMThreadStackSize=1" option) which
> was
> >>>>>>>>>>>>>>>>>>>>> pushed
> >>>>>>>> after
> >>>>>>>>>>>>>>>>>>>>> feature-close. As this was a rather recent change,
> it
> >>>>>>>>>>>>>>>>>>>>> must be
> >>>>>>>>>>>>>>>>>>>>> possible to
> >>>>>>>>>>>>>>>>>>>>> fix this follow up issue. What else is this period in
> >>>>>>>>>>>>>>>>>>>>> the project
> >>>>>>>>>> good
> >>>>>>>>>>>>>>>>>>>>> for if not fixing issues?
> >>>>>>>>>>>>>>>>>>>> So I am seeing a number of factors here.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> First, 8140520, set:
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> size_t
> >>>>>>>>>>>>>>>>>>>> os::Posix::_compiler_thread_min_stack_allowed =
> 128
> >>>>> *
> >>>>>>>> K;
> >>>>>>>>>>>>>>>>>>> So I'm confused by the above comment:
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> > The problem is caused by a rather recent change
> >>>>>>>>>>>>>>>>>>> (8140520:
> >>>>>>>>>>>>>> segfault
> >>>>>>>>>>>>>>>>>>> > on solaris-amd64 with "-XX:VMThreadStackSize=1"
> >>>>>>>>>>>>>>>>>>> option)
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~dcubed/8140520-
> webrev/5-jdk9-
> >>>>>>>>>>>>>>>>>>>
> >>>>> hs-
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>
> open/hotspot/src/os_cpu/linux_ppc/vm/os_linux_ppc.cpp.frames.html
> >>>>>>>>>>>>>>>>>>> shows this change:
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> @@ -531,19 +531,17 @@
> >>>>>>>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>
> //////////////////////////////////////////////////////////////////////////////
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>>>>>>>>>>> //
> >>>>>>>>>>>>>>>>>>> // thread stack
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> -size_t os::Linux::min_stack_allowed = 128*K;
> >>>>>>>>>>>>>>>>>>> +size_t
> >>>>>>>>>>>>>>>>>>> os::Posix::_compiler_thread_min_stack_allowed =
> 128
> >>>>> *
> >>>>>>>> K;
> >>>>>>>>>>>>>>>>>>> +size_t os::Posix::_java_thread_min_stack_allowed
> =
> >>>>>>>>>>>>>>>>>>> 128 * K;
> >>>>>>>>>>>>>>>>>>> +size_t
> >>>>>>>>>>>>>>>>>>> os::Posix::_vm_internal_thread_min_stack_allowed
> =
> >>>>>>>>>>>>>>>>>>> 128
> >>>>>>>> *
> >>>>>>>>>> K;
> >>>>>>>>>>>>>>>>>>> so the existing single variable of
> >>>>>>>>>>>>>>>>>>> 'min_stack_allowed' was
> >>>>>>>>>>>>>>>>>>> replaced by three variables:
> >>>>>>>> _compiler_thread_min_stack_allowed,
> >>>>>>>>>>>>>>>>>>> _java_thread_min_stack_allowed, and
> >>>>>>>>>>>>>>>>>>> _vm_internal_thread_min_stack_allowed.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> The old single variable and the three new variables
> >>>>>>>>>>>>>>>>>>> are all
> >>>>>>>>>>>>>>>>>>> initialized to the same value (128K) so the fix for
> >>>>>>>>>>>>>>>>>>> 8140520
> >>>>>>>>>>>>>>>>>>> did not change stack sizes for this platform. In
> >>>>>>>>>>>>>>>>>>> fact, only
> >>>>>>>>>>>>>>>>>>> one platform had a size change (Solaris X64).
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> So I'm confused about how the fix for 8140520
> caused
> >>>>>>>>>>>>>>>>>>> this
> >>>>>>>> problem.
> >>>>>>>>>>>>>>>>>>> Based on David's analysis below, it looks to me like
> >>>>>>>>>>>>>>>>>>> this
> >>>>>>>>>>>>>>>>>>> 64K stack
> >>>>>>>>>>>>>>>>>>> guard page problem should also exist prior to the
> >>>>>>>>>>>>>>>>>>> fix for
> >>>>>>>> 8140520.
> >>>>>>>>>>>>>>>>>>> Goetz, can you please explain how 8140520 caused
> this
> >>>>>>>>>>>>>>>>>>> problem?
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> Dan
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> Second on linux PPC it is hardwired to use 2 guard
> >>>>>>>>>>>>>>>>>>>> pages:
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> return 2 * page_size();
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> Third, you had a pagesize of 64K.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> Fourth, NPTL takes the guard space from the stack
> >>>>>>>>>>>>>>>>>>>> space -
> >>>>>>>> hence
> >>>>>>>>>>>>>> with
> >>>>>>>>>>>>>>> 2
> >>>>>>>>>>>>>>>>>>>> x 64K guard, and a 128K stack it was all consumed.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> ---
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> In the proposed changes you now only use
> >>>>>>>>>>>>>>>>>>>> page_size() for
> >>>>> the
> >>>>>>>>>> guard,
> >>>>>>>>>>>>>>> so
> >>>>>>>>>>>>>>>>>>>> that alone would have fixed the observed problem.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> But in addition you want to address the NPTL
> >>>>>>>>>>>>>>>>>>>> problem by
> >>>>>>>>>>>>>>>>>>>> adding
> >>>>>>>>>>>>>> back
> >>>>>>>>>>>>>>>>>>>> the guard space to the stack size requested. That
> >>>>>>>>>>>>>>>>>>>> alone
> >>>>>>>>>>>>>>>>>>>> would
> >>>>>>>> also
> >>>>>>>>>>>>>>>>>>>> have fixed the observed problem. :)
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> But in addition you have increased the minimum
> >>>>>>>>>>>>>>>>>>>> stack size:
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> ! size_t
> >>>>>>>>>>>>>>>>>>>> os::Posix::_compiler_thread_min_stack_allowed =
> >>>>>>>>>>>>>>>>>>>> 192 *
> >>>>>>>> K;
> >>>>>>>>>>>>>>>>>>>> which again, on its own would have fixed the
> original
> >>>>>>>>>>>>>>>>>>>> problem.
> >>>>>>>> :)
> >>>>>>>>>>>>>>>>>>>> Did you really intend to increase the real minimum
> >>>>>>>>>>>>>>>>>>>> stack
> >>>>>>>>>>>>>>>>>>>> from
> >>>>>>>>>> 128K
> >>>>>>>>>>>>>> to
> >>>>>>>>>>>>>>>>>>>> 256K ? (on a 64K page system)
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> ---
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> Focusing simply on the shared code change to
> adjust
> >>>>>>>>>>>>>>>>>>>> the
> >>>>>>>> requested
> >>>>>>>>>>>>>>>>>>>> stacksize by the amount of guard space (if any), this
> >>>>>>>>>>>>>>>>>>>> does not
> >>>>>>>> seem
> >>>>>>>>>>>>>>>>>>>> unreasonable. As you note it is restricted to
> >>>>>>>>>>>>>>>>>>>> non-JavaThreads
> >>>>>>>> and
> >>>>>>>>>>>>>> only
> >>>>>>>>>>>>>>>>>>>> adds a page to reserved stack space.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> My only query now is whether the minimum
> stacksize
> >>>>> detection
> >>>>>>>>>> logic
> >>>>>>>>>>>>>>>>>>>> will correctly report the real minimum stack size
> >>>>>>>>>>>>>>>>>>>> (taking
> >>>>>>>>>>>>>>>>>>>> into
> >>>>>>>>>> account
> >>>>>>>>>>>>>>>>>>>> the need for the guard page) ?
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> Thanks,
> >>>>>>>>>>>>>>>>>>>> David
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> So I really think this issue should be fixed.
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> Best regards,
> >>>>>>>>>>>>>>>>>>>>> Goetz.
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> -----Original Message-----
> >>>>>>>>>>>>>>>>>>>>>> From: David Holmes
> [mailto:david.holmes at oracle.com]
> >>>>>>>>>>>>>>>>>>>>>> Sent: Thursday, November 10, 2016 10:02 PM
> >>>>>>>>>>>>>>>>>>>>>> To: Lindenmaier, Goetz
> <goetz.lindenmaier at sap.com>;
> >>>>>>>> hotspot-
> >>>>>>>>>>>>>>>>>>> runtime-
> >>>>>>>>>>>>>>>>>>>>>> dev at openjdk.java.net
> >>>>>>>>>>>>>>>>>>>>>> Subject: Re: RFR(M): 8169373: Work around linux
> NPTL
> >>>>> stack
> >>>>>>>>>>>>>> guard
> >>>>>>>>>>>>>>>>> error.
> >>>>>>>>>>>>>>>>>>>>>> Hi Goetz,
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> As per the bug report, this issue was already
> known
> >>>>>>>> (6675312)
> >>>>>>>>>> and
> >>>>>>>>>>>>>>> we
> >>>>>>>>>>>>>>>>>>>>>> chose not to try and address it due to no
> reported
> >>>>>>>>>>>>>>>>>>>>>> issues at
> >>>>>>>> the
> >>>>>>>>>>>>>>> time.
> >>>>>>>>>>>>>>>>>>>>>> While I see that you have encountered an issue
> >>>>>>>>>>>>>>>>>>>>>> (is it
> >>>>>>>>>>>>>>>>>>>>>> real or
> >>>>>>>>>>>>>>>>>>>>>> fabricated?) I think this change is too intrusive
> >>>>>>>>>>>>>>>>>>>>>> to be
> >>>>>>>>>>>>>>>>>>>>>> applied
> >>>>>>>> at
> >>>>>>>>>> this
> >>>>>>>>>>>>>>>>>>>>>> stage of the JDK 9 release cycle, as it will
> >>>>>>>>>>>>>>>>>>>>>> change the
> >>>>>>>>>>>>>>>>>>>>>> stack
> >>>>>>>>>>>>>>>>>>>>>> requirements of every application running on
> Linux.
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> Thanks,
> >>>>>>>>>>>>>>>>>>>>>> David
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> On 11/11/2016 1:58 AM, Lindenmaier, Goetz
> wrote:
> >>>>>>>>>>>>>>>>>>>>>>> Hi,
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> Please review this change. I please need a
> sponsor:
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> http://cr.openjdk.java.net/~goetz/wr16/8169373-ppc-
> >>>>>>>>>>>>>>>>>>> stackFix/webrev.01/
> >>>>>>>>>>>>>>>>>>>>>>> In the Linux NPTL pthread implementation the
> >>>>>>>>>>>>>>>>>>>>>>> guard size
> >>>>>>>>>>>>>>> mechanism
> >>>>>>>>>>>>>>>>>>>>>>> is not
> >>>>>>>>>>>>>>>>>>>>>>> implemented properly. The posix standard
> >>>>>>>>>>>>>>>>>>>>>>> requires to
> >>>>> add
> >>>>>>>> the
> >>>>>>>>>>>>>>> size
> >>>>>>>>>>>>>>>>>>>>>>> of the
> >>>>>>>>>>>>>>>>>>>>>>> guard pages to the stack size, instead Linux
> >>>>>>>>>>>>>>>>>>>>>>> takes the
> >>>>>>>>>>>>>>>>>>>>>>> space
> >>>>>>>> out
> >>>>>>>>>>>>>> of
> >>>>>>>>>>>>>>>>>>>>>>> 'stacksize'.
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> The Posix standard
> >>>>>>>>>>>>>>>>>>> http://pubs.opengroup.org/onlinepubs/9699919799/
> >>>>>>>>>>>>>>>>>>>>>>> says "the implementation allocates extra
> memory
> >>>>>>>>>>>>>>>>>>>>>>> at the
> >>>>>>>>>>>>>>> overflow
> >>>>>>>>>>>>>>>>>>>>>>> end of
> >>>>>>>>>>>>>>>>>>>>>>> the stack". The linux man page
> >>>>>>>>>>>>>>>>>>>>>>>
> https://linux.die.net/man/3/pthread_attr_setguardsize
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> says
> >>>>>>>> "As
> >>>>>>>>>>>>>>> at
> >>>>>>>>>>>>>>>>>>>>>>> glibc
> >>>>>>>>>>>>>>>>>>>>>>> 2.8, the NPTL threading implementation
> includes the
> >>>>> guard
> >>>>>>>>>> area
> >>>>>>>>>>>>>>>>> within
> >>>>>>>>>>>>>>>>>>>>>>> the stack size allocation, rather than allocating
> >>>>>>>>>>>>>>>>>>>>>>> extra space
> >>>>>>>> at
> >>>>>>>>>>>>>>>>>>>>>>> the end
> >>>>>>>>>>>>>>>>>>>>>>> of the stack, as POSIX.1 requires".
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> I encounter this problem in
> >>>>>>>>>>>>>>> runtime/Thread/TooSmallStackSize.java
> >>>>>>>>>>>>>>>>>>>>>>> on ppc
> >>>>>>>>>>>>>>>>>>>>>>> with 64K pages.
> >>>>>>>>>>>>>>>>>>>>>>> _compiler_thread_min_stack_allowed is
> >>>>>>>> 128K
> >>>>>>>>>>>>>> on
> >>>>>>>>>>>>>>>>> ppc,
> >>>>>>>>>>>>>>>>>>> and
> >>>>>>>>>>>>>>>>>>>>>>> ppc specifies two OS guard pages. The VM
> crashes in
> >>>>>>>> pthread
> >>>>>>>>>>>>>>>>> creation
> >>>>>>>>>>>>>>>>>>>>>>> because there is no usable space in the thread
> >>>>>>>>>>>>>>>>>>>>>>> stack
> >>>>>>>>>>>>>>>>>>>>>>> after
> >>>>>>>>>>>>>>> allocating
> >>>>>>>>>>>>>>>>>>>>>>> the guard pages.
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> But TooSmallStackSize.java requires that the
> VM
> >>>>>>>>>>>>>>>>>>>>>>> comes
> >>>>> up
> >>>>>>>>>> with
> >>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>>>>>> stack
> >>>>>>>>>>>>>>>>>>>>>>> size mentioned in the error message.
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> This fix adapts the requested stack size on
> >>>>>>>>>>>>>>>>>>>>>>> Linux by
> >>>>>>>>>>>>>>>>>>>>>>> the size
> >>>>>>>> of
> >>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>>>>>> guard pages to mimick proper behaviour, see
> >>>>>>>>>>>>>>>>>>>>>>> change to
> >>>>>>>>>>>>>>>>> os_linux.cpp.
> >>>>>>>>>>>>>>>>>>>>>>> The change also streamlines usage of
> >>>>>>>>>>>>>>>>>>>>>>> stack_guard_page
> >>>>> on
> >>>>>>>>>>>>>>> linuxppc,
> >>>>>>>>>>>>>>>>>>>>>>> linuxppcle, aixppc and linuxs390.
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> To reproduce the error on linux_x86_64, apply
> below
> >>>>> patch
> >>>>>>>>>> and
> >>>>>>>>>>>>>>> call
> >>>>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>>>>>> VM with -XX:CompilerThreadStackSize=64.
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> I'm still exploring why I had to choose such big
> >>>>>>>>>>>>>>>>>>>>>>> compiler
> >>>>>>>> stacks
> >>>>>>>>>>>>>> on
> >>>>>>>>>>>>>>>>>>>>>>> ppc
> >>>>>>>>>>>>>>>>>>>>>>> to get -version passing, but I wanted to send
> >>>>>>>>>>>>>>>>>>>>>>> the RFR
> >>>>>>>>>>>>>>>>>>>>>>> now as
> >>>>>>>>>>>>>>> people
> >>>>>>>>>>>>>>>>>>>>>>> obviously looked at the bug I opened (Thanks
> >>>>>>>>>>>>>>>>>>>>>>> David!).
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> Best regards,
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> Goetz.
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> diff -r b7ae012c55c3
> >>>>>>>>>> src/os_cpu/linux_x86/vm/os_linux_x86.cpp
> >>>>>>>>>>>>>>>>>>>>>>> ---
> a/src/os_cpu/linux_x86/vm/os_linux_x86.cpp Mon
> >>>>> Nov
> >>>>>>>> 07
> >>>>>>>>>>>>>>>>> 12:37:28
> >>>>>>>>>>>>>>>>>>>>>> 2016
> >>>>>>>>>>>>>>>>>>>>>>> +0100
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> +++
> b/src/os_cpu/linux_x86/vm/os_linux_x86.cpp Thu
> >>>>> Nov
> >>>>>>>> 10
> >>>>>>>>>>>>>>>>>>> 16:52:17
> >>>>>>>>>>>>>>>>>>>>>> 2016
> >>>>>>>>>>>>>>>>>>>>>>> +0100
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> @@ -701,7 +701,7 @@
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> size_t
> os::Linux::default_guard_size(os::ThreadType
> >>>>>>>> thr_type) {
> >>>>>>>>>>>>>>>>>>>>>>> // Creating guard page is very expensive. Java
> >>>>>>>>>>>>>>>>>>>>>>> thread
> >>>>>>>> has
> >>>>>>>>>>>>>>> HotSpot
> >>>>>>>>>>>>>>>>>>>>>>> // guard page, only enable glibc guard page for
> >>>>>>>>>>>>>>>>>>>>>>> non-Java
> >>>>>>>>>>>>>>> threads.
> >>>>>>>>>>>>>>>>>>>>>>> - return (thr_type == java_thread ? 0 :
> >>>>>>>>>>>>>>>>>>>>>>> page_size());
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> + return (thr_type == java_thread ? 0 : 64*K);
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> // Java thread:
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>
> >>
> >>
> >
> >
More information about the hotspot-compiler-dev
mailing list