RFR(M): 8169373: Work around linux NPTL stack guard error.
Lindenmaier, Goetz
goetz.lindenmaier at sap.com
Tue Dec 13 16:24:37 UTC 2016
Hi,
I rebased 8169373 to the recent changes in hotspot:
http://cr.openjdk.java.net/~goetz/wr16/8169373-ppc-stackFix/webrev.09/
The patch is still in our test patch queue for the nightly tests, and there
were no failures I can attribute to this change.
Best regards,
Goetz.
> -----Original Message-----
> From: Daniel D. Daugherty [mailto:daniel.daugherty at oracle.com]
> Sent: Montag, 5. Dezember 2016 23:13
> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; David Holmes
> <david.holmes at oracle.com>; Vladimir Kozlov <vladimir.kozlov 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.
>
> On 12/5/16 3:09 PM, Lindenmaier, Goetz wrote:
> > Hi Dan,
> >
> > thanks for the testing! Sorry I can't help ...
>
> No worries. We'll get there...
>
> JPRT passed with the appropriate closed changes... Thanks to David H. for
> suggesting the changes to make. I've got an internal review thread going
> on that. I also kicked off a "full RBT" run which is the equivalent of a
> nightly test run.
>
> Dan
>
>
> >
> > Best regards,
> > Goetz.
> >
> >> -----Original Message-----
> >> From: Daniel D. Daugherty [mailto:daniel.daugherty at oracle.com]
> >> Sent: Monday, December 05, 2016 7:38 PM
> >> To: David Holmes <david.holmes at oracle.com>; Lindenmaier, Goetz
> >> <goetz.lindenmaier at sap.com>; Vladimir Kozlov
> >> <vladimir.kozlov 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.
> >>
> >> On 12/5/16 7:36 AM, Daniel D. Daugherty wrote:
> >>> On 12/4/16 2:57 PM, David Holmes wrote:
> >>>> On 4/12/2016 3:50 AM, Lindenmaier, Goetz wrote:
> >>>>> 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?
> >>>> It won't go away it will just move. Those files still need to be
> >>>> modified for the current changes.
> >>>>
> >>>> Dan: simply a matter of deleting os::Linux::default_guard_size,
> >>>> current_stack_region, os::current_stack_base, and
> >>>> os::current_stack_size from the os_linux_<arch>.cpp file.
> >>> I will be working on this AM (my TZ). Thanks for the info!
> >> Double checked the suggested changes against the JPRT build log failures.
> >> Made the suggested changes, double checked the deleted code against the
> >> new versions in src/os/linux/vm/os_linux.cpp, double checked these deletes
> >> against the deletes for the other platforms and just submitted a JPRT
> >> test job.
> >>
> >> This time I'll wait for a passing JPRT job before submitting RBT testing.
> >> Don't want to waste RBT test cycles (again...) :-)
> >>
> >> Dan
> >>
> >>
> >>
> >>> Dan
> >>>
> >>>
> >>>> Thanks,
> >>>> David
> >>>>
> >>>>> 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