RFR(M): 8169373: Work around linux NPTL stack guard error.
Daniel D. Daugherty
daniel.daugherty at oracle.com
Mon Dec 5 22:13:03 UTC 2016
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