RFR(M): 8169373: Work around linux NPTL stack guard error.
David Holmes
david.holmes at oracle.com
Sat Dec 3 00:51:19 UTC 2016
Hi Dan,
On 3/12/2016 10:02 AM, Daniel D. Daugherty wrote:
> Getting JPRT job failures on non-OpenJDK platforms.
> I'll have to look at this more on Monday...
Sorry we need some changes in the closed ports because the os-cpu method
has been hoisted to the os level. I should have realized that.
I'll see if I can throw together the patch over the weekend.
David
> 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