From david.buck at oracle.com Thu Dec 1 08:42:19 2016 From: david.buck at oracle.com (David Buck) Date: Thu, 1 Dec 2016 17:42:19 +0900 Subject: RFR(XS) [8u] 8164508: unexpected profiling mismatch in c1 generated code Message-ID: <583FE26B.1040604@oracle.com> Hi! Would some please review the backported changes of jdk8164508 to 8u: It is a *very* straightforward backport. The only difference is that I had to modify (remove) the package used for the testcase. Bug Report: [ 8164508: unexpected profiling mismatch in c1 generated code ] https://bugs.openjdk.java.net/browse/JDK-8164508 JDK 9 changeset: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/f940af863003 8u-dev Webrev: http://cr.openjdk.java.net/~dbuck/8164508_8u_0/ Testing: Manual verification and JPRT (hotspot testset) Cheers, -Buck From aph at redhat.com Thu Dec 1 09:14:44 2016 From: aph at redhat.com (Andrew Haley) Date: Thu, 1 Dec 2016 09:14:44 +0000 Subject: [JBS] {New} (JDK-8170430) x86 pow() stub from Intel libm is inconsistent with pow() from fdlib In-Reply-To: References: <53E8E64DB2403849AFD89B7D4DAC8B2A5F896326@ORSMSX106.amr.corp.intel.com> <4753cb3b-dbd8-d587-3e41-a6ab172c59ec@oracle.com> Message-ID: <2d1a5934-fc41-cc88-035f-5da80e1f15e3@redhat.com> I think we should fix up the interpreter and all JITs to call the common routines. It's not hard, and it will fix non-monotonic behaviour. Andrew. From volker.simonis at gmail.com Thu Dec 1 10:01:55 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 1 Dec 2016 11:01:55 +0100 Subject: [JBS] {New} (JDK-8170430) x86 pow() stub from Intel libm is inconsistent with pow() from fdlib In-Reply-To: <68a11a1c-92c9-e027-ce14-a443b91a896b@oracle.com> References: <53E8E64DB2403849AFD89B7D4DAC8B2A5F896326@ORSMSX106.amr.corp.intel.com> <4753cb3b-dbd8-d587-3e41-a6ab172c59ec@oracle.com> <68a11a1c-92c9-e027-ce14-a443b91a896b@oracle.com> Message-ID: Vladimir, Joe, thanks for your detailed descriptions and explanations. I'll check if our ports comply with the expected behavior. Regards, Volker On Wed, Nov 30, 2016 at 10:02 PM, joe darcy wrote: > Hello, > > It is allowed by the specification and desirable for Math.pow to return > different results than StrictMath.pow, subject to the quality of > implementation criteria governing both implementations. > > For pow those requirements are: > > The computed result must be within 1 ulp of the exact result. Results > must be semi-monotonic. > http://download.java.net/java/jdk9/docs/api/java/lang/Math.html#pow-double-double- > > Having "the computed result must be within 1 ulp of the exact result" means > (in summary) one of the the two floating-point values bracketing the exact > mathematical result must be returned. Requiring the results to be > "semi-monotonic" means that when the true pow function is increasing the > floating-point approximation must be non-decreasing. A particular example, > fix the first argument of pow to be some finite X > 1 and for successive > finite floating-point numbers y1, y2, y3, ... all > 1 it is true > mathematically that: > > pow(X, y1) < pow(X, y2) < pow(X, y3) < ... > > and thus by the semi-monotonic requirement the floating-point approximation > must have the property that: > > pow(X, y1) <= pow(X, y2) <= pow(X, y3) <= ... > > Say you have two pow implementations, pow1 and pow2, that separately mean > the accuracy and semi-monotonic requirements above. Is some interleaving of > pow1 and pow2 also a valid implementation? > > Since each of pow1 and pow2 meet the accuracy requirements for a given > argument, picking one or another is fine. However, the semi-monotonic > requirement can be problematic. For example, lets say in a flat portion of > the graph we have a true mathematical result close to (a+ b)/2 with a < b > and pow1 and pow2 behaving as follows: > > pow1(X, y1) = a > pow1(X, y2) = a > pow1(X, y3) = a > > pow2(X, y1) = b > pow2(X, y2) = b > pow2(X, y3) = b > > Separately, each of pow1 and pow2 is meeting the accuracy and semi-monotonic > requirements. > > However, if an interleaving pow picks pow2 for (X, y1) and pow1 for (X, y2), > the semi-monotonic requirement will be violated and the composite > implementation *illegal*. > > Just picking one of pow1 and pow2 and sticking with it for a given JVM run > avoids having to worry about such subtle issues. For that reason, we've > worked to make the math instrinics behave consistently independent of being > run in the interpreter, C1, C2, and so on. Various bugs to implement such > consistency have been filed and fixed over the years, but I'm dig them up at > this time. > > In this case, I strongly recommend the pow stub be used or not used > independent of what HotSpot compiler is run. > > HTH, > > -Joe > > > > On 11/30/2016 10:25 AM, Vladimir Kozlov wrote: >> >> On 11/30/16 9:35 AM, Volker Simonis wrote: >>> >>> Hi, >>> >>> what is the actual problem here? Is it the fact that Math.pow() >>> returns different results depending on whether it is executed in >>> interpreted or in JIT-compiled mode? >>> >>> Or in other words - do we insist on having the same results from the >>> Math functions while promoting from Interpreted to C1 and finally C2? >> >> >> Yes, that is the goal. The result should be the same from Interpreter and >> from code generated by JIT compilers. >> >>> The API-doc for Math says: "Unlike some of the numeric methods of >>> class StrictMath, all implementations of the equivalent functions of >>> class Math are not defined to return the bit-for-bit same results. >>> This relaxation permits better-performing implementations where strict >>> reproducibility is not required." But I'm not sure if this implies >>> that Math.FUNC(constant_value) always has to return the bit-for-bit >>> same result no matter how often we call it? >>> >>> The problem is that by default the Java implementation of the Math >>> functions call the StrictMath version. So if the interpreter does no >>> optimizations, it will get the exact StrictMath (i.e. fdlibm) results. >>> But when the Math methods are compiled, they may be intrinisfied, in >>> which case they are allowed to return less exact values. A further >>> complication is that the interpreter may optimize himself and either >>> use optimized assembler stubs for a function (e.g. >>> StubRoutines::_dsin()) or uses leaf-calls into HotSpots internal >>> C++-Implementation of the functions (e.g. SharedRuntime::dsin()). >> >> >> JIT compilers should follow the same rule as Interpreter: call >> StubRoutines::_dsin or SharedRuntime::dsin. >> >>> >>> So what does "strict reproducibility is not required" for Math >>> functions actually mean? Is it OK for a program like this: >>> >>> while(true) { >>> if (Math.FUNC(val) == XXX) System.out.println("YES"); >>> else System.out.println("NO"); >>> } >>> >>> to print both, "YES" and "NO"? >> >> >> No, we try to avoid this. During application one run the answer should be >> the same regardless how frequent a method is executed (JITed or not). But >> the result does not necessary need to be the same when an application run >> with different flags (InlineIntrinsics). >> >> This is how I understand it. >> >> We had a lot of bugs (for pow() especially) when results were inconsistent >> during run until we start using the same code in Interpreter and JITed code. >> >> Regards, >> Vladimir >> >>> >>> Thank you and best regards, >>> Volker >>> >>> >>> On Wed, Nov 30, 2016 at 2:34 AM, Vladimir Kozlov >>> wrote: >>>> >>>> Thank you, Vivek >>>> >>>> I will sponsor it. >>>> >>>> Do you think it is hard to fix stubs code even in some next release? >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> >>>> On 11/29/16 5:26 PM, Deshpande, Vivek R wrote: >>>>> >>>>> >>>>> Hi >>>>> >>>>> >>>>> >>>>> I have bug fix for avx512 8170430. >>>>> >>>>> http://cr.openjdk.java.net/~vdeshpande/8170430/webrev.00/ >>>>> >>>>> I have also updated the JBS entry. >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8170430 >>>>> >>>>> I have tested it with other libm stubs too along with pow. >>>>> >>>>> Would you please review and sponsor it. >>>>> >>>>> >>>>> >>>>> Regards, >>>>> >>>>> Vivek >>>>> >>>>> >>>> > From goetz.lindenmaier at sap.com Thu Dec 1 10:32:06 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 1 Dec 2016 10:32:06 +0000 Subject: RFR(M): 8169373: Work around linux NPTL stack guard error. In-Reply-To: <49acd657-aefa-b935-1b2c-195fc2d125ba@oracle.com> References: <1267cfcb-fa62-fb7b-76d5-a9d61c899ce5@oracle.com> <793ff470bbf14241a1d627bff25ed627@DEROTE13DE08.global.corp.sap> <45f66348d6d54f8d826c707aa70f2352@DEROTE13DE08.global.corp.sap> <24078321-9ca8-28e8-3895-59b09ab398f5@oracle.com> <4dfa4ae6-4fa6-994c-f2cf-8fc309d8c520@oracle.com> <821371d77c7c4e6d966901b461b3d6a1@DEROTE13DE08.global.corp.sap> <49acd657-aefa-b935-1b2c-195fc2d125ba@oracle.com> Message-ID: <04825132c7fd4f92a06057cecc3f9329@DEROTE13DE08.global.corp.sap> 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 > ; hotspot-compiler-dev at openjdk.java.net; > 'hotspot-runtime-dev at openjdk.java.net' 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 ; hotspot-compiler- > >>> dev at openjdk.java.net; 'hotspot-runtime-dev at openjdk.java.net' >>> 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 ; hotspot- > compiler- > >>>>> dev at openjdk.java.net; 'hotspot-runtime-dev at openjdk.java.net' > >>>>> 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 ; > >>>>>>> 'daniel.daugherty at oracle.com' ; > >>> 'hotspot- > >>>>>>> runtime-dev at openjdk.java.net' 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 ; > >>>>>>>>> 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 ; > >>>>>>>>>> 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 ; David > >>> Holmes > >>>>>>>>>>>> ; 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 ; Lindenmaier, > >>> Goetz > >>>>>>>>>>>>>> ; 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 ; > >>> 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: > >>>>>>>>>>>>>>>>>> > > From david.holmes at oracle.com Thu Dec 1 12:44:07 2016 From: david.holmes at oracle.com (David Holmes) Date: Thu, 1 Dec 2016 22:44:07 +1000 Subject: RFR(M): 8169373: Work around linux NPTL stack guard error. In-Reply-To: <04825132c7fd4f92a06057cecc3f9329@DEROTE13DE08.global.corp.sap> References: <1267cfcb-fa62-fb7b-76d5-a9d61c899ce5@oracle.com> <793ff470bbf14241a1d627bff25ed627@DEROTE13DE08.global.corp.sap> <45f66348d6d54f8d826c707aa70f2352@DEROTE13DE08.global.corp.sap> <24078321-9ca8-28e8-3895-59b09ab398f5@oracle.com> <4dfa4ae6-4fa6-994c-f2cf-8fc309d8c520@oracle.com> <821371d77c7c4e6d966901b461b3d6a1@DEROTE13DE08.global.corp.sap> <49acd657-aefa-b935-1b2c-195fc2d125ba@oracle.com> <04825132c7fd4f92a06057cecc3f9329@DEROTE13DE08.global.corp.sap> Message-ID: <116a8dec-114b-8c6f-557e-daae242b98e7@oracle.com> Hi Goetz, On 1/12/2016 8:32 PM, Lindenmaier, Goetz wrote: > Hi David, > > I fixed the comment: > http://cr.openjdk.java.net/~goetz/wr16/8169373-ppc-stackFix/webrev.07/ There are multiple occurrences to be fixed - no need for me to see new webrev though. > 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. That's great to hear - appreciated. But at this stage of the game some healthy paranoia is in order so I'd like to see this run through our internal testing too. Thanks, David > 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 >> ; hotspot-compiler-dev at openjdk.java.net; >> 'hotspot-runtime-dev at openjdk.java.net' > 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 ; hotspot-compiler- >>>>> dev at openjdk.java.net; 'hotspot-runtime-dev at openjdk.java.net' >>>> 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 ; hotspot- >> compiler- >>>>>>> dev at openjdk.java.net; 'hotspot-runtime-dev at openjdk.java.net' >> >>>>>> 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 ; >>>>>>>>> 'daniel.daugherty at oracle.com' ; >>>>> 'hotspot- >>>>>>>>> runtime-dev at openjdk.java.net' > 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 ; >>>>>>>>>>> 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 ; >>>>>>>>>>>> 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 ; David >>>>> Holmes >>>>>>>>>>>>>> ; 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 ; Lindenmaier, >>>>> Goetz >>>>>>>>>>>>>>>> ; 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 ; >>>>> 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: >>>>>>>>>>>>>>>>>>>> >>> From martin.doerr at sap.com Thu Dec 1 18:06:46 2016 From: martin.doerr at sap.com (Doerr, Martin) Date: Thu, 1 Dec 2016 18:06:46 +0000 Subject: [JBS] {New} (JDK-8170430) x86 pow() stub from Intel libm is inconsistent with pow() from fdlib In-Reply-To: <2d1a5934-fc41-cc88-035f-5da80e1f15e3@redhat.com> References: <53E8E64DB2403849AFD89B7D4DAC8B2A5F896326@ORSMSX106.amr.corp.intel.com> <4753cb3b-dbd8-d587-3e41-a6ab172c59ec@oracle.com> <2d1a5934-fc41-cc88-035f-5da80e1f15e3@redhat.com> Message-ID: <0b94799920074d668996fb88f3620e04@dewdfe13de06.global.corp.sap> Hi Andrew, sounds like a good idea. At least, the following functions should by in sync: Interpreter: TemplateInterpreterGenerator::generate_math_entry C1: LIRGenerator::do_MathIntrinsic C2: LibraryCallKit::inline_math_native I think it would be nice to have tables in shared code which translate the respective MethodKind or vmIntrinsics to the function pointers of the SharedRuntime functions. I don't like all function calls to get replicated for all platforms. E.g. generate_math_entry could handle platform specific intrinsics first. If none is available, it could just call the SharedRuntime function retrieved from the shared table. I believe generate_math_entry should never return 0 because that would mean ending up in StrictMath while C1 and C2 use the SharedRuntime functions. Right? Best regards, Martin -----Original Message----- From: hotspot-compiler-dev [mailto:hotspot-compiler-dev-bounces at openjdk.java.net] On Behalf Of Andrew Haley Sent: Donnerstag, 1. Dezember 2016 10:15 To: hotspot-compiler-dev at openjdk.java.net Subject: Re: [JBS] {New} (JDK-8170430) x86 pow() stub from Intel libm is inconsistent with pow() from fdlib I think we should fix up the interpreter and all JITs to call the common routines. It's not hard, and it will fix non-monotonic behaviour. Andrew. From vladimir.kozlov at oracle.com Fri Dec 2 05:19:55 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 1 Dec 2016 21:19:55 -0800 Subject: RFR(XS) [8u] 8164508: unexpected profiling mismatch in c1 generated code In-Reply-To: <583FE26B.1040604@oracle.com> References: <583FE26B.1040604@oracle.com> Message-ID: <8171e9ac-8d0f-28e8-3d1b-14abd18e779d@oracle.com> Backport changes looks good. thanks, Vladimir On 12/1/16 12:42 AM, David Buck wrote: > Hi! > > Would some please review the backported changes of jdk8164508 to 8u: > > It is a *very* straightforward backport. The only difference is that I had to modify (remove) the package used for the > testcase. > > Bug Report: > [ 8164508: unexpected profiling mismatch in c1 generated code ] > https://bugs.openjdk.java.net/browse/JDK-8164508 > > JDK 9 changeset: > http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/f940af863003 > > 8u-dev Webrev: > http://cr.openjdk.java.net/~dbuck/8164508_8u_0/ > > Testing: > Manual verification and JPRT (hotspot testset) > > Cheers, > -Buck From jamsheed.c.m at oracle.com Fri Dec 2 09:45:38 2016 From: jamsheed.c.m at oracle.com (Jamsheed C m) Date: Fri, 2 Dec 2016 15:15:38 +0530 Subject: RFR(XS) [8u] 8164508: unexpected profiling mismatch in c1 generated code In-Reply-To: <583FE26B.1040604@oracle.com> References: <583FE26B.1040604@oracle.com> Message-ID: Backport looks good to me (no a reviewer). Best Regards, Jamsheed On 12/1/2016 2:12 PM, David Buck wrote: > Hi! > > Would some please review the backported changes of jdk8164508 to 8u: > > It is a *very* straightforward backport. The only difference is that I > had to modify (remove) the package used for the testcase. > > Bug Report: > [ 8164508: unexpected profiling mismatch in c1 generated code ] > https://bugs.openjdk.java.net/browse/JDK-8164508 > > JDK 9 changeset: > http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/f940af863003 > > 8u-dev Webrev: > http://cr.openjdk.java.net/~dbuck/8164508_8u_0/ > > Testing: > Manual verification and JPRT (hotspot testset) > > Cheers, > -Buck From goetz.lindenmaier at sap.com Fri Dec 2 11:05:50 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 2 Dec 2016 11:05:50 +0000 Subject: [ping compiler review needed] RE: RFR(M): 8169373: Work around linux NPTL stack guard error. Message-ID: <84c7866ceea34cfeb1dc19ee2da3fbd7@DEROTE13DE08.global.corp.sap> Hi, I please need a review for the compiler part of this change Current webrev: http://cr.openjdk.java.net/~goetz/wr16/8169373-ppc-stackFix/webrev.07/ For an explanation of the compiler change see below. Best regards, Goetz. > -----Original Message----- > From: Lindenmaier, Goetz > Sent: Montag, 28. November 2016 10:09 > To: hotspot-compiler-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, > > 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/ > 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 ; > > '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 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 ; > > >> 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 ; > > >>> 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 ; David Holmes > > >>>>> ; 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 ; Lindenmaier, Goetz > > >>>>>>> ; 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 ; 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: > > >>>>>>>>>>> > > >>>> From jamsheed.c.m at oracle.com Fri Dec 2 15:38:15 2016 From: jamsheed.c.m at oracle.com (Jamsheed C m) Date: Fri, 2 Dec 2016 21:08:15 +0530 Subject: RFR: 8166002: Emulate client build on platforms with reduced virtual address space In-Reply-To: <30b01249-29d3-dfa5-2c0a-c7788780ca73@oracle.com> References: <12de5f29-f773-11df-c397-f699f6ede7c3@oracle.com> <5812F65E.5010703@oracle.com> <58139658.1010706@oracle.com> <21DE287E-E195-4824-8259-9C3237DFFE1E@oracle.com> <30b01249-29d3-dfa5-2c0a-c7788780ca73@oracle.com> Message-ID: <6106172a-a87d-f82e-467c-61677589cbfd@oracle.com> Hi Vladimir, Igor, I made a few more changes to include the optimization that was available only on client. 1) a few c1 changes (JDK-7153771..) 2) Made SerialGC as default GC. 3) Set CICompileCount=1 for client compilation mode. 4) Tuned thresholds to get better performance. 5) Added relevant flags in few tests, modified TestSelectDefaultGC.java. revised webrev: http://cr.openjdk.java.net/~jcm/8166002/webrev.03/ performance report is added in bug report. Best Regards, Jamsheed On 11/1/2016 1:14 AM, Vladimir Kozlov wrote: > webrev.02 looks good to me too. > > Thanks, > Vladimri > > On 10/31/16 10:39 AM, Igor Veresov wrote: >> Jamsheed explained to me that ReservedCodeCacheSize is now set in the >> else clause (udiffs are not showing the proper alignment and I missed >> it). The change looks good to me. >> >> igor >> >>> On Oct 31, 2016, at 9:42 AM, Igor Veresov >>> wrote: >>> >>> Assuming it gets the performance/startup numbers close to the client >>> VM it looks fine. >>> But what about adjusting the code cache sizes? With tiered we get >>> 240M ReservedCodeCacheSize, which also turns on SegmentedCodeCache. >>> It seems like we won?t need the ?profiled? segment of the code cache >>> at all. It is also likely that we?d do fine with a smaller overall >>> code cache. >>> >>> igor >>> >>>> On Oct 31, 2016, at 9:14 AM, Jamsheed C m >>>> wrote: >>>> >>>> Hi Vladimir, Igor, >>>> >>>> revised webrev: http://cr.openjdk.java.net/~jcm/8166002/webrev.02/ >>>> >>>> i took flags from bug comment. >>>> >>>> Igor V. suggested next flags setting to emulate Client VM compile >>>> threshold with TieredStopAtLevel=1: >>>> >>>> Tier3BackEdgeThreshold=14000 >>>> Tier3CompileThreshold=1500 >>>> Tier3InvocationThreshold=1500 >>>> Tier3MinInvocationThreshold =1500 >>>> >>>> Best Regards, >>>> >>>> Jamsheed >>>> >>>> On 10/28/2016 11:48 PM, Vladimir Kozlov wrote: >>>>> Add comment what the code does and why. Move the code into >>>>> separate function reaturning bool. And condition CodeCache setting >>>>> based on result. It will reduce #ifdef mess. >>>>> >>>>> Can you put && to the end of previous line? To get good alignment. >>>>> Should we also change CompilationPolicyChoice? >>>>> >>>>> Ask Igor Veresov to verify settings. >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> On 10/28/16 10:59 AM, Jamsheed C m wrote: >>>>>> Hi Vladimir, >>>>>> >>>>>> revised webrev with just ergo settings for win32. >>>>>> >>>>>> http://cr.openjdk.java.net/~jcm/8166002/webrev.01/ >>>>>> >>>>>> Best Regards >>>>>> >>>>>> Jamsheed >>>>>> >>>>>> >>>>>> On 10/28/2016 12:25 PM, Vladimir Kozlov wrote: >>>>>>> Hi Jamsheed, >>>>>>> >>>>>>> Why you need changes in tests? >>>>>>> >>>>>>> Why you can't use set_client_compilation_mode() in both places? >>>>>>> >>>>>>> Looks fine otherwise. >>>>>>> >>>>>>> Thanks, >>>>>>> Vladimir >>>>>>> >>>>>>> On 10/20/16 8:45 AM, Jamsheed C m wrote: >>>>>>>> Hi All, >>>>>>>> >>>>>>>> bug id:https://bugs.openjdk.java.net/browse/JDK-8166002 >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~jcm/8166002/webrev.00/ >>>>>>>> >>>>>>>> Fix: set NeverActAsServerClassMachine=true, Limit >>>>>>>> TieredCompilation to C1 by default, for win32 platform. >>>>>>>> >>>>>>>> A new flag CompilationMode= is introduced to >>>>>>>> select server/ client mode compilation. This option is >>>>>>>> supported only in TIERED builds. >>>>>>>> >>>>>>>> -XX:CompilationMode=server supports both -XX:+/-TieredCompilation. >>>>>>>> >>>>>>>> -XX:CompilationMode:client ignores TieredCompilation flag. >>>>>>>> >>>>>>>> Please review, >>>>>>>> >>>>>>>> Best Regards, >>>>>>>> >>>>>>>> Jamsheed >>>>>>>> >>>>>>>> >>>>>>>> >>>>>> >>>> >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladimir.kozlov at oracle.com Fri Dec 2 18:12:10 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 2 Dec 2016 10:12:10 -0800 Subject: RFR(M): 8169373: Work around linux NPTL stack guard error. In-Reply-To: <04825132c7fd4f92a06057cecc3f9329@DEROTE13DE08.global.corp.sap> References: <1267cfcb-fa62-fb7b-76d5-a9d61c899ce5@oracle.com> <793ff470bbf14241a1d627bff25ed627@DEROTE13DE08.global.corp.sap> <45f66348d6d54f8d826c707aa70f2352@DEROTE13DE08.global.corp.sap> <24078321-9ca8-28e8-3895-59b09ab398f5@oracle.com> <4dfa4ae6-4fa6-994c-f2cf-8fc309d8c520@oracle.com> <821371d77c7c4e6d966901b461b3d6a1@DEROTE13DE08.global.corp.sap> <49acd657-aefa-b935-1b2c-195fc2d125ba@oracle.com> <04825132c7fd4f92a06057cecc3f9329@DEROTE13DE08.global.corp.sap> Message-ID: <4abd1e03-27a2-4778-d1b0-09a952ccb525@oracle.com> 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 >> ; hotspot-compiler-dev at openjdk.java.net; >> 'hotspot-runtime-dev at openjdk.java.net' > 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 ; hotspot-compiler- >>>>> dev at openjdk.java.net; 'hotspot-runtime-dev at openjdk.java.net' >>>> 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 ; hotspot- >> compiler- >>>>>>> dev at openjdk.java.net; 'hotspot-runtime-dev at openjdk.java.net' >> >>>>>> 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 ; >>>>>>>>> 'daniel.daugherty at oracle.com' ; >>>>> 'hotspot- >>>>>>>>> runtime-dev at openjdk.java.net' > 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 ; >>>>>>>>>>> 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 ; >>>>>>>>>>>> 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 ; David >>>>> Holmes >>>>>>>>>>>>>> ; 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 ; Lindenmaier, >>>>> Goetz >>>>>>>>>>>>>>>> ; 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 ; >>>>> 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: >>>>>>>>>>>>>>>>>>>> >>> From gustavo.scalet at eldorado.org.br Fri Dec 2 20:09:03 2016 From: gustavo.scalet at eldorado.org.br (Gustavo Serra Scalet) Date: Fri, 2 Dec 2016 20:09:03 +0000 Subject: Use of cryptographic functions from OpenSSL's libcrypto Message-ID: <38810c301be44ea99e42f2fe04ae3474@serv030.corp.eldorado.org.br> Hi, I wonder why OpenJDK doesn't use OpenSSL for implementing the cryptographic functions. On OpenSSL the algorithms are HW accelerated on several platforms. Is it due to licensing issues? I ask because I intend on implementing SHA for PPC64 but then I considered having this integration, if possible. Thanks in advance From daniel.daugherty at oracle.com Fri Dec 2 21:04:18 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 2 Dec 2016 14:04:18 -0700 Subject: RFR(M): 8169373: Work around linux NPTL stack guard error. In-Reply-To: <4abd1e03-27a2-4778-d1b0-09a952ccb525@oracle.com> References: <793ff470bbf14241a1d627bff25ed627@DEROTE13DE08.global.corp.sap> <45f66348d6d54f8d826c707aa70f2352@DEROTE13DE08.global.corp.sap> <24078321-9ca8-28e8-3895-59b09ab398f5@oracle.com> <4dfa4ae6-4fa6-994c-f2cf-8fc309d8c520@oracle.com> <821371d77c7c4e6d966901b461b3d6a1@DEROTE13DE08.global.corp.sap> <49acd657-aefa-b935-1b2c-195fc2d125ba@oracle.com> <04825132c7fd4f92a06057cecc3f9329@DEROTE13DE08.global.corp.sap> <4abd1e03-27a2-4778-d1b0-09a952ccb525@oracle.com> Message-ID: <1111dc02-5d8f-3b50-b5f3-160c33474ace@oracle.com> 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 >>> ; hotspot-compiler-dev at openjdk.java.net; >>> 'hotspot-runtime-dev at openjdk.java.net' >> 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 ; >>>>>> hotspot-compiler- >>>>>> dev at openjdk.java.net; 'hotspot-runtime-dev at openjdk.java.net' >>>>>> >>>>> 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 ; hotspot- >>> compiler- >>>>>>>> dev at openjdk.java.net; 'hotspot-runtime-dev at openjdk.java.net' >>> >>>>>>> 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 ; >>>>>>>>>> 'daniel.daugherty at oracle.com' ; >>>>>> 'hotspot- >>>>>>>>>> runtime-dev at openjdk.java.net' >> 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 ; >>>>>>>>>>>> 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 ; >>>>>>>>>>>>> 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 ; David >>>>>> Holmes >>>>>>>>>>>>>>> ; 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 ; Lindenmaier, >>>>>> Goetz >>>>>>>>>>>>>>>>> ; 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 ; >>>>>> 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: >>>>>>>>>>>>>>>>>>>>> >>>> From vivek.r.deshpande at intel.com Fri Dec 2 22:17:34 2016 From: vivek.r.deshpande at intel.com (Deshpande, Vivek R) Date: Fri, 2 Dec 2016 22:17:34 +0000 Subject: [JBS] {New} (JDK-8170430) x86 pow() stub from Intel libm is inconsistent with pow() from fdlib In-Reply-To: <0b94799920074d668996fb88f3620e04@dewdfe13de06.global.corp.sap> References: <53E8E64DB2403849AFD89B7D4DAC8B2A5F896326@ORSMSX106.amr.corp.intel.com> <4753cb3b-dbd8-d587-3e41-a6ab172c59ec@oracle.com> <2d1a5934-fc41-cc88-035f-5da80e1f15e3@redhat.com> <0b94799920074d668996fb88f3620e04@dewdfe13de06.global.corp.sap> Message-ID: <53E8E64DB2403849AFD89B7D4DAC8B2A5F898596@ORSMSX106.amr.corp.intel.com> Hi Martin With the current solution with -InlineIntrinsics it does not go to either SharedRuntime function or Libm based function when its interpreted and goes to SharedRuntime function with C1 and C2. So removing this line if (!InlineIntrinsics) return NULL; // Generate a vanilla entry from generate_math_entry() seems a correct way, so that with with -InlineIntrinsics option it will always go to SharedRuntime function. Vladimir, could you please let me know if this sounds ok to you. Regards, Vivek -----Original Message----- From: hotspot-compiler-dev [mailto:hotspot-compiler-dev-bounces at openjdk.java.net] On Behalf Of Doerr, Martin Sent: Thursday, December 01, 2016 10:07 AM To: Andrew Haley; hotspot-compiler-dev at openjdk.java.net Subject: RE: [JBS] {New} (JDK-8170430) x86 pow() stub from Intel libm is inconsistent with pow() from fdlib Hi Andrew, sounds like a good idea. At least, the following functions should by in sync: Interpreter: TemplateInterpreterGenerator::generate_math_entry C1: LIRGenerator::do_MathIntrinsic C2: LibraryCallKit::inline_math_native I think it would be nice to have tables in shared code which translate the respective MethodKind or vmIntrinsics to the function pointers of the SharedRuntime functions. I don't like all function calls to get replicated for all platforms. E.g. generate_math_entry could handle platform specific intrinsics first. If none is available, it could just call the SharedRuntime function retrieved from the shared table. I believe generate_math_entry should never return 0 because that would mean ending up in StrictMath while C1 and C2 use the SharedRuntime functions. Right? Best regards, Martin -----Original Message----- From: hotspot-compiler-dev [mailto:hotspot-compiler-dev-bounces at openjdk.java.net] On Behalf Of Andrew Haley Sent: Donnerstag, 1. Dezember 2016 10:15 To: hotspot-compiler-dev at openjdk.java.net Subject: Re: [JBS] {New} (JDK-8170430) x86 pow() stub from Intel libm is inconsistent with pow() from fdlib I think we should fix up the interpreter and all JITs to call the common routines. It's not hard, and it will fix non-monotonic behaviour. Andrew. From daniel.daugherty at oracle.com Fri Dec 2 23:46:38 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 2 Dec 2016 16:46:38 -0700 Subject: RFR(M): 8169373: Work around linux NPTL stack guard error. In-Reply-To: <1111dc02-5d8f-3b50-b5f3-160c33474ace@oracle.com> References: <45f66348d6d54f8d826c707aa70f2352@DEROTE13DE08.global.corp.sap> <24078321-9ca8-28e8-3895-59b09ab398f5@oracle.com> <4dfa4ae6-4fa6-994c-f2cf-8fc309d8c520@oracle.com> <821371d77c7c4e6d966901b461b3d6a1@DEROTE13DE08.global.corp.sap> <49acd657-aefa-b935-1b2c-195fc2d125ba@oracle.com> <04825132c7fd4f92a06057cecc3f9329@DEROTE13DE08.global.corp.sap> <4abd1e03-27a2-4778-d1b0-09a952ccb525@oracle.com> <1111dc02-5d8f-3b50-b5f3-160c33474ace@oracle.com> Message-ID: <6ded66cf-558e-f6ce-7dff-7441992eb2ea@oracle.com> 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 >>>> ; hotspot-compiler-dev at openjdk.java.net; >>>> 'hotspot-runtime-dev at openjdk.java.net' >>> 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 ; >>>>>>> hotspot-compiler- >>>>>>> dev at openjdk.java.net; 'hotspot-runtime-dev at openjdk.java.net' >>>>>>> >>>>>> 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 ; hotspot- >>>> compiler- >>>>>>>>> dev at openjdk.java.net; 'hotspot-runtime-dev at openjdk.java.net' >>>> >>>>>>>> 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 ; >>>>>>>>>>> 'daniel.daugherty at oracle.com' ; >>>>>>> 'hotspot- >>>>>>>>>>> runtime-dev at openjdk.java.net' >>> 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 ; >>>>>>>>>>>>> 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 ; >>>>>>>>>>>>>> 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 ; David >>>>>>> Holmes >>>>>>>>>>>>>>>> ; 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 ; Lindenmaier, >>>>>>> Goetz >>>>>>>>>>>>>>>>>> ; 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 ; >>>>>>> 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: >>>>>>>>>>>>>>>>>>>>>> >>>>> > > From daniel.daugherty at oracle.com Sat Dec 3 00:02:56 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 2 Dec 2016 17:02:56 -0700 Subject: RFR(M): 8169373: Work around linux NPTL stack guard error. In-Reply-To: <6ded66cf-558e-f6ce-7dff-7441992eb2ea@oracle.com> References: <45f66348d6d54f8d826c707aa70f2352@DEROTE13DE08.global.corp.sap> <24078321-9ca8-28e8-3895-59b09ab398f5@oracle.com> <4dfa4ae6-4fa6-994c-f2cf-8fc309d8c520@oracle.com> <821371d77c7c4e6d966901b461b3d6a1@DEROTE13DE08.global.corp.sap> <49acd657-aefa-b935-1b2c-195fc2d125ba@oracle.com> <04825132c7fd4f92a06057cecc3f9329@DEROTE13DE08.global.corp.sap> <4abd1e03-27a2-4778-d1b0-09a952ccb525@oracle.com> <1111dc02-5d8f-3b50-b5f3-160c33474ace@oracle.com> <6ded66cf-558e-f6ce-7dff-7441992eb2ea@oracle.com> Message-ID: 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 >>>>> ; hotspot-compiler-dev at openjdk.java.net; >>>>> 'hotspot-runtime-dev at openjdk.java.net' >>>> 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 ; >>>>>>>> hotspot-compiler- >>>>>>>> dev at openjdk.java.net; 'hotspot-runtime-dev at openjdk.java.net' >>>>>>>> >>>>>>> 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 ; hotspot- >>>>> compiler- >>>>>>>>>> dev at openjdk.java.net; 'hotspot-runtime-dev at openjdk.java.net' >>>>> >>>>>>>>> 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 ; >>>>>>>>>>>> 'daniel.daugherty at oracle.com' ; >>>>>>>> 'hotspot- >>>>>>>>>>>> runtime-dev at openjdk.java.net' >>>> 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 ; >>>>>>>>>>>>>> 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 ; >>>>>>>>>>>>>>> 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 ; David >>>>>>>> Holmes >>>>>>>>>>>>>>>>> ; 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 ; >>>>>>>>>>>>>>>>>>> Lindenmaier, >>>>>>>> Goetz >>>>>>>>>>>>>>>>>>> ; 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 ; >>>>>>>> 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: >>>>>>>>>>>>>>>>>>>>>>> >>>>>> >> >> > > From vladimir.kozlov at oracle.com Sat Dec 3 00:22:07 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 2 Dec 2016 16:22:07 -0800 Subject: [JBS] {New} (JDK-8170430) x86 pow() stub from Intel libm is inconsistent with pow() from fdlib In-Reply-To: <53E8E64DB2403849AFD89B7D4DAC8B2A5F898596@ORSMSX106.amr.corp.intel.com> References: <53E8E64DB2403849AFD89B7D4DAC8B2A5F896326@ORSMSX106.amr.corp.intel.com> <4753cb3b-dbd8-d587-3e41-a6ab172c59ec@oracle.com> <2d1a5934-fc41-cc88-035f-5da80e1f15e3@redhat.com> <0b94799920074d668996fb88f3620e04@dewdfe13de06.global.corp.sap> <53E8E64DB2403849AFD89B7D4DAC8B2A5F898596@ORSMSX106.amr.corp.intel.com> Message-ID: <5842102F.5020904@oracle.com> First, 8170430 is already fixed to resolve issue with libm code. http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/5a6125eb47aa Yes, we still have discrepancy between Interpreter and JIT compilers when InlineIntrinsics is off. But we had it for long time. I agree with Martin that we should have a shared code (for Interpreter and JIT compilers) which choose what to call depending on flags. I filed Bug for jdk 10: https://bugs.openjdk.java.net/browse/JDK-8170693 Regards, Vladimir On 12/2/16 2:17 PM, Deshpande, Vivek R wrote: > Hi Martin > > With the current solution with -InlineIntrinsics it does not go to either SharedRuntime function or Libm based function when its interpreted and goes to SharedRuntime function with C1 and C2. > So removing this line > if (!InlineIntrinsics) return NULL; // Generate a vanilla entry > from generate_math_entry() seems a correct way, so that with with -InlineIntrinsics option it will always go to SharedRuntime function. > > Vladimir, could you please let me know if this sounds ok to you. > > Regards, > Vivek > -----Original Message----- > From: hotspot-compiler-dev [mailto:hotspot-compiler-dev-bounces at openjdk.java.net] On Behalf Of Doerr, Martin > Sent: Thursday, December 01, 2016 10:07 AM > To: Andrew Haley; hotspot-compiler-dev at openjdk.java.net > Subject: RE: [JBS] {New} (JDK-8170430) x86 pow() stub from Intel libm is inconsistent with pow() from fdlib > > Hi Andrew, > > sounds like a good idea. > > At least, the following functions should by in sync: > Interpreter: TemplateInterpreterGenerator::generate_math_entry > C1: LIRGenerator::do_MathIntrinsic > C2: LibraryCallKit::inline_math_native > > I think it would be nice to have tables in shared code which translate the respective MethodKind or vmIntrinsics to the function pointers of the SharedRuntime functions. > I don't like all function calls to get replicated for all platforms. > > E.g. generate_math_entry could handle platform specific intrinsics first. If none is available, it could just call the SharedRuntime function retrieved from the shared table. > > I believe generate_math_entry should never return 0 because that would mean ending up in StrictMath while C1 and C2 use the SharedRuntime functions. Right? > > Best regards, > Martin > > > -----Original Message----- > From: hotspot-compiler-dev [mailto:hotspot-compiler-dev-bounces at openjdk.java.net] On Behalf Of Andrew Haley > Sent: Donnerstag, 1. Dezember 2016 10:15 > To: hotspot-compiler-dev at openjdk.java.net > Subject: Re: [JBS] {New} (JDK-8170430) x86 pow() stub from Intel libm is inconsistent with pow() from fdlib > > I think we should fix up the interpreter and all JITs to call the common routines. It's not hard, and it will fix non-monotonic behaviour. > > Andrew. > From david.holmes at oracle.com Sat Dec 3 00:51:19 2016 From: david.holmes at oracle.com (David Holmes) Date: Sat, 3 Dec 2016 10:51:19 +1000 Subject: RFR(M): 8169373: Work around linux NPTL stack guard error. In-Reply-To: References: <24078321-9ca8-28e8-3895-59b09ab398f5@oracle.com> <4dfa4ae6-4fa6-994c-f2cf-8fc309d8c520@oracle.com> <821371d77c7c4e6d966901b461b3d6a1@DEROTE13DE08.global.corp.sap> <49acd657-aefa-b935-1b2c-195fc2d125ba@oracle.com> <04825132c7fd4f92a06057cecc3f9329@DEROTE13DE08.global.corp.sap> <4abd1e03-27a2-4778-d1b0-09a952ccb525@oracle.com> <1111dc02-5d8f-3b50-b5f3-160c33474ace@oracle.com> <6ded66cf-558e-f6ce-7dff-7441992eb2ea@oracle.com> Message-ID: <6cc01a02-d04e-01ed-a6eb-5e7dcc92fee0@oracle.com> 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 >>>>>> ; hotspot-compiler-dev at openjdk.java.net; >>>>>> 'hotspot-runtime-dev at openjdk.java.net' >>>>> 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 ; >>>>>>>>> hotspot-compiler- >>>>>>>>> dev at openjdk.java.net; 'hotspot-runtime-dev at openjdk.java.net' >>>>>>>>> >>>>>>>> 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 ; hotspot- >>>>>> compiler- >>>>>>>>>>> dev at openjdk.java.net; 'hotspot-runtime-dev at openjdk.java.net' >>>>>> >>>>>>>>>> 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 ; >>>>>>>>>>>>> 'daniel.daugherty at oracle.com' ; >>>>>>>>> 'hotspot- >>>>>>>>>>>>> runtime-dev at openjdk.java.net' >>>>> 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 ; >>>>>>>>>>>>>>> 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 ; >>>>>>>>>>>>>>>> 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 ; David >>>>>>>>> Holmes >>>>>>>>>>>>>>>>>> ; 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 ; >>>>>>>>>>>>>>>>>>>> Lindenmaier, >>>>>>>>> Goetz >>>>>>>>>>>>>>>>>>>> ; 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 ; >>>>>>>>> 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: >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>> >>> >>> >> >> > From vladimir.kozlov at oracle.com Sat Dec 3 02:32:16 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 2 Dec 2016 18:32:16 -0800 Subject: RFR: 8166002: Emulate client build on platforms with reduced virtual address space In-Reply-To: <6106172a-a87d-f82e-467c-61677589cbfd@oracle.com> References: <12de5f29-f773-11df-c397-f699f6ede7c3@oracle.com> <5812F65E.5010703@oracle.com> <58139658.1010706@oracle.com> <21DE287E-E195-4824-8259-9C3237DFFE1E@oracle.com> <30b01249-29d3-dfa5-2c0a-c7788780ca73@oracle.com> <6106172a-a87d-f82e-467c-61677589cbfd@oracle.com> Message-ID: <58422EB0.4080205@oracle.com> On 12/2/16 7:38 AM, Jamsheed C m wrote: > Hi Vladimir, Igor, > > I made a few more changes to include the optimization that was available only on client. > > 1) a few c1 changes (JDK-7153771..) Which one? > > 2) Made SerialGC as default GC. Should be only for client_compilation_mode > > 3) Set CICompileCount=1 for client compilation mode. I think check should be is_client_compilation_mode_vm() > > 4) Tuned thresholds to get better performance. ok > > 5) Added relevant flags in few tests, modified TestSelectDefaultGC.java. ok Thanks, Vladimir > > revised webrev: http://cr.openjdk.java.net/~jcm/8166002/webrev.03/ > > performance report is added in bug report. > > Best Regards, > > Jamsheed > > > > On 11/1/2016 1:14 AM, Vladimir Kozlov wrote: >> webrev.02 looks good to me too. >> >> Thanks, >> Vladimri >> >> On 10/31/16 10:39 AM, Igor Veresov wrote: >>> Jamsheed explained to me that ReservedCodeCacheSize is now set in the else clause (udiffs are not showing the proper alignment and I missed it). The change looks good to me. >>> >>> igor >>> >>>> On Oct 31, 2016, at 9:42 AM, Igor Veresov wrote: >>>> >>>> Assuming it gets the performance/startup numbers close to the client VM it looks fine. >>>> But what about adjusting the code cache sizes? With tiered we get 240M ReservedCodeCacheSize, which also turns on SegmentedCodeCache. It seems like we won?t need the ?profiled? segment of the code >>>> cache at all. It is also likely that we?d do fine with a smaller overall code cache. >>>> >>>> igor >>>> >>>>> On Oct 31, 2016, at 9:14 AM, Jamsheed C m wrote: >>>>> >>>>> Hi Vladimir, Igor, >>>>> >>>>> revised webrev: http://cr.openjdk.java.net/~jcm/8166002/webrev.02/ >>>>> >>>>> i took flags from bug comment. >>>>> >>>>> Igor V. suggested next flags setting to emulate Client VM compile threshold with TieredStopAtLevel=1: >>>>> >>>>> Tier3BackEdgeThreshold=14000 >>>>> Tier3CompileThreshold=1500 >>>>> Tier3InvocationThreshold=1500 >>>>> Tier3MinInvocationThreshold =1500 >>>>> >>>>> Best Regards, >>>>> >>>>> Jamsheed >>>>> >>>>> On 10/28/2016 11:48 PM, Vladimir Kozlov wrote: >>>>>> Add comment what the code does and why. Move the code into separate function reaturning bool. And condition CodeCache setting based on result. It will reduce #ifdef mess. >>>>>> >>>>>> Can you put && to the end of previous line? To get good alignment. >>>>>> Should we also change CompilationPolicyChoice? >>>>>> >>>>>> Ask Igor Veresov to verify settings. >>>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>> On 10/28/16 10:59 AM, Jamsheed C m wrote: >>>>>>> Hi Vladimir, >>>>>>> >>>>>>> revised webrev with just ergo settings for win32. >>>>>>> >>>>>>> http://cr.openjdk.java.net/~jcm/8166002/webrev.01/ >>>>>>> >>>>>>> Best Regards >>>>>>> >>>>>>> Jamsheed >>>>>>> >>>>>>> >>>>>>> On 10/28/2016 12:25 PM, Vladimir Kozlov wrote: >>>>>>>> Hi Jamsheed, >>>>>>>> >>>>>>>> Why you need changes in tests? >>>>>>>> >>>>>>>> Why you can't use set_client_compilation_mode() in both places? >>>>>>>> >>>>>>>> Looks fine otherwise. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Vladimir >>>>>>>> >>>>>>>> On 10/20/16 8:45 AM, Jamsheed C m wrote: >>>>>>>>> Hi All, >>>>>>>>> >>>>>>>>> bug id:https://bugs.openjdk.java.net/browse/JDK-8166002 >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~jcm/8166002/webrev.00/ >>>>>>>>> >>>>>>>>> Fix: set NeverActAsServerClassMachine=true, Limit TieredCompilation to C1 by default, for win32 platform. >>>>>>>>> >>>>>>>>> A new flag CompilationMode= is introduced to select server/ client mode compilation. This option is supported only in TIERED builds. >>>>>>>>> >>>>>>>>> -XX:CompilationMode=server supports both -XX:+/-TieredCompilation. >>>>>>>>> >>>>>>>>> -XX:CompilationMode:client ignores TieredCompilation flag. >>>>>>>>> >>>>>>>>> Please review, >>>>>>>>> >>>>>>>>> Best Regards, >>>>>>>>> >>>>>>>>> Jamsheed >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>> >>>>> >>>> >>> > From goetz.lindenmaier at sap.com Sat Dec 3 17:50:51 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Sat, 3 Dec 2016 17:50:51 +0000 Subject: RFR(M): 8169373: Work around linux NPTL stack guard error. In-Reply-To: References: <45f66348d6d54f8d826c707aa70f2352@DEROTE13DE08.global.corp.sap> <24078321-9ca8-28e8-3895-59b09ab398f5@oracle.com> <4dfa4ae6-4fa6-994c-f2cf-8fc309d8c520@oracle.com> <821371d77c7c4e6d966901b461b3d6a1@DEROTE13DE08.global.corp.sap> <49acd657-aefa-b935-1b2c-195fc2d125ba@oracle.com> <04825132c7fd4f92a06057cecc3f9329@DEROTE13DE08.global.corp.sap> <4abd1e03-27a2-4778-d1b0-09a952ccb525@oracle.com> <1111dc02-5d8f-3b50-b5f3-160c33474ace@oracle.com> <6ded66cf-558e-f6ce-7dff-7441992eb2ea@oracle.com> Message-ID: Hi, I made a final webrev adding Vladimir to reviewers and with the errno->error fixes: http://cr.openjdk.java.net/~goetz/wr16/8169373-ppc-stackFix/webrev.08/ I hope this does not invalidate the testing you already did. Will the closed port issue go away if arm is submitted to openJdk? Best regards, Goetz. > -----Original Message----- > From: Daniel D. Daugherty [mailto:daniel.daugherty at oracle.com] > Sent: Saturday, December 03, 2016 1:03 AM > To: Vladimir Kozlov ; Lindenmaier, Goetz > ; David Holmes ; > hotspot-compiler-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 > >>>>> ; hotspot-compiler- > dev at openjdk.java.net; > >>>>> 'hotspot-runtime-dev at openjdk.java.net' >>>>> 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 ; > >>>>>>>> hotspot-compiler- > >>>>>>>> dev at openjdk.java.net; 'hotspot-runtime-dev at openjdk.java.net' > >>>>>>>> >>>>>>>> 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 ; > hotspot- > >>>>> compiler- > >>>>>>>>>> dev at openjdk.java.net; 'hotspot-runtime- > dev at openjdk.java.net' > >>>>> >>>>>>>>>> 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 ; > >>>>>>>>>>>> 'daniel.daugherty at oracle.com' > ; > >>>>>>>> 'hotspot- > >>>>>>>>>>>> runtime-dev at openjdk.java.net' >>>>> 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 ; > >>>>>>>>>>>>>> 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 ; > >>>>>>>>>>>>>>> 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 ; > David > >>>>>>>> Holmes > >>>>>>>>>>>>>>>>> ; 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 ; > >>>>>>>>>>>>>>>>>>> Lindenmaier, > >>>>>>>> Goetz > >>>>>>>>>>>>>>>>>>> ; 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 > ; > >>>>>>>> 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: > >>>>>>>>>>>>>>>>>>>>>>> > >>>>>> > >> > >> > > > > From goetz.lindenmaier at sap.com Sat Dec 3 18:17:18 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Sat, 3 Dec 2016 18:17:18 +0000 Subject: RFR(M): 8170655: [posix] Fix minimum stack size computations Message-ID: Hi, I would like to fix two issues of minimum stack size computation: http://cr.openjdk.java.net/~goetz/wr16/8170655-compilerGuardFix/webrev.01/ Please review and sponsor. This are the issues I excluded from the "8169373: Work around linux NPTL stack guard error." I wrote a lengthy explanation in the bug, trying to comment on what was said in the other thread. I'll repeat it here, I think that's better for discussion. Dan, thanks for improving the text, I use the improved variant here: HotSpot has three cmd line options to set stack sizes (besides -Xss): -XX:ThreadStackSize for threads executing Java code. -XX:CompilerThreadStackSize for threads used by the JIT compilers. -XX:VMThreadStackSize for threads executing VM internal tasks as gc. All these flags should not be set to a value that leads to a stack overflow before user code can be executed. As the VM executes a lot of code for initialization and also the JIT already compiles methods, considerable amounts of stack can be used during startup. We must try to avoid stack overflows before startup is complete as error handling might not be properly in place yet. Required minimum stack sizes depend on frame sizes and program execution paths. Frame sizes again depend on the C compiler used, the platform compiled for, and design decisions in interpreter, C1 and C2. Required stack sizes also depend on option settings, e.g. with JVM/TI enabled, frames can get bigger. With inlining increased JIT compilers might do more optimizations leading to deeper call chains, etc. While the minimum stack sizes should reflect differences in Platform and compiler, they must not, and cannot, cover all possible option settings. This change addresses two issues: 1. Fixed minimum stack size configuration Currently, the minimum Java thread size is given in a constant per os/cpu platform for each of the three stack kinds. This number includes the size required for guard pages. The guard pages are used for stack overflow detection. They make up 4 zones on the stack: Red, Yellow, Reserved and Shadow pages. The Red, Yellow and Reserved pages are protected to detect stack overflows. The Shadow pages are just some extra space to allow methods that don't do a stack bang to execute. Unfortunately, the size required for guard pages is not fixed at compile time. It depends on the concrete system the VM is started on. Thus the minimum sizes given can be too small to hold the guard pages. This lead to errors in the past that were solved by introducing code that overruled the per-platform minimum stack size. This code nowadays is the MAX2() in os_posix.cpp:1114 and the SOLARIS special case further down. It uses the value (4 * BytesPerWord COMPILER2_PRESENT(+ 2)) * 4 * K) (os_posix.cpp:1117) as minimum required space for frames. Thereby it effectively overrules the minimum stack size settings given in the os/cpu constants, and there is currently no way to specify this size per platform. This change proposes to fix this issue by specifying the space needed for stack frames in the os/cpu constants. During startup, this number is increased by the space required for the guard pages. Thus, this takes into account the page size of the concrete system the VM runs on, and also eventual changes to the guard pages by the flags StackRed/Yellow/Reserved/Shadow/Pages. This gives the opportunity to reduce the minimum stack sizes on systems with small pages. Minimum stack size configuration is more simple with this change and valid for systems with any page size. 2. Stack guard pages not considered for compiler thread stacks Compiler threads are Java threads. The C++ class CompilerThread is a subclass of JavaThread. When a compiler thread is started, JavaThread::run() is executed which protects the red, yellow and reserved pages. Since 8140520 the minimum stack sizes for Compiler and VM internal threads no longer include the space for the guard pages. This is correct for the VM internal threads, but not for the Compiler thread. For the HotSpot C1 and C2 compilers it would be fine to reserve space for the Red/Yellow/Reserved pages, as they don't stack bang with the shadow page size. But since introducing JVMCI, compilers written in Java can be running on the compiler threads. Therefore the shadow pages are needed, too. As for the Java thread, this change uses a os/cpu constant for the required minimum space for compiler frames and then adds the zone sizes to the minimum stack sizes during startup. New sizing: The constants of the os/cpu minimum thread sizes are reduced by the default guard page sizes and then verified by starting the VM to assure the stack still suffices to get through startup. Hotspot jtreg tests are passing. The overall sizes required (after adding guard pages) on the systems I have available get a bit smaller. In most cases the sizes even suffice to run simple programs as SpecJvm98. The table below gives the systems I tested and the required sizes reported when started with too small stacks. 

 Thread kind:       Java      Compiler  VM

                    old new   old new   old new



bsd x86_64    dbg: 240 232    64  64    64  64

               opt: 240 232    64  64    64  64



linux x86_64  dbg: 240 144    64 152    64  64

               opt: 232 136    64 144    64  64



solaris sparc dbg:

               opt: 240 192   128 128   128 128



aix ppc64     dbg: 512 512   384 512   128 128

               opt: 512 512   384 512   128 128

 linux ppc64   dbg: 512 384   128 384   128  64

               opt: 512 384   128 384   128  64

 linux ppc64le dbg: 512 384   128 384   128  64

               opt: 512 384   128 384   128  64



linux s390    dbg: 236 140   128 184   128  32

               opt: 236 124   128 144   128  32
-------------- next part -------------- An HTML attachment was scrubbed... URL: From igor.veresov at oracle.com Sat Dec 3 18:58:55 2016 From: igor.veresov at oracle.com (Igor Veresov) Date: Sat, 3 Dec 2016 10:58:55 -0800 Subject: RFR: 8166002: Emulate client build on platforms with reduced virtual address space In-Reply-To: <6106172a-a87d-f82e-467c-61677589cbfd@oracle.com> References: <12de5f29-f773-11df-c397-f699f6ede7c3@oracle.com> <5812F65E.5010703@oracle.com> <58139658.1010706@oracle.com> <21DE287E-E195-4824-8259-9C3237DFFE1E@oracle.com> <30b01249-29d3-dfa5-2c0a-c7788780ca73@oracle.com> <6106172a-a87d-f82e-467c-61677589cbfd@oracle.com> Message-ID: <3DCDF924-B89F-4833-AE33-B1123A3EFD35@oracle.com> I really think you should consider creating a new compilation policy instead of hacking the existing tiered one. The easy way of doing that would be to subclass SimpleThresholdPolicy and override: 1. initialize() to setup the number of c1 threads to 1 and c2 threads to 0. 2. method_invocation_event and method_back_branch_event to handle level transitions. In the event handlers you would check method counters. You may emulate the old policy by triggering compiles when i + b > CompileThreshold. When a method is ready to compile you would call compile(). I think a separate policy is easier because you won?t have to deal with the fact that the tiered policy is really design with having all these compilation levels in mind. For example you won?t have to set TieredStopAtLevel, etc. Also instead of is_client_compilation_mode_vm() I?d rather add a method the policy. For example ?is_tiered_policy?, or simply check CompilerPolicy::policy()->compiler_count(CompLevel_full_optimization) == 0. What do you think? igor > On Dec 2, 2016, at 7:38 AM, Jamsheed C m wrote: > > Hi Vladimir, Igor, > > I made a few more changes to include the optimization that was available only on client. > 1) a few c1 changes (JDK-7153771 ..) > > 2) Made SerialGC as default GC. > 3) Set CICompileCount=1 for client compilation mode. > 4) Tuned thresholds to get better performance. > > 5) Added relevant flags in few tests, modified TestSelectDefaultGC.java. > > revised webrev: http://cr.openjdk.java.net/~jcm/8166002/webrev.03/ > > performance report is added in bug report. > Best Regards, > > Jamsheed > > > On 11/1/2016 1:14 AM, Vladimir Kozlov wrote: >> webrev.02 looks good to me too. >> >> Thanks, >> Vladimri >> >> On 10/31/16 10:39 AM, Igor Veresov wrote: >>> Jamsheed explained to me that ReservedCodeCacheSize is now set in the else clause (udiffs are not showing the proper alignment and I missed it). The change looks good to me. >>> >>> igor >>> >>>> On Oct 31, 2016, at 9:42 AM, Igor Veresov wrote: >>>> >>>> Assuming it gets the performance/startup numbers close to the client VM it looks fine. >>>> But what about adjusting the code cache sizes? With tiered we get 240M ReservedCodeCacheSize, which also turns on SegmentedCodeCache. It seems like we won?t need the ?profiled? segment of the code cache at all. It is also likely that we?d do fine with a smaller overall code cache. >>>> >>>> igor >>>> >>>>> On Oct 31, 2016, at 9:14 AM, Jamsheed C m wrote: >>>>> >>>>> Hi Vladimir, Igor, >>>>> >>>>> revised webrev: http://cr.openjdk.java.net/~jcm/8166002/webrev.02/ >>>>> >>>>> i took flags from bug comment. >>>>> >>>>> Igor V. suggested next flags setting to emulate Client VM compile threshold with TieredStopAtLevel=1: >>>>> >>>>> Tier3BackEdgeThreshold=14000 >>>>> Tier3CompileThreshold=1500 >>>>> Tier3InvocationThreshold=1500 >>>>> Tier3MinInvocationThreshold =1500 >>>>> >>>>> Best Regards, >>>>> >>>>> Jamsheed >>>>> >>>>> On 10/28/2016 11:48 PM, Vladimir Kozlov wrote: >>>>>> Add comment what the code does and why. Move the code into separate function reaturning bool. And condition CodeCache setting based on result. It will reduce #ifdef mess. >>>>>> >>>>>> Can you put && to the end of previous line? To get good alignment. >>>>>> Should we also change CompilationPolicyChoice? >>>>>> >>>>>> Ask Igor Veresov to verify settings. >>>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>> On 10/28/16 10:59 AM, Jamsheed C m wrote: >>>>>>> Hi Vladimir, >>>>>>> >>>>>>> revised webrev with just ergo settings for win32. >>>>>>> >>>>>>> http://cr.openjdk.java.net/~jcm/8166002/webrev.01/ >>>>>>> >>>>>>> Best Regards >>>>>>> >>>>>>> Jamsheed >>>>>>> >>>>>>> >>>>>>> On 10/28/2016 12:25 PM, Vladimir Kozlov wrote: >>>>>>>> Hi Jamsheed, >>>>>>>> >>>>>>>> Why you need changes in tests? >>>>>>>> >>>>>>>> Why you can't use set_client_compilation_mode() in both places? >>>>>>>> >>>>>>>> Looks fine otherwise. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Vladimir >>>>>>>> >>>>>>>> On 10/20/16 8:45 AM, Jamsheed C m wrote: >>>>>>>>> Hi All, >>>>>>>>> >>>>>>>>> bug id:https://bugs.openjdk.java.net/browse/JDK-8166002 >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~jcm/8166002/webrev.00/ >>>>>>>>> >>>>>>>>> Fix: set NeverActAsServerClassMachine=true, Limit TieredCompilation to C1 by default, for win32 platform. >>>>>>>>> >>>>>>>>> A new flag CompilationMode= is introduced to select server/ client mode compilation. This option is supported only in TIERED builds. >>>>>>>>> >>>>>>>>> -XX:CompilationMode=server supports both -XX:+/-TieredCompilation. >>>>>>>>> >>>>>>>>> -XX:CompilationMode:client ignores TieredCompilation flag. >>>>>>>>> >>>>>>>>> Please review, >>>>>>>>> >>>>>>>>> Best Regards, >>>>>>>>> >>>>>>>>> Jamsheed >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>> >>>>> >>>> >>> > From david.holmes at oracle.com Sun Dec 4 21:57:36 2016 From: david.holmes at oracle.com (David Holmes) Date: Mon, 5 Dec 2016 07:57:36 +1000 Subject: RFR(M): 8169373: Work around linux NPTL stack guard error. In-Reply-To: References: <24078321-9ca8-28e8-3895-59b09ab398f5@oracle.com> <4dfa4ae6-4fa6-994c-f2cf-8fc309d8c520@oracle.com> <821371d77c7c4e6d966901b461b3d6a1@DEROTE13DE08.global.corp.sap> <49acd657-aefa-b935-1b2c-195fc2d125ba@oracle.com> <04825132c7fd4f92a06057cecc3f9329@DEROTE13DE08.global.corp.sap> <4abd1e03-27a2-4778-d1b0-09a952ccb525@oracle.com> <1111dc02-5d8f-3b50-b5f3-160c33474ace@oracle.com> <6ded66cf-558e-f6ce-7dff-7441992eb2ea@oracle.com> Message-ID: 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_.cpp file. 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 ; Lindenmaier, Goetz >> ; David Holmes ; >> hotspot-compiler-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 >>>>>>> ; hotspot-compiler- >> dev at openjdk.java.net; >>>>>>> 'hotspot-runtime-dev at openjdk.java.net' >>>>>> 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 ; >>>>>>>>>> hotspot-compiler- >>>>>>>>>> dev at openjdk.java.net; 'hotspot-runtime-dev at openjdk.java.net' >>>>>>>>>> >>>>>>>>> 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 ; >> hotspot- >>>>>>> compiler- >>>>>>>>>>>> dev at openjdk.java.net; 'hotspot-runtime- >> dev at openjdk.java.net' >>>>>>> >>>>>>>>>>> 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 ; >>>>>>>>>>>>>> 'daniel.daugherty at oracle.com' >> ; >>>>>>>>>> 'hotspot- >>>>>>>>>>>>>> runtime-dev at openjdk.java.net' >>>>>> 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 ; >>>>>>>>>>>>>>>> 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 ; >>>>>>>>>>>>>>>>> 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 ; >> David >>>>>>>>>> Holmes >>>>>>>>>>>>>>>>>>> ; 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 ; >>>>>>>>>>>>>>>>>>>>> Lindenmaier, >>>>>>>>>> Goetz >>>>>>>>>>>>>>>>>>>>> ; 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 >> ; >>>>>>>>>> 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: >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>> >>>> >>>> >>> >>> > From boris.molodenkov at oracle.com Mon Dec 5 13:06:47 2016 From: boris.molodenkov at oracle.com (Boris Molodenkov) Date: Mon, 5 Dec 2016 16:06:47 +0300 Subject: RFR: 8170464: Remove shell script from compiler/c2/cr7005594/Test7005594.java Message-ID: <0fd73258-0865-8062-d3ca-a9797d4f0f9c@oracle.com> Hi All, Could you please review shell script removal from compiler test. Test used shell script to check available memory size and message "Could not reserve enough space" in output. Test was slightly changed. Now it allocates array of 2 bytes instead of 1GB as in original. Tested locally that issue is reproduced with JDK7 b120. JBS: https://bugs.openjdk.java.net/browse/JDK-8170464 Webrev: http://cr.openjdk.java.net/~bmoloden/8170464/webrev.00/ Thanks, Boris From jamsheed.c.m at oracle.com Mon Dec 5 14:01:35 2016 From: jamsheed.c.m at oracle.com (Jamsheed C m) Date: Mon, 5 Dec 2016 19:31:35 +0530 Subject: RFR: 8166002: Emulate client build on platforms with reduced virtual address space In-Reply-To: <3DCDF924-B89F-4833-AE33-B1123A3EFD35@oracle.com> References: <12de5f29-f773-11df-c397-f699f6ede7c3@oracle.com> <5812F65E.5010703@oracle.com> <58139658.1010706@oracle.com> <21DE287E-E195-4824-8259-9C3237DFFE1E@oracle.com> <30b01249-29d3-dfa5-2c0a-c7788780ca73@oracle.com> <6106172a-a87d-f82e-467c-61677589cbfd@oracle.com> <3DCDF924-B89F-4833-AE33-B1123A3EFD35@oracle.com> Message-ID: <6501518c-f146-83b7-11ff-7a594677ac92@oracle.com> Hi Igor, On 12/4/2016 12:28 AM, Igor Veresov wrote: > I really think you should consider creating a new compilation policy instead of hacking the existing tiered one. > The easy way of doing that would be to subclass SimpleThresholdPolicy and override: > 1. initialize() to setup the number of c1 threads to 1 and c2 threads to 0. > 2. method_invocation_event and method_back_branch_event to handle level transitions. > > In the event handlers you would check method counters. You may emulate the old policy by triggering compiles when i + b > CompileThreshold. > When a method is ready to compile you would call compile(). > > I think a separate policy is easier because you won?t have to deal with the fact that the tiered policy is really design with having all these compilation levels in mind. For example you won?t have to set TieredStopAtLevel, etc. > > Also instead of is_client_compilation_mode_vm() I?d rather add a method the policy. For example ?is_tiered_policy?, or simply check CompilerPolicy::policy()->compiler_count(CompLevel_full_optimization) == 0. > > What do you think? I agree. Should i be using CompileThreshold or new flags Tier1CompileThreshold.. ? Best Regards, Jamsheed > > igor > > >> On Dec 2, 2016, at 7:38 AM, Jamsheed C m wrote: >> >> Hi Vladimir, Igor, >> >> I made a few more changes to include the optimization that was available only on client. >> 1) a few c1 changes (JDK-7153771 ..) >> >> 2) Made SerialGC as default GC. >> 3) Set CICompileCount=1 for client compilation mode. >> 4) Tuned thresholds to get better performance. >> >> 5) Added relevant flags in few tests, modified TestSelectDefaultGC.java. >> >> revised webrev: http://cr.openjdk.java.net/~jcm/8166002/webrev.03/ >> >> performance report is added in bug report. >> Best Regards, >> >> Jamsheed >> >> >> On 11/1/2016 1:14 AM, Vladimir Kozlov wrote: >>> webrev.02 looks good to me too. >>> >>> Thanks, >>> Vladimri >>> >>> On 10/31/16 10:39 AM, Igor Veresov wrote: >>>> Jamsheed explained to me that ReservedCodeCacheSize is now set in the else clause (udiffs are not showing the proper alignment and I missed it). The change looks good to me. >>>> >>>> igor >>>> >>>>> On Oct 31, 2016, at 9:42 AM, Igor Veresov wrote: >>>>> >>>>> Assuming it gets the performance/startup numbers close to the client VM it looks fine. >>>>> But what about adjusting the code cache sizes? With tiered we get 240M ReservedCodeCacheSize, which also turns on SegmentedCodeCache. It seems like we won?t need the ?profiled? segment of the code cache at all. It is also likely that we?d do fine with a smaller overall code cache. >>>>> >>>>> igor >>>>> >>>>>> On Oct 31, 2016, at 9:14 AM, Jamsheed C m wrote: >>>>>> >>>>>> Hi Vladimir, Igor, >>>>>> >>>>>> revised webrev: http://cr.openjdk.java.net/~jcm/8166002/webrev.02/ >>>>>> >>>>>> i took flags from bug comment. >>>>>> >>>>>> Igor V. suggested next flags setting to emulate Client VM compile threshold with TieredStopAtLevel=1: >>>>>> >>>>>> Tier3BackEdgeThreshold=14000 >>>>>> Tier3CompileThreshold=1500 >>>>>> Tier3InvocationThreshold=1500 >>>>>> Tier3MinInvocationThreshold =1500 >>>>>> >>>>>> Best Regards, >>>>>> >>>>>> Jamsheed >>>>>> >>>>>> On 10/28/2016 11:48 PM, Vladimir Kozlov wrote: >>>>>>> Add comment what the code does and why. Move the code into separate function reaturning bool. And condition CodeCache setting based on result. It will reduce #ifdef mess. >>>>>>> >>>>>>> Can you put && to the end of previous line? To get good alignment. >>>>>>> Should we also change CompilationPolicyChoice? >>>>>>> >>>>>>> Ask Igor Veresov to verify settings. >>>>>>> >>>>>>> Thanks, >>>>>>> Vladimir >>>>>>> >>>>>>> On 10/28/16 10:59 AM, Jamsheed C m wrote: >>>>>>>> Hi Vladimir, >>>>>>>> >>>>>>>> revised webrev with just ergo settings for win32. >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~jcm/8166002/webrev.01/ >>>>>>>> >>>>>>>> Best Regards >>>>>>>> >>>>>>>> Jamsheed >>>>>>>> >>>>>>>> >>>>>>>> On 10/28/2016 12:25 PM, Vladimir Kozlov wrote: >>>>>>>>> Hi Jamsheed, >>>>>>>>> >>>>>>>>> Why you need changes in tests? >>>>>>>>> >>>>>>>>> Why you can't use set_client_compilation_mode() in both places? >>>>>>>>> >>>>>>>>> Looks fine otherwise. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Vladimir >>>>>>>>> >>>>>>>>> On 10/20/16 8:45 AM, Jamsheed C m wrote: >>>>>>>>>> Hi All, >>>>>>>>>> >>>>>>>>>> bug id:https://bugs.openjdk.java.net/browse/JDK-8166002 >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~jcm/8166002/webrev.00/ >>>>>>>>>> >>>>>>>>>> Fix: set NeverActAsServerClassMachine=true, Limit TieredCompilation to C1 by default, for win32 platform. >>>>>>>>>> >>>>>>>>>> A new flag CompilationMode= is introduced to select server/ client mode compilation. This option is supported only in TIERED builds. >>>>>>>>>> >>>>>>>>>> -XX:CompilationMode=server supports both -XX:+/-TieredCompilation. >>>>>>>>>> >>>>>>>>>> -XX:CompilationMode:client ignores TieredCompilation flag. >>>>>>>>>> >>>>>>>>>> Please review, >>>>>>>>>> >>>>>>>>>> Best Regards, >>>>>>>>>> >>>>>>>>>> Jamsheed >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> From jamsheed.c.m at oracle.com Mon Dec 5 14:21:12 2016 From: jamsheed.c.m at oracle.com (Jamsheed C m) Date: Mon, 5 Dec 2016 19:51:12 +0530 Subject: RFR: 8166002: Emulate client build on platforms with reduced virtual address space In-Reply-To: <58422EB0.4080205@oracle.com> References: <12de5f29-f773-11df-c397-f699f6ede7c3@oracle.com> <5812F65E.5010703@oracle.com> <58139658.1010706@oracle.com> <21DE287E-E195-4824-8259-9C3237DFFE1E@oracle.com> <30b01249-29d3-dfa5-2c0a-c7788780ca73@oracle.com> <6106172a-a87d-f82e-467c-61677589cbfd@oracle.com> <58422EB0.4080205@oracle.com> Message-ID: <9e9dca8d-9938-7c3d-e631-a69a8bc9d782@oracle.com> Hi Vladimir, On 12/3/2016 8:02 AM, Vladimir Kozlov wrote: > On 12/2/16 7:38 AM, Jamsheed C m wrote: >> Hi Vladimir, Igor, >> >> I made a few more changes to include the optimization that was >> available only on client. >> >> 1) a few c1 changes (JDK-7153771..) > > Which one? This one. src/share/vm/c1/c1_Compilation.hpp // will compilation make optimistic assumptions that might lead to // deoptimization and that the runtime will account for? bool is_optimistic() const { - return !TieredCompilation && + return is_client_compilation_mode_vm() && (RangeCheckElimination || UseLoopInvariantCodeMotion) && method()->method_data()->trap_count(Deoptimization::Reason_none) == 0; } src/share/vm/c1/c1_Runtime1.cpp - assert(!TieredCompilation, "incompatible with tiered compilation"); + assert(is_client_compilation_mode_vm(), "incompatible in non client modes"); mpegaudio was about 6% low without this. >> >> 2) Made SerialGC as default GC. > > Should be only for client_compilation_mode Ok. > >> >> 3) Set CICompileCount=1 for client compilation mode. > > I think check should be is_client_compilation_mode_vm() Ok. Best Regards, Jamsheed > >> >> 4) Tuned thresholds to get better performance. > > ok > >> >> 5) Added relevant flags in few tests, modified TestSelectDefaultGC.java. > > ok > > Thanks, > Vladimir > >> >> revised webrev: http://cr.openjdk.java.net/~jcm/8166002/webrev.03/ >> >> performance report is added in bug report. >> >> Best Regards, >> >> Jamsheed >> >> >> >> On 11/1/2016 1:14 AM, Vladimir Kozlov wrote: >>> webrev.02 looks good to me too. >>> >>> Thanks, >>> Vladimri >>> >>> On 10/31/16 10:39 AM, Igor Veresov wrote: >>>> Jamsheed explained to me that ReservedCodeCacheSize is now set in >>>> the else clause (udiffs are not showing the proper alignment and I >>>> missed it). The change looks good to me. >>>> >>>> igor >>>> >>>>> On Oct 31, 2016, at 9:42 AM, Igor Veresov >>>>> wrote: >>>>> >>>>> Assuming it gets the performance/startup numbers close to the >>>>> client VM it looks fine. >>>>> But what about adjusting the code cache sizes? With tiered we get >>>>> 240M ReservedCodeCacheSize, which also turns on >>>>> SegmentedCodeCache. It seems like we won?t need the ?profiled? >>>>> segment of the code >>>>> cache at all. It is also likely that we?d do fine with a smaller >>>>> overall code cache. >>>>> >>>>> igor >>>>> >>>>>> On Oct 31, 2016, at 9:14 AM, Jamsheed C m >>>>>> wrote: >>>>>> >>>>>> Hi Vladimir, Igor, >>>>>> >>>>>> revised webrev: http://cr.openjdk.java.net/~jcm/8166002/webrev.02/ >>>>>> >>>>>> i took flags from bug comment. >>>>>> >>>>>> Igor V. suggested next flags setting to emulate Client VM compile >>>>>> threshold with TieredStopAtLevel=1: >>>>>> >>>>>> Tier3BackEdgeThreshold=14000 >>>>>> Tier3CompileThreshold=1500 >>>>>> Tier3InvocationThreshold=1500 >>>>>> Tier3MinInvocationThreshold =1500 >>>>>> >>>>>> Best Regards, >>>>>> >>>>>> Jamsheed >>>>>> >>>>>> On 10/28/2016 11:48 PM, Vladimir Kozlov wrote: >>>>>>> Add comment what the code does and why. Move the code into >>>>>>> separate function reaturning bool. And condition CodeCache >>>>>>> setting based on result. It will reduce #ifdef mess. >>>>>>> >>>>>>> Can you put && to the end of previous line? To get good alignment. >>>>>>> Should we also change CompilationPolicyChoice? >>>>>>> >>>>>>> Ask Igor Veresov to verify settings. >>>>>>> >>>>>>> Thanks, >>>>>>> Vladimir >>>>>>> >>>>>>> On 10/28/16 10:59 AM, Jamsheed C m wrote: >>>>>>>> Hi Vladimir, >>>>>>>> >>>>>>>> revised webrev with just ergo settings for win32. >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~jcm/8166002/webrev.01/ >>>>>>>> >>>>>>>> Best Regards >>>>>>>> >>>>>>>> Jamsheed >>>>>>>> >>>>>>>> >>>>>>>> On 10/28/2016 12:25 PM, Vladimir Kozlov wrote: >>>>>>>>> Hi Jamsheed, >>>>>>>>> >>>>>>>>> Why you need changes in tests? >>>>>>>>> >>>>>>>>> Why you can't use set_client_compilation_mode() in both places? >>>>>>>>> >>>>>>>>> Looks fine otherwise. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Vladimir >>>>>>>>> >>>>>>>>> On 10/20/16 8:45 AM, Jamsheed C m wrote: >>>>>>>>>> Hi All, >>>>>>>>>> >>>>>>>>>> bug id:https://bugs.openjdk.java.net/browse/JDK-8166002 >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net/~jcm/8166002/webrev.00/ >>>>>>>>>> >>>>>>>>>> Fix: set NeverActAsServerClassMachine=true, Limit >>>>>>>>>> TieredCompilation to C1 by default, for win32 platform. >>>>>>>>>> >>>>>>>>>> A new flag CompilationMode= is introduced to >>>>>>>>>> select server/ client mode compilation. This option is >>>>>>>>>> supported only in TIERED builds. >>>>>>>>>> >>>>>>>>>> -XX:CompilationMode=server supports both >>>>>>>>>> -XX:+/-TieredCompilation. >>>>>>>>>> >>>>>>>>>> -XX:CompilationMode:client ignores TieredCompilation flag. >>>>>>>>>> >>>>>>>>>> Please review, >>>>>>>>>> >>>>>>>>>> Best Regards, >>>>>>>>>> >>>>>>>>>> Jamsheed >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>> >>>>> >>>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.daugherty at oracle.com Mon Dec 5 14:36:58 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Mon, 5 Dec 2016 07:36:58 -0700 Subject: RFR(M): 8169373: Work around linux NPTL stack guard error. In-Reply-To: References: <24078321-9ca8-28e8-3895-59b09ab398f5@oracle.com> <4dfa4ae6-4fa6-994c-f2cf-8fc309d8c520@oracle.com> <821371d77c7c4e6d966901b461b3d6a1@DEROTE13DE08.global.corp.sap> <49acd657-aefa-b935-1b2c-195fc2d125ba@oracle.com> <04825132c7fd4f92a06057cecc3f9329@DEROTE13DE08.global.corp.sap> <4abd1e03-27a2-4778-d1b0-09a952ccb525@oracle.com> <1111dc02-5d8f-3b50-b5f3-160c33474ace@oracle.com> <6ded66cf-558e-f6ce-7dff-7441992eb2ea@oracle.com> Message-ID: <371058eb-4e55-3ebd-6ce3-848628f96764@oracle.com> 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_.cpp file. I will be working on this AM (my TZ). Thanks for the info! 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 ; Lindenmaier, Goetz >>> ; David Holmes ; >>> hotspot-compiler-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 >>>>>>>> ; hotspot-compiler- >>> dev at openjdk.java.net; >>>>>>>> 'hotspot-runtime-dev at openjdk.java.net' >>>>>>> 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 ; >>>>>>>>>>> hotspot-compiler- >>>>>>>>>>> dev at openjdk.java.net; 'hotspot-runtime-dev at openjdk.java.net' >>>>>>>>>>> >>>>>>>>>> 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 ; >>> hotspot- >>>>>>>> compiler- >>>>>>>>>>>>> dev at openjdk.java.net; 'hotspot-runtime- >>> dev at openjdk.java.net' >>>>>>>> >>>>>>>>>>>> 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 ; >>>>>>>>>>>>>>> 'daniel.daugherty at oracle.com' >>> ; >>>>>>>>>>> 'hotspot- >>>>>>>>>>>>>>> runtime-dev at openjdk.java.net' >>>>>>> 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 ; >>>>>>>>>>>>>>>>> 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 ; >>>>>>>>>>>>>>>>>> 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 ; >>> David >>>>>>>>>>> Holmes >>>>>>>>>>>>>>>>>>>> ; 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 ; >>>>>>>>>>>>>>>>>>>>>> Lindenmaier, >>>>>>>>>>> Goetz >>>>>>>>>>>>>>>>>>>>>> ; 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 >>> ; >>>>>>>>>>> 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: >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>> >>>>> >>>>> >>>> >>>> >> From daniel.daugherty at oracle.com Mon Dec 5 14:39:12 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Mon, 5 Dec 2016 07:39:12 -0700 Subject: RFR(M): 8169373: Work around linux NPTL stack guard error. In-Reply-To: References: <24078321-9ca8-28e8-3895-59b09ab398f5@oracle.com> <4dfa4ae6-4fa6-994c-f2cf-8fc309d8c520@oracle.com> <821371d77c7c4e6d966901b461b3d6a1@DEROTE13DE08.global.corp.sap> <49acd657-aefa-b935-1b2c-195fc2d125ba@oracle.com> <04825132c7fd4f92a06057cecc3f9329@DEROTE13DE08.global.corp.sap> <4abd1e03-27a2-4778-d1b0-09a952ccb525@oracle.com> <1111dc02-5d8f-3b50-b5f3-160c33474ace@oracle.com> <6ded66cf-558e-f6ce-7dff-7441992eb2ea@oracle.com> Message-ID: <1e74a7c4-82f2-0dd9-6dbc-b860c51a322e@oracle.com> On 12/3/16 10: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'll also resync to this latest version this AM (my TZ). I thought the previous webrev was the "final" version... Dan > > I hope this does not invalidate the testing you already did. > > Will the closed port issue go away if arm is submitted to openJdk? > > Best regards, > Goetz. > > > >> -----Original Message----- >> From: Daniel D. Daugherty [mailto:daniel.daugherty at oracle.com] >> Sent: Saturday, December 03, 2016 1:03 AM >> To: Vladimir Kozlov ; Lindenmaier, Goetz >> ; David Holmes ; >> hotspot-compiler-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 >>>>>>> ; hotspot-compiler- >> dev at openjdk.java.net; >>>>>>> 'hotspot-runtime-dev at openjdk.java.net' >>>>>> 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 ; >>>>>>>>>> hotspot-compiler- >>>>>>>>>> dev at openjdk.java.net; 'hotspot-runtime-dev at openjdk.java.net' >>>>>>>>>> >>>>>>>>> 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 ; >> hotspot- >>>>>>> compiler- >>>>>>>>>>>> dev at openjdk.java.net; 'hotspot-runtime- >> dev at openjdk.java.net' >>>>>>> >>>>>>>>>>> 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 ; >>>>>>>>>>>>>> 'daniel.daugherty at oracle.com' >> ; >>>>>>>>>> 'hotspot- >>>>>>>>>>>>>> runtime-dev at openjdk.java.net' >>>>>> 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 ; >>>>>>>>>>>>>>>> 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 ; >>>>>>>>>>>>>>>>> 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 ; >> David >>>>>>>>>> Holmes >>>>>>>>>>>>>>>>>>> ; 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 ; >>>>>>>>>>>>>>>>>>>>> Lindenmaier, >>>>>>>>>> Goetz >>>>>>>>>>>>>>>>>>>>> ; 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 >> ; >>>>>>>>>> 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: >>>>>>>>>>>>>>>>>>>>>>>>> >>>> >>> > From vladimir.kozlov at oracle.com Mon Dec 5 17:09:16 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 5 Dec 2016 09:09:16 -0800 Subject: RFR: 8170464: Remove shell script from compiler/c2/cr7005594/Test7005594.java In-Reply-To: <0fd73258-0865-8062-d3ca-a9797d4f0f9c@oracle.com> References: <0fd73258-0865-8062-d3ca-a9797d4f0f9c@oracle.com> Message-ID: <58459F3C.7010204@oracle.com> You changed test behavior. The loop should execute 3 iterations to hit the problem (to execute main-loop after iterations split loop optimization). Please, verify that 7005594 problem is reproduced with old JVM. Vladimir On 12/5/16 5:06 AM, Boris Molodenkov wrote: > Hi All, > > Could you please review shell script removal from compiler test. > > Test used shell script to check available memory size and message "Could not reserve enough space" in output. > Test was slightly changed. Now it allocates array of 2 bytes instead of 1GB as in original. > Tested locally that issue is reproduced with JDK7 b120. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8170464 > Webrev: http://cr.openjdk.java.net/~bmoloden/8170464/webrev.00/ > > Thanks, > Boris > From martin.doerr at sap.com Mon Dec 5 17:09:56 2016 From: martin.doerr at sap.com (Doerr, Martin) Date: Mon, 5 Dec 2016 17:09:56 +0000 Subject: [JBS] {New} (JDK-8170430) x86 pow() stub from Intel libm is inconsistent with pow() from fdlib Message-ID: Hi Vladimir and Vivek, thank you very much for filing the bug. I guess x86 is fine, but other platforms return NULL for many entries in generate_math_entry. That means the interpreter's normal entry will be used which interprets the Math function which calls the StrictMath one. So finally, the interpreter will compute exact results, while the compilers use the SharedRuntime implementation. Best regards, Martin -----Original Message----- From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] Sent: Samstag, 3. Dezember 2016 01:22 To: Deshpande, Vivek R ; Doerr, Martin ; Andrew Haley ; hotspot-compiler-dev at openjdk.java.net Subject: Re: [JBS] {New} (JDK-8170430) x86 pow() stub from Intel libm is inconsistent with pow() from fdlib First, 8170430 is already fixed to resolve issue with libm code. http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/5a6125eb47aa Yes, we still have discrepancy between Interpreter and JIT compilers when InlineIntrinsics is off. But we had it for long time. I agree with Martin that we should have a shared code (for Interpreter and JIT compilers) which choose what to call depending on flags. I filed Bug for jdk 10: https://bugs.openjdk.java.net/browse/JDK-8170693 Regards, Vladimir On 12/2/16 2:17 PM, Deshpande, Vivek R wrote: > Hi Martin > > With the current solution with -InlineIntrinsics it does not go to either SharedRuntime function or Libm based function when its interpreted and goes to SharedRuntime function with C1 and C2. > So removing this line > if (!InlineIntrinsics) return NULL; // Generate a vanilla entry > from generate_math_entry() seems a correct way, so that with with -InlineIntrinsics option it will always go to SharedRuntime function. > > Vladimir, could you please let me know if this sounds ok to you. > > Regards, > Vivek > -----Original Message----- > From: hotspot-compiler-dev > [mailto:hotspot-compiler-dev-bounces at openjdk.java.net] On Behalf Of > Doerr, Martin > Sent: Thursday, December 01, 2016 10:07 AM > To: Andrew Haley; hotspot-compiler-dev at openjdk.java.net > Subject: RE: [JBS] {New} (JDK-8170430) x86 pow() stub from Intel libm > is inconsistent with pow() from fdlib > > Hi Andrew, > > sounds like a good idea. > > At least, the following functions should by in sync: > Interpreter: TemplateInterpreterGenerator::generate_math_entry > C1: LIRGenerator::do_MathIntrinsic > C2: LibraryCallKit::inline_math_native > > I think it would be nice to have tables in shared code which translate the respective MethodKind or vmIntrinsics to the function pointers of the SharedRuntime functions. > I don't like all function calls to get replicated for all platforms. > > E.g. generate_math_entry could handle platform specific intrinsics first. If none is available, it could just call the SharedRuntime function retrieved from the shared table. > > I believe generate_math_entry should never return 0 because that would mean ending up in StrictMath while C1 and C2 use the SharedRuntime functions. Right? > > Best regards, > Martin > > > -----Original Message----- > From: hotspot-compiler-dev > [mailto:hotspot-compiler-dev-bounces at openjdk.java.net] On Behalf Of > Andrew Haley > Sent: Donnerstag, 1. Dezember 2016 10:15 > To: hotspot-compiler-dev at openjdk.java.net > Subject: Re: [JBS] {New} (JDK-8170430) x86 pow() stub from Intel libm > is inconsistent with pow() from fdlib > > I think we should fix up the interpreter and all JITs to call the common routines. It's not hard, and it will fix non-monotonic behaviour. > > Andrew. > From daniel.daugherty at oracle.com Mon Dec 5 18:38:04 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Mon, 5 Dec 2016 11:38:04 -0700 Subject: RFR(M): 8169373: Work around linux NPTL stack guard error. In-Reply-To: <371058eb-4e55-3ebd-6ce3-848628f96764@oracle.com> References: <24078321-9ca8-28e8-3895-59b09ab398f5@oracle.com> <4dfa4ae6-4fa6-994c-f2cf-8fc309d8c520@oracle.com> <821371d77c7c4e6d966901b461b3d6a1@DEROTE13DE08.global.corp.sap> <49acd657-aefa-b935-1b2c-195fc2d125ba@oracle.com> <04825132c7fd4f92a06057cecc3f9329@DEROTE13DE08.global.corp.sap> <4abd1e03-27a2-4778-d1b0-09a952ccb525@oracle.com> <1111dc02-5d8f-3b50-b5f3-160c33474ace@oracle.com> <6ded66cf-558e-f6ce-7dff-7441992eb2ea@oracle.com> <371058eb-4e55-3ebd-6ce3-848628f96764@oracle.com> Message-ID: 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_.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 ; Lindenmaier, Goetz >>>> ; David Holmes ; >>>> hotspot-compiler-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 >>>>>>>>> ; hotspot-compiler- >>>> dev at openjdk.java.net; >>>>>>>>> 'hotspot-runtime-dev at openjdk.java.net' >>>>>>>> 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 ; >>>>>>>>>>>> hotspot-compiler- >>>>>>>>>>>> dev at openjdk.java.net; 'hotspot-runtime-dev at openjdk.java.net' >>>>>>>>>>>> >>>>>>>>>>> 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 ; >>>> hotspot- >>>>>>>>> compiler- >>>>>>>>>>>>>> dev at openjdk.java.net; 'hotspot-runtime- >>>> dev at openjdk.java.net' >>>>>>>>> >>>>>>>>>>>>> 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 ; >>>>>>>>>>>>>>>> 'daniel.daugherty at oracle.com' >>>> ; >>>>>>>>>>>> 'hotspot- >>>>>>>>>>>>>>>> runtime-dev at openjdk.java.net' >>>>>>>> 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 ; >>>>>>>>>>>>>>>>>> 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 ; >>>>>>>>>>>>>>>>>>> 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 ; >>>> David >>>>>>>>>>>> Holmes >>>>>>>>>>>>>>>>>>>>> ; 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 ; >>>>>>>>>>>>>>>>>>>>>>> Lindenmaier, >>>>>>>>>>>> Goetz >>>>>>>>>>>>>>>>>>>>>>> ; 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 >>>> ; >>>>>>>>>>>> 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: >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>> > > From vladimir.kozlov at oracle.com Mon Dec 5 18:52:59 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 5 Dec 2016 10:52:59 -0800 Subject: RFR: 8166002: Emulate client build on platforms with reduced virtual address space In-Reply-To: <9e9dca8d-9938-7c3d-e631-a69a8bc9d782@oracle.com> References: <12de5f29-f773-11df-c397-f699f6ede7c3@oracle.com> <5812F65E.5010703@oracle.com> <58139658.1010706@oracle.com> <21DE287E-E195-4824-8259-9C3237DFFE1E@oracle.com> <30b01249-29d3-dfa5-2c0a-c7788780ca73@oracle.com> <6106172a-a87d-f82e-467c-61677589cbfd@oracle.com> <58422EB0.4080205@oracle.com> <9e9dca8d-9938-7c3d-e631-a69a8bc9d782@oracle.com> Message-ID: <5845B78B.2090405@oracle.com> On 12/5/16 6:21 AM, Jamsheed C m wrote: > Hi Vladimir, > > On 12/3/2016 8:02 AM, Vladimir Kozlov wrote: >> On 12/2/16 7:38 AM, Jamsheed C m wrote: >>> Hi Vladimir, Igor, >>> >>> I made a few more changes to include the optimization that was available only on client. >>> >>> 1) a few c1 changes (JDK-7153771..) >> >> Which one? > This one. I see. Thanks, Vladimir > src/share/vm/c1/c1_Compilation.hpp > > // will compilation make optimistic assumptions that might lead to > // deoptimization and that the runtime will account for? > bool is_optimistic() const { > - return !TieredCompilation && > + return is_client_compilation_mode_vm() && > (RangeCheckElimination || UseLoopInvariantCodeMotion) && > method()->method_data()->trap_count(Deoptimization::Reason_none) == 0; > } > > src/share/vm/c1/c1_Runtime1.cpp > - assert(!TieredCompilation, "incompatible with tiered compilation"); > + assert(is_client_compilation_mode_vm(), "incompatible in non client modes"); > > mpegaudio was about 6% low without this. > >>> >>> 2) Made SerialGC as default GC. >> >> Should be only for client_compilation_mode > Ok. >> >>> >>> 3) Set CICompileCount=1 for client compilation mode. >> >> I think check should be is_client_compilation_mode_vm() > Ok. > Best Regards, > Jamsheed >> >>> >>> 4) Tuned thresholds to get better performance. >> >> ok >> >>> >>> 5) Added relevant flags in few tests, modified TestSelectDefaultGC.java. >> >> ok >> >> Thanks, >> Vladimir >> >>> >>> revised webrev: http://cr.openjdk.java.net/~jcm/8166002/webrev.03/ >>> >>> performance report is added in bug report. >>> >>> Best Regards, >>> >>> Jamsheed >>> >>> >>> >>> On 11/1/2016 1:14 AM, Vladimir Kozlov wrote: >>>> webrev.02 looks good to me too. >>>> >>>> Thanks, >>>> Vladimri >>>> >>>> On 10/31/16 10:39 AM, Igor Veresov wrote: >>>>> Jamsheed explained to me that ReservedCodeCacheSize is now set in the else clause (udiffs are not showing the proper alignment and I missed it). The change looks good to me. >>>>> >>>>> igor >>>>> >>>>>> On Oct 31, 2016, at 9:42 AM, Igor Veresov wrote: >>>>>> >>>>>> Assuming it gets the performance/startup numbers close to the client VM it looks fine. >>>>>> But what about adjusting the code cache sizes? With tiered we get 240M ReservedCodeCacheSize, which also turns on SegmentedCodeCache. It seems like we won?t need the ?profiled? segment of the code >>>>>> cache at all. It is also likely that we?d do fine with a smaller overall code cache. >>>>>> >>>>>> igor >>>>>> >>>>>>> On Oct 31, 2016, at 9:14 AM, Jamsheed C m wrote: >>>>>>> >>>>>>> Hi Vladimir, Igor, >>>>>>> >>>>>>> revised webrev: http://cr.openjdk.java.net/~jcm/8166002/webrev.02/ >>>>>>> >>>>>>> i took flags from bug comment. >>>>>>> >>>>>>> Igor V. suggested next flags setting to emulate Client VM compile threshold with TieredStopAtLevel=1: >>>>>>> >>>>>>> Tier3BackEdgeThreshold=14000 >>>>>>> Tier3CompileThreshold=1500 >>>>>>> Tier3InvocationThreshold=1500 >>>>>>> Tier3MinInvocationThreshold =1500 >>>>>>> >>>>>>> Best Regards, >>>>>>> >>>>>>> Jamsheed >>>>>>> >>>>>>> On 10/28/2016 11:48 PM, Vladimir Kozlov wrote: >>>>>>>> Add comment what the code does and why. Move the code into separate function reaturning bool. And condition CodeCache setting based on result. It will reduce #ifdef mess. >>>>>>>> >>>>>>>> Can you put && to the end of previous line? To get good alignment. >>>>>>>> Should we also change CompilationPolicyChoice? >>>>>>>> >>>>>>>> Ask Igor Veresov to verify settings. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Vladimir >>>>>>>> >>>>>>>> On 10/28/16 10:59 AM, Jamsheed C m wrote: >>>>>>>>> Hi Vladimir, >>>>>>>>> >>>>>>>>> revised webrev with just ergo settings for win32. >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~jcm/8166002/webrev.01/ >>>>>>>>> >>>>>>>>> Best Regards >>>>>>>>> >>>>>>>>> Jamsheed >>>>>>>>> >>>>>>>>> >>>>>>>>> On 10/28/2016 12:25 PM, Vladimir Kozlov wrote: >>>>>>>>>> Hi Jamsheed, >>>>>>>>>> >>>>>>>>>> Why you need changes in tests? >>>>>>>>>> >>>>>>>>>> Why you can't use set_client_compilation_mode() in both places? >>>>>>>>>> >>>>>>>>>> Looks fine otherwise. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Vladimir >>>>>>>>>> >>>>>>>>>> On 10/20/16 8:45 AM, Jamsheed C m wrote: >>>>>>>>>>> Hi All, >>>>>>>>>>> >>>>>>>>>>> bug id:https://bugs.openjdk.java.net/browse/JDK-8166002 >>>>>>>>>>> >>>>>>>>>>> http://cr.openjdk.java.net/~jcm/8166002/webrev.00/ >>>>>>>>>>> >>>>>>>>>>> Fix: set NeverActAsServerClassMachine=true, Limit TieredCompilation to C1 by default, for win32 platform. >>>>>>>>>>> >>>>>>>>>>> A new flag CompilationMode= is introduced to select server/ client mode compilation. This option is supported only in TIERED builds. >>>>>>>>>>> >>>>>>>>>>> -XX:CompilationMode=server supports both -XX:+/-TieredCompilation. >>>>>>>>>>> >>>>>>>>>>> -XX:CompilationMode:client ignores TieredCompilation flag. >>>>>>>>>>> >>>>>>>>>>> Please review, >>>>>>>>>>> >>>>>>>>>>> Best Regards, >>>>>>>>>>> >>>>>>>>>>> Jamsheed >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> >>>>>>> >>>>>> >>>>> >>> > From shrinivas.joshi at oracle.com Mon Dec 5 22:01:07 2016 From: shrinivas.joshi at oracle.com (Shrinivas Joshi) Date: Mon, 05 Dec 2016 14:01:07 -0800 Subject: RFR(S): 8158012: Use SW prefetch instructions instead of BIS for allocation prefetches on SPARC Core S4 Message-ID: <5845E3A3.4070603@oracle.com> Hi, Please review this small change which sets the default allocation prefetch mechanism on Oracle SPARC Core S4 processor based systems to use explicit SW prefetch instructions instead of Block Init Store(BIS) instructions. Bug: http://bugs.openjdk.java.net/browse/JDK-8158012 Webrev: http://cr.openjdk.java.net/~kvn/8158012/webrev.00/ Tested with JTREG and JPRT. Thanks, -Shrinivas From goetz.lindenmaier at sap.com Mon Dec 5 22:09:05 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 5 Dec 2016 22:09:05 +0000 Subject: RFR(M): 8169373: Work around linux NPTL stack guard error. In-Reply-To: References: <24078321-9ca8-28e8-3895-59b09ab398f5@oracle.com> <4dfa4ae6-4fa6-994c-f2cf-8fc309d8c520@oracle.com> <821371d77c7c4e6d966901b461b3d6a1@DEROTE13DE08.global.corp.sap> <49acd657-aefa-b935-1b2c-195fc2d125ba@oracle.com> <04825132c7fd4f92a06057cecc3f9329@DEROTE13DE08.global.corp.sap> <4abd1e03-27a2-4778-d1b0-09a952ccb525@oracle.com> <1111dc02-5d8f-3b50-b5f3-160c33474ace@oracle.com> <6ded66cf-558e-f6ce-7dff-7441992eb2ea@oracle.com> <371058eb-4e55-3ebd-6ce3-848628f96764@oracle.com> Message-ID: <8377024f345c46009b33a1f0db9deb9f@DEROTE13DE08.global.corp.sap> Hi Dan, thanks for the testing! Sorry I can't help ... 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 ; Lindenmaier, Goetz > ; Vladimir Kozlov > ; hotspot-compiler-dev at openjdk.java.net; > 'hotspot-runtime-dev at openjdk.java.net' 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_.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 ; Lindenmaier, Goetz > >>>> ; David Holmes > ; > >>>> hotspot-compiler-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 > >>>>>>>>> ; hotspot-compiler- > >>>> dev at openjdk.java.net; > >>>>>>>>> 'hotspot-runtime-dev at openjdk.java.net' >>>>>>>>> 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 ; > >>>>>>>>>>>> hotspot-compiler- > >>>>>>>>>>>> dev at openjdk.java.net; 'hotspot-runtime- > dev at openjdk.java.net' > >>>>>>>>>>>> >>>>>>>>>>>> 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 ; > >>>> hotspot- > >>>>>>>>> compiler- > >>>>>>>>>>>>>> dev at openjdk.java.net; 'hotspot-runtime- > >>>> dev at openjdk.java.net' > >>>>>>>>> >>>>>>>>>>>>>> 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 ; > >>>>>>>>>>>>>>>> 'daniel.daugherty at oracle.com' > >>>> ; > >>>>>>>>>>>> 'hotspot- > >>>>>>>>>>>>>>>> runtime-dev at openjdk.java.net' >>>>>>>>> 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 ; > >>>>>>>>>>>>>>>>>> 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 > ; > >>>>>>>>>>>>>>>>>>> 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 > ; > >>>> David > >>>>>>>>>>>> Holmes > >>>>>>>>>>>>>>>>>>>>> ; 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 ; > >>>>>>>>>>>>>>>>>>>>>>> Lindenmaier, > >>>>>>>>>>>> Goetz > >>>>>>>>>>>>>>>>>>>>>>> ; 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 > >>>> ; > >>>>>>>>>>>> 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: > >>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>> > >>>>>> > >>>>>> > >>>>> > >>>>> > >>> > > > > From daniel.daugherty at oracle.com Mon Dec 5 22:13:03 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Mon, 5 Dec 2016 15:13:03 -0700 Subject: RFR(M): 8169373: Work around linux NPTL stack guard error. In-Reply-To: <8377024f345c46009b33a1f0db9deb9f@DEROTE13DE08.global.corp.sap> References: <4dfa4ae6-4fa6-994c-f2cf-8fc309d8c520@oracle.com> <821371d77c7c4e6d966901b461b3d6a1@DEROTE13DE08.global.corp.sap> <49acd657-aefa-b935-1b2c-195fc2d125ba@oracle.com> <04825132c7fd4f92a06057cecc3f9329@DEROTE13DE08.global.corp.sap> <4abd1e03-27a2-4778-d1b0-09a952ccb525@oracle.com> <1111dc02-5d8f-3b50-b5f3-160c33474ace@oracle.com> <6ded66cf-558e-f6ce-7dff-7441992eb2ea@oracle.com> <371058eb-4e55-3ebd-6ce3-848628f96764@oracle.com> <8377024f345c46009b33a1f0db9deb9f@DEROTE13DE08.global.corp.sap> Message-ID: <462496af-d1b2-2c1f-f869-a98dc48120fb@oracle.com> 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 ; Lindenmaier, Goetz >> ; Vladimir Kozlov >> ; hotspot-compiler-dev at openjdk.java.net; >> 'hotspot-runtime-dev at openjdk.java.net' > 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_.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 ; Lindenmaier, Goetz >>>>>> ; David Holmes >> ; >>>>>> hotspot-compiler-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 >>>>>>>>>>> ; hotspot-compiler- >>>>>> dev at openjdk.java.net; >>>>>>>>>>> 'hotspot-runtime-dev at openjdk.java.net' >>>>>>>>>> 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 ; >>>>>>>>>>>>>> hotspot-compiler- >>>>>>>>>>>>>> dev at openjdk.java.net; 'hotspot-runtime- >> dev at openjdk.java.net' >>>>>>>>>>>>>> >>>>>>>>>>>>> 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 ; >>>>>> hotspot- >>>>>>>>>>> compiler- >>>>>>>>>>>>>>>> dev at openjdk.java.net; 'hotspot-runtime- >>>>>> dev at openjdk.java.net' >>>>>>>>>>> >>>>>>>>>>>>>>> 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 ; >>>>>>>>>>>>>>>>>> 'daniel.daugherty at oracle.com' >>>>>> ; >>>>>>>>>>>>>> 'hotspot- >>>>>>>>>>>>>>>>>> runtime-dev at openjdk.java.net' >>>>>>>>>> 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 ; >>>>>>>>>>>>>>>>>>>> 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 >> ; >>>>>>>>>>>>>>>>>>>>> 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 >> ; >>>>>> David >>>>>>>>>>>>>> Holmes >>>>>>>>>>>>>>>>>>>>>>> ; 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 ; >>>>>>>>>>>>>>>>>>>>>>>>> Lindenmaier, >>>>>>>>>>>>>> Goetz >>>>>>>>>>>>>>>>>>>>>>>>> ; 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 >>>>>> ; >>>>>>>>>>>>>> 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: >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>> >>>>>>> >>> From daniel.daugherty at oracle.com Mon Dec 5 23:27:46 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Mon, 5 Dec 2016 16:27:46 -0700 Subject: RFR(M): 8170655: [posix] Fix minimum stack size computations In-Reply-To: References: Message-ID: On 12/3/16 11:17 AM, Lindenmaier, Goetz wrote: > Hi, > > > > I would like to fix two issues of minimum stack size computation: > > http://cr.openjdk.java.net/~goetz/wr16/8170655-compilerGuardFix/webrev.01/ > > Please review and sponsor. I'm sponsoring the related bug: 8169373 Work around linux NPTL stack guard error https://bugs.openjdk.java.net/browse/JDK-8169373 so I guess I should sponsor this one also... For obvious reasons, this fix will also need a "full RBT" run... > http://cr.openjdk.java.net/~goetz/wr16/8170655-compilerGuardFix/webrev.01/ src/cpu/ppc/vm/globals_ppc.hpp No comments. src/cpu/x86/vm/globals_x86.hpp No comments. src/os/posix/vm/os_posix.cpp My brain read right past where you took out "MAX2" and changed the math to "cur = cur + guard_size + shadow_size". I think I've been staring at that particular line of code for way too long (in a couple of different bug fixes)... I think with your fix that Solaris specific block on L1132 - L1148 can go away (see JDK-8161093). Hopefully Coleen will chime in on just this part. L1154: _compiler_thread_min_stack_allowed = _compiler_thread_min_stack_allowed + Please add a comment above this line: // Reminder: a compiler thread is-a Java thread. src/os/posix/vm/os_posix.hpp L48: // Set_minimum_stack_sizes() ... Please change 'S' -> 's' since it is the function's name. src/os_cpu/aix_ppc/vm/os_aix_ppc.cpp L539: // HotSpotguard pages is added later. Typo: space before 'guard' L542: size_t os::Posix::_vm_internal_thread_min_stack_allowed = 64 * K; VM internal thread size lowered from 128K to 64K without any changes to how _vm_internal_thread_min_stack_allowed is set. Any particular reason for this change? src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp No comments. src/os_cpu/linux_aarch64/vm/os_linux_aarch64.cpp No comments. src/os_cpu/linux_ppc/vm/os_linux_ppc.cpp L542: size_t os::Posix::_vm_internal_thread_min_stack_allowed = 64 * K; VM internal thread size lowered from 128K to 64K without any changes to how _vm_internal_thread_min_stack_allowed is set. Any particular reason for this change? src/os_cpu/linux_s390/vm/os_linux_s390.cpp L478: size_t os::Posix::_compiler_thread_min_stack_allowed = (52 DEBUG_ONLY(+32)) * K; L479: size_t os::Posix::_java_thread_min_stack_allowed = (32 DEBUG_ONLY(+8)) * K; consistency - trying to put space around operators so... '+32' -> '+ 32' '+8' -> '+ 8' L480: size_t os::Posix::_vm_internal_thread_min_stack_allowed = 32 * K; VM internal thread size lowered from 128K to 32K without any changes to how _vm_internal_thread_min_stack_allowed is set. Any particular reason for this change? 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/solaris_sparc/vm/os_solaris_sparc.cpp No comments. src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp No comments. src/share/vm/runtime/os.hpp L439: java_thread, // Java, CocdeCacheSweeper, JVMTIAgent and Service threads. Typo: 'CocdeCacheSweeper' -> 'CodeCacheSweeper' Dan > > > > This are the issues I excluded from the "8169373: Work around linux NPTL stack guard error." > > > > I wrote a lengthy explanation in the bug, trying to comment on what was > > said in the other thread. I'll repeat it here, I think that's better for discussion. > > Dan, thanks for improving the text, I use the improved variant here: > > > > HotSpot has three cmd line options to set stack sizes (besides -Xss): > > -XX:ThreadStackSize for threads executing Java code. > > -XX:CompilerThreadStackSize for threads used by the JIT compilers. > > -XX:VMThreadStackSize for threads executing VM internal tasks as gc. > > > > All these flags should not be set to a value that leads to a stack overflow before user code can be executed. As the VM executes a lot of code for initialization and also the JIT already compiles methods, considerable amounts of stack can be used during startup. We must try to avoid stack overflows before startup is complete as error handling might not be properly in place yet. > > > > Required minimum stack sizes depend on frame sizes and program execution paths. Frame sizes again depend on the C compiler used, the platform compiled for, and design decisions in interpreter, C1 and C2. > > > > Required stack sizes also depend on option settings, e.g. with JVM/TI enabled, frames can get bigger. With inlining increased JIT compilers might do more optimizations leading to deeper call chains, etc. > > > > While the minimum stack sizes should reflect differences in Platform and compiler, they must not, and cannot, cover all possible option settings. > > > > This change addresses two issues: > > > > 1. Fixed minimum stack size configuration > > > > Currently, the minimum Java thread size is given in a constant per os/cpu platform for each of the three stack kinds. This number includes the size required for guard pages. > > > > The guard pages are used for stack overflow detection. They make up 4 zones on the stack: Red, Yellow, Reserved and Shadow pages. The Red, Yellow and Reserved pages are protected to detect stack overflows. The Shadow pages are just some extra space to allow methods that don't do a stack bang to execute. > > > > Unfortunately, the size required for guard pages is not fixed at compile time. It depends on the concrete system the VM is started on. Thus the minimum sizes given can be too small to hold the guard pages. This lead to errors in the past that were solved by introducing code that overruled the per-platform minimum stack size. This code nowadays is the MAX2() in os_posix.cpp:1114 and the SOLARIS special case further down. It uses the value (4 * BytesPerWord COMPILER2_PRESENT(+ 2)) * 4 * K) (os_posix.cpp:1117) as minimum required space for frames. Thereby it effectively overrules the minimum stack size settings given in the os/cpu constants, and there is currently no way to specify this size per platform. > > > > This change proposes to fix this issue by specifying the space needed for stack frames in the os/cpu constants. During startup, this number is increased by the space required for the guard pages. Thus, this takes into account the page size of the concrete system the VM runs on, and also eventual changes to the guard pages by the flags StackRed/Yellow/Reserved/Shadow/Pages. This gives the opportunity to reduce the minimum stack sizes on systems with small pages. > > > > Minimum stack size configuration is more simple with this change and valid for systems with any page size. > > > > 2. Stack guard pages not considered for compiler thread stacks > > > > Compiler threads are Java threads. The C++ class CompilerThread is a subclass of JavaThread. When a compiler thread is started, JavaThread::run() is executed which protects the red, yellow and reserved pages. > > > > Since 8140520 the minimum stack sizes for Compiler and VM internal threads no longer include the space for the guard pages. This is correct for the VM internal threads, but not for the Compiler thread. > > > > For the HotSpot C1 and C2 compilers it would be fine to reserve space for the Red/Yellow/Reserved pages, as they don't stack bang with the shadow page size. But since introducing JVMCI, compilers written in Java can be running on the compiler threads. Therefore the shadow pages are needed, too. > > > > As for the Java thread, this change uses a os/cpu constant for the required minimum space for compiler frames and then adds the zone sizes to the minimum stack sizes during startup. > > > > New sizing: > > > > The constants of the os/cpu minimum thread sizes are reduced by the default guard page sizes and then verified by starting the VM to assure the stack still suffices to get through startup. Hotspot jtreg tests are passing. The overall sizes required (after adding guard pages) on the systems I have available get a bit smaller. In most cases the sizes even suffice to run simple programs as SpecJvm98. The table below gives the systems I tested and the required sizes reported when started with too small stacks. > > > > 
>
>   Thread kind:       Java      Compiler  VM
>
>                      old new   old new   old new
>
>
>
> bsd x86_64    dbg: 240 232    64  64    64  64
>
>                 opt: 240 232    64  64    64  64
>
>
>
> linux x86_64  dbg: 240 144    64 152    64  64
>
>                 opt: 232 136    64 144    64  64
>
>
>
> solaris sparc dbg:
>
>                 opt: 240 192   128 128   128 128
>
>
>
> aix ppc64     dbg: 512 512   384 512   128 128
>
>                 opt: 512 512   384 512   128 128
>
>   linux ppc64   dbg: 512 384   128 384   128  64
>
>                 opt: 512 384   128 384   128  64
>
>   linux ppc64le dbg: 512 384   128 384   128  64
>
>                 opt: 512 384   128 384   128  64
>
>
>
> linux s390    dbg: 236 140   128 184   128  32
>
>                 opt: 236 124   128 144   128  32
>
>
> > > > > > From vladimir.kozlov at oracle.com Mon Dec 5 23:39:57 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 5 Dec 2016 15:39:57 -0800 Subject: RFR(S): 8158012: Use SW prefetch instructions instead of BIS for allocation prefetches on SPARC Core S4 In-Reply-To: <5845E3A3.4070603@oracle.com> References: <5845E3A3.4070603@oracle.com> Message-ID: <5845FACD.9030901@oracle.com> Looks good. Have to wait for approval. Thanks, Vladimir On 12/5/16 2:01 PM, Shrinivas Joshi wrote: > Hi, > > Please review this small change which sets the default allocation prefetch mechanism on Oracle SPARC Core S4 processor based systems to use explicit SW prefetch instructions instead of Block Init > Store(BIS) instructions. > > Bug: http://bugs.openjdk.java.net/browse/JDK-8158012 > Webrev: http://cr.openjdk.java.net/~kvn/8158012/webrev.00/ > > Tested with JTREG and JPRT. > > Thanks, > -Shrinivas From anthony.scarpino at oracle.com Mon Dec 5 23:40:01 2016 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Mon, 5 Dec 2016 15:40:01 -0800 Subject: Use of cryptographic functions from OpenSSL's libcrypto In-Reply-To: <38810c301be44ea99e42f2fe04ae3474@serv030.corp.eldorado.org.br> References: <38810c301be44ea99e42f2fe04ae3474@serv030.corp.eldorado.org.br> Message-ID: <5845FAD1.6020106@oracle.com> On 12/02/2016 12:09 PM, Gustavo Serra Scalet wrote: > Hi, > > I wonder why OpenJDK doesn't use OpenSSL for implementing the > cryptographic functions. On OpenSSL the algorithms are HW accelerated > on several platforms. > > Is it due to licensing issues? I ask because I intend on implementing > SHA for PPC64 but then I considered having this integration, if > possible. > > Thanks in advance > In many cases it is much faster it implement the crypto instructions in hotspot than to call an external library. The JCE provider, SunPKCS11, is an example of calling an external library. It requires JNI calls to the specification's public API that can result in complicated code and hinder performance. You can see JEPs 164 and 264 as a starting point for info. Tony From daniel.daugherty at oracle.com Mon Dec 5 23:43:49 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Mon, 5 Dec 2016 16:43:49 -0700 Subject: RFR(M): 8170655: [posix] Fix minimum stack size computations In-Reply-To: References: Message-ID: On 12/5/16 4:27 PM, Daniel D. Daugherty wrote: > On 12/3/16 11:17 AM, Lindenmaier, Goetz wrote: >> Hi, >> >> >> >> I would like to fix two issues of minimum stack size computation: >> >> http://cr.openjdk.java.net/~goetz/wr16/8170655-compilerGuardFix/webrev.01/ >> >> >> Please review and sponsor. > > I'm sponsoring the related bug: > > 8169373 Work around linux NPTL stack guard error > https://bugs.openjdk.java.net/browse/JDK-8169373 > > so I guess I should sponsor this one also... For obvious reasons, this > fix will also need a "full RBT" run... > > > > http://cr.openjdk.java.net/~goetz/wr16/8170655-compilerGuardFix/webrev.01/ > > src/cpu/ppc/vm/globals_ppc.hpp > No comments. > > src/cpu/x86/vm/globals_x86.hpp > No comments. > > src/os/posix/vm/os_posix.cpp > My brain read right past where you took out "MAX2" and changed the > math to "cur = cur + guard_size + shadow_size". I think I've been > staring at that particular line of code for way too long (in a couple > of different bug fixes)... > > I think with your fix that Solaris specific block on > L1132 - L1148 can go away (see JDK-8161093). Hopefully > Coleen will chime in on just this part. > > L1154: _compiler_thread_min_stack_allowed = > _compiler_thread_min_stack_allowed + > Please add a comment above this line: > > // Reminder: a compiler thread is-a Java thread. And this comment above set_minimum_stack_sizes also needs work: 1108 // Check minimum allowable stack sizes for thread creation and to initialize 1109 // the java system classes, including StackOverflowError - depends on page 1110 // size. Add two 4K pages for compiler2 recursion in main thread. 1111 // Add in 4*BytesPerWord 4K pages to account for VM stack during 1112 // class initialization depending on 32 or 64 bit VM. 1113 jint os::Posix::set_minimum_stack_sizes() { since the code that did a lot of that comment is now gone... Dan > > src/os/posix/vm/os_posix.hpp > L48: // Set_minimum_stack_sizes() ... > Please change 'S' -> 's' since it is the function's name. > > src/os_cpu/aix_ppc/vm/os_aix_ppc.cpp > L539: // HotSpotguard pages is added later. > Typo: space before 'guard' > > L542: size_t os::Posix::_vm_internal_thread_min_stack_allowed = 64 > * K; > VM internal thread size lowered from 128K to 64K without any > changes to how _vm_internal_thread_min_stack_allowed is set. > Any particular reason for this change? > > src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp > No comments. > > src/os_cpu/linux_aarch64/vm/os_linux_aarch64.cpp > No comments. > > src/os_cpu/linux_ppc/vm/os_linux_ppc.cpp > L542: size_t os::Posix::_vm_internal_thread_min_stack_allowed = 64 > * K; > VM internal thread size lowered from 128K to 64K without any > changes to how _vm_internal_thread_min_stack_allowed is set. > Any particular reason for this change? > > src/os_cpu/linux_s390/vm/os_linux_s390.cpp > L478: size_t os::Posix::_compiler_thread_min_stack_allowed = (52 > DEBUG_ONLY(+32)) * K; > L479: size_t os::Posix::_java_thread_min_stack_allowed = (32 > DEBUG_ONLY(+8)) * K; > consistency - trying to put space around operators so... > > '+32' -> '+ 32' > '+8' -> '+ 8' > > L480: size_t os::Posix::_vm_internal_thread_min_stack_allowed = 32 > * K; > VM internal thread size lowered from 128K to 32K without any > changes to how _vm_internal_thread_min_stack_allowed is set. > Any particular reason for this change? > > 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/solaris_sparc/vm/os_solaris_sparc.cpp > No comments. > > src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp > No comments. > > src/share/vm/runtime/os.hpp > L439: java_thread, // Java, CocdeCacheSweeper, > JVMTIAgent and Service threads. > Typo: 'CocdeCacheSweeper' -> 'CodeCacheSweeper' > > > Dan > >> >> >> >> This are the issues I excluded from the "8169373: Work around linux >> NPTL stack guard error." >> >> >> >> I wrote a lengthy explanation in the bug, trying to comment on what was >> >> said in the other thread. I'll repeat it here, I think that's better >> for discussion. >> >> Dan, thanks for improving the text, I use the improved variant here: >> >> >> >> HotSpot has three cmd line options to set stack sizes (besides -Xss): >> >> -XX:ThreadStackSize for threads executing Java code. >> >> -XX:CompilerThreadStackSize for threads used by the JIT compilers. >> >> -XX:VMThreadStackSize for threads executing VM internal tasks as gc. >> >> >> >> All these flags should not be set to a value that leads to a stack >> overflow before user code can be executed. As the VM executes a lot >> of code for initialization and also the JIT already compiles methods, >> considerable amounts of stack can be used during startup. We must try >> to avoid stack overflows before startup is complete as error handling >> might not be properly in place yet. >> >> >> >> Required minimum stack sizes depend on frame sizes and program >> execution paths. Frame sizes again depend on the C compiler used, the >> platform compiled for, and design decisions in interpreter, C1 and C2. >> >> >> >> Required stack sizes also depend on option settings, e.g. with JVM/TI >> enabled, frames can get bigger. With inlining increased JIT compilers >> might do more optimizations leading to deeper call chains, etc. >> >> >> >> While the minimum stack sizes should reflect differences in Platform >> and compiler, they must not, and cannot, cover all possible option >> settings. >> >> >> >> This change addresses two issues: >> >> >> >> 1. Fixed minimum stack size configuration >> >> >> >> Currently, the minimum Java thread size is given in a constant per >> os/cpu platform for each of the three stack kinds. This number >> includes the size required for guard pages. >> >> >> >> The guard pages are used for stack overflow detection. They make up 4 >> zones on the stack: Red, Yellow, Reserved and Shadow pages. The Red, >> Yellow and Reserved pages are protected to detect stack overflows. >> The Shadow pages are just some extra space to allow methods that >> don't do a stack bang to execute. >> >> >> >> Unfortunately, the size required for guard pages is not fixed at >> compile time. It depends on the concrete system the VM is started on. >> Thus the minimum sizes given can be too small to hold the guard >> pages. This lead to errors in the past that were solved by >> introducing code that overruled the per-platform minimum stack size. >> This code nowadays is the MAX2() in os_posix.cpp:1114 and the SOLARIS >> special case further down. It uses the value (4 * BytesPerWord >> COMPILER2_PRESENT(+ 2)) * 4 * K) (os_posix.cpp:1117) as minimum >> required space for frames. Thereby it effectively overrules the >> minimum stack size settings given in the os/cpu constants, and there >> is currently no way to specify this size per platform. >> >> >> >> This change proposes to fix this issue by specifying the space needed >> for stack frames in the os/cpu constants. During startup, this number >> is increased by the space required for the guard pages. Thus, this >> takes into account the page size of the concrete system the VM runs >> on, and also eventual changes to the guard pages by the flags >> StackRed/Yellow/Reserved/Shadow/Pages. This gives the opportunity to >> reduce the minimum stack sizes on systems with small pages. >> >> >> >> Minimum stack size configuration is more simple with this change and >> valid for systems with any page size. >> >> >> >> 2. Stack guard pages not considered for compiler thread stacks >> >> >> >> Compiler threads are Java threads. The C++ class CompilerThread is a >> subclass of JavaThread. When a compiler thread is started, >> JavaThread::run() is executed which protects the red, yellow and >> reserved pages. >> >> >> >> Since 8140520 the minimum stack sizes for Compiler and VM internal >> threads no longer include the space for the guard pages. This is >> correct for the VM internal threads, but not for the Compiler thread. >> >> >> >> For the HotSpot C1 and C2 compilers it would be fine to reserve space >> for the Red/Yellow/Reserved pages, as they don't stack bang with the >> shadow page size. But since introducing JVMCI, compilers written in >> Java can be running on the compiler threads. Therefore the shadow >> pages are needed, too. >> >> >> >> As for the Java thread, this change uses a os/cpu constant for the >> required minimum space for compiler frames and then adds the zone >> sizes to the minimum stack sizes during startup. >> >> >> >> New sizing: >> >> >> >> The constants of the os/cpu minimum thread sizes are reduced by the >> default guard page sizes and then verified by starting the VM to >> assure the stack still suffices to get through startup. Hotspot jtreg >> tests are passing. The overall sizes required (after adding guard >> pages) on the systems I have available get a bit smaller. In most >> cases the sizes even suffice to run simple programs as SpecJvm98. The >> table below gives the systems I tested and the required sizes >> reported when started with too small stacks. >> >> >> >> 
>>
>>   Thread kind:       Java      Compiler  VM
>>
>>                      old new   old new   old new
>>
>>
>>
>> bsd x86_64    dbg: 240 232    64  64    64  64
>>
>>                 opt: 240 232    64  64    64  64
>>
>>
>>
>> linux x86_64  dbg: 240 144    64 152    64  64
>>
>>                 opt: 232 136    64 144    64  64
>>
>>
>>
>> solaris sparc dbg:
>>
>>                 opt: 240 192   128 128   128 128
>>
>>
>>
>> aix ppc64     dbg: 512 512   384 512   128 128
>>
>>                 opt: 512 512   384 512   128 128
>>
>>   linux ppc64   dbg: 512 384   128 384   128  64
>>
>>                 opt: 512 384   128 384   128  64
>>
>>   linux ppc64le dbg: 512 384   128 384   128  64
>>
>>                 opt: 512 384   128 384   128  64
>>
>>
>>
>> linux s390    dbg: 236 140   128 184   128  32
>>
>>                 opt: 236 124   128 144   128  32
>>
>>
>> >> >> >> >> >> > > From shrinivas.joshi at oracle.com Mon Dec 5 23:48:51 2016 From: shrinivas.joshi at oracle.com (Shrinivas Joshi) Date: Mon, 05 Dec 2016 15:48:51 -0800 Subject: RFR(S): 8158012: Use SW prefetch instructions instead of BIS for allocation prefetches on SPARC Core S4 In-Reply-To: <5845FACD.9030901@oracle.com> References: <5845E3A3.4070603@oracle.com> <5845FACD.9030901@oracle.com> Message-ID: <5845FCE3.2060902@oracle.com> Hi Vladimir, Thanks for the review. -Shrinivas On 12/5/2016 3:39 PM, Vladimir Kozlov wrote: > Looks good. > > Have to wait for approval. > > Thanks, > Vladimir > > On 12/5/16 2:01 PM, Shrinivas Joshi wrote: >> Hi, >> >> Please review this small change which sets the default allocation >> prefetch mechanism on Oracle SPARC Core S4 processor based systems to >> use explicit SW prefetch instructions instead of Block Init >> Store(BIS) instructions. >> >> Bug: http://bugs.openjdk.java.net/browse/JDK-8158012 >> Webrev: http://cr.openjdk.java.net/~kvn/8158012/webrev.00/ >> >> Tested with JTREG and JPRT. >> >> Thanks, >> -Shrinivas > > From igor.veresov at oracle.com Tue Dec 6 01:56:58 2016 From: igor.veresov at oracle.com (Igor Veresov) Date: Mon, 5 Dec 2016 17:56:58 -0800 Subject: RFR: 8166002: Emulate client build on platforms with reduced virtual address space In-Reply-To: <6501518c-f146-83b7-11ff-7a594677ac92@oracle.com> References: <12de5f29-f773-11df-c397-f699f6ede7c3@oracle.com> <5812F65E.5010703@oracle.com> <58139658.1010706@oracle.com> <21DE287E-E195-4824-8259-9C3237DFFE1E@oracle.com> <30b01249-29d3-dfa5-2c0a-c7788780ca73@oracle.com> <6106172a-a87d-f82e-467c-61677589cbfd@oracle.com> <3DCDF924-B89F-4833-AE33-B1123A3EFD35@oracle.com> <6501518c-f146-83b7-11ff-7a594677ac92@oracle.com> Message-ID: <7B01231D-6D08-4971-BDB5-A2A52394EF4C@oracle.com> > On Dec 5, 2016, at 6:01 AM, Jamsheed C m wrote: > > Hi Igor, > > On 12/4/2016 12:28 AM, Igor Veresov wrote: >> I really think you should consider creating a new compilation policy instead of hacking the existing tiered one. >> The easy way of doing that would be to subclass SimpleThresholdPolicy and override: >> 1. initialize() to setup the number of c1 threads to 1 and c2 threads to 0. >> 2. method_invocation_event and method_back_branch_event to handle level transitions. >> >> In the event handlers you would check method counters. You may emulate the old policy by triggering compiles when i + b > CompileThreshold. >> When a method is ready to compile you would call compile(). >> >> I think a separate policy is easier because you won?t have to deal with the fact that the tiered policy is really design with having all these compilation levels in mind. For example you won?t have to set TieredStopAtLevel, etc. >> >> Also instead of is_client_compilation_mode_vm() I?d rather add a method the policy. For example ?is_tiered_policy?, or simply check CompilerPolicy::policy()->compiler_count(CompLevel_full_optimization) == 0. >> >> What do you think? > I agree. Should i be using CompileThreshold or new flags Tier1CompileThreshold.. ? Your call. It?s probably better not to add more flags though if we can meaningfully reused the old ones though. Make sure CompileThresholdScaling works with whatever you choose. igor > > Best Regards, > Jamsheed > >> >> igor >> >> >>> On Dec 2, 2016, at 7:38 AM, Jamsheed C m wrote: >>> >>> Hi Vladimir, Igor, >>> >>> I made a few more changes to include the optimization that was available only on client. >>> 1) a few c1 changes (JDK-7153771 ..) >>> >>> 2) Made SerialGC as default GC. >>> 3) Set CICompileCount=1 for client compilation mode. >>> 4) Tuned thresholds to get better performance. >>> >>> 5) Added relevant flags in few tests, modified TestSelectDefaultGC.java. >>> >>> revised webrev: http://cr.openjdk.java.net/~jcm/8166002/webrev.03/ >>> >>> performance report is added in bug report. >>> Best Regards, >>> >>> Jamsheed >>> >>> >>> On 11/1/2016 1:14 AM, Vladimir Kozlov wrote: >>>> webrev.02 looks good to me too. >>>> >>>> Thanks, >>>> Vladimri >>>> >>>> On 10/31/16 10:39 AM, Igor Veresov wrote: >>>>> Jamsheed explained to me that ReservedCodeCacheSize is now set in the else clause (udiffs are not showing the proper alignment and I missed it). The change looks good to me. >>>>> >>>>> igor >>>>> >>>>>> On Oct 31, 2016, at 9:42 AM, Igor Veresov wrote: >>>>>> >>>>>> Assuming it gets the performance/startup numbers close to the client VM it looks fine. >>>>>> But what about adjusting the code cache sizes? With tiered we get 240M ReservedCodeCacheSize, which also turns on SegmentedCodeCache. It seems like we won?t need the ?profiled? segment of the code cache at all. It is also likely that we?d do fine with a smaller overall code cache. >>>>>> >>>>>> igor >>>>>> >>>>>>> On Oct 31, 2016, at 9:14 AM, Jamsheed C m wrote: >>>>>>> >>>>>>> Hi Vladimir, Igor, >>>>>>> >>>>>>> revised webrev: http://cr.openjdk.java.net/~jcm/8166002/webrev.02/ >>>>>>> >>>>>>> i took flags from bug comment. >>>>>>> >>>>>>> Igor V. suggested next flags setting to emulate Client VM compile threshold with TieredStopAtLevel=1: >>>>>>> >>>>>>> Tier3BackEdgeThreshold=14000 >>>>>>> Tier3CompileThreshold=1500 >>>>>>> Tier3InvocationThreshold=1500 >>>>>>> Tier3MinInvocationThreshold =1500 >>>>>>> >>>>>>> Best Regards, >>>>>>> >>>>>>> Jamsheed >>>>>>> >>>>>>> On 10/28/2016 11:48 PM, Vladimir Kozlov wrote: >>>>>>>> Add comment what the code does and why. Move the code into separate function reaturning bool. And condition CodeCache setting based on result. It will reduce #ifdef mess. >>>>>>>> >>>>>>>> Can you put && to the end of previous line? To get good alignment. >>>>>>>> Should we also change CompilationPolicyChoice? >>>>>>>> >>>>>>>> Ask Igor Veresov to verify settings. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Vladimir >>>>>>>> >>>>>>>> On 10/28/16 10:59 AM, Jamsheed C m wrote: >>>>>>>>> Hi Vladimir, >>>>>>>>> >>>>>>>>> revised webrev with just ergo settings for win32. >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~jcm/8166002/webrev.01/ >>>>>>>>> >>>>>>>>> Best Regards >>>>>>>>> >>>>>>>>> Jamsheed >>>>>>>>> >>>>>>>>> >>>>>>>>> On 10/28/2016 12:25 PM, Vladimir Kozlov wrote: >>>>>>>>>> Hi Jamsheed, >>>>>>>>>> >>>>>>>>>> Why you need changes in tests? >>>>>>>>>> >>>>>>>>>> Why you can't use set_client_compilation_mode() in both places? >>>>>>>>>> >>>>>>>>>> Looks fine otherwise. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Vladimir >>>>>>>>>> >>>>>>>>>> On 10/20/16 8:45 AM, Jamsheed C m wrote: >>>>>>>>>>> Hi All, >>>>>>>>>>> >>>>>>>>>>> bug id:https://bugs.openjdk.java.net/browse/JDK-8166002 >>>>>>>>>>> >>>>>>>>>>> http://cr.openjdk.java.net/~jcm/8166002/webrev.00/ >>>>>>>>>>> >>>>>>>>>>> Fix: set NeverActAsServerClassMachine=true, Limit TieredCompilation to C1 by default, for win32 platform. >>>>>>>>>>> >>>>>>>>>>> A new flag CompilationMode= is introduced to select server/ client mode compilation. This option is supported only in TIERED builds. >>>>>>>>>>> >>>>>>>>>>> -XX:CompilationMode=server supports both -XX:+/-TieredCompilation. >>>>>>>>>>> >>>>>>>>>>> -XX:CompilationMode:client ignores TieredCompilation flag. >>>>>>>>>>> >>>>>>>>>>> Please review, >>>>>>>>>>> >>>>>>>>>>> Best Regards, >>>>>>>>>>> >>>>>>>>>>> Jamsheed -------------- next part -------------- An HTML attachment was scrubbed... URL: From goetz.lindenmaier at sap.com Tue Dec 6 07:48:28 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 6 Dec 2016 07:48:28 +0000 Subject: RFR(M): 8170655: [posix] Fix minimum stack size computations In-Reply-To: References: Message-ID: > -----Original Message----- > From: Daniel D. Daugherty [mailto:daniel.daugherty at oracle.com] > Sent: Dienstag, 6. Dezember 2016 00:28 > To: Lindenmaier, Goetz ; hotspot-runtime- > dev at openjdk.java.net; hotspot-compiler-dev at openjdk.java.net > Subject: Re: RFR(M): 8170655: [posix] Fix minimum stack size computations > > On 12/3/16 11:17 AM, Lindenmaier, Goetz wrote: > > Hi, > > > > > > > > I would like to fix two issues of minimum stack size computation: > > > > http://cr.openjdk.java.net/~goetz/wr16/8170655- > compilerGuardFix/webrev.01/ > > > > Please review and sponsor. > > I'm sponsoring the related bug: > > 8169373 Work around linux NPTL stack guard error > https://bugs.openjdk.java.net/browse/JDK-8169373 > > so I guess I should sponsor this one also... For obvious reasons, this > fix will also need a "full RBT" run... > > > > http://cr.openjdk.java.net/~goetz/wr16/8170655-compilerGuardFix/webrev.01/ > > src/cpu/ppc/vm/globals_ppc.hpp > No comments. > > src/cpu/x86/vm/globals_x86.hpp > No comments. > > src/os/posix/vm/os_posix.cpp > My brain read right past where you took out "MAX2" and changed the > math to "cur = cur + guard_size + shadow_size". I think I've been > staring at that particular line of code for way too long (in a couple > of different bug fixes)... Well, so did I. And therefore I think it's good i fit goes away. Maybe the new code needs less staring :) > I think with your fix that Solaris specific block on > L1132 - L1148 can go away (see JDK-8161093). Hopefully > Coleen will chime in on just this part. Removed. Coleen agreed. > L1154: _compiler_thread_min_stack_allowed = > _compiler_thread_min_stack_allowed + > Please add a comment above this line: > // Reminder: a compiler thread is-a Java thread. Done > src/os/posix/vm/os_posix.hpp > L48: // Set_minimum_stack_sizes() ... > Please change 'S' -> 's' since it is the function's name. Done. > src/os_cpu/aix_ppc/vm/os_aix_ppc.cpp > L539: // HotSpotguard pages is added later. > Typo: space before 'guard' Done. > L542: size_t os::Posix::_vm_internal_thread_min_stack_allowed = 64 * K; > VM internal thread size lowered from 128K to 64K without any > changes to how _vm_internal_thread_min_stack_allowed is set. > Any particular reason for this change? I did thorough sizing after I had implemented both of the stack changes. This showed that 64K are sufficient. Before all the stack changes in jdk9, we needed crazy high minimum stack sizes and the high number is probably a remnant of this. I'm a bit concerned why I need the 192K for the Java stack, but I think that's an aix-only issue. > src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp > No comments. > > src/os_cpu/linux_aarch64/vm/os_linux_aarch64.cpp > No comments. > > src/os_cpu/linux_ppc/vm/os_linux_ppc.cpp > L542: size_t os::Posix::_vm_internal_thread_min_stack_allowed = 64 * K; > VM internal thread size lowered from 128K to 64K without any > changes to how _vm_internal_thread_min_stack_allowed is set. > Any particular reason for this change? As above, I did sizing for all the numbers. > src/os_cpu/linux_s390/vm/os_linux_s390.cpp > L478: size_t os::Posix::_compiler_thread_min_stack_allowed = (52 > DEBUG_ONLY(+32)) * K; > L479: size_t os::Posix::_java_thread_min_stack_allowed = (32 > DEBUG_ONLY(+8)) * K; > consistency - trying to put space around operators so... > > '+32' -> '+ 32' > '+8' -> '+ 8' Done. > L480: size_t os::Posix::_vm_internal_thread_min_stack_allowed = 32 * K; > VM internal thread size lowered from 128K to 32K without any > changes to how _vm_internal_thread_min_stack_allowed is set. > Any particular reason for this change? See above. > 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/solaris_sparc/vm/os_solaris_sparc.cpp > No comments. > > src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp > No comments. > > src/share/vm/runtime/os.hpp > L439: java_thread, // Java, CocdeCacheSweeper, JVMTIAgent > and Service threads. > Typo: 'CocdeCacheSweeper' -> 'CodeCacheSweeper' Fixed. Thanks for the thorough review! And thanks for offering to sponsor. You probably also need a closed change reducing the constants on arm. I started out with the old value minus Red+Yellow+Reserved+Shadow * 4K. Best regards, Goetz. > > > Dan > > > > > > > > > This are the issues I excluded from the "8169373: Work around linux NPTL > stack guard error." > > > > > > > > I wrote a lengthy explanation in the bug, trying to comment on what was > > > > said in the other thread. I'll repeat it here, I think that's better for discussion. > > > > Dan, thanks for improving the text, I use the improved variant here: > > > > > > > > HotSpot has three cmd line options to set stack sizes (besides -Xss): > > > > -XX:ThreadStackSize for threads executing Java code. > > > > -XX:CompilerThreadStackSize for threads used by the JIT compilers. > > > > -XX:VMThreadStackSize for threads executing VM internal tasks as gc. > > > > > > > > All these flags should not be set to a value that leads to a stack overflow > before user code can be executed. As the VM executes a lot of code for > initialization and also the JIT already compiles methods, considerable amounts > of stack can be used during startup. We must try to avoid stack overflows > before startup is complete as error handling might not be properly in place yet. > > > > > > > > Required minimum stack sizes depend on frame sizes and program execution > paths. Frame sizes again depend on the C compiler used, the platform compiled > for, and design decisions in interpreter, C1 and C2. > > > > > > > > Required stack sizes also depend on option settings, e.g. with JVM/TI enabled, > frames can get bigger. With inlining increased JIT compilers might do more > optimizations leading to deeper call chains, etc. > > > > > > > > While the minimum stack sizes should reflect differences in Platform and > compiler, they must not, and cannot, cover all possible option settings. > > > > > > > > This change addresses two issues: > > > > > > > > 1. Fixed minimum stack size configuration > > > > > > > > Currently, the minimum Java thread size is given in a constant per os/cpu > platform for each of the three stack kinds. This number includes the size > required for guard pages. > > > > > > > > The guard pages are used for stack overflow detection. They make up 4 zones > on the stack: Red, Yellow, Reserved and Shadow pages. The Red, Yellow and > Reserved pages are protected to detect stack overflows. The Shadow pages are > just some extra space to allow methods that don't do a stack bang to execute. > > > > > > > > Unfortunately, the size required for guard pages is not fixed at compile time. > It depends on the concrete system the VM is started on. Thus the minimum > sizes given can be too small to hold the guard pages. This lead to errors in the > past that were solved by introducing code that overruled the per-platform > minimum stack size. This code nowadays is the MAX2() in os_posix.cpp:1114 > and the SOLARIS special case further down. It uses the value (4 * BytesPerWord > COMPILER2_PRESENT(+ 2)) * 4 * K) (os_posix.cpp:1117) as minimum required > space for frames. Thereby it effectively overrules the minimum stack size > settings given in the os/cpu constants, and there is currently no way to specify > this size per platform. > > > > > > > > This change proposes to fix this issue by specifying the space needed for stack > frames in the os/cpu constants. During startup, this number is increased by the > space required for the guard pages. Thus, this takes into account the page size > of the concrete system the VM runs on, and also eventual changes to the guard > pages by the flags StackRed/Yellow/Reserved/Shadow/Pages. This gives the > opportunity to reduce the minimum stack sizes on systems with small pages. > > > > > > > > Minimum stack size configuration is more simple with this change and valid > for systems with any page size. > > > > > > > > 2. Stack guard pages not considered for compiler thread stacks > > > > > > > > Compiler threads are Java threads. The C++ class CompilerThread is a > subclass of JavaThread. When a compiler thread is started, JavaThread::run() is > executed which protects the red, yellow and reserved pages. > > > > > > > > Since 8140520 the minimum stack sizes for Compiler and VM internal threads > no longer include the space for the guard pages. This is correct for the VM > internal threads, but not for the Compiler thread. > > > > > > > > For the HotSpot C1 and C2 compilers it would be fine to reserve space for the > Red/Yellow/Reserved pages, as they don't stack bang with the shadow page > size. But since introducing JVMCI, compilers written in Java can be running on > the compiler threads. Therefore the shadow pages are needed, too. > > > > > > > > As for the Java thread, this change uses a os/cpu constant for the required > minimum space for compiler frames and then adds the zone sizes to the > minimum stack sizes during startup. > > > > > > > > New sizing: > > > > > > > > The constants of the os/cpu minimum thread sizes are reduced by the default > guard page sizes and then verified by starting the VM to assure the stack still > suffices to get through startup. Hotspot jtreg tests are passing. The overall sizes > required (after adding guard pages) on the systems I have available get a bit > smaller. In most cases the sizes even suffice to run simple programs as > SpecJvm98. The table below gives the systems I tested and the required sizes > reported when started with too small stacks. > > > > > > > > 
> >
> >   Thread kind:       Java      Compiler  VM
> >
> >                      old new   old new   old new
> >
> >
> >
> > bsd x86_64    dbg: 240 232    64  64    64  64
> >
> >                 opt: 240 232    64  64    64  64
> >
> >
> >
> > linux x86_64  dbg: 240 144    64 152    64  64
> >
> >                 opt: 232 136    64 144    64  64
> >
> >
> >
> > solaris sparc dbg:
> >
> >                 opt: 240 192   128 128   128 128
> >
> >
> >
> > aix ppc64     dbg: 512 512   384 512   128 128
> >
> >                 opt: 512 512   384 512   128 128
> >
> >   linux ppc64   dbg: 512 384   128 384   128  64
> >
> >                 opt: 512 384   128 384   128  64
> >
> >   linux ppc64le dbg: 512 384   128 384   128  64
> >
> >                 opt: 512 384   128 384   128  64
> >
> >
> >
> > linux s390    dbg: 236 140   128 184   128  32
> >
> >                 opt: 236 124   128 144   128  32
> >
> >
> > > > > > > > > > > > From vitalyd at gmail.com Tue Dec 6 17:02:19 2016 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Tue, 6 Dec 2016 12:02:19 -0500 Subject: 8u102 NMethod sweeper related Hotspot crashes Message-ID: Hi guys, I have a couple of Hotspot crashes to report - both occur in nmethod sweeping/flushing. I'm going to strip down the hs_err content, but let me know if there's something else you need from there. Are these known? A quick google suggests there are some bugs around nmethod sweeping, but I couldn't find anything exactly like this. Let me know if you need more info. Thanks *The first is:* # # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (instanceKlass.cpp:1995), pid=15444, tid=0x00002b1fd0186700 # guarantee(val >= 0) failed: Underflow: -1 # # JRE version: Java(TM) SE Runtime Environment (8.0_102-b14) (build 1.8.0_102-b14) # Java VM: Java HotSpot(TM) 64-Bit Server VM (25.102-b14 mixed mode linux-amd64 ) # # If you would like to submit a bug report, please visit: # http://bugreport.java.com/bugreport/crash.jsp # --------------- T H R E A D --------------- Current thread (0x00002b1f58056800): JavaThread "C2 CompilerThread2" daemon [_thread_in_vm, id=15533, stack(0x00002b1fd0086000,0x00002b1fd0187000)] Stack: [0x00002b1fd0086000,0x00002b1fd0187000], sp=0x00002b1fd0185580, free space=1021k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0xac52aa] VMError::report_and_die()+0x2ba V [libjvm.so+0x4fba22] report_vm_error(char const*, int, char const*, char const*)+0x62 V [libjvm.so+0x63e9b0] InstanceKlass::remove_dependent_nmethod(nmethod*, bool)+0x110 V [libjvm.so+0x8e61b3] nmethod::flush_dependencies(BoolObjectClosure*)+0x93 V [libjvm.so+0x8ebd5b] nmethod::make_not_entrant_or_zombie(unsigned int)+0x48b V [libjvm.so+0xa2b0cd] NMethodSweeper::process_nmethod(nmethod*)+0x27d V [libjvm.so+0xa2b468] NMethodSweeper::sweep_code_cache()+0x328 V [libjvm.so+0xa2b7d4] NMethodSweeper::possibly_sweep()+0xb4 V [libjvm.so+0x4ae105] CompileQueue::get()+0x15 V [libjvm.so+0x4b047b] CompileBroker::compiler_thread_loop()+0x18b V [libjvm.so+0xa73ce3] JavaThread::thread_main_inner()+0x103 V [libjvm.so+0xa73e2c] JavaThread::run()+0x11c V [libjvm.so+0x9249c8] java_start(Thread*)+0x108 C [libpthread.so.0+0x6b50] start_thread+0xd0 =>0x00002b1f58056800 JavaThread "C2 CompilerThread2" daemon [_thread_in_vm, id=15533, stack(0x00002b1fd0086000,0x00002b1fd0187000)] VM state:not at safepoint (normal execution) VM Mutex/Monitor currently owned by a thread: ([mutex/lock_event]) [0x0000000001ac5f40] CodeCache_lock - owner thread: 0x00002b1f58056800 [0x0000000001ac7240] CompiledIC_lock - owner thread: 0x00002b1f58056800 Heap: PSYoungGen total 16531968K, used 13673471K [0x00002b1b0b200000, 0x00002b1f49900000, 0x00002b1f4b200000) eden space 15297024K, 83% used [0x00002b1b0b200000,0x00002b1e19277f68,0x00002b1eb0c80000) from space 1234944K, 69% used [0x00002b1eb0c80000,0x00002b1ee5507eb0,0x00002b1efc280000) to space 1198080K, 0% used [0x00002b1f00700000,0x00002b1f00700000,0x00002b1f49900000) ParOldGen total 34891264K, used 26246257K [0x00002b128b200000, 0x00002b1adcb80000, 0x00002b1b0b200000) object space 34891264K, 75% used [0x00002b128b200000,0x00002b18cd11c630,0x00002b1adcb80000) Metaspace used 211158K, capacity 610281K, committed 610528K, reserved 612352K Polling page: 0x00002b1281166000 CodeCache: size=102400Kb used=71326Kb max_used=81914Kb free=31073Kb bounds [0x00002b1284ab2000, 0x00002b128aeb2000, 0x00002b128aeb2000] total_blobs=13619 nmethods=12436 adapters=1089 compilation: enabled *Here's the second:* # # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (instanceKlass.cpp:2018), pid=83979, tid=0x00002bb97feba700 # Error: ShouldNotReachHere() # # JRE version: Java(TM) SE Runtime Environment (8.0_102-b14) (build 1.8.0_102-b14) # Java VM: Java HotSpot(TM) 64-Bit Server VM (25.102-b14 mixed mode linux-amd64 ) # # If you would like to submit a bug report, please visit: # http://bugreport.java.com/bugreport/crash.jsp # --------------- T H R E A D --------------- Current thread (0x00002bb8f40cf800): JavaThread "C2 CompilerThread6" daemon [_thread_in_vm, id=84042, stack(0x00002bb97fdba000,0x00002bb97febb000)] Stack: [0x00002bb97fdba000,0x00002bb97febb000], sp=0x00002bb97feb9710, free space=1021k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0xac52aa] VMError::report_and_die()+0x2ba V [libjvm.so+0x4fbd92] report_should_not_reach_here(char const*, int)+0x52 V [libjvm.so+0x63e8fb] InstanceKlass::remove_dependent_nmethod(nmethod*, bool)+0x5b V [libjvm.so+0x8e61b3] nmethod::flush_dependencies(BoolObjectClosure*)+0x93 V [libjvm.so+0x8ebd5b] nmethod::make_not_entrant_or_zombie(unsigned int)+0x48b V [libjvm.so+0xa2b0cd] NMethodSweeper::process_nmethod(nmethod*)+0x27d V [libjvm.so+0xa2b468] NMethodSweeper::sweep_code_cache()+0x328 V [libjvm.so+0xa2b7d4] NMethodSweeper::possibly_sweep()+0xb4 V [libjvm.so+0x4ae105] CompileQueue::get()+0x15 V [libjvm.so+0x4b047b] CompileBroker::compiler_thread_loop()+0x18b V [libjvm.so+0xa73ce3] JavaThread::thread_main_inner()+0x103 V [libjvm.so+0xa73e2c] JavaThread::run()+0x11c V [libjvm.so+0x9249c8] java_start(Thread*)+0x108 C [libpthread.so.0+0x6b50] start_thread+0xd0 =>0x00002bb8f40cf800 JavaThread "C2 CompilerThread6" daemon [_thread_in_vm, id=84042, stack(0x00002bb97fdba000,0x00002bb97febb000)] VM state:not at safepoint (normal execution) VM Mutex/Monitor currently owned by a thread: ([mutex/lock_event]) [0x0000000001858f40] CodeCache_lock - owner thread: 0x00002bb8f40cf800 [0x000000000185a240] CompiledIC_lock - owner thread: 0x00002bb8f40cf800 Heap: PSYoungGen total 18567168K, used 3149269K [0x00002bb3cdf00000, 0x00002bb8e3400000, 0x00002bb8e3400000) eden space 15838208K, 5% used [0x00002bb3cdf00000,0x00002bb402b26e00,0x00002bb794a00000) from space 2728960K, 83% used [0x00002bb83ab00000,0x00002bb8c624e6b0,0x00002bb8e1400000) to space 2720768K, 0% used [0x00002bb794a00000,0x00002bb794a00000,0x00002bb83ab00000) ParOldGen total 23083520K, used 21102913K [0x00002ba9a3400000, 0x00002baf24280000, 0x00002bb3cdf00000) object space 23083520K, 91% used [0x00002ba9a3400000,0x00002baeab450478,0x00002baf24280000) Metaspace used 167926K, capacity 377784K, committed 377856K, reserved 378880K Polling page: 0x00002ba999461000 CodeCache: size=102400Kb used=72829Kb max_used=81642Kb free=29570Kb bounds [0x00002ba99cdad000, 0x00002ba9a31ad000, 0x00002ba9a31ad000] total_blobs=14843 nmethods=13668 adapters=1082 compilation: enabled -------------- next part -------------- An HTML attachment was scrubbed... URL: From vitalyd at gmail.com Tue Dec 6 17:33:43 2016 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Tue, 06 Dec 2016 17:33:43 +0000 Subject: 8u102 NMethod sweeper related Hotspot crashes In-Reply-To: References: Message-ID: Btw, for now I've advised the group hitting these to turn off tiered compilation to reduce code cache pressure and thus hopefully avoid whatever bug(s) is lurking here. I should've also mentioned that this doesn't happen all the time, of course, so there's no reliable repro. On Tue, Dec 6, 2016 at 12:02 PM Vitaly Davidovich wrote: > Hi guys, > > I have a couple of Hotspot crashes to report - both occur in nmethod > sweeping/flushing. I'm going to strip down the hs_err content, but let me > know if there's something else you need from there. Are these known? A > quick google suggests there are some bugs around nmethod sweeping, but I > couldn't find anything exactly like this. > > Let me know if you need more info. > > Thanks > > *The first is:* > > # > # A fatal error has been detected by the Java Runtime Environment: > # > # Internal Error (instanceKlass.cpp:1995), pid=15444, > tid=0x00002b1fd0186700 > # guarantee(val >= 0) failed: Underflow: -1 > # > # JRE version: Java(TM) SE Runtime Environment (8.0_102-b14) (build > 1.8.0_102-b14) > # Java VM: Java HotSpot(TM) 64-Bit Server VM (25.102-b14 mixed mode > linux-amd64 ) > # > # If you would like to submit a bug report, please visit: > # http://bugreport.java.com/bugreport/crash.jsp > # > > --------------- T H R E A D --------------- > > Current thread (0x00002b1f58056800): JavaThread "C2 CompilerThread2" > daemon [_thread_in_vm, id=15533, > stack(0x00002b1fd0086000,0x00002b1fd0187000)] > > Stack: [0x00002b1fd0086000,0x00002b1fd0187000], sp=0x00002b1fd0185580, > free space=1021k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native > code) > V [libjvm.so+0xac52aa] VMError::report_and_die()+0x2ba > V [libjvm.so+0x4fba22] report_vm_error(char const*, int, char const*, > char const*)+0x62 > V [libjvm.so+0x63e9b0] InstanceKlass::remove_dependent_nmethod(nmethod*, > bool)+0x110 > V [libjvm.so+0x8e61b3] > nmethod::flush_dependencies(BoolObjectClosure*)+0x93 > V [libjvm.so+0x8ebd5b] nmethod::make_not_entrant_or_zombie(unsigned > int)+0x48b > V [libjvm.so+0xa2b0cd] NMethodSweeper::process_nmethod(nmethod*)+0x27d > V [libjvm.so+0xa2b468] NMethodSweeper::sweep_code_cache()+0x328 > V [libjvm.so+0xa2b7d4] NMethodSweeper::possibly_sweep()+0xb4 > V [libjvm.so+0x4ae105] CompileQueue::get()+0x15 > V [libjvm.so+0x4b047b] CompileBroker::compiler_thread_loop()+0x18b > V [libjvm.so+0xa73ce3] JavaThread::thread_main_inner()+0x103 > V [libjvm.so+0xa73e2c] JavaThread::run()+0x11c > V [libjvm.so+0x9249c8] java_start(Thread*)+0x108 > C [libpthread.so.0+0x6b50] start_thread+0xd0 > > =>0x00002b1f58056800 JavaThread "C2 CompilerThread2" daemon > [_thread_in_vm, id=15533, stack(0x00002b1fd0086000,0x00002b1fd0187000)] > > VM state:not at safepoint (normal execution) > VM Mutex/Monitor currently owned by a thread: ([mutex/lock_event]) > [0x0000000001ac5f40] CodeCache_lock - owner thread: 0x00002b1f58056800 > [0x0000000001ac7240] CompiledIC_lock - owner thread: 0x00002b1f58056800 > > Heap: > PSYoungGen total 16531968K, used 13673471K [0x00002b1b0b200000, > 0x00002b1f49900000, 0x00002b1f4b200000) > eden space 15297024K, 83% used > [0x00002b1b0b200000,0x00002b1e19277f68,0x00002b1eb0c80000) > from space 1234944K, 69% used > [0x00002b1eb0c80000,0x00002b1ee5507eb0,0x00002b1efc280000) > to space 1198080K, 0% used > [0x00002b1f00700000,0x00002b1f00700000,0x00002b1f49900000) > ParOldGen total 34891264K, used 26246257K [0x00002b128b200000, > 0x00002b1adcb80000, 0x00002b1b0b200000) > object space 34891264K, 75% used > [0x00002b128b200000,0x00002b18cd11c630,0x00002b1adcb80000) > Metaspace used 211158K, capacity 610281K, committed 610528K, > reserved 612352K > > Polling page: 0x00002b1281166000 > > CodeCache: size=102400Kb used=71326Kb max_used=81914Kb free=31073Kb > bounds [0x00002b1284ab2000, 0x00002b128aeb2000, 0x00002b128aeb2000] > total_blobs=13619 nmethods=12436 adapters=1089 > compilation: enabled > > *Here's the second:* > # > # A fatal error has been detected by the Java Runtime Environment: > # > # Internal Error (instanceKlass.cpp:2018), pid=83979, > tid=0x00002bb97feba700 > # Error: ShouldNotReachHere() > # > # JRE version: Java(TM) SE Runtime Environment (8.0_102-b14) (build > 1.8.0_102-b14) > # Java VM: Java HotSpot(TM) 64-Bit Server VM (25.102-b14 mixed mode > linux-amd64 ) > # > # If you would like to submit a bug report, please visit: > # http://bugreport.java.com/bugreport/crash.jsp > # > > --------------- T H R E A D --------------- > > Current thread (0x00002bb8f40cf800): JavaThread "C2 CompilerThread6" > daemon [_thread_in_vm, id=84042, > stack(0x00002bb97fdba000,0x00002bb97febb000)] > > Stack: [0x00002bb97fdba000,0x00002bb97febb000], sp=0x00002bb97feb9710, > free space=1021k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native > code) > V [libjvm.so+0xac52aa] VMError::report_and_die()+0x2ba > V [libjvm.so+0x4fbd92] report_should_not_reach_here(char const*, > int)+0x52 > V [libjvm.so+0x63e8fb] InstanceKlass::remove_dependent_nmethod(nmethod*, > bool)+0x5b > V [libjvm.so+0x8e61b3] > nmethod::flush_dependencies(BoolObjectClosure*)+0x93 > V [libjvm.so+0x8ebd5b] nmethod::make_not_entrant_or_zombie(unsigned > int)+0x48b > V [libjvm.so+0xa2b0cd] NMethodSweeper::process_nmethod(nmethod*)+0x27d > V [libjvm.so+0xa2b468] NMethodSweeper::sweep_code_cache()+0x328 > V [libjvm.so+0xa2b7d4] NMethodSweeper::possibly_sweep()+0xb4 > V [libjvm.so+0x4ae105] CompileQueue::get()+0x15 > V [libjvm.so+0x4b047b] CompileBroker::compiler_thread_loop()+0x18b > V [libjvm.so+0xa73ce3] JavaThread::thread_main_inner()+0x103 > V [libjvm.so+0xa73e2c] JavaThread::run()+0x11c > V [libjvm.so+0x9249c8] java_start(Thread*)+0x108 > C [libpthread.so.0+0x6b50] start_thread+0xd0 > > =>0x00002bb8f40cf800 JavaThread "C2 CompilerThread6" daemon > [_thread_in_vm, id=84042, stack(0x00002bb97fdba000,0x00002bb97febb000)] > VM state:not at safepoint (normal execution) > > VM Mutex/Monitor currently owned by a thread: ([mutex/lock_event]) > [0x0000000001858f40] CodeCache_lock - owner thread: 0x00002bb8f40cf800 > [0x000000000185a240] CompiledIC_lock - owner thread: 0x00002bb8f40cf800 > > Heap: > PSYoungGen total 18567168K, used 3149269K [0x00002bb3cdf00000, 0x00002bb8e3400000, 0x00002bb8e3400000) > eden space 15838208K, 5% used [0x00002bb3cdf00000,0x00002bb402b26e00,0x00002bb794a00000) > from space 2728960K, 83% used [0x00002bb83ab00000,0x00002bb8c624e6b0,0x00002bb8e1400000) > to space 2720768K, 0% used [0x00002bb794a00000,0x00002bb794a00000,0x00002bb83ab00000) > ParOldGen total 23083520K, used 21102913K [0x00002ba9a3400000, 0x00002baf24280000, 0x00002bb3cdf00000) > object space 23083520K, 91% used [0x00002ba9a3400000,0x00002baeab450478,0x00002baf24280000) > Metaspace used 167926K, capacity 377784K, committed 377856K, reserved 378880K > > > > Polling page: 0x00002ba999461000 > > CodeCache: size=102400Kb used=72829Kb max_used=81642Kb free=29570Kb > bounds [0x00002ba99cdad000, 0x00002ba9a31ad000, 0x00002ba9a31ad000] > total_blobs=14843 nmethods=13668 adapters=1082 > compilation: enabled > > -- Sent from my phone -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladimir.kozlov at oracle.com Tue Dec 6 17:57:34 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 6 Dec 2016 09:57:34 -0800 Subject: 8u102 NMethod sweeper related Hotspot crashes In-Reply-To: References: Message-ID: <4a46f7da-10af-db7b-9e4c-eca4c0508979@oracle.com> Could be https://bugs.openjdk.java.net/browse/JDK-8139595 (not backported to 8u). I can't find anything else with remove_dependent_nmethod() on call stack in JBS. Vladimir On 12/6/16 9:33 AM, Vitaly Davidovich wrote: > Btw, for now I've advised the group hitting these to turn off tiered > compilation to reduce code cache pressure and thus hopefully avoid > whatever bug(s) is lurking here. > > I should've also mentioned that this doesn't happen all the time, of > course, so there's no reliable repro. > > On Tue, Dec 6, 2016 at 12:02 PM Vitaly Davidovich > wrote: > > Hi guys, > > I have a couple of Hotspot crashes to report - both occur in nmethod > sweeping/flushing. I'm going to strip down the hs_err content, but > let me know if there's something else you need from there. Are > these known? A quick google suggests there are some bugs around > nmethod sweeping, but I couldn't find anything exactly like this. > > Let me know if you need more info. > > Thanks > > *The first is:* > > # > # A fatal error has been detected by the Java Runtime Environment: > # > # Internal Error (instanceKlass.cpp:1995), pid=15444, > tid=0x00002b1fd0186700 > # guarantee(val >= 0) failed: Underflow: -1 > # > # JRE version: Java(TM) SE Runtime Environment (8.0_102-b14) (build > 1.8.0_102-b14) > # Java VM: Java HotSpot(TM) 64-Bit Server VM (25.102-b14 mixed mode > linux-amd64 ) > # > # If you would like to submit a bug report, please visit: > # http://bugreport.java.com/bugreport/crash.jsp > # > > --------------- T H R E A D --------------- > > Current thread (0x00002b1f58056800): JavaThread "C2 > CompilerThread2" daemon [_thread_in_vm, id=15533, > stack(0x00002b1fd0086000,0x00002b1fd0187000)] > > Stack: [0x00002b1fd0086000,0x00002b1fd0187000], > sp=0x00002b1fd0185580, free space=1021k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, > C=native code) > V [libjvm.so+0xac52aa] VMError::report_and_die()+0x2ba > V [libjvm.so+0x4fba22] report_vm_error(char const*, int, char > const*, char const*)+0x62 > V [libjvm.so+0x63e9b0] > InstanceKlass::remove_dependent_nmethod(nmethod*, bool)+0x110 > V [libjvm.so+0x8e61b3] > nmethod::flush_dependencies(BoolObjectClosure*)+0x93 > V [libjvm.so+0x8ebd5b] > nmethod::make_not_entrant_or_zombie(unsigned int)+0x48b > V [libjvm.so+0xa2b0cd] NMethodSweeper::process_nmethod(nmethod*)+0x27d > V [libjvm.so+0xa2b468] NMethodSweeper::sweep_code_cache()+0x328 > V [libjvm.so+0xa2b7d4] NMethodSweeper::possibly_sweep()+0xb4 > V [libjvm.so+0x4ae105] CompileQueue::get()+0x15 > V [libjvm.so+0x4b047b] CompileBroker::compiler_thread_loop()+0x18b > V [libjvm.so+0xa73ce3] JavaThread::thread_main_inner()+0x103 > V [libjvm.so+0xa73e2c] JavaThread::run()+0x11c > V [libjvm.so+0x9249c8] java_start(Thread*)+0x108 > C [libpthread.so.0+0x6b50] start_thread+0xd0 > > =>0x00002b1f58056800 JavaThread "C2 CompilerThread2" daemon > [_thread_in_vm, id=15533, stack(0x00002b1fd0086000,0x00002b1fd0187000)] > > VM state:not at safepoint (normal execution) > VM Mutex/Monitor currently owned by a thread: ([mutex/lock_event]) > [0x0000000001ac5f40] CodeCache_lock - owner thread: 0x00002b1f58056800 > [0x0000000001ac7240] CompiledIC_lock - owner thread: 0x00002b1f58056800 > > Heap: > PSYoungGen total 16531968K, used 13673471K > [0x00002b1b0b200000, 0x00002b1f49900000, 0x00002b1f4b200000) > eden space 15297024K, 83% used > [0x00002b1b0b200000,0x00002b1e19277f68,0x00002b1eb0c80000) > from space 1234944K, 69% used > [0x00002b1eb0c80000,0x00002b1ee5507eb0,0x00002b1efc280000) > to space 1198080K, 0% used > [0x00002b1f00700000,0x00002b1f00700000,0x00002b1f49900000) > ParOldGen total 34891264K, used 26246257K > [0x00002b128b200000, 0x00002b1adcb80000, 0x00002b1b0b200000) > object space 34891264K, 75% used > [0x00002b128b200000,0x00002b18cd11c630,0x00002b1adcb80000) > Metaspace used 211158K, capacity 610281K, committed 610528K, > reserved 612352K > > Polling page: 0x00002b1281166000 > > CodeCache: size=102400Kb used=71326Kb max_used=81914Kb free=31073Kb > bounds [0x00002b1284ab2000, 0x00002b128aeb2000, 0x00002b128aeb2000] > total_blobs=13619 nmethods=12436 adapters=1089 > compilation: enabled > > *Here's the second:* > # > # A fatal error has been detected by the Java Runtime Environment: > # > # Internal Error (instanceKlass.cpp:2018), pid=83979, > tid=0x00002bb97feba700 > # Error: ShouldNotReachHere() > # > # JRE version: Java(TM) SE Runtime Environment (8.0_102-b14) (build > 1.8.0_102-b14) > # Java VM: Java HotSpot(TM) 64-Bit Server VM (25.102-b14 mixed mode > linux-amd64 ) > # > # If you would like to submit a bug report, please visit: > # http://bugreport.java.com/bugreport/crash.jsp > # > > --------------- T H R E A D --------------- > > Current thread (0x00002bb8f40cf800): JavaThread "C2 > CompilerThread6" daemon [_thread_in_vm, id=84042, > stack(0x00002bb97fdba000,0x00002bb97febb000)] > > Stack: [0x00002bb97fdba000,0x00002bb97febb000], > sp=0x00002bb97feb9710, free space=1021k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, > C=native code) > V [libjvm.so+0xac52aa] VMError::report_and_die()+0x2ba > V [libjvm.so+0x4fbd92] report_should_not_reach_here(char const*, > int)+0x52 > V [libjvm.so+0x63e8fb] > InstanceKlass::remove_dependent_nmethod(nmethod*, bool)+0x5b > V [libjvm.so+0x8e61b3] > nmethod::flush_dependencies(BoolObjectClosure*)+0x93 > V [libjvm.so+0x8ebd5b] > nmethod::make_not_entrant_or_zombie(unsigned int)+0x48b > V [libjvm.so+0xa2b0cd] NMethodSweeper::process_nmethod(nmethod*)+0x27d > V [libjvm.so+0xa2b468] NMethodSweeper::sweep_code_cache()+0x328 > V [libjvm.so+0xa2b7d4] NMethodSweeper::possibly_sweep()+0xb4 > V [libjvm.so+0x4ae105] CompileQueue::get()+0x15 > V [libjvm.so+0x4b047b] CompileBroker::compiler_thread_loop()+0x18b > V [libjvm.so+0xa73ce3] JavaThread::thread_main_inner()+0x103 > V [libjvm.so+0xa73e2c] JavaThread::run()+0x11c > V [libjvm.so+0x9249c8] java_start(Thread*)+0x108 > C [libpthread.so.0+0x6b50] start_thread+0xd0 > > =>0x00002bb8f40cf800 JavaThread "C2 CompilerThread6" daemon > [_thread_in_vm, id=84042, stack(0x00002bb97fdba000,0x00002bb97febb000)] > VM state:not at safepoint (normal execution) > > VM Mutex/Monitor currently owned by a thread: ([mutex/lock_event]) > [0x0000000001858f40] CodeCache_lock - owner thread: 0x00002bb8f40cf800 > [0x000000000185a240] CompiledIC_lock - owner thread: 0x00002bb8f40cf800 > > Heap: > PSYoungGen total 18567168K, used 3149269K [0x00002bb3cdf00000, 0x00002bb8e3400000, 0x00002bb8e3400000) > eden space 15838208K, 5% used [0x00002bb3cdf00000,0x00002bb402b26e00,0x00002bb794a00000) > from space 2728960K, 83% used [0x00002bb83ab00000,0x00002bb8c624e6b0,0x00002bb8e1400000) > to space 2720768K, 0% used [0x00002bb794a00000,0x00002bb794a00000,0x00002bb83ab00000) > ParOldGen total 23083520K, used 21102913K [0x00002ba9a3400000, 0x00002baf24280000, 0x00002bb3cdf00000) > object space 23083520K, 91% used [0x00002ba9a3400000,0x00002baeab450478,0x00002baf24280000) > Metaspace used 167926K, capacity 377784K, committed 377856K, reserved 378880K > > > > Polling page: 0x00002ba999461000 > > CodeCache: size=102400Kb used=72829Kb max_used=81642Kb free=29570Kb > bounds [0x00002ba99cdad000, 0x00002ba9a31ad000, 0x00002ba9a31ad000] > total_blobs=14843 nmethods=13668 adapters=1082 > compilation: enabled > > -- > Sent from my phone From vitalyd at gmail.com Tue Dec 6 18:12:23 2016 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Tue, 6 Dec 2016 13:12:23 -0500 Subject: 8u102 NMethod sweeper related Hotspot crashes In-Reply-To: <4a46f7da-10af-db7b-9e4c-eca4c0508979@oracle.com> References: <4a46f7da-10af-db7b-9e4c-eca4c0508979@oracle.com> Message-ID: Hi Vladimir, On Tue, Dec 6, 2016 at 12:57 PM, Vladimir Kozlov wrote: > Could be https://bugs.openjdk.java.net/browse/JDK-8139595 (not backported > to 8u). > > I can't find anything else with remove_dependent_nmethod() on call stack > in JBS. It does seem like it could be related, but yeah, it's unclear. Hoping someone else here may have an idea. Thanks > > Vladimir > > On 12/6/16 9:33 AM, Vitaly Davidovich wrote: > >> Btw, for now I've advised the group hitting these to turn off tiered >> compilation to reduce code cache pressure and thus hopefully avoid >> whatever bug(s) is lurking here. >> >> I should've also mentioned that this doesn't happen all the time, of >> course, so there's no reliable repro. >> >> On Tue, Dec 6, 2016 at 12:02 PM Vitaly Davidovich > > wrote: >> >> Hi guys, >> >> I have a couple of Hotspot crashes to report - both occur in nmethod >> sweeping/flushing. I'm going to strip down the hs_err content, but >> let me know if there's something else you need from there. Are >> these known? A quick google suggests there are some bugs around >> nmethod sweeping, but I couldn't find anything exactly like this. >> >> Let me know if you need more info. >> >> Thanks >> >> *The first is:* >> >> >> # >> # A fatal error has been detected by the Java Runtime Environment: >> # >> # Internal Error (instanceKlass.cpp:1995), pid=15444, >> tid=0x00002b1fd0186700 >> # guarantee(val >= 0) failed: Underflow: -1 >> # >> # JRE version: Java(TM) SE Runtime Environment (8.0_102-b14) (build >> 1.8.0_102-b14) >> # Java VM: Java HotSpot(TM) 64-Bit Server VM (25.102-b14 mixed mode >> linux-amd64 ) >> # >> # If you would like to submit a bug report, please visit: >> # http://bugreport.java.com/bugreport/crash.jsp >> # >> >> --------------- T H R E A D --------------- >> >> Current thread (0x00002b1f58056800): JavaThread "C2 >> CompilerThread2" daemon [_thread_in_vm, id=15533, >> stack(0x00002b1fd0086000,0x00002b1fd0187000)] >> >> Stack: [0x00002b1fd0086000,0x00002b1fd0187000], >> sp=0x00002b1fd0185580, free space=1021k >> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, >> C=native code) >> V [libjvm.so+0xac52aa] VMError::report_and_die()+0x2ba >> V [libjvm.so+0x4fba22] report_vm_error(char const*, int, char >> const*, char const*)+0x62 >> V [libjvm.so+0x63e9b0] >> InstanceKlass::remove_dependent_nmethod(nmethod*, bool)+0x110 >> V [libjvm.so+0x8e61b3] >> nmethod::flush_dependencies(BoolObjectClosure*)+0x93 >> V [libjvm.so+0x8ebd5b] >> nmethod::make_not_entrant_or_zombie(unsigned int)+0x48b >> V [libjvm.so+0xa2b0cd] NMethodSweeper::process_nmetho >> d(nmethod*)+0x27d >> V [libjvm.so+0xa2b468] NMethodSweeper::sweep_code_cache()+0x328 >> V [libjvm.so+0xa2b7d4] NMethodSweeper::possibly_sweep()+0xb4 >> V [libjvm.so+0x4ae105] CompileQueue::get()+0x15 >> V [libjvm.so+0x4b047b] CompileBroker::compiler_thread_loop()+0x18b >> V [libjvm.so+0xa73ce3] JavaThread::thread_main_inner()+0x103 >> V [libjvm.so+0xa73e2c] JavaThread::run()+0x11c >> V [libjvm.so+0x9249c8] java_start(Thread*)+0x108 >> C [libpthread.so.0+0x6b50] start_thread+0xd0 >> >> =>0x00002b1f58056800 JavaThread "C2 CompilerThread2" daemon >> [_thread_in_vm, id=15533, stack(0x00002b1fd0086000,0x000 >> 02b1fd0187000)] >> >> VM state:not at safepoint (normal execution) >> VM Mutex/Monitor currently owned by a thread: ([mutex/lock_event]) >> [0x0000000001ac5f40] CodeCache_lock - owner thread: 0x00002b1f58056800 >> [0x0000000001ac7240] CompiledIC_lock - owner thread: >> 0x00002b1f58056800 >> >> Heap: >> PSYoungGen total 16531968K, used 13673471K >> [0x00002b1b0b200000, 0x00002b1f49900000, 0x00002b1f4b200000) >> eden space 15297024K, 83% used >> [0x00002b1b0b200000,0x00002b1e19277f68,0x00002b1eb0c80000) >> from space 1234944K, 69% used >> [0x00002b1eb0c80000,0x00002b1ee5507eb0,0x00002b1efc280000) >> to space 1198080K, 0% used >> [0x00002b1f00700000,0x00002b1f00700000,0x00002b1f49900000) >> ParOldGen total 34891264K, used 26246257K >> [0x00002b128b200000, 0x00002b1adcb80000, 0x00002b1b0b200000) >> object space 34891264K, 75% used >> [0x00002b128b200000,0x00002b18cd11c630,0x00002b1adcb80000) >> Metaspace used 211158K, capacity 610281K, committed 610528K, >> reserved 612352K >> >> Polling page: 0x00002b1281166000 >> >> CodeCache: size=102400Kb used=71326Kb max_used=81914Kb free=31073Kb >> bounds [0x00002b1284ab2000, 0x00002b128aeb2000, 0x00002b128aeb2000] >> total_blobs=13619 nmethods=12436 adapters=1089 >> compilation: enabled >> >> *Here's the second:* >> >> # >> # A fatal error has been detected by the Java Runtime Environment: >> # >> # Internal Error (instanceKlass.cpp:2018), pid=83979, >> tid=0x00002bb97feba700 >> # Error: ShouldNotReachHere() >> # >> # JRE version: Java(TM) SE Runtime Environment (8.0_102-b14) (build >> 1.8.0_102-b14) >> # Java VM: Java HotSpot(TM) 64-Bit Server VM (25.102-b14 mixed mode >> linux-amd64 ) >> # >> # If you would like to submit a bug report, please visit: >> # http://bugreport.java.com/bugreport/crash.jsp >> # >> >> --------------- T H R E A D --------------- >> >> Current thread (0x00002bb8f40cf800): JavaThread "C2 >> CompilerThread6" daemon [_thread_in_vm, id=84042, >> stack(0x00002bb97fdba000,0x00002bb97febb000)] >> >> Stack: [0x00002bb97fdba000,0x00002bb97febb000], >> sp=0x00002bb97feb9710, free space=1021k >> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, >> C=native code) >> V [libjvm.so+0xac52aa] VMError::report_and_die()+0x2ba >> V [libjvm.so+0x4fbd92] report_should_not_reach_here(char const*, >> int)+0x52 >> V [libjvm.so+0x63e8fb] >> InstanceKlass::remove_dependent_nmethod(nmethod*, bool)+0x5b >> V [libjvm.so+0x8e61b3] >> nmethod::flush_dependencies(BoolObjectClosure*)+0x93 >> V [libjvm.so+0x8ebd5b] >> nmethod::make_not_entrant_or_zombie(unsigned int)+0x48b >> V [libjvm.so+0xa2b0cd] NMethodSweeper::process_nmetho >> d(nmethod*)+0x27d >> V [libjvm.so+0xa2b468] NMethodSweeper::sweep_code_cache()+0x328 >> V [libjvm.so+0xa2b7d4] NMethodSweeper::possibly_sweep()+0xb4 >> V [libjvm.so+0x4ae105] CompileQueue::get()+0x15 >> V [libjvm.so+0x4b047b] CompileBroker::compiler_thread_loop()+0x18b >> V [libjvm.so+0xa73ce3] JavaThread::thread_main_inner()+0x103 >> V [libjvm.so+0xa73e2c] JavaThread::run()+0x11c >> V [libjvm.so+0x9249c8] java_start(Thread*)+0x108 >> C [libpthread.so.0+0x6b50] start_thread+0xd0 >> >> =>0x00002bb8f40cf800 JavaThread "C2 CompilerThread6" daemon >> [_thread_in_vm, id=84042, stack(0x00002bb97fdba000,0x000 >> 02bb97febb000)] >> VM state:not at safepoint (normal execution) >> >> VM Mutex/Monitor currently owned by a thread: ([mutex/lock_event]) >> [0x0000000001858f40] CodeCache_lock - owner thread: 0x00002bb8f40cf800 >> [0x000000000185a240] CompiledIC_lock - owner thread: >> 0x00002bb8f40cf800 >> >> Heap: >> PSYoungGen total 18567168K, used 3149269K [0x00002bb3cdf00000, >> 0x00002bb8e3400000, 0x00002bb8e3400000) >> eden space 15838208K, 5% used [0x00002bb3cdf00000,0x00002bb4 >> 02b26e00,0x00002bb794a00000) >> from space 2728960K, 83% used [0x00002bb83ab00000,0x00002bb8 >> c624e6b0,0x00002bb8e1400000) >> to space 2720768K, 0% used [0x00002bb794a00000,0x00002bb7 >> 94a00000,0x00002bb83ab00000) >> ParOldGen total 23083520K, used 21102913K [0x00002ba9a3400000, >> 0x00002baf24280000, 0x00002bb3cdf00000) >> object space 23083520K, 91% used [0x00002ba9a3400000,0x00002bae >> ab450478,0x00002baf24280000) >> Metaspace used 167926K, capacity 377784K, committed 377856K, >> reserved 378880K >> >> >> >> Polling page: 0x00002ba999461000 >> >> CodeCache: size=102400Kb used=72829Kb max_used=81642Kb free=29570Kb >> bounds [0x00002ba99cdad000, 0x00002ba9a31ad000, 0x00002ba9a31ad000] >> total_blobs=14843 nmethods=13668 adapters=1082 >> compilation: enabled >> >> -- >> Sent from my phone >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vitalyd at gmail.com Wed Dec 7 18:13:29 2016 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Wed, 07 Dec 2016 18:13:29 +0000 Subject: 8u102 NMethod sweeper related Hotspot crashes In-Reply-To: References: <4a46f7da-10af-db7b-9e4c-eca4c0508979@oracle.com> Message-ID: Vladimir, What do you think the next step should be? Is a JBS bug entry warranted? Thanks On Tue, Dec 6, 2016 at 1:12 PM Vitaly Davidovich wrote: > Hi Vladimir, > > On Tue, Dec 6, 2016 at 12:57 PM, Vladimir Kozlov < > vladimir.kozlov at oracle.com> wrote: > > Could be https://bugs.openjdk.java.net/browse/JDK-8139595 (not backported > to 8u). > > I can't find anything else with remove_dependent_nmethod() on call stack > in JBS. > > It does seem like it could be related, but yeah, it's unclear. Hoping > someone else here may have an idea. > > Thanks > > > Vladimir > > On 12/6/16 9:33 AM, Vitaly Davidovich wrote: > > Btw, for now I've advised the group hitting these to turn off tiered > compilation to reduce code cache pressure and thus hopefully avoid > whatever bug(s) is lurking here. > > I should've also mentioned that this doesn't happen all the time, of > course, so there's no reliable repro. > > On Tue, Dec 6, 2016 at 12:02 PM Vitaly Davidovich > wrote: > > Hi guys, > > I have a couple of Hotspot crashes to report - both occur in nmethod > sweeping/flushing. I'm going to strip down the hs_err content, but > let me know if there's something else you need from there. Are > these known? A quick google suggests there are some bugs around > nmethod sweeping, but I couldn't find anything exactly like this. > > Let me know if you need more info. > > Thanks > > *The first is:* > > > # > # A fatal error has been detected by the Java Runtime Environment: > # > # Internal Error (instanceKlass.cpp:1995), pid=15444, > tid=0x00002b1fd0186700 > # guarantee(val >= 0) failed: Underflow: -1 > # > # JRE version: Java(TM) SE Runtime Environment (8.0_102-b14) (build > 1.8.0_102-b14) > # Java VM: Java HotSpot(TM) 64-Bit Server VM (25.102-b14 mixed mode > linux-amd64 ) > # > # If you would like to submit a bug report, please visit: > # http://bugreport.java.com/bugreport/crash.jsp > # > > --------------- T H R E A D --------------- > > Current thread (0x00002b1f58056800): JavaThread "C2 > CompilerThread2" daemon [_thread_in_vm, id=15533, > stack(0x00002b1fd0086000,0x00002b1fd0187000)] > > Stack: [0x00002b1fd0086000,0x00002b1fd0187000], > sp=0x00002b1fd0185580, free space=1021k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, > C=native code) > V [libjvm.so+0xac52aa] VMError::report_and_die()+0x2ba > V [libjvm.so+0x4fba22] report_vm_error(char const*, int, char > const*, char const*)+0x62 > V [libjvm.so+0x63e9b0] > InstanceKlass::remove_dependent_nmethod(nmethod*, bool)+0x110 > V [libjvm.so+0x8e61b3] > nmethod::flush_dependencies(BoolObjectClosure*)+0x93 > V [libjvm.so+0x8ebd5b] > nmethod::make_not_entrant_or_zombie(unsigned int)+0x48b > V [libjvm.so+0xa2b0cd] > NMethodSweeper::process_nmethod(nmethod*)+0x27d > V [libjvm.so+0xa2b468] NMethodSweeper::sweep_code_cache()+0x328 > V [libjvm.so+0xa2b7d4] NMethodSweeper::possibly_sweep()+0xb4 > V [libjvm.so+0x4ae105] CompileQueue::get()+0x15 > V [libjvm.so+0x4b047b] CompileBroker::compiler_thread_loop()+0x18b > V [libjvm.so+0xa73ce3] JavaThread::thread_main_inner()+0x103 > V [libjvm.so+0xa73e2c] JavaThread::run()+0x11c > V [libjvm.so+0x9249c8] java_start(Thread*)+0x108 > C [libpthread.so.0+0x6b50] start_thread+0xd0 > > =>0x00002b1f58056800 JavaThread "C2 CompilerThread2" daemon > [_thread_in_vm, id=15533, stack(0x00002b1fd0086000,0x00002b1fd0187000)] > > VM state:not at safepoint (normal execution) > VM Mutex/Monitor currently owned by a thread: ([mutex/lock_event]) > [0x0000000001ac5f40] CodeCache_lock - owner thread: 0x00002b1f58056800 > [0x0000000001ac7240] CompiledIC_lock - owner thread: 0x00002b1f58056800 > > Heap: > PSYoungGen total 16531968K, used 13673471K > [0x00002b1b0b200000, 0x00002b1f49900000, 0x00002b1f4b200000) > eden space 15297024K, 83% used > [0x00002b1b0b200000,0x00002b1e19277f68,0x00002b1eb0c80000) > from space 1234944K, 69% used > [0x00002b1eb0c80000,0x00002b1ee5507eb0,0x00002b1efc280000) > to space 1198080K, 0% used > [0x00002b1f00700000,0x00002b1f00700000,0x00002b1f49900000) > ParOldGen total 34891264K, used 26246257K > [0x00002b128b200000, 0x00002b1adcb80000, 0x00002b1b0b200000) > object space 34891264K, 75% used > [0x00002b128b200000,0x00002b18cd11c630,0x00002b1adcb80000) > Metaspace used 211158K, capacity 610281K, committed 610528K, > reserved 612352K > > Polling page: 0x00002b1281166000 > > CodeCache: size=102400Kb used=71326Kb max_used=81914Kb free=31073Kb > bounds [0x00002b1284ab2000, 0x00002b128aeb2000, 0x00002b128aeb2000] > total_blobs=13619 nmethods=12436 adapters=1089 > compilation: enabled > > *Here's the second:* > > # > # A fatal error has been detected by the Java Runtime Environment: > # > # Internal Error (instanceKlass.cpp:2018), pid=83979, > tid=0x00002bb97feba700 > # Error: ShouldNotReachHere() > # > # JRE version: Java(TM) SE Runtime Environment (8.0_102-b14) (build > 1.8.0_102-b14) > # Java VM: Java HotSpot(TM) 64-Bit Server VM (25.102-b14 mixed mode > linux-amd64 ) > # > # If you would like to submit a bug report, please visit: > # http://bugreport.java.com/bugreport/crash.jsp > # > > --------------- T H R E A D --------------- > > Current thread (0x00002bb8f40cf800): JavaThread "C2 > CompilerThread6" daemon [_thread_in_vm, id=84042, > stack(0x00002bb97fdba000,0x00002bb97febb000)] > > Stack: [0x00002bb97fdba000,0x00002bb97febb000], > sp=0x00002bb97feb9710, free space=1021k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, > C=native code) > V [libjvm.so+0xac52aa] VMError::report_and_die()+0x2ba > V [libjvm.so+0x4fbd92] report_should_not_reach_here(char const*, > int)+0x52 > V [libjvm.so+0x63e8fb] > InstanceKlass::remove_dependent_nmethod(nmethod*, bool)+0x5b > V [libjvm.so+0x8e61b3] > nmethod::flush_dependencies(BoolObjectClosure*)+0x93 > V [libjvm.so+0x8ebd5b] > nmethod::make_not_entrant_or_zombie(unsigned int)+0x48b > V [libjvm.so+0xa2b0cd] > NMethodSweeper::process_nmethod(nmethod*)+0x27d > V [libjvm.so+0xa2b468] NMethodSweeper::sweep_code_cache()+0x328 > V [libjvm.so+0xa2b7d4] NMethodSweeper::possibly_sweep()+0xb4 > V [libjvm.so+0x4ae105] CompileQueue::get()+0x15 > V [libjvm.so+0x4b047b] CompileBroker::compiler_thread_loop()+0x18b > V [libjvm.so+0xa73ce3] JavaThread::thread_main_inner()+0x103 > V [libjvm.so+0xa73e2c] JavaThread::run()+0x11c > V [libjvm.so+0x9249c8] java_start(Thread*)+0x108 > C [libpthread.so.0+0x6b50] start_thread+0xd0 > > =>0x00002bb8f40cf800 JavaThread "C2 CompilerThread6" daemon > [_thread_in_vm, id=84042, stack(0x00002bb97fdba000,0x00002bb97febb000)] > VM state:not at safepoint (normal execution) > > VM Mutex/Monitor currently owned by a thread: ([mutex/lock_event]) > [0x0000000001858f40] CodeCache_lock - owner thread: 0x00002bb8f40cf800 > [0x000000000185a240] CompiledIC_lock - owner thread: 0x00002bb8f40cf800 > > Heap: > PSYoungGen total 18567168K, used 3149269K [0x00002bb3cdf00000, > 0x00002bb8e3400000, 0x00002bb8e3400000) > eden space 15838208K, 5% used > [0x00002bb3cdf00000,0x00002bb402b26e00,0x00002bb794a00000) > from space 2728960K, 83% used > [0x00002bb83ab00000,0x00002bb8c624e6b0,0x00002bb8e1400000) > to space 2720768K, 0% used > [0x00002bb794a00000,0x00002bb794a00000,0x00002bb83ab00000) > ParOldGen total 23083520K, used 21102913K [0x00002ba9a3400000, > 0x00002baf24280000, 0x00002bb3cdf00000) > object space 23083520K, 91% used > [0x00002ba9a3400000,0x00002baeab450478,0x00002baf24280000) > Metaspace used 167926K, capacity 377784K, committed 377856K, > reserved 378880K > > > > Polling page: 0x00002ba999461000 > > CodeCache: size=102400Kb used=72829Kb max_used=81642Kb free=29570Kb > bounds [0x00002ba99cdad000, 0x00002ba9a31ad000, 0x00002ba9a31ad000] > total_blobs=14843 nmethods=13668 adapters=1082 > compilation: enabled > > -- > Sent from my phone > > -- Sent from my phone -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladimir.kozlov at oracle.com Wed Dec 7 18:20:38 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 7 Dec 2016 10:20:38 -0800 Subject: 8u102 NMethod sweeper related Hotspot crashes In-Reply-To: References: <4a46f7da-10af-db7b-9e4c-eca4c0508979@oracle.com> Message-ID: <345cf4cf-9b50-1911-da34-a77e6f7890a0@oracle.com> All crashes have to have JBS entry. Please, file bug. JDK-8139595 is not related unfortunately. It fixed code present only in JDK 9. Thanks, Vladimir On 12/7/16 10:13 AM, Vitaly Davidovich wrote: > Vladimir, > > What do you think the next step should be? Is a JBS bug entry warranted? > > Thanks > > On Tue, Dec 6, 2016 at 1:12 PM Vitaly Davidovich > wrote: > > Hi Vladimir, > > On Tue, Dec 6, 2016 at 12:57 PM, Vladimir Kozlov > > wrote: > > Could be https://bugs.openjdk.java.net/browse/JDK-8139595 (not > backported to 8u). > > I can't find anything else with remove_dependent_nmethod() on > call stack in JBS. > > It does seem like it could be related, but yeah, it's unclear. > Hoping someone else here may have an idea. > > Thanks > > > Vladimir > > On 12/6/16 9:33 AM, Vitaly Davidovich wrote: > > Btw, for now I've advised the group hitting these to turn > off tiered > compilation to reduce code cache pressure and thus hopefully > avoid > whatever bug(s) is lurking here. > > I should've also mentioned that this doesn't happen all the > time, of > course, so there's no reliable repro. > > On Tue, Dec 6, 2016 at 12:02 PM Vitaly Davidovich > > >> wrote: > > Hi guys, > > I have a couple of Hotspot crashes to report - both > occur in nmethod > sweeping/flushing. I'm going to strip down the hs_err > content, but > let me know if there's something else you need from > there. Are > these known? A quick google suggests there are some bugs > around > nmethod sweeping, but I couldn't find anything exactly > like this. > > Let me know if you need more info. > > Thanks > > *The first is:* > > > # > # A fatal error has been detected by the Java Runtime > Environment: > # > # Internal Error (instanceKlass.cpp:1995), pid=15444, > tid=0x00002b1fd0186700 > # guarantee(val >= 0) failed: Underflow: -1 > # > # JRE version: Java(TM) SE Runtime Environment > (8.0_102-b14) (build > 1.8.0_102-b14) > # Java VM: Java HotSpot(TM) 64-Bit Server VM (25.102-b14 > mixed mode > linux-amd64 ) > # > # If you would like to submit a bug report, please visit: > # http://bugreport.java.com/bugreport/crash.jsp > # > > --------------- T H R E A D --------------- > > Current thread (0x00002b1f58056800): JavaThread "C2 > CompilerThread2" daemon [_thread_in_vm, id=15533, > stack(0x00002b1fd0086000,0x00002b1fd0187000)] > > Stack: [0x00002b1fd0086000,0x00002b1fd0187000], > sp=0x00002b1fd0185580, free space=1021k > Native frames: (J=compiled Java code, j=interpreted, > Vv=VM code, > C=native code) > V [libjvm.so+0xac52aa] VMError::report_and_die()+0x2ba > V [libjvm.so+0x4fba22] report_vm_error(char const*, > int, char > const*, char const*)+0x62 > V [libjvm.so+0x63e9b0] > InstanceKlass::remove_dependent_nmethod(nmethod*, > bool)+0x110 > V [libjvm.so+0x8e61b3] > nmethod::flush_dependencies(BoolObjectClosure*)+0x93 > V [libjvm.so+0x8ebd5b] > nmethod::make_not_entrant_or_zombie(unsigned int)+0x48b > V [libjvm.so+0xa2b0cd] > NMethodSweeper::process_nmethod(nmethod*)+0x27d > V [libjvm.so+0xa2b468] > NMethodSweeper::sweep_code_cache()+0x328 > V [libjvm.so+0xa2b7d4] > NMethodSweeper::possibly_sweep()+0xb4 > V [libjvm.so+0x4ae105] CompileQueue::get()+0x15 > V [libjvm.so+0x4b047b] > CompileBroker::compiler_thread_loop()+0x18b > V [libjvm.so+0xa73ce3] > JavaThread::thread_main_inner()+0x103 > V [libjvm.so+0xa73e2c] JavaThread::run()+0x11c > V [libjvm.so+0x9249c8] java_start(Thread*)+0x108 > C [libpthread.so.0+0x6b50] start_thread+0xd0 > > =>0x00002b1f58056800 JavaThread "C2 CompilerThread2" daemon > [_thread_in_vm, id=15533, > stack(0x00002b1fd0086000,0x00002b1fd0187000)] > > VM state:not at safepoint (normal execution) > VM Mutex/Monitor currently owned by a thread: > ([mutex/lock_event]) > [0x0000000001ac5f40] CodeCache_lock - owner thread: > 0x00002b1f58056800 > [0x0000000001ac7240] CompiledIC_lock - owner thread: > 0x00002b1f58056800 > > Heap: > PSYoungGen total 16531968K, used 13673471K > [0x00002b1b0b200000, 0x00002b1f49900000, 0x00002b1f4b200000) > eden space 15297024K, 83% used > [0x00002b1b0b200000,0x00002b1e19277f68,0x00002b1eb0c80000) > from space 1234944K, 69% used > [0x00002b1eb0c80000,0x00002b1ee5507eb0,0x00002b1efc280000) > to space 1198080K, 0% used > [0x00002b1f00700000,0x00002b1f00700000,0x00002b1f49900000) > ParOldGen total 34891264K, used 26246257K > [0x00002b128b200000, 0x00002b1adcb80000, 0x00002b1b0b200000) > object space 34891264K, 75% used > [0x00002b128b200000,0x00002b18cd11c630,0x00002b1adcb80000) > Metaspace used 211158K, capacity 610281K, > committed 610528K, > reserved 612352K > > Polling page: 0x00002b1281166000 > > CodeCache: size=102400Kb used=71326Kb max_used=81914Kb > free=31073Kb > bounds [0x00002b1284ab2000, 0x00002b128aeb2000, > 0x00002b128aeb2000] > total_blobs=13619 nmethods=12436 adapters=1089 > compilation: enabled > > *Here's the second:* > > # > # A fatal error has been detected by the Java Runtime > Environment: > # > # Internal Error (instanceKlass.cpp:2018), pid=83979, > tid=0x00002bb97feba700 > # Error: ShouldNotReachHere() > # > # JRE version: Java(TM) SE Runtime Environment > (8.0_102-b14) (build > 1.8.0_102-b14) > # Java VM: Java HotSpot(TM) 64-Bit Server VM (25.102-b14 > mixed mode > linux-amd64 ) > # > # If you would like to submit a bug report, please visit: > # http://bugreport.java.com/bugreport/crash.jsp > # > > --------------- T H R E A D --------------- > > Current thread (0x00002bb8f40cf800): JavaThread "C2 > CompilerThread6" daemon [_thread_in_vm, id=84042, > stack(0x00002bb97fdba000,0x00002bb97febb000)] > > Stack: [0x00002bb97fdba000,0x00002bb97febb000], > sp=0x00002bb97feb9710, free space=1021k > Native frames: (J=compiled Java code, j=interpreted, > Vv=VM code, > C=native code) > V [libjvm.so+0xac52aa] VMError::report_and_die()+0x2ba > V [libjvm.so+0x4fbd92] > report_should_not_reach_here(char const*, > int)+0x52 > V [libjvm.so+0x63e8fb] > InstanceKlass::remove_dependent_nmethod(nmethod*, > bool)+0x5b > V [libjvm.so+0x8e61b3] > nmethod::flush_dependencies(BoolObjectClosure*)+0x93 > V [libjvm.so+0x8ebd5b] > nmethod::make_not_entrant_or_zombie(unsigned int)+0x48b > V [libjvm.so+0xa2b0cd] > NMethodSweeper::process_nmethod(nmethod*)+0x27d > V [libjvm.so+0xa2b468] > NMethodSweeper::sweep_code_cache()+0x328 > V [libjvm.so+0xa2b7d4] > NMethodSweeper::possibly_sweep()+0xb4 > V [libjvm.so+0x4ae105] CompileQueue::get()+0x15 > V [libjvm.so+0x4b047b] > CompileBroker::compiler_thread_loop()+0x18b > V [libjvm.so+0xa73ce3] > JavaThread::thread_main_inner()+0x103 > V [libjvm.so+0xa73e2c] JavaThread::run()+0x11c > V [libjvm.so+0x9249c8] java_start(Thread*)+0x108 > C [libpthread.so.0+0x6b50] start_thread+0xd0 > > =>0x00002bb8f40cf800 JavaThread "C2 CompilerThread6" daemon > [_thread_in_vm, id=84042, > stack(0x00002bb97fdba000,0x00002bb97febb000)] > VM state:not at safepoint (normal execution) > > VM Mutex/Monitor currently owned by a thread: > ([mutex/lock_event]) > [0x0000000001858f40] CodeCache_lock - owner thread: > 0x00002bb8f40cf800 > [0x000000000185a240] CompiledIC_lock - owner thread: > 0x00002bb8f40cf800 > > Heap: > PSYoungGen total 18567168K, used 3149269K > [0x00002bb3cdf00000, 0x00002bb8e3400000, 0x00002bb8e3400000) > eden space 15838208K, 5% used > [0x00002bb3cdf00000,0x00002bb402b26e00,0x00002bb794a00000) > from space 2728960K, 83% used > [0x00002bb83ab00000,0x00002bb8c624e6b0,0x00002bb8e1400000) > to space 2720768K, 0% used > [0x00002bb794a00000,0x00002bb794a00000,0x00002bb83ab00000) > ParOldGen total 23083520K, used 21102913K > [0x00002ba9a3400000, 0x00002baf24280000, 0x00002bb3cdf00000) > object space 23083520K, 91% used > [0x00002ba9a3400000,0x00002baeab450478,0x00002baf24280000) > Metaspace used 167926K, capacity 377784K, > committed 377856K, reserved 378880K > > > > Polling page: 0x00002ba999461000 > > CodeCache: size=102400Kb used=72829Kb max_used=81642Kb > free=29570Kb > bounds [0x00002ba99cdad000, 0x00002ba9a31ad000, > 0x00002ba9a31ad000] > total_blobs=14843 nmethods=13668 adapters=1082 > compilation: enabled > > -- > Sent from my phone > > -- > Sent from my phone From rahul.v.raghavan at oracle.com Thu Dec 8 08:10:27 2016 From: rahul.v.raghavan at oracle.com (Rahul Raghavan) Date: Thu, 8 Dec 2016 00:10:27 -0800 (PST) Subject: RFR: 8156762: compiler/ciReplay/TestVM_no_comp_level.java fails with - 'Unexpected exit code for negative case: [-client]: expected 0 to not equal 0' Message-ID: <597494ba-cce4-4758-9517-09ceeca99de2@default> Hi, Please review following patch for JDK-8156762. - http://cr.openjdk.java.net/~rraghavan/8156762/webrev.00/ - https://bugs.openjdk.java.net/browse/JDK-8156762 Please note that JDK-8156762 is an Oracle closed bug, reporting failure for hotspot/test/compiler/ciReplay/TestVM_no_comp_level.sh for build configuration with only Client VM. Understood the test scenario as - force JVM to generate test_replay.txt file - remove compilation level from test_replay.txt file - then check replay the modified test_replay.txt Above proposed test fix in webrev.00 - [test/compiler/ciReplay/TestVMNoCompLevel.java] .............. public void testAction() { ...... ...... if (CLIENT_VM_AVAILABLE) { - negativeTest(CLIENT_VM_OPTION); + if (SERVER_VM_AVAILABLE) { + negativeTest(CLIENT_VM_OPTION); + } + else { + positiveTest(CLIENT_VM_OPTION); + } } if (SERVER_VM_AVAILABLE) { positiveTest(TIERED_DISABLED_VM_OPTION, SERVER_VM_OPTION); positiveTest(TIERED_ENABLED_VM_OPTION, SERVER_VM_OPTION); } } .............. The test was written expecting VM to crash always in Client VM available case, when replay the modified test_replay.txt without compilation level. But found this is not true because a default compiler level of highest available level value is always used, if the same is missing, to support older version of Compiler replay without compiler level support. [process_compile() - hotspot\src\share\vm\ci\ciReplay.cpp] So for the reported case if ONLY CLIENT_VM_AVAILABLE is true - Originally in test, VM was expected to crash always here. Found this is wrong due to the setting of default compiler level to highest available level value in process_compile() - which is 'CompLevel_simple' in this case. So for ONLY CLIENT_VM_AVAILABLE case the VM will not crash at 'is_valid_comp_level()', going ahead with replaying the modified test_replay.txt with -client option. (.i.e. positiveTest(-client) is required) For the case with if both CLIENT_VM_AVAILABLE and SERVER_VM_AVAILABLE are true, when test_replay.txt without compilation level is used, the default compiler level assigned in process_compile() will be 'CompLevel_full_optimization'. So when attempted replay the modified test_replay.txt with -client option, the VM should fail for 'if (CLIENT_VM_AVAILABLE)' block at - if (!TieredCompilation && (comp_level != CompLevel_highest_tier)) check [is_valid_comp_level()] (.i.e. negativeTest(-client) is required) The further testing for SERVER_VM_AVAILABLE is not touched and any how will always continue with required tiered disable/enabled , -server options. No issues with testing for various targets. Thanks, Rahul From zoltan.majo at oracle.com Thu Dec 8 08:25:04 2016 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Thu, 8 Dec 2016 09:25:04 +0100 Subject: RFR: 8156762: compiler/ciReplay/TestVM_no_comp_level.java fails with - 'Unexpected exit code for negative case: [-client]: expected 0 to not equal 0' In-Reply-To: <597494ba-cce4-4758-9517-09ceeca99de2@default> References: <597494ba-cce4-4758-9517-09ceeca99de2@default> Message-ID: Hi Rahul, can you please move the else on line 71 to line 70 (to the same line with the closing '}')? 68 if (SERVER_VM_AVAILABLE) { 69 negativeTest(CLIENT_VM_OPTION); 70 } 71 else { 72 positiveTest(CLIENT_VM_OPTION); 73 } Otherwise it looks good to me. Thank you! Best regards, Zoltan On 12/08/2016 09:10 AM, Rahul Raghavan wrote: > Hi, > > Please review following patch for JDK-8156762. > - http://cr.openjdk.java.net/~rraghavan/8156762/webrev.00/ > > - https://bugs.openjdk.java.net/browse/JDK-8156762 > > Please note that JDK-8156762 is an Oracle closed bug, > reporting failure for hotspot/test/compiler/ciReplay/TestVM_no_comp_level.sh > for build configuration with only Client VM. > > Understood the test scenario as > - force JVM to generate test_replay.txt file > - remove compilation level from test_replay.txt file > - then check replay the modified test_replay.txt > > Above proposed test fix in webrev.00 - > [test/compiler/ciReplay/TestVMNoCompLevel.java] > .............. > public void testAction() { > ...... > ...... > if (CLIENT_VM_AVAILABLE) { > - negativeTest(CLIENT_VM_OPTION); > + if (SERVER_VM_AVAILABLE) { > + negativeTest(CLIENT_VM_OPTION); > + } > + else { > + positiveTest(CLIENT_VM_OPTION); > + } > } > if (SERVER_VM_AVAILABLE) { > positiveTest(TIERED_DISABLED_VM_OPTION, SERVER_VM_OPTION); > positiveTest(TIERED_ENABLED_VM_OPTION, SERVER_VM_OPTION); > } > } > .............. > > The test was written expecting VM to crash always in Client VM available case, > when replay the modified test_replay.txt without compilation level. > But found this is not true because a default compiler level of highest available level value is always used, if the same is missing, > to support older version of Compiler replay without compiler level support. > [process_compile() - hotspot\src\share\vm\ci\ciReplay.cpp] > > So for the reported case if ONLY CLIENT_VM_AVAILABLE is true - > Originally in test, VM was expected to crash always here. > Found this is wrong due to the setting of default compiler level > to highest available level value in process_compile() - which is 'CompLevel_simple' in this case. > So for ONLY CLIENT_VM_AVAILABLE case the VM will not crash at 'is_valid_comp_level()', > going ahead with replaying the modified test_replay.txt with -client option. > (.i.e. positiveTest(-client) is required) > > For the case with if both CLIENT_VM_AVAILABLE and SERVER_VM_AVAILABLE are true, > when test_replay.txt without compilation level is used, > the default compiler level assigned in process_compile() will be 'CompLevel_full_optimization'. > So when attempted replay the modified test_replay.txt with -client option, > the VM should fail for 'if (CLIENT_VM_AVAILABLE)' block at - > if (!TieredCompilation && (comp_level != CompLevel_highest_tier)) check [is_valid_comp_level()] > (.i.e. negativeTest(-client) is required) > > The further testing for SERVER_VM_AVAILABLE is not touched > and any how will always continue with required tiered disable/enabled , -server options. > > No issues with testing for various targets. > > Thanks, > Rahul From boris.molodenkov at oracle.com Thu Dec 8 10:30:29 2016 From: boris.molodenkov at oracle.com (Boris Molodenkov) Date: Thu, 8 Dec 2016 13:30:29 +0300 Subject: RFR: 8170464: Remove shell script from compiler/c2/cr7005594/Test7005594.java In-Reply-To: <58459F3C.7010204@oracle.com> References: <0fd73258-0865-8062-d3ca-a9797d4f0f9c@oracle.com> <58459F3C.7010204@oracle.com> Message-ID: <58493645.6070401@oracle.com> Vladimir, I checked that changed test reproduces 7005594 problem in JDK7 b120. Issue is not reproduced with suggested workaround -XX:LoopOptsCount=0. $ jdk1.7.0/bin/java -showversion -Xcomp -XX:CompileOnly=compiler.c2.cr7005594.Test7005594::test compiler.c2.cr7005594.Test7005594 java version "1.7.0-ea" Java(TM) SE Runtime Environment (build 1.7.0-ea-b120) Java HotSpot(TM) 64-Bit Server VM (build 20.0-b03, compiled mode) Exception in thread "main" java.lang.AssertionError: Expected ArrayIndexOutOfBoundsException was not thrown at compiler.c2.cr7005594.Test7005594.main(Test7005594.java:48) $ jdk1.7.0/bin/java -showversion -Xcomp -XX:LoopOptsCount=0 -XX:CompileOnly=compiler.c2.cr7005594.Test7005594::test compiler.c2.cr7005594.Test7005594 java version "1.7.0-ea" Java(TM) SE Runtime Environment (build 1.7.0-ea-b120) Java HotSpot(TM) 64-Bit Server VM (build 20.0-b03, compiled mode) Expected java.lang.ArrayIndexOutOfBoundsException: -2147483648 was thrown Thanks, Boris On 12/05/2016 08:09 PM, Vladimir Kozlov wrote: > You changed test behavior. The loop should execute 3 iterations to hit > the problem (to execute main-loop after iterations split loop > optimization). Please, verify that 7005594 problem is reproduced with > old JVM. > > Vladimir > > On 12/5/16 5:06 AM, Boris Molodenkov wrote: >> Hi All, >> >> Could you please review shell script removal from compiler test. >> >> Test used shell script to check available memory size and message >> "Could not reserve enough space" in output. >> Test was slightly changed. Now it allocates array of 2 bytes instead >> of 1GB as in original. >> Tested locally that issue is reproduced with JDK7 b120. >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8170464 >> Webrev: http://cr.openjdk.java.net/~bmoloden/8170464/webrev.00/ >> >> Thanks, >> Boris >> From rwestrel at redhat.com Thu Dec 8 13:41:01 2016 From: rwestrel at redhat.com (Roland Westrelin) Date: Thu, 08 Dec 2016 14:41:01 +0100 Subject: [aarch64-port-dev ] RFR: 8169697: aarch64: vectorized MLA instruction not generated for some test cases In-Reply-To: References: Message-ID: Hi Ningsheng, > NEON vector MLA instructions can not be generated in some simple > multiply-add cases. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8169697 > This is a bug fix and bug fixes can still be pushed without restrictions so I see no reason to not go with this: > In the mean time, Yang also has a more generic fix for this issue, > which patches share code and could also fix this issue: > > http://cr.openjdk.java.net/~njian/8169697/webrev.share/ That looks good to me. Anyone on the compiler side can take a look (and sponsor)? Roland. From jamsheed.c.m at oracle.com Thu Dec 8 14:46:44 2016 From: jamsheed.c.m at oracle.com (Jamsheed C m) Date: Thu, 8 Dec 2016 20:16:44 +0530 Subject: RFR: 8170761: Buffer overrun in sharedRuntime_x86_64.cpp:477 Message-ID: <895ad5a2-afbc-45a0-5533-9893251a60e1@oracle.com> Hi, Please review a minor assert correction. webrev: http://cr.openjdk.java.net/~jcm/8170761/webrev.00/ Best Regards, Jamsheed From vladimir.kozlov at oracle.com Thu Dec 8 18:13:10 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 8 Dec 2016 10:13:10 -0800 Subject: RFR: 8170464: Remove shell script from compiler/c2/cr7005594/Test7005594.java In-Reply-To: <58493645.6070401@oracle.com> References: <0fd73258-0865-8062-d3ca-a9797d4f0f9c@oracle.com> <58459F3C.7010204@oracle.com> <58493645.6070401@oracle.com> Message-ID: Than it is good. Thank you for testing. Vladimir On 12/8/16 2:30 AM, Boris Molodenkov wrote: > Vladimir, > > I checked that changed test reproduces 7005594 problem in JDK7 b120. > Issue is not reproduced with suggested workaround -XX:LoopOptsCount=0. > > $ jdk1.7.0/bin/java -showversion -Xcomp > -XX:CompileOnly=compiler.c2.cr7005594.Test7005594::test > compiler.c2.cr7005594.Test7005594 > java version "1.7.0-ea" > Java(TM) SE Runtime Environment (build 1.7.0-ea-b120) > Java HotSpot(TM) 64-Bit Server VM (build 20.0-b03, compiled mode) > > Exception in thread "main" java.lang.AssertionError: Expected > ArrayIndexOutOfBoundsException was not thrown > at compiler.c2.cr7005594.Test7005594.main(Test7005594.java:48) > > $ jdk1.7.0/bin/java -showversion -Xcomp -XX:LoopOptsCount=0 > -XX:CompileOnly=compiler.c2.cr7005594.Test7005594::test > compiler.c2.cr7005594.Test7005594 > java version "1.7.0-ea" > Java(TM) SE Runtime Environment (build 1.7.0-ea-b120) > Java HotSpot(TM) 64-Bit Server VM (build 20.0-b03, compiled mode) > > Expected java.lang.ArrayIndexOutOfBoundsException: -2147483648 was thrown > > Thanks, > Boris > > On 12/05/2016 08:09 PM, Vladimir Kozlov wrote: >> You changed test behavior. The loop should execute 3 iterations to hit >> the problem (to execute main-loop after iterations split loop >> optimization). Please, verify that 7005594 problem is reproduced with >> old JVM. >> >> Vladimir >> >> On 12/5/16 5:06 AM, Boris Molodenkov wrote: >>> Hi All, >>> >>> Could you please review shell script removal from compiler test. >>> >>> Test used shell script to check available memory size and message >>> "Could not reserve enough space" in output. >>> Test was slightly changed. Now it allocates array of 2 bytes instead >>> of 1GB as in original. >>> Tested locally that issue is reproduced with JDK7 b120. >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8170464 >>> Webrev: http://cr.openjdk.java.net/~bmoloden/8170464/webrev.00/ >>> >>> Thanks, >>> Boris >>> > From vladimir.kozlov at oracle.com Thu Dec 8 18:57:22 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 8 Dec 2016 10:57:22 -0800 Subject: RFR: 8170761: Buffer overrun in sharedRuntime_x86_64.cpp:477 In-Reply-To: <895ad5a2-afbc-45a0-5533-9893251a60e1@oracle.com> References: <895ad5a2-afbc-45a0-5533-9893251a60e1@oracle.com> Message-ID: Good. Thanks, Vladimir On 12/8/16 6:46 AM, Jamsheed C m wrote: > Hi, > > Please review a minor assert correction. > > webrev: http://cr.openjdk.java.net/~jcm/8170761/webrev.00/ > > Best Regards, > > Jamsheed > From ningsheng.jian at linaro.org Fri Dec 9 01:56:24 2016 From: ningsheng.jian at linaro.org (Ningsheng Jian) Date: Fri, 9 Dec 2016 09:56:24 +0800 Subject: [aarch64-port-dev ] RFR: 8169697: aarch64: vectorized MLA instruction not generated for some test cases In-Reply-To: References: Message-ID: Hi Roland, Thanks for the review. >> NEON vector MLA instructions can not be generated in some simple >> multiply-add cases. >> >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8169697 >> > > This is a bug fix and bug fixes can still be pushed without restrictions > so I see no reason to not go with this: > >> In the mean time, Yang also has a more generic fix for this issue, >> which patches share code and could also fix this issue: >> >> http://cr.openjdk.java.net/~njian/8169697/webrev.share/ > > That looks good to me. Anyone on the compiler side can take a look (and > sponsor)? Compared to aarch64 only version, I also prefer this patch. Thanks, Ningsheng From boris.molodenkov at oracle.com Fri Dec 9 08:00:57 2016 From: boris.molodenkov at oracle.com (Boris Molodenkov) Date: Fri, 9 Dec 2016 11:00:57 +0300 Subject: RFR: 8170464: Remove shell script from compiler/c2/cr7005594/Test7005594.java In-Reply-To: References: <0fd73258-0865-8062-d3ca-a9797d4f0f9c@oracle.com> <58459F3C.7010204@oracle.com> <58493645.6070401@oracle.com> Message-ID: <7aa664ea-f316-937f-fb52-cd6b842f638c@oracle.com> Thank you for review. Boris On 08.12.2016 21:13, Vladimir Kozlov wrote: > Than it is good. Thank you for testing. > > Vladimir > > On 12/8/16 2:30 AM, Boris Molodenkov wrote: >> Vladimir, >> >> I checked that changed test reproduces 7005594 problem in JDK7 b120. >> Issue is not reproduced with suggested workaround -XX:LoopOptsCount=0. >> >> $ jdk1.7.0/bin/java -showversion -Xcomp >> -XX:CompileOnly=compiler.c2.cr7005594.Test7005594::test >> compiler.c2.cr7005594.Test7005594 >> java version "1.7.0-ea" >> Java(TM) SE Runtime Environment (build 1.7.0-ea-b120) >> Java HotSpot(TM) 64-Bit Server VM (build 20.0-b03, compiled mode) >> >> Exception in thread "main" java.lang.AssertionError: Expected >> ArrayIndexOutOfBoundsException was not thrown >> at compiler.c2.cr7005594.Test7005594.main(Test7005594.java:48) >> >> $ jdk1.7.0/bin/java -showversion -Xcomp -XX:LoopOptsCount=0 >> -XX:CompileOnly=compiler.c2.cr7005594.Test7005594::test >> compiler.c2.cr7005594.Test7005594 >> java version "1.7.0-ea" >> Java(TM) SE Runtime Environment (build 1.7.0-ea-b120) >> Java HotSpot(TM) 64-Bit Server VM (build 20.0-b03, compiled mode) >> >> Expected java.lang.ArrayIndexOutOfBoundsException: -2147483648 was >> thrown >> >> Thanks, >> Boris >> >> On 12/05/2016 08:09 PM, Vladimir Kozlov wrote: >>> You changed test behavior. The loop should execute 3 iterations to hit >>> the problem (to execute main-loop after iterations split loop >>> optimization). Please, verify that 7005594 problem is reproduced with >>> old JVM. >>> >>> Vladimir >>> >>> On 12/5/16 5:06 AM, Boris Molodenkov wrote: >>>> Hi All, >>>> >>>> Could you please review shell script removal from compiler test. >>>> >>>> Test used shell script to check available memory size and message >>>> "Could not reserve enough space" in output. >>>> Test was slightly changed. Now it allocates array of 2 bytes instead >>>> of 1GB as in original. >>>> Tested locally that issue is reproduced with JDK7 b120. >>>> >>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8170464 >>>> Webrev: http://cr.openjdk.java.net/~bmoloden/8170464/webrev.00/ >>>> >>>> Thanks, >>>> Boris >>>> >> From jamsheed.c.m at oracle.com Fri Dec 9 08:11:57 2016 From: jamsheed.c.m at oracle.com (Jamsheed C m) Date: Fri, 9 Dec 2016 13:41:57 +0530 Subject: RFR: 8170761: Buffer overrun in sharedRuntime_x86_64.cpp:477 In-Reply-To: References: <895ad5a2-afbc-45a0-5533-9893251a60e1@oracle.com> Message-ID: <134fca0e-3e8b-c892-4db4-f6aeefff5012@oracle.com> i missed applying fixes in other similar sites. sorry! revised webrev: http://cr.openjdk.java.net/~jcm/8170761/webrev.01 Please review. Best Regards, Jamsheed On 12/9/2016 12:27 AM, Vladimir Kozlov wrote: > Good. > > Thanks, > Vladimir > > On 12/8/16 6:46 AM, Jamsheed C m wrote: >> Hi, >> >> Please review a minor assert correction. >> >> webrev: http://cr.openjdk.java.net/~jcm/8170761/webrev.00/ >> >> Best Regards, >> >> Jamsheed >> From rwestrel at redhat.com Fri Dec 9 16:35:32 2016 From: rwestrel at redhat.com (Roland Westrelin) Date: Fri, 09 Dec 2016 17:35:32 +0100 Subject: RFR(S): 8162338: AArch64: Intrinsify fused mac operations Message-ID: http://cr.openjdk.java.net/~roland/8162338/webrev.00/ This also fixes a shared code bug in c1 and adds a new test case so I'll need a sponsor. I know I need to request extension: I'll do that. Roland. From martin.doerr at sap.com Fri Dec 9 17:01:23 2016 From: martin.doerr at sap.com (Doerr, Martin) Date: Fri, 9 Dec 2016 17:01:23 +0000 Subject: RFR(M): 8170991: PPC64: Bad code for initialization of short arrays Message-ID: Hello everybody, the new flag "InitArrayShortSize" was set to 8 on PPC64. However, this leads to bad code. PPC64's C2 compiler currently does not have dedicated match rules to store 0. Unfortunately, loading of the constant 0 got rematerialized many times in some cases consuming more registers and code space than needed. An attempt to improve initialization was 8170094: PPC64: Keep immediate value 0 cached into a register to improve performance but this approach has disadvantages and we had decided against it. It is possibly to implement special ClearArray nodes to improve the initialization of arrays only: http://cr.openjdk.java.net/~mdoerr/8170991_PPC64_ClearArray/webrev.00/ Please review. @Gustavo: Maybe this improves your test cases, too? Best regards, Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladimir.kozlov at oracle.com Fri Dec 9 18:46:05 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 9 Dec 2016 10:46:05 -0800 Subject: RFR(S): 8162338: AArch64: Intrinsify fused mac operations In-Reply-To: References: Message-ID: <326e7e90-ba04-9b94-6f85-8d8d292e36ad@oracle.com> Hi Roland, You said in FC extension request that only aarch64 code is affected but you changed c1/c1_LIR.cpp. Can you do without this change? Otherwise RFE have to be rejected since there is no time to go through internal review process. I am fine with additional test. Thanks, Vladimir On 12/9/16 8:35 AM, Roland Westrelin wrote: > > http://cr.openjdk.java.net/~roland/8162338/webrev.00/ > > This also fixes a shared code bug in c1 and adds a new test case so I'll > need a sponsor. I know I need to request extension: I'll do that. > > Roland. > From vladimir.kozlov at oracle.com Fri Dec 9 18:49:33 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 9 Dec 2016 10:49:33 -0800 Subject: RFR: 8170761: Buffer overrun in sharedRuntime_x86_64.cpp:477 In-Reply-To: <134fca0e-3e8b-c892-4db4-f6aeefff5012@oracle.com> References: <895ad5a2-afbc-45a0-5533-9893251a60e1@oracle.com> <134fca0e-3e8b-c892-4db4-f6aeefff5012@oracle.com> Message-ID: <7baf272e-7bd1-1cc7-584c-f363b5a74e65@oracle.com> Still good. Vladimir On 12/9/16 12:11 AM, Jamsheed C m wrote: > i missed applying fixes in other similar sites. sorry! > > revised webrev: http://cr.openjdk.java.net/~jcm/8170761/webrev.01 > > Please review. > > Best Regards, > > Jamsheed > > > On 12/9/2016 12:27 AM, Vladimir Kozlov wrote: >> Good. >> >> Thanks, >> Vladimir >> >> On 12/8/16 6:46 AM, Jamsheed C m wrote: >>> Hi, >>> >>> Please review a minor assert correction. >>> >>> webrev: http://cr.openjdk.java.net/~jcm/8170761/webrev.00/ >>> >>> Best Regards, >>> >>> Jamsheed >>> > From rwestrel at redhat.com Fri Dec 9 19:19:54 2016 From: rwestrel at redhat.com (Roland Westrelin) Date: Fri, 09 Dec 2016 20:19:54 +0100 Subject: RFR(S): 8162338: AArch64: Intrinsify fused mac operations In-Reply-To: <326e7e90-ba04-9b94-6f85-8d8d292e36ad@oracle.com> References: <326e7e90-ba04-9b94-6f85-8d8d292e36ad@oracle.com> Message-ID: Vladimir, Thanks for looking at this (and while I have your attention: I would need your opinion on 8169697 as well). > You said in FC extension request that only aarch64 code is affected but > you changed c1/c1_LIR.cpp. > > Can you do without this change? Otherwise RFE have to be rejected since > there is no time to go through internal review process. It's a bug fix. In the current code there's no call to do_input(op3->_opr3) which is how the register allocator knows that there's a third input to the LIR operation. So the current code works by accident at best. Do you want me to get this fixed separately? Roland. From vladimir.kozlov at oracle.com Fri Dec 9 19:30:20 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 9 Dec 2016 11:30:20 -0800 Subject: [aarch64-port-dev ] RFR: 8169697: aarch64: vectorized MLA instruction not generated for some test cases In-Reply-To: References: Message-ID: <15b3b2dc-481f-98fd-c7db-f72f58d970e1@oracle.com> On 12/8/16 5:56 PM, Ningsheng Jian wrote: > Hi Roland, > > Thanks for the review. > >>> NEON vector MLA instructions can not be generated in some simple >>> multiply-add cases. >>> >>> Bug: >>> https://bugs.openjdk.java.net/browse/JDK-8169697 >>> >> >> This is a bug fix and bug fixes can still be pushed without restrictions >> so I see no reason to not go with this: >> >>> In the mean time, Yang also has a more generic fix for this issue, >>> which patches share code and could also fix this issue: >>> >>> http://cr.openjdk.java.net/~njian/8169697/webrev.share/ >> >> That looks good to me. Anyone on the compiler side can take a look (and >> sponsor)? > > Compared to aarch64 only version, I also prefer this patch. What about SubV* and MulV* nodes? I prefer shared code change but we would need to test on all platforms which support vectors. Thanks, Vladimir > > Thanks, > Ningsheng > From vladimir.kozlov at oracle.com Fri Dec 9 19:31:35 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 9 Dec 2016 11:31:35 -0800 Subject: RFR(S): 8162338: AArch64: Intrinsify fused mac operations In-Reply-To: References: <326e7e90-ba04-9b94-6f85-8d8d292e36ad@oracle.com> Message-ID: <7466bbbc-3de1-0a64-aa56-d24a5067ac86@oracle.com> On 12/9/16 11:19 AM, Roland Westrelin wrote: > > Vladimir, > > Thanks for looking at this (and while I have your attention: I would > need your opinion on 8169697 as well). It is bug but very intrusive for all platforms supporting vectors. We will have to test it before push. But I am fine to keep it as bug. > >> You said in FC extension request that only aarch64 code is affected but >> you changed c1/c1_LIR.cpp. >> >> Can you do without this change? Otherwise RFE have to be rejected since >> there is no time to go through internal review process. > > It's a bug fix. In the current code there's no call to > do_input(op3->_opr3) which is how the register allocator knows that > there's a third input to the LIR operation. So the current code works by > accident at best. Do you want me to get this fixed separately? File separate bug for this we can fix it any time until ZBB in Feb. Include test into it too. This way I can approve this RFE and you can push. Vladimir > > Roland. > From yang.zhang at linaro.org Mon Dec 12 03:42:59 2016 From: yang.zhang at linaro.org (Yang Zhang) Date: Mon, 12 Dec 2016 11:42:59 +0800 Subject: [aarch64-port-dev ] RFR: 8169697: aarch64: vectorized MLA instruction not generated for some test cases In-Reply-To: <15b3b2dc-481f-98fd-c7db-f72f58d970e1@oracle.com> References: <15b3b2dc-481f-98fd-c7db-f72f58d970e1@oracle.com> Message-ID: Hi Vladimir, Thanks for your review. > > What about SubV* and MulV* nodes? > After checking commut_op_list, I think MulV*, AndV, OrV and XorV nodes can also be added. Should I add them all? SubV* nodes are not commutative, so I don't think they need to be considered here. > > I prefer shared code change but we would need to test on all platforms which support vectors. > Yeah, we need to test on all platforms. We already tested previous patch on x86 and aarch64 platforms, but we don't have other platforms. Regards Yang From jamsheed.c.m at oracle.com Mon Dec 12 06:04:52 2016 From: jamsheed.c.m at oracle.com (Jamsheed C m) Date: Mon, 12 Dec 2016 11:34:52 +0530 Subject: RFR: 8170761: Buffer overrun in sharedRuntime_x86_64.cpp:477 In-Reply-To: <7baf272e-7bd1-1cc7-584c-f363b5a74e65@oracle.com> References: <895ad5a2-afbc-45a0-5533-9893251a60e1@oracle.com> <134fca0e-3e8b-c892-4db4-f6aeefff5012@oracle.com> <7baf272e-7bd1-1cc7-584c-f363b5a74e65@oracle.com> Message-ID: <73159554-72a3-817b-ac30-b8e162952f7d@oracle.com> Thank you, Vladimir. Best Regards, Jamsheed On 12/10/2016 12:19 AM, Vladimir Kozlov wrote: > Still good. > > Vladimir > > On 12/9/16 12:11 AM, Jamsheed C m wrote: >> i missed applying fixes in other similar sites. sorry! >> >> revised webrev: http://cr.openjdk.java.net/~jcm/8170761/webrev.01 >> >> Please review. >> >> Best Regards, >> >> Jamsheed >> >> >> On 12/9/2016 12:27 AM, Vladimir Kozlov wrote: >>> Good. >>> >>> Thanks, >>> Vladimir >>> >>> On 12/8/16 6:46 AM, Jamsheed C m wrote: >>>> Hi, >>>> >>>> Please review a minor assert correction. >>>> >>>> webrev: http://cr.openjdk.java.net/~jcm/8170761/webrev.00/ >>>> >>>> Best Regards, >>>> >>>> Jamsheed >>>> >> From rahul.v.raghavan at oracle.com Mon Dec 12 07:04:46 2016 From: rahul.v.raghavan at oracle.com (Rahul Raghavan) Date: Sun, 11 Dec 2016 23:04:46 -0800 (PST) Subject: RFR: 8156762: compiler/ciReplay/TestVM_no_comp_level.java fails with - 'Unexpected exit code for negative case: [-client]: expected 0 to not equal 0' In-Reply-To: References: <597494ba-cce4-4758-9517-09ceeca99de2@default> Message-ID: Hi, Thank you Zoltan for review comments. Yes made the required change. - http://cr.openjdk.java.net/~rraghavan/8156762/webrev.01/ Thanks, Rahul > -----Original Message----- > From: Zolt?n Maj? > Sent: Thursday, December 08, 2016 1:55 PM > To: Rahul Raghavan; hotspot-compiler-dev at openjdk.java.net > Subject: Re: RFR: 8156762: compiler/ciReplay/TestVM_no_comp_level.java fails with - 'Unexpected exit code for negative case: [- > client]: expected 0 to not equal 0' > > Hi Rahul, > > > can you please move the else on line 71 to line 70 (to the same line > with the closing '}')? > > 68 if (SERVER_VM_AVAILABLE) { > 69 negativeTest(CLIENT_VM_OPTION); > 70 } > 71 else { > 72 positiveTest(CLIENT_VM_OPTION); > 73 } > > Otherwise it looks good to me. > > Thank you! > > Best regards, > > > Zoltan > > On 12/08/2016 09:10 AM, Rahul Raghavan wrote: > > Hi, > > > > Please review following patch for JDK-8156762. > > - http://cr.openjdk.java.net/~rraghavan/8156762/webrev.00/ > > > > - https://bugs.openjdk.java.net/browse/JDK-8156762 > > > > Please note that JDK-8156762 is an Oracle closed bug, > > reporting failure for hotspot/test/compiler/ciReplay/TestVM_no_comp_level.sh > > for build configuration with only Client VM. > > > > Understood the test scenario as > > - force JVM to generate test_replay.txt file > > - remove compilation level from test_replay.txt file > > - then check replay the modified test_replay.txt > > > > Above proposed test fix in webrev.00 - > > [test/compiler/ciReplay/TestVMNoCompLevel.java] > > .............. > > public void testAction() { > > ...... > > ...... > > if (CLIENT_VM_AVAILABLE) { > > - negativeTest(CLIENT_VM_OPTION); > > + if (SERVER_VM_AVAILABLE) { > > + negativeTest(CLIENT_VM_OPTION); > > + } > > + else { > > + positiveTest(CLIENT_VM_OPTION); > > + } > > } > > if (SERVER_VM_AVAILABLE) { > > positiveTest(TIERED_DISABLED_VM_OPTION, SERVER_VM_OPTION); > > positiveTest(TIERED_ENABLED_VM_OPTION, SERVER_VM_OPTION); > > } > > } > > .............. > > > > The test was written expecting VM to crash always in Client VM available case, > > when replay the modified test_replay.txt without compilation level. > > But found this is not true because a default compiler level of highest available level value is always used, if the same is missing, > > to support older version of Compiler replay without compiler level support. > > [process_compile() - hotspot\src\share\vm\ci\ciReplay.cpp] > > > > So for the reported case if ONLY CLIENT_VM_AVAILABLE is true - > > Originally in test, VM was expected to crash always here. > > Found this is wrong due to the setting of default compiler level > > to highest available level value in process_compile() - which is 'CompLevel_simple' in this case. > > So for ONLY CLIENT_VM_AVAILABLE case the VM will not crash at 'is_valid_comp_level()', > > going ahead with replaying the modified test_replay.txt with -client option. > > (.i.e. positiveTest(-client) is required) > > > > For the case with if both CLIENT_VM_AVAILABLE and SERVER_VM_AVAILABLE are true, > > when test_replay.txt without compilation level is used, > > the default compiler level assigned in process_compile() will be 'CompLevel_full_optimization'. > > So when attempted replay the modified test_replay.txt with -client option, > > the VM should fail for 'if (CLIENT_VM_AVAILABLE)' block at - > > if (!TieredCompilation && (comp_level != CompLevel_highest_tier)) check [is_valid_comp_level()] > > (.i.e. negativeTest(-client) is required) > > > > The further testing for SERVER_VM_AVAILABLE is not touched > > and any how will always continue with required tiered disable/enabled , -server options. > > > > No issues with testing for various targets. > > > > Thanks, > > Rahul > From zoltan.majo at oracle.com Mon Dec 12 08:11:33 2016 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Mon, 12 Dec 2016 09:11:33 +0100 Subject: RFR: 8156762: compiler/ciReplay/TestVM_no_comp_level.java fails with - 'Unexpected exit code for negative case: [-client]: expected 0 to not equal 0' In-Reply-To: References: <597494ba-cce4-4758-9517-09ceeca99de2@default> Message-ID: Hi Rahul, On 12/12/2016 08:04 AM, Rahul Raghavan wrote: > Hi, > > Thank you Zoltan for review comments. > Yes made the required change. > > - http://cr.openjdk.java.net/~rraghavan/8156762/webrev.01/ that looks good to me. Thank you! Best regards, Zoltan > > Thanks, > Rahul > >> -----Original Message----- >> From: Zolt?n Maj? >> Sent: Thursday, December 08, 2016 1:55 PM >> To: Rahul Raghavan; hotspot-compiler-dev at openjdk.java.net >> Subject: Re: RFR: 8156762: compiler/ciReplay/TestVM_no_comp_level.java fails with - 'Unexpected exit code for negative case: [- >> client]: expected 0 to not equal 0' >> >> Hi Rahul, >> >> >> can you please move the else on line 71 to line 70 (to the same line >> with the closing '}')? >> >> 68 if (SERVER_VM_AVAILABLE) { >> 69 negativeTest(CLIENT_VM_OPTION); >> 70 } >> 71 else { >> 72 positiveTest(CLIENT_VM_OPTION); >> 73 } >> >> Otherwise it looks good to me. >> >> Thank you! >> >> Best regards, >> >> >> Zoltan >> >> On 12/08/2016 09:10 AM, Rahul Raghavan wrote: >>> Hi, >>> >>> Please review following patch for JDK-8156762. >>> - http://cr.openjdk.java.net/~rraghavan/8156762/webrev.00/ >>> >>> - https://bugs.openjdk.java.net/browse/JDK-8156762 >>> >>> Please note that JDK-8156762 is an Oracle closed bug, >>> reporting failure for hotspot/test/compiler/ciReplay/TestVM_no_comp_level.sh >>> for build configuration with only Client VM. >>> >>> Understood the test scenario as >>> - force JVM to generate test_replay.txt file >>> - remove compilation level from test_replay.txt file >>> - then check replay the modified test_replay.txt >>> >>> Above proposed test fix in webrev.00 - >>> [test/compiler/ciReplay/TestVMNoCompLevel.java] >>> .............. >>> public void testAction() { >>> ...... >>> ...... >>> if (CLIENT_VM_AVAILABLE) { >>> - negativeTest(CLIENT_VM_OPTION); >>> + if (SERVER_VM_AVAILABLE) { >>> + negativeTest(CLIENT_VM_OPTION); >>> + } >>> + else { >>> + positiveTest(CLIENT_VM_OPTION); >>> + } >>> } >>> if (SERVER_VM_AVAILABLE) { >>> positiveTest(TIERED_DISABLED_VM_OPTION, SERVER_VM_OPTION); >>> positiveTest(TIERED_ENABLED_VM_OPTION, SERVER_VM_OPTION); >>> } >>> } >>> .............. >>> >>> The test was written expecting VM to crash always in Client VM available case, >>> when replay the modified test_replay.txt without compilation level. >>> But found this is not true because a default compiler level of highest available level value is always used, if the same is missing, >>> to support older version of Compiler replay without compiler level support. >>> [process_compile() - hotspot\src\share\vm\ci\ciReplay.cpp] >>> >>> So for the reported case if ONLY CLIENT_VM_AVAILABLE is true - >>> Originally in test, VM was expected to crash always here. >>> Found this is wrong due to the setting of default compiler level >>> to highest available level value in process_compile() - which is 'CompLevel_simple' in this case. >>> So for ONLY CLIENT_VM_AVAILABLE case the VM will not crash at 'is_valid_comp_level()', >>> going ahead with replaying the modified test_replay.txt with -client option. >>> (.i.e. positiveTest(-client) is required) >>> >>> For the case with if both CLIENT_VM_AVAILABLE and SERVER_VM_AVAILABLE are true, >>> when test_replay.txt without compilation level is used, >>> the default compiler level assigned in process_compile() will be 'CompLevel_full_optimization'. >>> So when attempted replay the modified test_replay.txt with -client option, >>> the VM should fail for 'if (CLIENT_VM_AVAILABLE)' block at - >>> if (!TieredCompilation && (comp_level != CompLevel_highest_tier)) check [is_valid_comp_level()] >>> (.i.e. negativeTest(-client) is required) >>> >>> The further testing for SERVER_VM_AVAILABLE is not touched >>> and any how will always continue with required tiered disable/enabled , -server options. >>> >>> No issues with testing for various targets. >>> >>> Thanks, >>> Rahul From goetz.lindenmaier at sap.com Mon Dec 12 11:53:52 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 12 Dec 2016 11:53:52 +0000 Subject: RFR(M): 8170991: PPC64: Bad code for initialization of short arrays In-Reply-To: References: Message-ID: <9ae526c6aa204060905bf247fc2aa783@DEROTE13DE08.global.corp.sap> Hi Martin, I had a look at your change. I like you cleaned up the C1 implementation, moving the various cases to the macro assembler and reusing it. I'm also fine with matching for constant array sizes. I'm not sure whether reducing InitArrayShortSize helps. It sure removes the simple-to-spot pattern of loading 0 too often into registers. This only happened if register allocation ran out of registers and rematerialized. And as we saw, where the 0 was rematerialized, the register pressure was not that high, sufficient registers to hold 0 were available :). This is just an artefact of register allocation. I would assume the processor internally handles this efficiently. Loading 0 into a register should be one of the cheapest operations altogether! If you only look at the places where rematerialization happened, you miss other benefits in the places where there is no rematerialization necessary. So you optimize for the few cases with rematerialization, paying the cost in the many places without rematerialization. E.g., if 0 is used in some other places in the same code, it's there anyways. So I'm not sure it helps with performance, but if you don't spot regressions I'm fine with the change to InitArrayShortSize, too. Best regards, Goetz. > -----Original Message----- > From: hotspot-compiler-dev [mailto:hotspot-compiler-dev- > bounces at openjdk.java.net] On Behalf Of Doerr, Martin > Sent: Freitag, 9. Dezember 2016 18:01 > To: 'hotspot-compiler-dev at openjdk.java.net' dev at openjdk.java.net>; Gustavo Serra Scalet > > Subject: RFR(M): 8170991: PPC64: Bad code for initialization of short arrays > > Hello everybody, > > > > the new flag "InitArrayShortSize" was set to 8 on PPC64. However, this leads to > bad code. PPC64's C2 compiler currently does not have dedicated match rules > to store 0. > > Unfortunately, loading of the constant 0 got rematerialized many times in some > cases consuming more registers and code space than needed. > > > > An attempt to improve initialization was > > 8170094: PPC64: Keep immediate value 0 cached into a register to improve > performance > > but this approach has disadvantages and we had decided against it. > > > > It is possibly to implement special ClearArray nodes to improve the > initialization of arrays only: > > http://cr.openjdk.java.net/~mdoerr/8170991_PPC64_ClearArray/webrev.00/ > > > > Please review. > > > > @Gustavo: Maybe this improves your test cases, too? > > > > Best regards, > > Martin > > From dmitrij.pochepko at oracle.com Mon Dec 12 12:39:58 2016 From: dmitrij.pochepko at oracle.com (Dmitrij Pochepko) Date: Mon, 12 Dec 2016 15:39:58 +0300 Subject: RFR: 8156762: compiler/ciReplay/TestVM_no_comp_level.java fails with - 'Unexpected exit code for negative case: [-client]: expected 0 to not equal 0' In-Reply-To: References: <597494ba-cce4-4758-9517-09ceeca99de2@default> Message-ID: <82516341-a1fa-34ac-da23-205c59c91368@oracle.com> Looks good to me(not a reviewer) On 12.12.2016 10:04, Rahul Raghavan wrote: > Hi, > > Thank you Zoltan for review comments. > Yes made the required change. > > - http://cr.openjdk.java.net/~rraghavan/8156762/webrev.01/ > > Thanks, > Rahul > >> -----Original Message----- >> From: Zolt?n Maj? >> Sent: Thursday, December 08, 2016 1:55 PM >> To: Rahul Raghavan; hotspot-compiler-dev at openjdk.java.net >> Subject: Re: RFR: 8156762: compiler/ciReplay/TestVM_no_comp_level.java fails with - 'Unexpected exit code for negative case: [- >> client]: expected 0 to not equal 0' >> >> Hi Rahul, >> >> >> can you please move the else on line 71 to line 70 (to the same line >> with the closing '}')? >> >> 68 if (SERVER_VM_AVAILABLE) { >> 69 negativeTest(CLIENT_VM_OPTION); >> 70 } >> 71 else { >> 72 positiveTest(CLIENT_VM_OPTION); >> 73 } >> >> Otherwise it looks good to me. >> >> Thank you! >> >> Best regards, >> >> >> Zoltan >> >> On 12/08/2016 09:10 AM, Rahul Raghavan wrote: >>> Hi, >>> >>> Please review following patch for JDK-8156762. >>> - http://cr.openjdk.java.net/~rraghavan/8156762/webrev.00/ >>> >>> - https://bugs.openjdk.java.net/browse/JDK-8156762 >>> >>> Please note that JDK-8156762 is an Oracle closed bug, >>> reporting failure for hotspot/test/compiler/ciReplay/TestVM_no_comp_level.sh >>> for build configuration with only Client VM. >>> >>> Understood the test scenario as >>> - force JVM to generate test_replay.txt file >>> - remove compilation level from test_replay.txt file >>> - then check replay the modified test_replay.txt >>> >>> Above proposed test fix in webrev.00 - >>> [test/compiler/ciReplay/TestVMNoCompLevel.java] >>> .............. >>> public void testAction() { >>> ...... >>> ...... >>> if (CLIENT_VM_AVAILABLE) { >>> - negativeTest(CLIENT_VM_OPTION); >>> + if (SERVER_VM_AVAILABLE) { >>> + negativeTest(CLIENT_VM_OPTION); >>> + } >>> + else { >>> + positiveTest(CLIENT_VM_OPTION); >>> + } >>> } >>> if (SERVER_VM_AVAILABLE) { >>> positiveTest(TIERED_DISABLED_VM_OPTION, SERVER_VM_OPTION); >>> positiveTest(TIERED_ENABLED_VM_OPTION, SERVER_VM_OPTION); >>> } >>> } >>> .............. >>> >>> The test was written expecting VM to crash always in Client VM available case, >>> when replay the modified test_replay.txt without compilation level. >>> But found this is not true because a default compiler level of highest available level value is always used, if the same is missing, >>> to support older version of Compiler replay without compiler level support. >>> [process_compile() - hotspot\src\share\vm\ci\ciReplay.cpp] >>> >>> So for the reported case if ONLY CLIENT_VM_AVAILABLE is true - >>> Originally in test, VM was expected to crash always here. >>> Found this is wrong due to the setting of default compiler level >>> to highest available level value in process_compile() - which is 'CompLevel_simple' in this case. >>> So for ONLY CLIENT_VM_AVAILABLE case the VM will not crash at 'is_valid_comp_level()', >>> going ahead with replaying the modified test_replay.txt with -client option. >>> (.i.e. positiveTest(-client) is required) >>> >>> For the case with if both CLIENT_VM_AVAILABLE and SERVER_VM_AVAILABLE are true, >>> when test_replay.txt without compilation level is used, >>> the default compiler level assigned in process_compile() will be 'CompLevel_full_optimization'. >>> So when attempted replay the modified test_replay.txt with -client option, >>> the VM should fail for 'if (CLIENT_VM_AVAILABLE)' block at - >>> if (!TieredCompilation && (comp_level != CompLevel_highest_tier)) check [is_valid_comp_level()] >>> (.i.e. negativeTest(-client) is required) >>> >>> The further testing for SERVER_VM_AVAILABLE is not touched >>> and any how will always continue with required tiered disable/enabled , -server options. >>> >>> No issues with testing for various targets. >>> >>> Thanks, >>> Rahul From rwestrel at redhat.com Mon Dec 12 14:32:03 2016 From: rwestrel at redhat.com (Roland Westrelin) Date: Mon, 12 Dec 2016 15:32:03 +0100 Subject: RFR(XS): 8171092: C1's Math.fma() intrinsic doesn't correctly process its inputs Message-ID: http://cr.openjdk.java.net/~roland/8171092/webrev.00/ 3rd input of the fma intrinsic is processed as a temp but is actually an input. The test case triggers the problem on aarch64 (with the patch from 8162338). I couldn't get a failure on x86 because the input is overwritten by the fma instruction: a copy of the input is made to a new register right before the fma instruction and the input is live until right before the fma instruction. I'm far from certain the bug cannot show up on x86 with some other code pattern. Roland. From rwestrel at redhat.com Mon Dec 12 14:40:08 2016 From: rwestrel at redhat.com (Roland Westrelin) Date: Mon, 12 Dec 2016 15:40:08 +0100 Subject: RFR(S): 8162338: AArch64: Intrinsify fused mac operations In-Reply-To: <7466bbbc-3de1-0a64-aa56-d24a5067ac86@oracle.com> References: <326e7e90-ba04-9b94-6f85-8d8d292e36ad@oracle.com> <7466bbbc-3de1-0a64-aa56-d24a5067ac86@oracle.com> Message-ID: > File separate bug for this we can fix it any time until ZBB in Feb. > Include test into it too. It's 8171092. It's out for review. Here is the updated webrev without the bug fix for the fma aarch64 support: http://cr.openjdk.java.net/~roland/8162338/webrev.01/ Roland. From dmitrij.pochepko at oracle.com Mon Dec 12 15:21:50 2016 From: dmitrij.pochepko at oracle.com (Dmitrij Pochepko) Date: Mon, 12 Dec 2016 18:21:50 +0300 Subject: RFR(S): 8171060 - [AOT] aot tests: WARNING: Requested compilation levels are out of current vm capabilities. Message-ID: <516c715a-ea07-1799-62ce-a83f957d627e@oracle.com> Hi, please review small fix for 8171060 - [AOT] aot tests: WARNING: Requested compilation levels are out of current vm capabilities. Few aot tests had a warning about requested compilation levels. I've modified respective check in CallsBase.java. Also tests options were modified(added -Xbatch since test logic assumes it and removed -checkCallerCompileLevel -1, which is wrong because of aot method deoptimization). webrev: http://cr.openjdk.java.net/~dpochepk/8171060/webrev.01/ CR: https://bugs.openjdk.java.net/browse/JDK-8171060 I've verified this fix on linux-x64. Thanks, Dmitrij From dmitrij.pochepko at oracle.com Mon Dec 12 15:34:43 2016 From: dmitrij.pochepko at oracle.com (Dmitrij Pochepko) Date: Mon, 12 Dec 2016 18:34:43 +0300 Subject: RFR(S): 8171059 - [AOT] error in AotCompiler output in some aot tests Message-ID: <211850e7-28c9-a850-9ca7-520e8732316e@oracle.com> Hi, please review small fix for 8171059 - [AOT] error in AotCompiler output in some aot tests AotCompilation produced error messages in test log because of missing whitebox-related options. This fix adds such options. webrev: http://cr.openjdk.java.net/~dpochepk/8171059/webrev.01/ CR: https://bugs.openjdk.java.net/browse/JDK-8171059 I've verified this fix on linux-x64 Thanks, Dmitrij From gustavo.scalet at eldorado.org.br Mon Dec 12 16:50:20 2016 From: gustavo.scalet at eldorado.org.br (Gustavo Serra Scalet) Date: Mon, 12 Dec 2016 16:50:20 +0000 Subject: RFR(M): 8170991: PPC64: Bad code for initialization of short arrays In-Reply-To: References: Message-ID: Hello Martin, I checked the changes and I actually noticed that there were slightly more loading zeroes to a register followed by a store (of that zero) than without your patch. That doesn't say much about performance, but I would say that, on that point of view, it didn't make the code smarter. In short, it didn't help the issue I was looking at. Thanks for cc'ing me so I could take a closer look. > -----Original Message----- > From: Doerr, Martin [mailto:martin.doerr at sap.com] > Sent: sexta-feira, 9 de dezembro de 2016 15:01 > To: 'hotspot-compiler-dev at openjdk.java.net' dev at openjdk.java.net>; Gustavo Serra Scalet > > Subject: RFR(M): 8170991: PPC64: Bad code for initialization of short > arrays > > Hello everybody, > > > > the new flag "InitArrayShortSize" was set to 8 on PPC64. However, this > leads to bad code. PPC64's C2 compiler currently does not have dedicated > match rules to store 0. > > Unfortunately, loading of the constant 0 got rematerialized many times > in some cases consuming more registers and code space than needed. > > > > An attempt to improve initialization was > > 8170094: PPC64: Keep immediate value 0 cached into a register to improve > performance > > but this approach has disadvantages and we had decided against it. > > > > It is possibly to implement special ClearArray nodes to improve the > initialization of arrays only: > > http://cr.openjdk.java.net/~mdoerr/8170991_PPC64_ClearArray/webrev.00/ > > > > Please review. > > > > @Gustavo: Maybe this improves your test cases, too? > > > > Best regards, > > Martin > > From aph at redhat.com Mon Dec 12 16:59:06 2016 From: aph at redhat.com (Andrew Haley) Date: Mon, 12 Dec 2016 16:59:06 +0000 Subject: RFR(S): 8162338: AArch64: Intrinsify fused mac operations In-Reply-To: References: <326e7e90-ba04-9b94-6f85-8d8d292e36ad@oracle.com> <7466bbbc-3de1-0a64-aa56-d24a5067ac86@oracle.com> Message-ID: On 12/12/16 14:40, Roland Westrelin wrote: > Here is the updated webrev without the bug fix for the fma aarch64 > support: > > http://cr.openjdk.java.net/~roland/8162338/webrev.01/ OK, thanks. Andrew. From vladimir.kozlov at oracle.com Mon Dec 12 17:23:12 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 12 Dec 2016 09:23:12 -0800 Subject: RFR(XS): 8171092: C1's Math.fma() intrinsic doesn't correctly process its inputs In-Reply-To: References: Message-ID: <9125d709-9926-9884-0808-91e2ae900115@oracle.com> Looks good. When jdk9/hs is open for pushes I will sponsor it. Thanks, Vladimir On 12/12/16 6:32 AM, Roland Westrelin wrote: > > http://cr.openjdk.java.net/~roland/8171092/webrev.00/ > > 3rd input of the fma intrinsic is processed as a temp but is actually an > input. The test case triggers the problem on aarch64 (with the patch > from 8162338). I couldn't get a failure on x86 because the input is > overwritten by the fma instruction: a copy of the input is made to a new > register right before the fma instruction and the input is live until > right before the fma instruction. I'm far from certain the bug cannot > show up on x86 with some other code pattern. > > Roland. > From vladimir.kozlov at oracle.com Mon Dec 12 17:29:35 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 12 Dec 2016 09:29:35 -0800 Subject: RFR(S): 8162338: AArch64: Intrinsify fused mac operations In-Reply-To: References: <326e7e90-ba04-9b94-6f85-8d8d292e36ad@oracle.com> <7466bbbc-3de1-0a64-aa56-d24a5067ac86@oracle.com> Message-ID: <72ebde65-c0b3-9ec7-3f68-71044f29ef4f@oracle.com> Good. Let me push since we need to run test on all platforms. Thanks, Vladimir On 12/12/16 6:40 AM, Roland Westrelin wrote: > >> File separate bug for this we can fix it any time until ZBB in Feb. >> Include test into it too. > > It's 8171092. It's out for review. > > Here is the updated webrev without the bug fix for the fma aarch64 > support: > > http://cr.openjdk.java.net/~roland/8162338/webrev.01/ > > Roland. > From vladimir.kozlov at oracle.com Mon Dec 12 17:38:07 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 12 Dec 2016 09:38:07 -0800 Subject: RFR(S): 8171060 - [AOT] aot tests: WARNING: Requested compilation levels are out of current vm capabilities. In-Reply-To: <516c715a-ea07-1799-62ce-a83f957d627e@oracle.com> References: <516c715a-ea07-1799-62ce-a83f957d627e@oracle.com> Message-ID: Thank you, Dmitrij In AotInvokeDynamic2CompiledTest.java "compiler.calls.common.InvokeDynamic" was removed from command line. By accident? Otherwise looks good. Thanks, Vladimir On 12/12/16 7:21 AM, Dmitrij Pochepko wrote: > Hi, > > > please review small fix for 8171060 - [AOT] aot tests: WARNING: > Requested compilation levels are out of current vm capabilities. > > Few aot tests had a warning about requested compilation levels. I've > modified respective check in CallsBase.java. > > Also tests options were modified(added -Xbatch since test logic assumes > it and removed -checkCallerCompileLevel -1, which is wrong because of > aot method deoptimization). > > > webrev: http://cr.openjdk.java.net/~dpochepk/8171060/webrev.01/ > > CR: https://bugs.openjdk.java.net/browse/JDK-8171060 > > I've verified this fix on linux-x64. > > Thanks, > > Dmitrij > From vladimir.kozlov at oracle.com Mon Dec 12 17:38:56 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 12 Dec 2016 09:38:56 -0800 Subject: RFR(S): 8171059 - [AOT] error in AotCompiler output in some aot tests In-Reply-To: <211850e7-28c9-a850-9ca7-520e8732316e@oracle.com> References: <211850e7-28c9-a850-9ca7-520e8732316e@oracle.com> Message-ID: <2ea127ed-0cca-10fd-7ee3-1ab0c2baacea@oracle.com> Very good. Thanks, Vladimir On 12/12/16 7:34 AM, Dmitrij Pochepko wrote: > Hi, > > please review small fix for 8171059 - [AOT] error in AotCompiler output > in some aot tests > > AotCompilation produced error messages in test log because of missing > whitebox-related options. > > This fix adds such options. > > webrev: http://cr.openjdk.java.net/~dpochepk/8171059/webrev.01/ > > CR: https://bugs.openjdk.java.net/browse/JDK-8171059 > > I've verified this fix on linux-x64 > > Thanks, > > Dmitrij > From dmitrij.pochepko at oracle.com Mon Dec 12 17:47:52 2016 From: dmitrij.pochepko at oracle.com (Dmitrij Pochepko) Date: Mon, 12 Dec 2016 09:47:52 -0800 (PST) Subject: RFR(S): 8171060 - [AOT] aot tests: WARNING: Requested compilation levels are out of current vm capabilities. Message-ID: <9e7b49be-26f7-494a-b4ea-693a9c2a967b@default> Yes. It's an accident. Thank you for noticing it! ----- Original Message ----- From: vladimir.kozlov at oracle.com To: hotspot-compiler-dev at openjdk.java.net Sent: Monday, December 12, 2016 8:38:48 PM GMT +03:00 Iraq Subject: Re: RFR(S): 8171060 - [AOT] aot tests: WARNING: Requested compilation levels are out of current vm capabilities. Thank you, Dmitrij In AotInvokeDynamic2CompiledTest.java "compiler.calls.common.InvokeDynamic" was removed from command line. By accident? Otherwise looks good. Thanks, Vladimir On 12/12/16 7:21 AM, Dmitrij Pochepko wrote: > Hi, > > > please review small fix for 8171060 - [AOT] aot tests: WARNING: > Requested compilation levels are out of current vm capabilities. > > Few aot tests had a warning about requested compilation levels. I've > modified respective check in CallsBase.java. > > Also tests options were modified(added -Xbatch since test logic assumes > it and removed -checkCallerCompileLevel -1, which is wrong because of > aot method deoptimization). > > > webrev: http://cr.openjdk.java.net/~dpochepk/8171060/webrev.01/ > > CR: https://bugs.openjdk.java.net/browse/JDK-8171060 > > I've verified this fix on linux-x64. > > Thanks, > > Dmitrij > From dmitrij.pochepko at oracle.com Mon Dec 12 17:48:19 2016 From: dmitrij.pochepko at oracle.com (Dmitrij Pochepko) Date: Mon, 12 Dec 2016 09:48:19 -0800 (PST) Subject: RFR(S): 8171059 - [AOT] error in AotCompiler output in some aot tests Message-ID: <8ee82393-b86f-4f19-a810-27af34cb5d0d@default> Thank you! ----- Original Message ----- From: vladimir.kozlov at oracle.com To: hotspot-compiler-dev at openjdk.java.net Sent: Monday, December 12, 2016 8:39:29 PM GMT +03:00 Iraq Subject: Re: RFR(S): 8171059 - [AOT] error in AotCompiler output in some aot tests Very good. Thanks, Vladimir On 12/12/16 7:34 AM, Dmitrij Pochepko wrote: > Hi, > > please review small fix for 8171059 - [AOT] error in AotCompiler output > in some aot tests > > AotCompilation produced error messages in test log because of missing > whitebox-related options. > > This fix adds such options. > > webrev: http://cr.openjdk.java.net/~dpochepk/8171059/webrev.01/ > > CR: https://bugs.openjdk.java.net/browse/JDK-8171059 > > I've verified this fix on linux-x64 > > Thanks, > > Dmitrij > From vitalyd at gmail.com Mon Dec 12 18:05:20 2016 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Mon, 12 Dec 2016 13:05:20 -0500 Subject: 8u102 NMethod sweeper related Hotspot crashes In-Reply-To: <345cf4cf-9b50-1911-da34-a77e6f7890a0@oracle.com> References: <4a46f7da-10af-db7b-9e4c-eca4c0508979@oracle.com> <345cf4cf-9b50-1911-da34-a77e6f7890a0@oracle.com> Message-ID: Hi Vladimir, There are now multiple crash reports around this code path, but all with a slightly different assertion error. Is one JBS entry with all the seen flavors sufficient or does each one need to be separate? Unfortunately, turning off tiered compilation causes a segfault although I'm trying to get the full crash report to see if it's in the same code (path) or something else entirely. Thanks On Wed, Dec 7, 2016 at 1:20 PM, Vladimir Kozlov wrote: > All crashes have to have JBS entry. Please, file bug. > > JDK-8139595 is not related unfortunately. It fixed code present only in > JDK 9. > > Thanks, > Vladimir > > On 12/7/16 10:13 AM, Vitaly Davidovich wrote: > >> Vladimir, >> >> What do you think the next step should be? Is a JBS bug entry warranted? >> >> Thanks >> >> On Tue, Dec 6, 2016 at 1:12 PM Vitaly Davidovich > > wrote: >> >> Hi Vladimir, >> >> On Tue, Dec 6, 2016 at 12:57 PM, Vladimir Kozlov >> > >> wrote: >> >> Could be https://bugs.openjdk.java.net/browse/JDK-8139595 (not >> backported to 8u). >> >> I can't find anything else with remove_dependent_nmethod() on >> call stack in JBS. >> >> It does seem like it could be related, but yeah, it's unclear. >> Hoping someone else here may have an idea. >> >> Thanks >> >> >> Vladimir >> >> On 12/6/16 9:33 AM, Vitaly Davidovich wrote: >> >> Btw, for now I've advised the group hitting these to turn >> off tiered >> compilation to reduce code cache pressure and thus hopefully >> avoid >> whatever bug(s) is lurking here. >> >> I should've also mentioned that this doesn't happen all the >> time, of >> course, so there's no reliable repro. >> >> On Tue, Dec 6, 2016 at 12:02 PM Vitaly Davidovich >> >> >> wrote: >> >> Hi guys, >> >> I have a couple of Hotspot crashes to report - both >> occur in nmethod >> sweeping/flushing. I'm going to strip down the hs_err >> content, but >> let me know if there's something else you need from >> there. Are >> these known? A quick google suggests there are some bugs >> around >> nmethod sweeping, but I couldn't find anything exactly >> like this. >> >> Let me know if you need more info. >> >> Thanks >> >> *The first is:* >> >> >> # >> # A fatal error has been detected by the Java Runtime >> Environment: >> # >> # Internal Error (instanceKlass.cpp:1995), pid=15444, >> tid=0x00002b1fd0186700 >> # guarantee(val >= 0) failed: Underflow: -1 >> # >> # JRE version: Java(TM) SE Runtime Environment >> (8.0_102-b14) (build >> 1.8.0_102-b14) >> # Java VM: Java HotSpot(TM) 64-Bit Server VM (25.102-b14 >> mixed mode >> linux-amd64 ) >> # >> # If you would like to submit a bug report, please visit: >> # http://bugreport.java.com/bugreport/crash.jsp >> # >> >> --------------- T H R E A D --------------- >> >> Current thread (0x00002b1f58056800): JavaThread "C2 >> CompilerThread2" daemon [_thread_in_vm, id=15533, >> stack(0x00002b1fd0086000,0x00002b1fd0187000)] >> >> Stack: [0x00002b1fd0086000,0x00002b1fd0187000], >> sp=0x00002b1fd0185580, free space=1021k >> Native frames: (J=compiled Java code, j=interpreted, >> Vv=VM code, >> C=native code) >> V [libjvm.so+0xac52aa] VMError::report_and_die()+0x2ba >> V [libjvm.so+0x4fba22] report_vm_error(char const*, >> int, char >> const*, char const*)+0x62 >> V [libjvm.so+0x63e9b0] >> InstanceKlass::remove_dependent_nmethod(nmethod*, >> bool)+0x110 >> V [libjvm.so+0x8e61b3] >> nmethod::flush_dependencies(BoolObjectClosure*)+0x93 >> V [libjvm.so+0x8ebd5b] >> nmethod::make_not_entrant_or_zombie(unsigned int)+0x48b >> V [libjvm.so+0xa2b0cd] >> NMethodSweeper::process_nmethod(nmethod*)+0x27d >> V [libjvm.so+0xa2b468] >> NMethodSweeper::sweep_code_cache()+0x328 >> V [libjvm.so+0xa2b7d4] >> NMethodSweeper::possibly_sweep()+0xb4 >> V [libjvm.so+0x4ae105] CompileQueue::get()+0x15 >> V [libjvm.so+0x4b047b] >> CompileBroker::compiler_thread_loop()+0x18b >> V [libjvm.so+0xa73ce3] >> JavaThread::thread_main_inner()+0x103 >> V [libjvm.so+0xa73e2c] JavaThread::run()+0x11c >> V [libjvm.so+0x9249c8] java_start(Thread*)+0x108 >> C [libpthread.so.0+0x6b50] start_thread+0xd0 >> >> =>0x00002b1f58056800 JavaThread "C2 CompilerThread2" >> daemon >> [_thread_in_vm, id=15533, >> stack(0x00002b1fd0086000,0x00002b1fd0187000)] >> >> VM state:not at safepoint (normal execution) >> VM Mutex/Monitor currently owned by a thread: >> ([mutex/lock_event]) >> [0x0000000001ac5f40] CodeCache_lock - owner thread: >> 0x00002b1f58056800 >> [0x0000000001ac7240] CompiledIC_lock - owner thread: >> 0x00002b1f58056800 >> >> Heap: >> PSYoungGen total 16531968K, used 13673471K >> [0x00002b1b0b200000, 0x00002b1f49900000, >> 0x00002b1f4b200000) >> eden space 15297024K, 83% used >> [0x00002b1b0b200000,0x00002b1e >> 19277f68,0x00002b1eb0c80000) >> from space 1234944K, 69% used >> [0x00002b1eb0c80000,0x00002b1e >> e5507eb0,0x00002b1efc280000) >> to space 1198080K, 0% used >> [0x00002b1f00700000,0x00002b1f >> 00700000,0x00002b1f49900000) >> ParOldGen total 34891264K, used 26246257K >> [0x00002b128b200000, 0x00002b1adcb80000, >> 0x00002b1b0b200000) >> object space 34891264K, 75% used >> [0x00002b128b200000,0x00002b18 >> cd11c630,0x00002b1adcb80000) >> Metaspace used 211158K, capacity 610281K, >> committed 610528K, >> reserved 612352K >> >> Polling page: 0x00002b1281166000 >> >> CodeCache: size=102400Kb used=71326Kb max_used=81914Kb >> free=31073Kb >> bounds [0x00002b1284ab2000, 0x00002b128aeb2000, >> 0x00002b128aeb2000] >> total_blobs=13619 nmethods=12436 adapters=1089 >> compilation: enabled >> >> *Here's the second:* >> >> # >> # A fatal error has been detected by the Java Runtime >> Environment: >> # >> # Internal Error (instanceKlass.cpp:2018), pid=83979, >> tid=0x00002bb97feba700 >> # Error: ShouldNotReachHere() >> # >> # JRE version: Java(TM) SE Runtime Environment >> (8.0_102-b14) (build >> 1.8.0_102-b14) >> # Java VM: Java HotSpot(TM) 64-Bit Server VM (25.102-b14 >> mixed mode >> linux-amd64 ) >> # >> # If you would like to submit a bug report, please visit: >> # http://bugreport.java.com/bugreport/crash.jsp >> # >> >> --------------- T H R E A D --------------- >> >> Current thread (0x00002bb8f40cf800): JavaThread "C2 >> CompilerThread6" daemon [_thread_in_vm, id=84042, >> stack(0x00002bb97fdba000,0x00002bb97febb000)] >> >> Stack: [0x00002bb97fdba000,0x00002bb97febb000], >> sp=0x00002bb97feb9710, free space=1021k >> Native frames: (J=compiled Java code, j=interpreted, >> Vv=VM code, >> C=native code) >> V [libjvm.so+0xac52aa] VMError::report_and_die()+0x2ba >> V [libjvm.so+0x4fbd92] >> report_should_not_reach_here(char const*, >> int)+0x52 >> V [libjvm.so+0x63e8fb] >> InstanceKlass::remove_dependent_nmethod(nmethod*, >> bool)+0x5b >> V [libjvm.so+0x8e61b3] >> nmethod::flush_dependencies(BoolObjectClosure*)+0x93 >> V [libjvm.so+0x8ebd5b] >> nmethod::make_not_entrant_or_zombie(unsigned int)+0x48b >> V [libjvm.so+0xa2b0cd] >> NMethodSweeper::process_nmethod(nmethod*)+0x27d >> V [libjvm.so+0xa2b468] >> NMethodSweeper::sweep_code_cache()+0x328 >> V [libjvm.so+0xa2b7d4] >> NMethodSweeper::possibly_sweep()+0xb4 >> V [libjvm.so+0x4ae105] CompileQueue::get()+0x15 >> V [libjvm.so+0x4b047b] >> CompileBroker::compiler_thread_loop()+0x18b >> V [libjvm.so+0xa73ce3] >> JavaThread::thread_main_inner()+0x103 >> V [libjvm.so+0xa73e2c] JavaThread::run()+0x11c >> V [libjvm.so+0x9249c8] java_start(Thread*)+0x108 >> C [libpthread.so.0+0x6b50] start_thread+0xd0 >> >> =>0x00002bb8f40cf800 JavaThread "C2 CompilerThread6" >> daemon >> [_thread_in_vm, id=84042, >> stack(0x00002bb97fdba000,0x00002bb97febb000)] >> VM state:not at safepoint (normal execution) >> >> VM Mutex/Monitor currently owned by a thread: >> ([mutex/lock_event]) >> [0x0000000001858f40] CodeCache_lock - owner thread: >> 0x00002bb8f40cf800 >> [0x000000000185a240] CompiledIC_lock - owner thread: >> 0x00002bb8f40cf800 >> >> Heap: >> PSYoungGen total 18567168K, used 3149269K >> [0x00002bb3cdf00000, 0x00002bb8e3400000, 0x00002bb8e3400000) >> eden space 15838208K, 5% used >> [0x00002bb3cdf00000,0x00002bb402b26e00,0x00002bb794a00000) >> from space 2728960K, 83% used >> [0x00002bb83ab00000,0x00002bb8c624e6b0,0x00002bb8e1400000) >> to space 2720768K, 0% used >> [0x00002bb794a00000,0x00002bb794a00000,0x00002bb83ab00000) >> ParOldGen total 23083520K, used 21102913K >> [0x00002ba9a3400000, 0x00002baf24280000, 0x00002bb3cdf00000) >> object space 23083520K, 91% used >> [0x00002ba9a3400000,0x00002baeab450478,0x00002baf24280000) >> Metaspace used 167926K, capacity 377784K, >> committed 377856K, reserved 378880K >> >> >> >> Polling page: 0x00002ba999461000 >> >> CodeCache: size=102400Kb used=72829Kb max_used=81642Kb >> free=29570Kb >> bounds [0x00002ba99cdad000, 0x00002ba9a31ad000, >> 0x00002ba9a31ad000] >> total_blobs=14843 nmethods=13668 adapters=1082 >> compilation: enabled >> >> -- >> Sent from my phone >> >> -- >> Sent from my phone >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladimir.kozlov at oracle.com Mon Dec 12 18:10:00 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 12 Dec 2016 10:10:00 -0800 Subject: 8u102 NMethod sweeper related Hotspot crashes In-Reply-To: References: <4a46f7da-10af-db7b-9e4c-eca4c0508979@oracle.com> <345cf4cf-9b50-1911-da34-a77e6f7890a0@oracle.com> Message-ID: If all in the same path (calls from NMethodSweeper::process_nmethod()) then one JBS entry is enough. Vladimir On 12/12/16 10:05 AM, Vitaly Davidovich wrote: > Hi Vladimir, > > There are now multiple crash reports around this code path, but all with > a slightly different assertion error. Is one JBS entry with all the > seen flavors sufficient or does each one need to be separate? > Unfortunately, turning off tiered compilation causes a segfault although > I'm trying to get the full crash report to see if it's in the same code > (path) or something else entirely. > > Thanks > > On Wed, Dec 7, 2016 at 1:20 PM, Vladimir Kozlov > > wrote: > > All crashes have to have JBS entry. Please, file bug. > > JDK-8139595 is not related unfortunately. It fixed code present only > in JDK 9. > > Thanks, > Vladimir > > On 12/7/16 10:13 AM, Vitaly Davidovich wrote: > > Vladimir, > > What do you think the next step should be? Is a JBS bug entry > warranted? > > Thanks > > On Tue, Dec 6, 2016 at 1:12 PM Vitaly Davidovich > > >> wrote: > > Hi Vladimir, > > On Tue, Dec 6, 2016 at 12:57 PM, Vladimir Kozlov > > >> wrote: > > Could be > https://bugs.openjdk.java.net/browse/JDK-8139595 > (not > backported to 8u). > > I can't find anything else with > remove_dependent_nmethod() on > call stack in JBS. > > It does seem like it could be related, but yeah, it's unclear. > Hoping someone else here may have an idea. > > Thanks > > > Vladimir > > On 12/6/16 9:33 AM, Vitaly Davidovich wrote: > > Btw, for now I've advised the group hitting these to > turn > off tiered > compilation to reduce code cache pressure and thus > hopefully > avoid > whatever bug(s) is lurking here. > > I should've also mentioned that this doesn't happen > all the > time, of > course, so there's no reliable repro. > > On Tue, Dec 6, 2016 at 12:02 PM Vitaly Davidovich > > > > > >>> wrote: > > Hi guys, > > I have a couple of Hotspot crashes to report - both > occur in nmethod > sweeping/flushing. I'm going to strip down the > hs_err > content, but > let me know if there's something else you need from > there. Are > these known? A quick google suggests there are > some bugs > around > nmethod sweeping, but I couldn't find anything > exactly > like this. > > Let me know if you need more info. > > Thanks > > *The first is:* > > > # > # A fatal error has been detected by the Java > Runtime > Environment: > # > # Internal Error (instanceKlass.cpp:1995), > pid=15444, > tid=0x00002b1fd0186700 > # guarantee(val >= 0) failed: Underflow: -1 > # > # JRE version: Java(TM) SE Runtime Environment > (8.0_102-b14) (build > 1.8.0_102-b14) > # Java VM: Java HotSpot(TM) 64-Bit Server VM > (25.102-b14 > mixed mode > linux-amd64 ) > # > # If you would like to submit a bug report, > please visit: > # > http://bugreport.java.com/bugreport/crash.jsp > > # > > --------------- T H R E A D --------------- > > Current thread (0x00002b1f58056800): JavaThread "C2 > CompilerThread2" daemon [_thread_in_vm, id=15533, > stack(0x00002b1fd0086000,0x00002b1fd0187000)] > > Stack: [0x00002b1fd0086000,0x00002b1fd0187000], > sp=0x00002b1fd0185580, free space=1021k > Native frames: (J=compiled Java code, j=interpreted, > Vv=VM code, > C=native code) > V [libjvm.so+0xac52aa] > VMError::report_and_die()+0x2ba > V [libjvm.so+0x4fba22] report_vm_error(char > const*, > int, char > const*, char const*)+0x62 > V [libjvm.so+0x63e9b0] > InstanceKlass::remove_dependent_nmethod(nmethod*, > bool)+0x110 > V [libjvm.so+0x8e61b3] > > nmethod::flush_dependencies(BoolObjectClosure*)+0x93 > V [libjvm.so+0x8ebd5b] > nmethod::make_not_entrant_or_zombie(unsigned > int)+0x48b > V [libjvm.so+0xa2b0cd] > NMethodSweeper::process_nmethod(nmethod*)+0x27d > V [libjvm.so+0xa2b468] > NMethodSweeper::sweep_code_cache()+0x328 > V [libjvm.so+0xa2b7d4] > NMethodSweeper::possibly_sweep()+0xb4 > V [libjvm.so+0x4ae105] CompileQueue::get()+0x15 > V [libjvm.so+0x4b047b] > CompileBroker::compiler_thread_loop()+0x18b > V [libjvm.so+0xa73ce3] > JavaThread::thread_main_inner()+0x103 > V [libjvm.so+0xa73e2c] JavaThread::run()+0x11c > V [libjvm.so+0x9249c8] java_start(Thread*)+0x108 > C [libpthread.so.0+0x6b50] start_thread+0xd0 > > =>0x00002b1f58056800 JavaThread "C2 > CompilerThread2" daemon > [_thread_in_vm, id=15533, > stack(0x00002b1fd0086000,0x00002b1fd0187000)] > > VM state:not at safepoint (normal execution) > VM Mutex/Monitor currently owned by a thread: > ([mutex/lock_event]) > [0x0000000001ac5f40] CodeCache_lock - owner thread: > 0x00002b1f58056800 > [0x0000000001ac7240] CompiledIC_lock - owner thread: > 0x00002b1f58056800 > > Heap: > PSYoungGen total 16531968K, used 13673471K > [0x00002b1b0b200000, 0x00002b1f49900000, > 0x00002b1f4b200000) > eden space 15297024K, 83% used > > [0x00002b1b0b200000,0x00002b1e19277f68,0x00002b1eb0c80000) > from space 1234944K, 69% used > > [0x00002b1eb0c80000,0x00002b1ee5507eb0,0x00002b1efc280000) > to space 1198080K, 0% used > > [0x00002b1f00700000,0x00002b1f00700000,0x00002b1f49900000) > ParOldGen total 34891264K, used 26246257K > [0x00002b128b200000, 0x00002b1adcb80000, > 0x00002b1b0b200000) > object space 34891264K, 75% used > > [0x00002b128b200000,0x00002b18cd11c630,0x00002b1adcb80000) > Metaspace used 211158K, capacity 610281K, > committed 610528K, > reserved 612352K > > Polling page: 0x00002b1281166000 > > CodeCache: size=102400Kb used=71326Kb > max_used=81914Kb > free=31073Kb > bounds [0x00002b1284ab2000, 0x00002b128aeb2000, > 0x00002b128aeb2000] > total_blobs=13619 nmethods=12436 adapters=1089 > compilation: enabled > > *Here's the second:* > > # > # A fatal error has been detected by the Java > Runtime > Environment: > # > # Internal Error (instanceKlass.cpp:2018), > pid=83979, > tid=0x00002bb97feba700 > # Error: ShouldNotReachHere() > # > # JRE version: Java(TM) SE Runtime Environment > (8.0_102-b14) (build > 1.8.0_102-b14) > # Java VM: Java HotSpot(TM) 64-Bit Server VM > (25.102-b14 > mixed mode > linux-amd64 ) > # > # If you would like to submit a bug report, > please visit: > # > http://bugreport.java.com/bugreport/crash.jsp > > # > > --------------- T H R E A D --------------- > > Current thread (0x00002bb8f40cf800): JavaThread "C2 > CompilerThread6" daemon [_thread_in_vm, id=84042, > stack(0x00002bb97fdba000,0x00002bb97febb000)] > > Stack: [0x00002bb97fdba000,0x00002bb97febb000], > sp=0x00002bb97feb9710, free space=1021k > Native frames: (J=compiled Java code, j=interpreted, > Vv=VM code, > C=native code) > V [libjvm.so+0xac52aa] > VMError::report_and_die()+0x2ba > V [libjvm.so+0x4fbd92] > report_should_not_reach_here(char const*, > int)+0x52 > V [libjvm.so+0x63e8fb] > InstanceKlass::remove_dependent_nmethod(nmethod*, > bool)+0x5b > V [libjvm.so+0x8e61b3] > > nmethod::flush_dependencies(BoolObjectClosure*)+0x93 > V [libjvm.so+0x8ebd5b] > nmethod::make_not_entrant_or_zombie(unsigned > int)+0x48b > V [libjvm.so+0xa2b0cd] > NMethodSweeper::process_nmethod(nmethod*)+0x27d > V [libjvm.so+0xa2b468] > NMethodSweeper::sweep_code_cache()+0x328 > V [libjvm.so+0xa2b7d4] > NMethodSweeper::possibly_sweep()+0xb4 > V [libjvm.so+0x4ae105] CompileQueue::get()+0x15 > V [libjvm.so+0x4b047b] > CompileBroker::compiler_thread_loop()+0x18b > V [libjvm.so+0xa73ce3] > JavaThread::thread_main_inner()+0x103 > V [libjvm.so+0xa73e2c] JavaThread::run()+0x11c > V [libjvm.so+0x9249c8] java_start(Thread*)+0x108 > C [libpthread.so.0+0x6b50] start_thread+0xd0 > > =>0x00002bb8f40cf800 JavaThread "C2 > CompilerThread6" daemon > [_thread_in_vm, id=84042, > stack(0x00002bb97fdba000,0x00002bb97febb000)] > VM state:not at safepoint (normal execution) > > VM Mutex/Monitor currently owned by a thread: > ([mutex/lock_event]) > [0x0000000001858f40] CodeCache_lock - owner thread: > 0x00002bb8f40cf800 > [0x000000000185a240] CompiledIC_lock - owner thread: > 0x00002bb8f40cf800 > > Heap: > PSYoungGen total 18567168K, used 3149269K > [0x00002bb3cdf00000, 0x00002bb8e3400000, > 0x00002bb8e3400000) > eden space 15838208K, 5% used > > [0x00002bb3cdf00000,0x00002bb402b26e00,0x00002bb794a00000) > from space 2728960K, 83% used > > [0x00002bb83ab00000,0x00002bb8c624e6b0,0x00002bb8e1400000) > to space 2720768K, 0% used > > [0x00002bb794a00000,0x00002bb794a00000,0x00002bb83ab00000) > ParOldGen total 23083520K, used 21102913K > [0x00002ba9a3400000, 0x00002baf24280000, > 0x00002bb3cdf00000) > object space 23083520K, 91% used > > [0x00002ba9a3400000,0x00002baeab450478,0x00002baf24280000) > Metaspace used 167926K, capacity 377784K, > committed 377856K, reserved 378880K > > > > Polling page: 0x00002ba999461000 > > CodeCache: size=102400Kb used=72829Kb > max_used=81642Kb > free=29570Kb > bounds [0x00002ba99cdad000, 0x00002ba9a31ad000, > 0x00002ba9a31ad000] > total_blobs=14843 nmethods=13668 adapters=1082 > compilation: enabled > > -- > Sent from my phone > > -- > Sent from my phone > > From martin.doerr at sap.com Mon Dec 12 19:00:19 2016 From: martin.doerr at sap.com (Doerr, Martin) Date: Mon, 12 Dec 2016 19:00:19 +0000 Subject: RFR(M): 8170991: PPC64: Bad code for initialization of short arrays In-Reply-To: <9ae526c6aa204060905bf247fc2aa783@DEROTE13DE08.global.corp.sap> References: <9ae526c6aa204060905bf247fc2aa783@DEROTE13DE08.global.corp.sap> Message-ID: <269fac2e594645ca896be5f76d57ecd1@dewdfe13de06.global.corp.sap> Hi G?tz and Gustavo, thank you very much for reviewing and for testing. As using a lower value for InitArrayShortSize didn't improve Gustavo's test cases, I agree with G?tz that this part of the change should better not be done. I was only able to observe shorter code in some test cases which don't seem to be important. I have removed the match rule for very short arrays again and set InitArrayShortSize to match C1's implementation (2x unrolled loop is shorter with more than 9 HeapWords): http://cr.openjdk.java.net/~mdoerr/8170991_PPC64_ClearArray/webrev.01/ Please review. Thanks and best regards, Martin -----Original Message----- From: Lindenmaier, Goetz Sent: Montag, 12. Dezember 2016 12:54 To: Doerr, Martin ; 'hotspot-compiler-dev at openjdk.java.net' ; Gustavo Serra Scalet Subject: RE: RFR(M): 8170991: PPC64: Bad code for initialization of short arrays Hi Martin, I had a look at your change. I like you cleaned up the C1 implementation, moving the various cases to the macro assembler and reusing it. I'm also fine with matching for constant array sizes. I'm not sure whether reducing InitArrayShortSize helps. It sure removes the simple-to-spot pattern of loading 0 too often into registers. This only happened if register allocation ran out of registers and rematerialized. And as we saw, where the 0 was rematerialized, the register pressure was not that high, sufficient registers to hold 0 were available :). This is just an artefact of register allocation. I would assume the processor internally handles this efficiently. Loading 0 into a register should be one of the cheapest operations altogether! If you only look at the places where rematerialization happened, you miss other benefits in the places where there is no rematerialization necessary. So you optimize for the few cases with rematerialization, paying the cost in the many places without rematerialization. E.g., if 0 is used in some other places in the same code, it's there anyways. So I'm not sure it helps with performance, but if you don't spot regressions I'm fine with the change to InitArrayShortSize, too. Best regards, Goetz. > -----Original Message----- > From: hotspot-compiler-dev [mailto:hotspot-compiler-dev- > bounces at openjdk.java.net] On Behalf Of Doerr, Martin > Sent: Freitag, 9. Dezember 2016 18:01 > To: 'hotspot-compiler-dev at openjdk.java.net' dev at openjdk.java.net>; Gustavo Serra Scalet > > Subject: RFR(M): 8170991: PPC64: Bad code for initialization of short > arrays > > Hello everybody, > > > > the new flag "InitArrayShortSize" was set to 8 on PPC64. However, this > leads to bad code. PPC64's C2 compiler currently does not have > dedicated match rules to store 0. > > Unfortunately, loading of the constant 0 got rematerialized many times > in some cases consuming more registers and code space than needed. > > > > An attempt to improve initialization was > > 8170094: PPC64: Keep immediate value 0 cached into a register to > improve performance > > but this approach has disadvantages and we had decided against it. > > > > It is possibly to implement special ClearArray nodes to improve the > initialization of arrays only: > > http://cr.openjdk.java.net/~mdoerr/8170991_PPC64_ClearArray/webrev.00/ > > > > Please review. > > > > @Gustavo: Maybe this improves your test cases, too? > > > > Best regards, > > Martin > > From vitalyd at gmail.com Mon Dec 12 19:57:21 2016 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Mon, 12 Dec 2016 14:57:21 -0500 Subject: 8u102 NMethod sweeper related Hotspot crashes In-Reply-To: References: <4a46f7da-10af-db7b-9e4c-eca4c0508979@oracle.com> <345cf4cf-9b50-1911-da34-a77e6f7890a0@oracle.com> Message-ID: Thanks Vladimir. The segfault looks unrelated to this, so scratch that for now. I filed a JBS entry for the nmethod sweeper crashes though - internal id is 9046080. I'm happy to provide any additional info that you guys may need, but I put the full hs_err file contents for the 3 flavors of the crash we've seen. Thanks On Mon, Dec 12, 2016 at 1:10 PM, Vladimir Kozlov wrote: > If all in the same path (calls from NMethodSweeper::process_nmethod()) > then one JBS entry is enough. > > Vladimir > > On 12/12/16 10:05 AM, Vitaly Davidovich wrote: > >> Hi Vladimir, >> >> There are now multiple crash reports around this code path, but all with >> a slightly different assertion error. Is one JBS entry with all the >> seen flavors sufficient or does each one need to be separate? >> Unfortunately, turning off tiered compilation causes a segfault although >> I'm trying to get the full crash report to see if it's in the same code >> (path) or something else entirely. >> >> Thanks >> >> On Wed, Dec 7, 2016 at 1:20 PM, Vladimir Kozlov >> > wrote: >> >> All crashes have to have JBS entry. Please, file bug. >> >> JDK-8139595 is not related unfortunately. It fixed code present only >> in JDK 9. >> >> Thanks, >> Vladimir >> >> On 12/7/16 10:13 AM, Vitaly Davidovich wrote: >> >> Vladimir, >> >> What do you think the next step should be? Is a JBS bug entry >> warranted? >> >> Thanks >> >> On Tue, Dec 6, 2016 at 1:12 PM Vitaly Davidovich >> >> >> wrote: >> >> Hi Vladimir, >> >> On Tue, Dec 6, 2016 at 12:57 PM, Vladimir Kozlov >> > >> > >> >> wrote: >> >> Could be >> https://bugs.openjdk.java.net/browse/JDK-8139595 >> (not >> backported to 8u). >> >> I can't find anything else with >> remove_dependent_nmethod() on >> call stack in JBS. >> >> It does seem like it could be related, but yeah, it's unclear. >> Hoping someone else here may have an idea. >> >> Thanks >> >> >> Vladimir >> >> On 12/6/16 9:33 AM, Vitaly Davidovich wrote: >> >> Btw, for now I've advised the group hitting these to >> turn >> off tiered >> compilation to reduce code cache pressure and thus >> hopefully >> avoid >> whatever bug(s) is lurking here. >> >> I should've also mentioned that this doesn't happen >> all the >> time, of >> course, so there's no reliable repro. >> >> On Tue, Dec 6, 2016 at 12:02 PM Vitaly Davidovich >> >> > >> >> >>> wrote: >> >> Hi guys, >> >> I have a couple of Hotspot crashes to report - >> both >> occur in nmethod >> sweeping/flushing. I'm going to strip down the >> hs_err >> content, but >> let me know if there's something else you need >> from >> there. Are >> these known? A quick google suggests there are >> some bugs >> around >> nmethod sweeping, but I couldn't find anything >> exactly >> like this. >> >> Let me know if you need more info. >> >> Thanks >> >> *The first is:* >> >> >> # >> # A fatal error has been detected by the Java >> Runtime >> Environment: >> # >> # Internal Error (instanceKlass.cpp:1995), >> pid=15444, >> tid=0x00002b1fd0186700 >> # guarantee(val >= 0) failed: Underflow: -1 >> # >> # JRE version: Java(TM) SE Runtime Environment >> (8.0_102-b14) (build >> 1.8.0_102-b14) >> # Java VM: Java HotSpot(TM) 64-Bit Server VM >> (25.102-b14 >> mixed mode >> linux-amd64 ) >> # >> # If you would like to submit a bug report, >> please visit: >> # >> http://bugreport.java.com/bugreport/crash.jsp >> >> # >> >> --------------- T H R E A D --------------- >> >> Current thread (0x00002b1f58056800): JavaThread >> "C2 >> CompilerThread2" daemon [_thread_in_vm, id=15533, >> stack(0x00002b1fd0086000,0x00002b1fd0187000)] >> >> Stack: [0x00002b1fd0086000,0x00002b1fd0187000], >> sp=0x00002b1fd0185580, free space=1021k >> Native frames: (J=compiled Java code, >> j=interpreted, >> Vv=VM code, >> C=native code) >> V [libjvm.so+0xac52aa] >> VMError::report_and_die()+0x2ba >> V [libjvm.so+0x4fba22] report_vm_error(char >> const*, >> int, char >> const*, char const*)+0x62 >> V [libjvm.so+0x63e9b0] >> InstanceKlass::remove_depende >> nt_nmethod(nmethod*, >> bool)+0x110 >> V [libjvm.so+0x8e61b3] >> >> nmethod::flush_dependencies(BoolObjectClosure*)+0x93 >> V [libjvm.so+0x8ebd5b] >> nmethod::make_not_entrant_or_zombie(unsigned >> int)+0x48b >> V [libjvm.so+0xa2b0cd] >> NMethodSweeper::process_nmethod(nmethod*)+0x27d >> V [libjvm.so+0xa2b468] >> NMethodSweeper::sweep_code_cache()+0x328 >> V [libjvm.so+0xa2b7d4] >> NMethodSweeper::possibly_sweep()+0xb4 >> V [libjvm.so+0x4ae105] CompileQueue::get()+0x15 >> V [libjvm.so+0x4b047b] >> CompileBroker::compiler_thread_loop()+0x18b >> V [libjvm.so+0xa73ce3] >> JavaThread::thread_main_inner()+0x103 >> V [libjvm.so+0xa73e2c] JavaThread::run()+0x11c >> V [libjvm.so+0x9249c8] java_start(Thread*)+0x108 >> C [libpthread.so.0+0x6b50] start_thread+0xd0 >> >> =>0x00002b1f58056800 JavaThread "C2 >> CompilerThread2" daemon >> [_thread_in_vm, id=15533, >> stack(0x00002b1fd0086000,0x00002b1fd0187000)] >> >> VM state:not at safepoint (normal execution) >> VM Mutex/Monitor currently owned by a thread: >> ([mutex/lock_event]) >> [0x0000000001ac5f40] CodeCache_lock - owner >> thread: >> 0x00002b1f58056800 >> [0x0000000001ac7240] CompiledIC_lock - owner >> thread: >> 0x00002b1f58056800 >> >> Heap: >> PSYoungGen total 16531968K, used 13673471K >> [0x00002b1b0b200000, 0x00002b1f49900000, >> 0x00002b1f4b200000) >> eden space 15297024K, 83% used >> >> [0x00002b1b0b200000,0x00002b1e19277f68,0x00002b1eb0c80000) >> from space 1234944K, 69% used >> >> [0x00002b1eb0c80000,0x00002b1ee5507eb0,0x00002b1efc280000) >> to space 1198080K, 0% used >> >> [0x00002b1f00700000,0x00002b1f00700000,0x00002b1f49900000) >> ParOldGen total 34891264K, used 26246257K >> [0x00002b128b200000, 0x00002b1adcb80000, >> 0x00002b1b0b200000) >> object space 34891264K, 75% used >> >> [0x00002b128b200000,0x00002b18cd11c630,0x00002b1adcb80000) >> Metaspace used 211158K, capacity 610281K, >> committed 610528K, >> reserved 612352K >> >> Polling page: 0x00002b1281166000 >> >> CodeCache: size=102400Kb used=71326Kb >> max_used=81914Kb >> free=31073Kb >> bounds [0x00002b1284ab2000, 0x00002b128aeb2000, >> 0x00002b128aeb2000] >> total_blobs=13619 nmethods=12436 adapters=1089 >> compilation: enabled >> >> *Here's the second:* >> >> # >> # A fatal error has been detected by the Java >> Runtime >> Environment: >> # >> # Internal Error (instanceKlass.cpp:2018), >> pid=83979, >> tid=0x00002bb97feba700 >> # Error: ShouldNotReachHere() >> # >> # JRE version: Java(TM) SE Runtime Environment >> (8.0_102-b14) (build >> 1.8.0_102-b14) >> # Java VM: Java HotSpot(TM) 64-Bit Server VM >> (25.102-b14 >> mixed mode >> linux-amd64 ) >> # >> # If you would like to submit a bug report, >> please visit: >> # >> http://bugreport.java.com/bugreport/crash.jsp >> >> # >> >> --------------- T H R E A D --------------- >> >> Current thread (0x00002bb8f40cf800): JavaThread >> "C2 >> CompilerThread6" daemon [_thread_in_vm, id=84042, >> stack(0x00002bb97fdba000,0x00002bb97febb000)] >> >> Stack: [0x00002bb97fdba000,0x00002bb97febb000], >> sp=0x00002bb97feb9710, free space=1021k >> Native frames: (J=compiled Java code, >> j=interpreted, >> Vv=VM code, >> C=native code) >> V [libjvm.so+0xac52aa] >> VMError::report_and_die()+0x2ba >> V [libjvm.so+0x4fbd92] >> report_should_not_reach_here(char const*, >> int)+0x52 >> V [libjvm.so+0x63e8fb] >> InstanceKlass::remove_depende >> nt_nmethod(nmethod*, >> bool)+0x5b >> V [libjvm.so+0x8e61b3] >> >> nmethod::flush_dependencies(BoolObjectClosure*)+0x93 >> V [libjvm.so+0x8ebd5b] >> nmethod::make_not_entrant_or_zombie(unsigned >> int)+0x48b >> V [libjvm.so+0xa2b0cd] >> NMethodSweeper::process_nmethod(nmethod*)+0x27d >> V [libjvm.so+0xa2b468] >> NMethodSweeper::sweep_code_cache()+0x328 >> V [libjvm.so+0xa2b7d4] >> NMethodSweeper::possibly_sweep()+0xb4 >> V [libjvm.so+0x4ae105] CompileQueue::get()+0x15 >> V [libjvm.so+0x4b047b] >> CompileBroker::compiler_thread_loop()+0x18b >> V [libjvm.so+0xa73ce3] >> JavaThread::thread_main_inner()+0x103 >> V [libjvm.so+0xa73e2c] JavaThread::run()+0x11c >> V [libjvm.so+0x9249c8] java_start(Thread*)+0x108 >> C [libpthread.so.0+0x6b50] start_thread+0xd0 >> >> =>0x00002bb8f40cf800 JavaThread "C2 >> CompilerThread6" daemon >> [_thread_in_vm, id=84042, >> stack(0x00002bb97fdba000,0x00002bb97febb000)] >> VM state:not at safepoint (normal execution) >> >> VM Mutex/Monitor currently owned by a thread: >> ([mutex/lock_event]) >> [0x0000000001858f40] CodeCache_lock - owner >> thread: >> 0x00002bb8f40cf800 >> [0x000000000185a240] CompiledIC_lock - owner >> thread: >> 0x00002bb8f40cf800 >> >> Heap: >> PSYoungGen total 18567168K, used 3149269K >> [0x00002bb3cdf00000, 0x00002bb8e3400000, >> 0x00002bb8e3400000) >> eden space 15838208K, 5% used >> >> [0x00002bb3cdf00000,0x00002bb402b26e00,0x00002bb794a00000) >> from space 2728960K, 83% used >> >> [0x00002bb83ab00000,0x00002bb8c624e6b0,0x00002bb8e1400000) >> to space 2720768K, 0% used >> >> [0x00002bb794a00000,0x00002bb794a00000,0x00002bb83ab00000) >> ParOldGen total 23083520K, used 21102913K >> [0x00002ba9a3400000, 0x00002baf24280000, >> 0x00002bb3cdf00000) >> object space 23083520K, 91% used >> >> [0x00002ba9a3400000,0x00002baeab450478,0x00002baf24280000) >> Metaspace used 167926K, capacity 377784K, >> committed 377856K, reserved 378880K >> >> >> >> Polling page: 0x00002ba999461000 >> >> CodeCache: size=102400Kb used=72829Kb >> max_used=81642Kb >> free=29570Kb >> bounds [0x00002ba99cdad000, 0x00002ba9a31ad000, >> 0x00002ba9a31ad000] >> total_blobs=14843 nmethods=13668 adapters=1082 >> compilation: enabled >> >> -- >> Sent from my phone >> >> -- >> Sent from my phone >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladimir.kozlov at oracle.com Mon Dec 12 20:15:36 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 12 Dec 2016 12:15:36 -0800 Subject: 8u102 NMethod sweeper related Hotspot crashes In-Reply-To: References: <4a46f7da-10af-db7b-9e4c-eca4c0508979@oracle.com> <345cf4cf-9b50-1911-da34-a77e6f7890a0@oracle.com> Message-ID: Converted to JDK bug: https://bugs.openjdk.java.net/browse/JDK-8171116 Vladimir On 12/12/16 11:57 AM, Vitaly Davidovich wrote: > Thanks Vladimir. > > The segfault looks unrelated to this, so scratch that for now. > > I filed a JBS entry for the nmethod sweeper crashes though - internal id > is 9046080. > > I'm happy to provide any additional info that you guys may need, but I > put the full hs_err file contents for the 3 flavors of the crash we've seen. > > Thanks > > On Mon, Dec 12, 2016 at 1:10 PM, Vladimir Kozlov > > wrote: > > If all in the same path (calls from > NMethodSweeper::process_nmethod()) then one JBS entry is enough. > > Vladimir > > On 12/12/16 10:05 AM, Vitaly Davidovich wrote: > > Hi Vladimir, > > There are now multiple crash reports around this code path, but > all with > a slightly different assertion error. Is one JBS entry with all the > seen flavors sufficient or does each one need to be separate? > Unfortunately, turning off tiered compilation causes a segfault > although > I'm trying to get the full crash report to see if it's in the > same code > (path) or something else entirely. > > Thanks > > On Wed, Dec 7, 2016 at 1:20 PM, Vladimir Kozlov > > >> wrote: > > All crashes have to have JBS entry. Please, file bug. > > JDK-8139595 is not related unfortunately. It fixed code > present only > in JDK 9. > > Thanks, > Vladimir > > On 12/7/16 10:13 AM, Vitaly Davidovich wrote: > > Vladimir, > > What do you think the next step should be? Is a JBS bug > entry > warranted? > > Thanks > > On Tue, Dec 6, 2016 at 1:12 PM Vitaly Davidovich > > > > > >>> wrote: > > Hi Vladimir, > > On Tue, Dec 6, 2016 at 12:57 PM, Vladimir Kozlov > > > > > > >>> wrote: > > Could be > https://bugs.openjdk.java.net/browse/JDK-8139595 > > > (not > backported to 8u). > > I can't find anything else with > remove_dependent_nmethod() on > call stack in JBS. > > It does seem like it could be related, but yeah, > it's unclear. > Hoping someone else here may have an idea. > > Thanks > > > Vladimir > > On 12/6/16 9:33 AM, Vitaly Davidovich wrote: > > Btw, for now I've advised the group hitting > these to > turn > off tiered > compilation to reduce code cache pressure > and thus > hopefully > avoid > whatever bug(s) is lurking here. > > I should've also mentioned that this doesn't > happen > all the > time, of > course, so there's no reliable repro. > > On Tue, Dec 6, 2016 at 12:02 PM Vitaly > Davidovich > > > > >> > > > > >>>> wrote: > > Hi guys, > > I have a couple of Hotspot crashes to > report - both > occur in nmethod > sweeping/flushing. I'm going to strip > down the > hs_err > content, but > let me know if there's something else > you need from > there. Are > these known? A quick google suggests > there are > some bugs > around > nmethod sweeping, but I couldn't find > anything > exactly > like this. > > Let me know if you need more info. > > Thanks > > *The first is:* > > > # > # A fatal error has been detected by the > Java > Runtime > Environment: > # > # Internal Error (instanceKlass.cpp:1995), > pid=15444, > tid=0x00002b1fd0186700 > # guarantee(val >= 0) failed: Underflow: -1 > # > # JRE version: Java(TM) SE Runtime > Environment > (8.0_102-b14) (build > 1.8.0_102-b14) > # Java VM: Java HotSpot(TM) 64-Bit Server VM > (25.102-b14 > mixed mode > linux-amd64 ) > # > # If you would like to submit a bug report, > please visit: > # > http://bugreport.java.com/bugreport/crash.jsp > > > > # > > --------------- T H R E A D > --------------- > > Current thread (0x00002b1f58056800): > JavaThread "C2 > CompilerThread2" daemon [_thread_in_vm, > id=15533, > > stack(0x00002b1fd0086000,0x00002b1fd0187000)] > > Stack: > [0x00002b1fd0086000,0x00002b1fd0187000], > sp=0x00002b1fd0185580, free space=1021k > Native frames: (J=compiled Java code, > j=interpreted, > Vv=VM code, > C=native code) > V [libjvm.so+0xac52aa] > VMError::report_and_die()+0x2ba > V [libjvm.so+0x4fba22] > report_vm_error(char > const*, > int, char > const*, char const*)+0x62 > V [libjvm.so+0x63e9b0] > > InstanceKlass::remove_dependent_nmethod(nmethod*, > bool)+0x110 > V [libjvm.so+0x8e61b3] > > nmethod::flush_dependencies(BoolObjectClosure*)+0x93 > V [libjvm.so+0x8ebd5b] > > nmethod::make_not_entrant_or_zombie(unsigned > int)+0x48b > V [libjvm.so+0xa2b0cd] > NMethodSweeper::process_nmethod(nmethod*)+0x27d > V [libjvm.so+0xa2b468] > NMethodSweeper::sweep_code_cache()+0x328 > V [libjvm.so+0xa2b7d4] > NMethodSweeper::possibly_sweep()+0xb4 > V [libjvm.so+0x4ae105] > CompileQueue::get()+0x15 > V [libjvm.so+0x4b047b] > CompileBroker::compiler_thread_loop()+0x18b > V [libjvm.so+0xa73ce3] > JavaThread::thread_main_inner()+0x103 > V [libjvm.so+0xa73e2c] > JavaThread::run()+0x11c > V [libjvm.so+0x9249c8] > java_start(Thread*)+0x108 > C [libpthread.so.0+0x6b50] > start_thread+0xd0 > > =>0x00002b1f58056800 JavaThread "C2 > CompilerThread2" daemon > [_thread_in_vm, id=15533, > stack(0x00002b1fd0086000,0x00002b1fd0187000)] > > VM state:not at safepoint (normal execution) > VM Mutex/Monitor currently owned by a > thread: > ([mutex/lock_event]) > [0x0000000001ac5f40] CodeCache_lock - > owner thread: > 0x00002b1f58056800 > [0x0000000001ac7240] CompiledIC_lock - > owner thread: > 0x00002b1f58056800 > > Heap: > PSYoungGen total 16531968K, used > 13673471K > [0x00002b1b0b200000, 0x00002b1f49900000, > 0x00002b1f4b200000) > eden space 15297024K, 83% used > > [0x00002b1b0b200000,0x00002b1e19277f68,0x00002b1eb0c80000) > from space 1234944K, 69% used > > [0x00002b1eb0c80000,0x00002b1ee5507eb0,0x00002b1efc280000) > to space 1198080K, 0% used > > [0x00002b1f00700000,0x00002b1f00700000,0x00002b1f49900000) > ParOldGen total 34891264K, used > 26246257K > [0x00002b128b200000, 0x00002b1adcb80000, > 0x00002b1b0b200000) > object space 34891264K, 75% used > > [0x00002b128b200000,0x00002b18cd11c630,0x00002b1adcb80000) > Metaspace used 211158K, capacity > 610281K, > committed 610528K, > reserved 612352K > > Polling page: 0x00002b1281166000 > > CodeCache: size=102400Kb used=71326Kb > max_used=81914Kb > free=31073Kb > bounds [0x00002b1284ab2000, > 0x00002b128aeb2000, > 0x00002b128aeb2000] > total_blobs=13619 nmethods=12436 > adapters=1089 > compilation: enabled > > *Here's the second:* > > # > # A fatal error has been detected by the > Java > Runtime > Environment: > # > # Internal Error (instanceKlass.cpp:2018), > pid=83979, > tid=0x00002bb97feba700 > # Error: ShouldNotReachHere() > # > # JRE version: Java(TM) SE Runtime > Environment > (8.0_102-b14) (build > 1.8.0_102-b14) > # Java VM: Java HotSpot(TM) 64-Bit Server VM > (25.102-b14 > mixed mode > linux-amd64 ) > # > # If you would like to submit a bug report, > please visit: > # > http://bugreport.java.com/bugreport/crash.jsp > > > > # > > --------------- T H R E A D > --------------- > > Current thread (0x00002bb8f40cf800): > JavaThread "C2 > CompilerThread6" daemon [_thread_in_vm, > id=84042, > > stack(0x00002bb97fdba000,0x00002bb97febb000)] > > Stack: > [0x00002bb97fdba000,0x00002bb97febb000], > sp=0x00002bb97feb9710, free space=1021k > Native frames: (J=compiled Java code, > j=interpreted, > Vv=VM code, > C=native code) > V [libjvm.so+0xac52aa] > VMError::report_and_die()+0x2ba > V [libjvm.so+0x4fbd92] > report_should_not_reach_here(char const*, > int)+0x52 > V [libjvm.so+0x63e8fb] > > InstanceKlass::remove_dependent_nmethod(nmethod*, > bool)+0x5b > V [libjvm.so+0x8e61b3] > > nmethod::flush_dependencies(BoolObjectClosure*)+0x93 > V [libjvm.so+0x8ebd5b] > > nmethod::make_not_entrant_or_zombie(unsigned > int)+0x48b > V [libjvm.so+0xa2b0cd] > NMethodSweeper::process_nmethod(nmethod*)+0x27d > V [libjvm.so+0xa2b468] > NMethodSweeper::sweep_code_cache()+0x328 > V [libjvm.so+0xa2b7d4] > NMethodSweeper::possibly_sweep()+0xb4 > V [libjvm.so+0x4ae105] > CompileQueue::get()+0x15 > V [libjvm.so+0x4b047b] > CompileBroker::compiler_thread_loop()+0x18b > V [libjvm.so+0xa73ce3] > JavaThread::thread_main_inner()+0x103 > V [libjvm.so+0xa73e2c] > JavaThread::run()+0x11c > V [libjvm.so+0x9249c8] > java_start(Thread*)+0x108 > C [libpthread.so.0+0x6b50] > start_thread+0xd0 > > =>0x00002bb8f40cf800 JavaThread "C2 > CompilerThread6" daemon > [_thread_in_vm, id=84042, > stack(0x00002bb97fdba000,0x00002bb97febb000)] > VM state:not at safepoint (normal execution) > > VM Mutex/Monitor currently owned by a > thread: > ([mutex/lock_event]) > [0x0000000001858f40] CodeCache_lock - > owner thread: > 0x00002bb8f40cf800 > [0x000000000185a240] CompiledIC_lock - > owner thread: > 0x00002bb8f40cf800 > > Heap: > PSYoungGen total 18567168K, used > 3149269K > [0x00002bb3cdf00000, 0x00002bb8e3400000, > 0x00002bb8e3400000) > eden space 15838208K, 5% used > > [0x00002bb3cdf00000,0x00002bb402b26e00,0x00002bb794a00000) > from space 2728960K, 83% used > > [0x00002bb83ab00000,0x00002bb8c624e6b0,0x00002bb8e1400000) > to space 2720768K, 0% used > > [0x00002bb794a00000,0x00002bb794a00000,0x00002bb83ab00000) > ParOldGen total 23083520K, used > 21102913K > [0x00002ba9a3400000, 0x00002baf24280000, > 0x00002bb3cdf00000) > object space 23083520K, 91% used > > [0x00002ba9a3400000,0x00002baeab450478,0x00002baf24280000) > Metaspace used 167926K, capacity > 377784K, > committed 377856K, reserved 378880K > > > > Polling page: 0x00002ba999461000 > > CodeCache: size=102400Kb used=72829Kb > max_used=81642Kb > free=29570Kb > bounds [0x00002ba99cdad000, > 0x00002ba9a31ad000, > 0x00002ba9a31ad000] > total_blobs=14843 nmethods=13668 > adapters=1082 > compilation: enabled > > -- > Sent from my phone > > -- > Sent from my phone > > > From vitalyd at gmail.com Mon Dec 12 20:19:37 2016 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Mon, 12 Dec 2016 15:19:37 -0500 Subject: 8u102 NMethod sweeper related Hotspot crashes In-Reply-To: References: <4a46f7da-10af-db7b-9e4c-eca4c0508979@oracle.com> <345cf4cf-9b50-1911-da34-a77e6f7890a0@oracle.com> Message-ID: Great, thanks! Keep me posted :) And as mentioned, if you need any further info, let me know (although I've included pretty much all I have at the moment). On Mon, Dec 12, 2016 at 3:15 PM, Vladimir Kozlov wrote: > Converted to JDK bug: > > https://bugs.openjdk.java.net/browse/JDK-8171116 > > Vladimir > > On 12/12/16 11:57 AM, Vitaly Davidovich wrote: > >> Thanks Vladimir. >> >> The segfault looks unrelated to this, so scratch that for now. >> >> I filed a JBS entry for the nmethod sweeper crashes though - internal id >> is 9046080. >> >> I'm happy to provide any additional info that you guys may need, but I >> put the full hs_err file contents for the 3 flavors of the crash we've >> seen. >> >> Thanks >> >> On Mon, Dec 12, 2016 at 1:10 PM, Vladimir Kozlov >> > wrote: >> >> If all in the same path (calls from >> NMethodSweeper::process_nmethod()) then one JBS entry is enough. >> >> Vladimir >> >> On 12/12/16 10:05 AM, Vitaly Davidovich wrote: >> >> Hi Vladimir, >> >> There are now multiple crash reports around this code path, but >> all with >> a slightly different assertion error. Is one JBS entry with all >> the >> seen flavors sufficient or does each one need to be separate? >> Unfortunately, turning off tiered compilation causes a segfault >> although >> I'm trying to get the full crash report to see if it's in the >> same code >> (path) or something else entirely. >> >> Thanks >> >> On Wed, Dec 7, 2016 at 1:20 PM, Vladimir Kozlov >> >> > >> wrote: >> >> All crashes have to have JBS entry. Please, file bug. >> >> JDK-8139595 is not related unfortunately. It fixed code >> present only >> in JDK 9. >> >> Thanks, >> Vladimir >> >> On 12/7/16 10:13 AM, Vitaly Davidovich wrote: >> >> Vladimir, >> >> What do you think the next step should be? Is a JBS bug >> entry >> warranted? >> >> Thanks >> >> On Tue, Dec 6, 2016 at 1:12 PM Vitaly Davidovich >> >> > >> >> >>> wrote: >> >> Hi Vladimir, >> >> On Tue, Dec 6, 2016 at 12:57 PM, Vladimir Kozlov >> > >> > > >> > >> >> > >>> wrote: >> >> Could be >> https://bugs.openjdk.java.net/browse/JDK-8139595 >> >> > > (not >> backported to 8u). >> >> I can't find anything else with >> remove_dependent_nmethod() on >> call stack in JBS. >> >> It does seem like it could be related, but yeah, >> it's unclear. >> Hoping someone else here may have an idea. >> >> Thanks >> >> >> Vladimir >> >> On 12/6/16 9:33 AM, Vitaly Davidovich wrote: >> >> Btw, for now I've advised the group hitting >> these to >> turn >> off tiered >> compilation to reduce code cache pressure >> and thus >> hopefully >> avoid >> whatever bug(s) is lurking here. >> >> I should've also mentioned that this doesn't >> happen >> all the >> time, of >> course, so there's no reliable repro. >> >> On Tue, Dec 6, 2016 at 12:02 PM Vitaly >> Davidovich >> > > > >> >> >> >> > > > >> >> >>>> wrote: >> >> Hi guys, >> >> I have a couple of Hotspot crashes to >> report - both >> occur in nmethod >> sweeping/flushing. I'm going to strip >> down the >> hs_err >> content, but >> let me know if there's something else >> you need from >> there. Are >> these known? A quick google suggests >> there are >> some bugs >> around >> nmethod sweeping, but I couldn't find >> anything >> exactly >> like this. >> >> Let me know if you need more info. >> >> Thanks >> >> *The first is:* >> >> >> # >> # A fatal error has been detected by the >> Java >> Runtime >> Environment: >> # >> # Internal Error >> (instanceKlass.cpp:1995), >> pid=15444, >> tid=0x00002b1fd0186700 >> # guarantee(val >= 0) failed: Underflow: >> -1 >> # >> # JRE version: Java(TM) SE Runtime >> Environment >> (8.0_102-b14) (build >> 1.8.0_102-b14) >> # Java VM: Java HotSpot(TM) 64-Bit Server >> VM >> (25.102-b14 >> mixed mode >> linux-amd64 ) >> # >> # If you would like to submit a bug >> report, >> please visit: >> # >> http://bugreport.java.com/bugreport/crash.jsp >> >> > > >> # >> >> --------------- T H R E A D >> --------------- >> >> Current thread (0x00002b1f58056800): >> JavaThread "C2 >> CompilerThread2" daemon [_thread_in_vm, >> id=15533, >> >> stack(0x00002b1fd0086000,0x00002b1fd0187000)] >> >> Stack: >> [0x00002b1fd0086000,0x00002b1fd0187000], >> sp=0x00002b1fd0185580, free space=1021k >> Native frames: (J=compiled Java code, >> j=interpreted, >> Vv=VM code, >> C=native code) >> V [libjvm.so+0xac52aa] >> VMError::report_and_die()+0x2ba >> V [libjvm.so+0x4fba22] >> report_vm_error(char >> const*, >> int, char >> const*, char const*)+0x62 >> V [libjvm.so+0x63e9b0] >> >> InstanceKlass::remove_dependent_nmethod(nmethod*, >> bool)+0x110 >> V [libjvm.so+0x8e61b3] >> >> nmethod::flush_dependencies(BoolObjectClosure*)+0x93 >> V [libjvm.so+0x8ebd5b] >> >> nmethod::make_not_entrant_or_zombie(unsigned >> int)+0x48b >> V [libjvm.so+0xa2b0cd] >> NMethodSweeper::process_nmetho >> d(nmethod*)+0x27d >> V [libjvm.so+0xa2b468] >> NMethodSweeper::sweep_code_cache()+0x328 >> V [libjvm.so+0xa2b7d4] >> NMethodSweeper::possibly_sweep()+0xb4 >> V [libjvm.so+0x4ae105] >> CompileQueue::get()+0x15 >> V [libjvm.so+0x4b047b] >> CompileBroker::compiler_thread_loop()+0x18b >> V [libjvm.so+0xa73ce3] >> JavaThread::thread_main_inner()+0x103 >> V [libjvm.so+0xa73e2c] >> JavaThread::run()+0x11c >> V [libjvm.so+0x9249c8] >> java_start(Thread*)+0x108 >> C [libpthread.so.0+0x6b50] >> start_thread+0xd0 >> >> =>0x00002b1f58056800 JavaThread "C2 >> CompilerThread2" daemon >> [_thread_in_vm, id=15533, >> stack(0x00002b1fd0086000,0x00002b1fd0187000)] >> >> VM state:not at safepoint (normal >> execution) >> VM Mutex/Monitor currently owned by a >> thread: >> ([mutex/lock_event]) >> [0x0000000001ac5f40] CodeCache_lock - >> owner thread: >> 0x00002b1f58056800 >> [0x0000000001ac7240] CompiledIC_lock - >> owner thread: >> 0x00002b1f58056800 >> >> Heap: >> PSYoungGen total 16531968K, used >> 13673471K >> [0x00002b1b0b200000, 0x00002b1f49900000, >> 0x00002b1f4b200000) >> eden space 15297024K, 83% used >> >> [0x00002b1b0b200000,0x00002b1e >> 19277f68,0x00002b1eb0c80000) >> from space 1234944K, 69% used >> >> [0x00002b1eb0c80000,0x00002b1e >> e5507eb0,0x00002b1efc280000) >> to space 1198080K, 0% used >> >> [0x00002b1f00700000,0x00002b1f >> 00700000,0x00002b1f49900000) >> ParOldGen total 34891264K, used >> 26246257K >> [0x00002b128b200000, 0x00002b1adcb80000, >> 0x00002b1b0b200000) >> object space 34891264K, 75% used >> >> [0x00002b128b200000,0x00002b18 >> cd11c630,0x00002b1adcb80000) >> Metaspace used 211158K, capacity >> 610281K, >> committed 610528K, >> reserved 612352K >> >> Polling page: 0x00002b1281166000 >> >> CodeCache: size=102400Kb used=71326Kb >> max_used=81914Kb >> free=31073Kb >> bounds [0x00002b1284ab2000, >> 0x00002b128aeb2000, >> 0x00002b128aeb2000] >> total_blobs=13619 nmethods=12436 >> adapters=1089 >> compilation: enabled >> >> *Here's the second:* >> >> # >> # A fatal error has been detected by the >> Java >> Runtime >> Environment: >> # >> # Internal Error >> (instanceKlass.cpp:2018), >> pid=83979, >> tid=0x00002bb97feba700 >> # Error: ShouldNotReachHere() >> # >> # JRE version: Java(TM) SE Runtime >> Environment >> (8.0_102-b14) (build >> 1.8.0_102-b14) >> # Java VM: Java HotSpot(TM) 64-Bit Server >> VM >> (25.102-b14 >> mixed mode >> linux-amd64 ) >> # >> # If you would like to submit a bug >> report, >> please visit: >> # >> http://bugreport.java.com/bugreport/crash.jsp >> >> > > >> # >> >> --------------- T H R E A D >> --------------- >> >> Current thread (0x00002bb8f40cf800): >> JavaThread "C2 >> CompilerThread6" daemon [_thread_in_vm, >> id=84042, >> >> stack(0x00002bb97fdba000,0x00002bb97febb000)] >> >> Stack: >> [0x00002bb97fdba000,0x00002bb97febb000], >> sp=0x00002bb97feb9710, free space=1021k >> Native frames: (J=compiled Java code, >> j=interpreted, >> Vv=VM code, >> C=native code) >> V [libjvm.so+0xac52aa] >> VMError::report_and_die()+0x2ba >> V [libjvm.so+0x4fbd92] >> report_should_not_reach_here(char const*, >> int)+0x52 >> V [libjvm.so+0x63e8fb] >> >> InstanceKlass::remove_dependent_nmethod(nmethod*, >> bool)+0x5b >> V [libjvm.so+0x8e61b3] >> >> nmethod::flush_dependencies(BoolObjectClosure*)+0x93 >> V [libjvm.so+0x8ebd5b] >> >> nmethod::make_not_entrant_or_zombie(unsigned >> int)+0x48b >> V [libjvm.so+0xa2b0cd] >> NMethodSweeper::process_nmetho >> d(nmethod*)+0x27d >> V [libjvm.so+0xa2b468] >> NMethodSweeper::sweep_code_cache()+0x328 >> V [libjvm.so+0xa2b7d4] >> NMethodSweeper::possibly_sweep()+0xb4 >> V [libjvm.so+0x4ae105] >> CompileQueue::get()+0x15 >> V [libjvm.so+0x4b047b] >> CompileBroker::compiler_thread_loop()+0x18b >> V [libjvm.so+0xa73ce3] >> JavaThread::thread_main_inner()+0x103 >> V [libjvm.so+0xa73e2c] >> JavaThread::run()+0x11c >> V [libjvm.so+0x9249c8] >> java_start(Thread*)+0x108 >> C [libpthread.so.0+0x6b50] >> start_thread+0xd0 >> >> =>0x00002bb8f40cf800 JavaThread "C2 >> CompilerThread6" daemon >> [_thread_in_vm, id=84042, >> stack(0x00002bb97fdba000,0x00002bb97febb000)] >> VM state:not at safepoint (normal >> execution) >> >> VM Mutex/Monitor currently owned by a >> thread: >> ([mutex/lock_event]) >> [0x0000000001858f40] CodeCache_lock - >> owner thread: >> 0x00002bb8f40cf800 >> [0x000000000185a240] CompiledIC_lock - >> owner thread: >> 0x00002bb8f40cf800 >> >> Heap: >> PSYoungGen total 18567168K, used >> 3149269K >> [0x00002bb3cdf00000, 0x00002bb8e3400000, >> 0x00002bb8e3400000) >> eden space 15838208K, 5% used >> >> [0x00002bb3cdf00000,0x00002bb4 >> 02b26e00,0x00002bb794a00000) >> from space 2728960K, 83% used >> >> [0x00002bb83ab00000,0x00002bb8 >> c624e6b0,0x00002bb8e1400000) >> to space 2720768K, 0% used >> >> [0x00002bb794a00000,0x00002bb7 >> 94a00000,0x00002bb83ab00000) >> ParOldGen total 23083520K, used >> 21102913K >> [0x00002ba9a3400000, 0x00002baf24280000, >> 0x00002bb3cdf00000) >> object space 23083520K, 91% used >> >> [0x00002ba9a3400000,0x00002bae >> ab450478,0x00002baf24280000) >> Metaspace used 167926K, capacity >> 377784K, >> committed 377856K, reserved 378880K >> >> >> >> Polling page: 0x00002ba999461000 >> >> CodeCache: size=102400Kb used=72829Kb >> max_used=81642Kb >> free=29570Kb >> bounds [0x00002ba99cdad000, >> 0x00002ba9a31ad000, >> 0x00002ba9a31ad000] >> total_blobs=14843 nmethods=13668 >> adapters=1082 >> compilation: enabled >> >> -- >> Sent from my phone >> >> -- >> Sent from my phone >> >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladimir.kozlov at oracle.com Tue Dec 13 04:35:47 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 12 Dec 2016 20:35:47 -0800 Subject: [9] RFR(S) 8171134: Unexpected output in compiler/aot/SharedUsageTest.java Message-ID: https://bugs.openjdk.java.net/browse/JDK-8171134 http://cr.openjdk.java.net/~kvn/8171134/webrev/ AOT requires to have the same compressed oops settings when AOT code is compiled and when it is executed because oop shift values are embedded into decoding instructions. To have the the same heap size and heap base address should be the same. Unfortunately it is not always the same when nothing is specified on command line (HeapBaseMinAddress). And even that does not guarantee matching. If parameters are not the same AOT code will be ignored. But AOT tests incorrectly assume that configuration will be the same. For short fix I am suggesting to switch off compressed oops for few AOT test which could be affected by this issue. The test do not needed COOPs for what they are testing. Thanks, Vladimir From igor.veresov at oracle.com Tue Dec 13 04:40:16 2016 From: igor.veresov at oracle.com (Igor Veresov) Date: Mon, 12 Dec 2016 20:40:16 -0800 Subject: [9] RFR(S) 8171134: Unexpected output in compiler/aot/SharedUsageTest.java In-Reply-To: References: Message-ID: <5D2B77B1-F956-4159-AACE-DF291E38E414@oracle.com> Looks good. igor > On Dec 12, 2016, at 8:35 PM, Vladimir Kozlov wrote: > > https://bugs.openjdk.java.net/browse/JDK-8171134 > > http://cr.openjdk.java.net/~kvn/8171134/webrev/ > > AOT requires to have the same compressed oops settings when AOT code is compiled and when it is executed because oop shift values are embedded into decoding instructions. > To have the the same heap size and heap base address should be the same. Unfortunately it is not always the same when nothing is specified on command line (HeapBaseMinAddress). And even that does not guarantee matching. > If parameters are not the same AOT code will be ignored. > But AOT tests incorrectly assume that configuration will be the same. > > For short fix I am suggesting to switch off compressed oops for few AOT test which could be affected by this issue. The test do not needed COOPs for what they are testing. > > Thanks, > Vladimir > From vladimir.kozlov at oracle.com Tue Dec 13 04:44:20 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 12 Dec 2016 20:44:20 -0800 Subject: [9] RFR(S) 8171134: Unexpected output in compiler/aot/SharedUsageTest.java In-Reply-To: <5D2B77B1-F956-4159-AACE-DF291E38E414@oracle.com> References: <5D2B77B1-F956-4159-AACE-DF291E38E414@oracle.com> Message-ID: Thank you, Igor Vladimir On 12/12/16 8:40 PM, Igor Veresov wrote: > Looks good. > > igor > >> On Dec 12, 2016, at 8:35 PM, Vladimir Kozlov wrote: >> >> https://bugs.openjdk.java.net/browse/JDK-8171134 >> >> http://cr.openjdk.java.net/~kvn/8171134/webrev/ >> >> AOT requires to have the same compressed oops settings when AOT code is compiled and when it is executed because oop shift values are embedded into decoding instructions. >> To have the the same heap size and heap base address should be the same. Unfortunately it is not always the same when nothing is specified on command line (HeapBaseMinAddress). And even that does not guarantee matching. >> If parameters are not the same AOT code will be ignored. >> But AOT tests incorrectly assume that configuration will be the same. >> >> For short fix I am suggesting to switch off compressed oops for few AOT test which could be affected by this issue. The test do not needed COOPs for what they are testing. >> >> Thanks, >> Vladimir >> > From vladimir.kozlov at oracle.com Tue Dec 13 05:04:34 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 12 Dec 2016 21:04:34 -0800 Subject: [9] RFR(S) 8171137: Avoid warning: -Xint is not compatible with AOT (switching AOT off) Message-ID: <9223f469-66b0-a167-d65e-6cd2112d44dd@oracle.com> https://bugs.openjdk.java.net/browse/JDK-8171137 http://cr.openjdk.java.net/~kvn/8171137/webrev/ Put all AOT warnings under PrintAOT flag. Thanks, Vladimir From david.holmes at oracle.com Tue Dec 13 05:15:26 2016 From: david.holmes at oracle.com (David Holmes) Date: Tue, 13 Dec 2016 15:15:26 +1000 Subject: [9] RFR(S) 8171137: Avoid warning: -Xint is not compatible with AOT (switching AOT off) In-Reply-To: <9223f469-66b0-a167-d65e-6cd2112d44dd@oracle.com> References: <9223f469-66b0-a167-d65e-6cd2112d44dd@oracle.com> Message-ID: Hi Vladimir, > https://bugs.openjdk.java.net/browse/JDK-8171137 > > http://cr.openjdk.java.net/~kvn/8171137/webrev/ > > Put all AOT warnings under PrintAOT flag. That fixes the immediate problem - thanks. Not sure the -Xint case really warrants a warning unless someone deliberately tries to turn AOT on. But that's your call. Thanks, David > Thanks, > Vladimir From vladimir.kozlov at oracle.com Tue Dec 13 05:20:56 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 12 Dec 2016 21:20:56 -0800 Subject: [9] RFR(S) 8171137: Avoid warning: -Xint is not compatible with AOT (switching AOT off) In-Reply-To: References: <9223f469-66b0-a167-d65e-6cd2112d44dd@oracle.com> Message-ID: Thank you, David. Vladimir On 12/12/16 9:15 PM, David Holmes wrote: > Hi Vladimir, > >> https://bugs.openjdk.java.net/browse/JDK-8171137 >> >> http://cr.openjdk.java.net/~kvn/8171137/webrev/ >> >> Put all AOT warnings under PrintAOT flag. > > That fixes the immediate problem - thanks. > > Not sure the -Xint case really warrants a warning unless someone > deliberately tries to turn AOT on. But that's your call. > > Thanks, > David > >> Thanks, >> Vladimir > From igor.veresov at oracle.com Tue Dec 13 05:22:56 2016 From: igor.veresov at oracle.com (Igor Veresov) Date: Mon, 12 Dec 2016 21:22:56 -0800 Subject: [9] RFR(S) 8171137: Avoid warning: -Xint is not compatible with AOT (switching AOT off) In-Reply-To: <9223f469-66b0-a167-d65e-6cd2112d44dd@oracle.com> References: <9223f469-66b0-a167-d65e-6cd2112d44dd@oracle.com> Message-ID: Looks good. igor > On Dec 12, 2016, at 9:04 PM, Vladimir Kozlov wrote: > > https://bugs.openjdk.java.net/browse/JDK-8171137 > > http://cr.openjdk.java.net/~kvn/8171137/webrev/ > > Put all AOT warnings under PrintAOT flag. > > Thanks, > Vladimir From vladimir.kozlov at oracle.com Tue Dec 13 05:55:35 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 12 Dec 2016 21:55:35 -0800 Subject: [9] RFR(S) 8171137: Avoid warning: -Xint is not compatible with AOT (switching AOT off) In-Reply-To: References: <9223f469-66b0-a167-d65e-6cd2112d44dd@oracle.com> Message-ID: <6c2c07f0-3166-341c-bc07-1aa6b6b48857@oracle.com> Thank you, Igor Vladimir On 12/12/16 9:22 PM, Igor Veresov wrote: > Looks good. > > igor > >> On Dec 12, 2016, at 9:04 PM, Vladimir Kozlov wrote: >> >> https://bugs.openjdk.java.net/browse/JDK-8171137 >> >> http://cr.openjdk.java.net/~kvn/8171137/webrev/ >> >> Put all AOT warnings under PrintAOT flag. >> >> Thanks, >> Vladimir > From rwestrel at redhat.com Tue Dec 13 09:21:06 2016 From: rwestrel at redhat.com (Roland Westrelin) Date: Tue, 13 Dec 2016 10:21:06 +0100 Subject: RFR(S): 8162338: AArch64: Intrinsify fused mac operations In-Reply-To: <72ebde65-c0b3-9ec7-3f68-71044f29ef4f@oracle.com> References: <326e7e90-ba04-9b94-6f85-8d8d292e36ad@oracle.com> <7466bbbc-3de1-0a64-aa56-d24a5067ac86@oracle.com> <72ebde65-c0b3-9ec7-3f68-71044f29ef4f@oracle.com> Message-ID: > Good. Let me push since we need to run test on all platforms. Thanks for your help with this. Roland. From rwestrel at redhat.com Tue Dec 13 09:21:30 2016 From: rwestrel at redhat.com (Roland Westrelin) Date: Tue, 13 Dec 2016 10:21:30 +0100 Subject: RFR(XS): 8171092: C1's Math.fma() intrinsic doesn't correctly process its inputs In-Reply-To: <9125d709-9926-9884-0808-91e2ae900115@oracle.com> References: <9125d709-9926-9884-0808-91e2ae900115@oracle.com> Message-ID: > Looks good. When jdk9/hs is open for pushes I will sponsor it. Thanks! Roland. From goetz.lindenmaier at sap.com Tue Dec 13 09:49:19 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 13 Dec 2016 09:49:19 +0000 Subject: RFR(M): 8170991: PPC64: Bad code for initialization of short arrays In-Reply-To: <269fac2e594645ca896be5f76d57ecd1@dewdfe13de06.global.corp.sap> References: <9ae526c6aa204060905bf247fc2aa783@DEROTE13DE08.global.corp.sap> <269fac2e594645ca896be5f76d57ecd1@dewdfe13de06.global.corp.sap> Message-ID: <05ca2a9a2f114887a4b64f3f89671781@DEROTE13DE08.global.corp.sap> HI Martin, Looks, good, thanks! Best regards, Goetz. > -----Original Message----- > From: Doerr, Martin > Sent: Montag, 12. Dezember 2016 20:00 > To: Lindenmaier, Goetz ; 'hotspot-compiler- > dev at openjdk.java.net' ; Gustavo > Serra Scalet > Subject: RE: RFR(M): 8170991: PPC64: Bad code for initialization of short arrays > > Hi G?tz and Gustavo, > > thank you very much for reviewing and for testing. > As using a lower value for InitArrayShortSize didn't improve Gustavo's test > cases, I agree with G?tz that this part of the change should better not be done. > I was only able to observe shorter code in some test cases which don't seem to > be important. > > I have removed the match rule for very short arrays again and set > InitArrayShortSize to match C1's implementation (2x unrolled loop is shorter > with more than 9 HeapWords): > http://cr.openjdk.java.net/~mdoerr/8170991_PPC64_ClearArray/webrev.01/ > > Please review. > > Thanks and best regards, > Martin > > > -----Original Message----- > From: Lindenmaier, Goetz > Sent: Montag, 12. Dezember 2016 12:54 > To: Doerr, Martin ; 'hotspot-compiler- > dev at openjdk.java.net' ; Gustavo > Serra Scalet > Subject: RE: RFR(M): 8170991: PPC64: Bad code for initialization of short arrays > > Hi Martin, > > I had a look at your change. I like you cleaned up the C1 implementation, > moving the various cases to the macro assembler and reusing it. > I'm also fine with matching for constant array sizes. > > I'm not sure whether reducing InitArrayShortSize helps. > It sure removes the simple-to-spot pattern of loading 0 too often into registers. > This only happened if register allocation ran out of registers and > rematerialized. And as we saw, where the 0 was rematerialized, the register > pressure was not that high, sufficient registers to hold 0 were available :). This > is just an artefact of register allocation. I would assume the processor > internally handles this efficiently. Loading 0 into a register should be one of the > cheapest operations altogether! > If you only look at the places where rematerialization happened, you miss other > benefits in the places where there is no rematerialization necessary. > So you optimize for the few cases with rematerialization, paying the cost in the > many places without rematerialization. > E.g., if 0 is used in some other places in the same code, it's there anyways. > > So I'm not sure it helps with performance, but if you don't spot regressions I'm > fine with the change to InitArrayShortSize, too. > > Best regards, > Goetz. > > > > > > -----Original Message----- > > From: hotspot-compiler-dev [mailto:hotspot-compiler-dev- > > bounces at openjdk.java.net] On Behalf Of Doerr, Martin > > Sent: Freitag, 9. Dezember 2016 18:01 > > To: 'hotspot-compiler-dev at openjdk.java.net' > dev at openjdk.java.net>; Gustavo Serra Scalet > > > > Subject: RFR(M): 8170991: PPC64: Bad code for initialization of short > > arrays > > > > Hello everybody, > > > > > > > > the new flag "InitArrayShortSize" was set to 8 on PPC64. However, this > > leads to bad code. PPC64's C2 compiler currently does not have > > dedicated match rules to store 0. > > > > Unfortunately, loading of the constant 0 got rematerialized many times > > in some cases consuming more registers and code space than needed. > > > > > > > > An attempt to improve initialization was > > > > 8170094: PPC64: Keep immediate value 0 cached into a register to > > improve performance > > > > but this approach has disadvantages and we had decided against it. > > > > > > > > It is possibly to implement special ClearArray nodes to improve the > > initialization of arrays only: > > > > http://cr.openjdk.java.net/~mdoerr/8170991_PPC64_ClearArray/webrev.00/ > > > > > > > > Please review. > > > > > > > > @Gustavo: Maybe this improves your test cases, too? > > > > > > > > Best regards, > > > > Martin > > > > From goetz.lindenmaier at sap.com Tue Dec 13 16:24:37 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 13 Dec 2016 16:24:37 +0000 Subject: RFR(M): 8169373: Work around linux NPTL stack guard error. In-Reply-To: <462496af-d1b2-2c1f-f869-a98dc48120fb@oracle.com> References: <4dfa4ae6-4fa6-994c-f2cf-8fc309d8c520@oracle.com> <821371d77c7c4e6d966901b461b3d6a1@DEROTE13DE08.global.corp.sap> <49acd657-aefa-b935-1b2c-195fc2d125ba@oracle.com> <04825132c7fd4f92a06057cecc3f9329@DEROTE13DE08.global.corp.sap> <4abd1e03-27a2-4778-d1b0-09a952ccb525@oracle.com> <1111dc02-5d8f-3b50-b5f3-160c33474ace@oracle.com> <6ded66cf-558e-f6ce-7dff-7441992eb2ea@oracle.com> <371058eb-4e55-3ebd-6ce3-848628f96764@oracle.com> <8377024f345c46009b33a1f0db9deb9f@DEROTE13DE08.global.corp.sap> <462496af-d1b2-2c1f-f869-a98dc48120fb@oracle.com> Message-ID: <9dd3c7f1e021445e8fd0abfaf552d8d7@DEROTE13DE08.global.corp.sap> Hi, I rebased 8169373 to the recent changes in hotspot: http://cr.openjdk.java.net/~goetz/wr16/8169373-ppc-stackFix/webrev.09/ The patch is still in our test patch queue for the nightly tests, and there were no failures I can attribute to this change. Best regards, Goetz. > -----Original Message----- > From: Daniel D. Daugherty [mailto:daniel.daugherty at oracle.com] > Sent: Montag, 5. Dezember 2016 23:13 > To: Lindenmaier, Goetz ; David Holmes > ; Vladimir Kozlov ; > hotspot-compiler-dev at openjdk.java.net; 'hotspot-runtime- > dev at openjdk.java.net' > Subject: Re: RFR(M): 8169373: Work around linux NPTL stack guard error. > > On 12/5/16 3:09 PM, Lindenmaier, Goetz wrote: > > Hi Dan, > > > > thanks for the testing! Sorry I can't help ... > > No worries. We'll get there... > > JPRT passed with the appropriate closed changes... Thanks to David H. for > suggesting the changes to make. I've got an internal review thread going > on that. I also kicked off a "full RBT" run which is the equivalent of a > nightly test run. > > Dan > > > > > > Best regards, > > Goetz. > > > >> -----Original Message----- > >> From: Daniel D. Daugherty [mailto:daniel.daugherty at oracle.com] > >> Sent: Monday, December 05, 2016 7:38 PM > >> To: David Holmes ; Lindenmaier, Goetz > >> ; Vladimir Kozlov > >> ; hotspot-compiler-dev at openjdk.java.net; > >> 'hotspot-runtime-dev at openjdk.java.net' >> 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_.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 ; Lindenmaier, Goetz > >>>>>> ; David Holmes > >> ; > >>>>>> hotspot-compiler-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 > >>>>>>>>>>> ; hotspot-compiler- > >>>>>> dev at openjdk.java.net; > >>>>>>>>>>> 'hotspot-runtime-dev at openjdk.java.net' >>>>>>>>>>> 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 ; > >>>>>>>>>>>>>> hotspot-compiler- > >>>>>>>>>>>>>> dev at openjdk.java.net; 'hotspot-runtime- > >> dev at openjdk.java.net' > >>>>>>>>>>>>>> >>>>>>>>>>>>>> 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 ; > >>>>>> hotspot- > >>>>>>>>>>> compiler- > >>>>>>>>>>>>>>>> dev at openjdk.java.net; 'hotspot-runtime- > >>>>>> dev at openjdk.java.net' > >>>>>>>>>>> >>>>>>>>>>>>>>>> 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 ; > >>>>>>>>>>>>>>>>>> 'daniel.daugherty at oracle.com' > >>>>>> ; > >>>>>>>>>>>>>> 'hotspot- > >>>>>>>>>>>>>>>>>> runtime-dev at openjdk.java.net' >>>>>>>>>>> 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 ; > >>>>>>>>>>>>>>>>>>>> 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 > >> ; > >>>>>>>>>>>>>>>>>>>>> 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 > >> ; > >>>>>> David > >>>>>>>>>>>>>> Holmes > >>>>>>>>>>>>>>>>>>>>>>> ; 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 ; > >>>>>>>>>>>>>>>>>>>>>>>>> Lindenmaier, > >>>>>>>>>>>>>> Goetz > >>>>>>>>>>>>>>>>>>>>>>>>> ; 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 > >>>>>> ; > >>>>>>>>>>>>>> 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: > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>> > >>>>>>> > >>> From vladimir.kozlov at oracle.com Wed Dec 14 01:22:20 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 13 Dec 2016 17:22:20 -0800 Subject: [9] RFR(S) 8171187: Expected compilation level after compilation to be no less than 1 Message-ID: <58509ECC.4000102@oracle.com> http://cr.openjdk.java.net/~kvn/8171187/webrev/ https://bugs.openjdk.java.net/browse/JDK-8171187 compiler/aot/RecompilationTest.java fails with java.lang.RuntimeException: METHOD_TEST: expected compilation level after compilation to be no less than 1 for METHOD_TEST: expected -1 >= 1 The AOT method SimpleTestCaseHelper.method() is not recompiled sometimes. The main cause is that this method is very trivial ( int method() { return 42; } ) and it is inlined into other AOT methods which are executed during run. An other cause it profiling event is triggered using 'rdtsc; test $0xff,%eax;' instructions. Which may not jump during 256 invocations. These changes only fix inlining issue by adding -XX:CompileCommand=dontinline flag to AOT compilation commands. I added missing -UseCompressedOops flags which I did not add in JDK-8171134 fix. I added suffix to AOT libraries names to keep both in case of debugging. And I replaced -XX:CompileCommand=dontinline,*.* with -XX:-Inline for java execution commands. I verified that test methods are not inlined during recompilation. Thanks, Vladimir From igor.veresov at oracle.com Wed Dec 14 01:52:08 2016 From: igor.veresov at oracle.com (Igor Veresov) Date: Tue, 13 Dec 2016 17:52:08 -0800 Subject: [9] RFR(S) 8171187: Expected compilation level after compilation to be no less than 1 In-Reply-To: <58509ECC.4000102@oracle.com> References: <58509ECC.4000102@oracle.com> Message-ID: Looks good. igor > On Dec 13, 2016, at 5:22 PM, Vladimir Kozlov wrote: > > http://cr.openjdk.java.net/~kvn/8171187/webrev/ > https://bugs.openjdk.java.net/browse/JDK-8171187 > > compiler/aot/RecompilationTest.java fails with > > java.lang.RuntimeException: METHOD_TEST: expected compilation level after compilation to be no less than 1 for METHOD_TEST: expected -1 >= 1 > > The AOT method SimpleTestCaseHelper.method() is not recompiled sometimes. > > The main cause is that this method is very trivial ( int method() { return 42; } ) > and it is inlined into other AOT methods which are executed during run. > > An other cause it profiling event is triggered using 'rdtsc; test $0xff,%eax;' instructions. Which may not jump during 256 invocations. > > These changes only fix inlining issue by adding -XX:CompileCommand=dontinline flag to AOT compilation commands. > > I added missing -UseCompressedOops flags which I did not add in JDK-8171134 fix. > I added suffix to AOT libraries names to keep both in case of debugging. > And I replaced -XX:CompileCommand=dontinline,*.* with -XX:-Inline for java execution commands. I verified that test methods are not inlined during recompilation. > > Thanks, > Vladimir From vladimir.kozlov at oracle.com Wed Dec 14 01:56:53 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 13 Dec 2016 17:56:53 -0800 Subject: [9] RFR(S) 8171187: Expected compilation level after compilation to be no less than 1 In-Reply-To: References: <58509ECC.4000102@oracle.com> Message-ID: <5850A6E5.4010804@oracle.com> Thank you, Igor Vladimir On 12/13/16 5:52 PM, Igor Veresov wrote: > Looks good. > > igor > >> On Dec 13, 2016, at 5:22 PM, Vladimir Kozlov wrote: >> >> http://cr.openjdk.java.net/~kvn/8171187/webrev/ >> https://bugs.openjdk.java.net/browse/JDK-8171187 >> >> compiler/aot/RecompilationTest.java fails with >> >> java.lang.RuntimeException: METHOD_TEST: expected compilation level after compilation to be no less than 1 for METHOD_TEST: expected -1 >= 1 >> >> The AOT method SimpleTestCaseHelper.method() is not recompiled sometimes. >> >> The main cause is that this method is very trivial ( int method() { return 42; } ) >> and it is inlined into other AOT methods which are executed during run. >> >> An other cause it profiling event is triggered using 'rdtsc; test $0xff,%eax;' instructions. Which may not jump during 256 invocations. >> >> These changes only fix inlining issue by adding -XX:CompileCommand=dontinline flag to AOT compilation commands. >> >> I added missing -UseCompressedOops flags which I did not add in JDK-8171134 fix. >> I added suffix to AOT libraries names to keep both in case of debugging. >> And I replaced -XX:CompileCommand=dontinline,*.* with -XX:-Inline for java execution commands. I verified that test methods are not inlined during recompilation. >> >> Thanks, >> Vladimir > From martin.doerr at sap.com Wed Dec 14 16:59:24 2016 From: martin.doerr at sap.com (Doerr, Martin) Date: Wed, 14 Dec 2016 16:59:24 +0000 Subject: RFR(M): 8171244: PPC64: Make interpreter's math entries consistent with C1 and C2 and support FMA Message-ID: Hi, as discussed in [1], floating point computations should produce consistent results regardless of whether the Java code gets interpreted or is compiled by any JIT-compiler. In addition, JDK9 introduced new floating point multiply-accumulate intrinsics which are currently missing on PPC64. Webrev is here: http://cr.openjdk.java.net/~mdoerr/8171244_PPC64_fma/webrev.00/ Note: The current version of the change removes the function "math_entry_available" from shared code which was only used by PPC. I can either leave it there or ask somebody from Oracle to sponsor. Please review. Best regards, Martin [1] http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2016-December/025073.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladimir.kozlov at oracle.com Wed Dec 14 18:05:13 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 14 Dec 2016 10:05:13 -0800 Subject: RFR(M): 8171244: PPC64: Make interpreter's math entries consistent with C1 and C2 and support FMA In-Reply-To: References: Message-ID: Thank you, Martin Looks good to me but someone familiar with ppc64 have to review it too. I am fine with changes in abstractInterpreter.hpp. I will sponsor it since it need to go through JPRT. Thanks, Vladimir On 12/14/16 8:59 AM, Doerr, Martin wrote: > Hi, > > > > as discussed in [1], floating point computations should produce consistent results regardless of whether the Java code > gets interpreted or is compiled by any JIT-compiler. > > In addition, JDK9 introduced new floating point multiply-accumulate intrinsics which are currently missing on PPC64. > > > > Webrev is here: > > http://cr.openjdk.java.net/~mdoerr/8171244_PPC64_fma/webrev.00/ > > > > Note: The current version of the change removes the function ?math_entry_available? from shared code which was only used > by PPC. > > I can either leave it there or ask somebody from Oracle to sponsor. > > > > Please review. > > > > Best regards, > > Martin > > > > > > [1] http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2016-December/025073.html > > > From kavitha.natarajan at linaro.org Thu Dec 15 09:55:42 2016 From: kavitha.natarajan at linaro.org (Kavitha Natarajan) Date: Thu, 15 Dec 2016 15:25:42 +0530 Subject: RFR: JDK-8169177 Aarch64: SIGSEGV when "-XX:+ZeroTLAB" is specified along with GC options Message-ID: Hi, I am re-posting the review request on hotspot-dev which I had missed earlier. The below bug fix was already posted in aarch64-port-dev and hotspot-compiler-dev mailing lists. The following are the jtreg test cases that fail with SIGSEGV on aarch64 when "-XX:+ZeroTLAB" is specified along with a GC option: hotspot/test/compiler/stringopts/TestStringObjectInitialization.java hotspot/test/gc/TestSystemGC.java hotspot/test/gc/arguments/TestAlignmentToUseLargePages.java hotspot/test/gc/cms/TestBubbleUpRef.java hotspot/test/gc/metaspace/TestMetaspacePerfCounters.java hotspot/test/gc/parallel/TestDynShrinkHeap.java hotspot/test/gc/stress/TestGCOld.java Bug fix for JDK-8086053 (Address inconsistencies regarding ZeroTLAB) fixes similar issue on x86 and sparc. This fix has been ported to aarch64 and the above test cases now pass on aarch64 as well. Below is the webrev for the aarch64 changes: http://people.linaro.org/~kavitha.natarajan/8169177/webrev.00/ Derek White and Andrew Haley had done the review and suggested to use zero_memory() only in C1 and zero_words() in C2. However, zero_words itself need to be enhanced before its been used. So currenly zero_memory() is only used for both C1 and C2. A separate enhancement request has been raised for zero_words(). https://bugs.openjdk.java.net/browse/JDK-8171237 Please review and approve. Thanks, Kavitha -------------- next part -------------- An HTML attachment was scrubbed... URL: From aph at redhat.com Thu Dec 15 10:04:08 2016 From: aph at redhat.com (Andrew Haley) Date: Thu, 15 Dec 2016 10:04:08 +0000 Subject: RFR: JDK-8169177 Aarch64: SIGSEGV when "-XX:+ZeroTLAB" is specified along with GC options In-Reply-To: References: Message-ID: On 15/12/16 09:55, Kavitha Natarajan wrote: > Below is the webrev for the aarch64 changes: > > http://people.linaro.org/~kavitha.natarajan/8169177/webrev.00/ This is OK. Andrew. From david.holmes at oracle.com Thu Dec 15 10:26:49 2016 From: david.holmes at oracle.com (David Holmes) Date: Thu, 15 Dec 2016 20:26:49 +1000 Subject: RFR: JDK-8169177 Aarch64: SIGSEGV when "-XX:+ZeroTLAB" is specified along with GC options In-Reply-To: References: Message-ID: Hi Kavitha, Please note that is a requirement that all contributions be hosted on openjdk systems (cr.openjdk.java.net) or else included in-line with openjdk email. They can not be taken directly from external systems like people.linaro.org. Thanks, David On 15/12/2016 7:55 PM, Kavitha Natarajan wrote: > Hi, > > I am re-posting the review request on hotspot-dev which I had missed > earlier. > > The below bug fix was already posted in aarch64-port-dev and > hotspot-compiler-dev mailing lists. > > The following are the jtreg test cases that fail with SIGSEGV on aarch64 > when "-XX:+ZeroTLAB" is specified along with a GC option: > > hotspot/test/compiler/stringopts/TestStringObjectInitialization.java > hotspot/test/gc/TestSystemGC.java > hotspot/test/gc/arguments/TestAlignmentToUseLargePages.java > hotspot/test/gc/cms/TestBubbleUpRef.java > hotspot/test/gc/metaspace/TestMetaspacePerfCounters.java > hotspot/test/gc/parallel/TestDynShrinkHeap.java > hotspot/test/gc/stress/TestGCOld.java > > Bug fix for JDK-8086053 > (Address > inconsistencies regarding ZeroTLAB) fixes similar issue on x86 and sparc. > This fix has been ported to aarch64 and the above test cases now pass on > aarch64 as well. > > Below is the webrev for the aarch64 changes: > > http://people.linaro.org/~kavitha.natarajan/8169177/webrev.00/ > > Derek White and Andrew Haley had done the review and suggested to use > zero_memory() only in C1 and zero_words() in C2. However, zero_words itself > need to be enhanced before its been used. So currenly zero_memory() is only > used for both C1 and C2. > > A separate enhancement request has been raised for zero_words(). > > https://bugs.openjdk.java.net/browse/JDK-8171237 > > Please review and approve. > > Thanks, > Kavitha > From goetz.lindenmaier at sap.com Thu Dec 15 10:59:55 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 15 Dec 2016 10:59:55 +0000 Subject: RFR(M): 8171244: PPC64: Make interpreter's math entries consistent with C1 and C2 and support FMA In-Reply-To: References: Message-ID: Hi Martin, thanks for doing this change. I looked a while at the change in the ad file: Would it make sense to add match rules with outermost Neg? // -src1 * src2 - src3 = -(src1*src2+src3) instruct mnaddF_reg_reg(regF dst, regF src1, regF src2, regF src3) %{ predicate(UseFMA); match(Set dst (FmaF (NegF src3) (Binary (NegF src1) src2))); match(Set dst (FmaF (NegF src3) (Binary src1 (NegF src2)))); + match(Set dst Neg(FmaF src3 (Binary src1 src2))); Besides that the change looks good. Please run it through our nightly tests. Maybe you could use $reg$$FloatRegister as in the other rules. Best regards, Goetz. > -----Original Message----- > From: hotspot-compiler-dev [mailto:hotspot-compiler-dev- > bounces at openjdk.java.net] On Behalf Of Doerr, Martin > Sent: Mittwoch, 14. Dezember 2016 17:59 > To: 'hotspot-compiler-dev at openjdk.java.net' dev at openjdk.java.net> > Subject: RFR(M): 8171244: PPC64: Make interpreter's math entries consistent > with C1 and C2 and support FMA > > Hi, > > > > as discussed in [1], floating point computations should produce consistent > results regardless of whether the Java code gets interpreted or is compiled by > any JIT-compiler. > > In addition, JDK9 introduced new floating point multiply-accumulate intrinsics > which are currently missing on PPC64. > > > > Webrev is here: > > http://cr.openjdk.java.net/~mdoerr/8171244_PPC64_fma/webrev.00/ > > > > > Note: The current version of the change removes the function > "math_entry_available" from shared code which was only used by PPC. > > I can either leave it there or ask somebody from Oracle to sponsor. > > > > Please review. > > > > Best regards, > > Martin > > > > > > [1] http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2016- > December/025073.html compiler-dev/2016-December/025073.html> > > From martin.doerr at sap.com Thu Dec 15 15:32:03 2016 From: martin.doerr at sap.com (Doerr, Martin) Date: Thu, 15 Dec 2016 15:32:03 +0000 Subject: RFR(M): 8171244: PPC64: Make interpreter's math entries consistent with C1 and C2 and support FMA In-Reply-To: References: Message-ID: <0abeddf7f58a48f1b97daa65efb3b8af@dewdfe13de06.global.corp.sap> Hi, thank you very much for reviewing. I have added reviewer information and made minor changes. The as_FloatRegister usages are replaced, now. I have also removed the predicate(UseFMA). They don't make any sense because the matcher doesn't have a choice. The decision whether they should be used is done before, of course. New webrev is here: http://cr.openjdk.java.net/~mdoerr/8171244_PPC64_fma/webrev.01/ I have also tried the match rules proposed by G?tz, but they didn't match. Reason seems to be that the Fma nodes have a control input. Vladimir, you can push it if you're ok with it. Thank you very much for sponsoring. Best regards, Martin -----Original Message----- From: Lindenmaier, Goetz Sent: Donnerstag, 15. Dezember 2016 12:00 To: Doerr, Martin ; 'hotspot-compiler-dev at openjdk.java.net' Subject: RE: RFR(M): 8171244: PPC64: Make interpreter's math entries consistent with C1 and C2 and support FMA Hi Martin, thanks for doing this change. I looked a while at the change in the ad file: Would it make sense to add match rules with outermost Neg? // -src1 * src2 - src3 = -(src1*src2+src3) instruct mnaddF_reg_reg(regF dst, regF src1, regF src2, regF src3) %{ predicate(UseFMA); match(Set dst (FmaF (NegF src3) (Binary (NegF src1) src2))); match(Set dst (FmaF (NegF src3) (Binary src1 (NegF src2)))); + match(Set dst Neg(FmaF src3 (Binary src1 src2))); Besides that the change looks good. Please run it through our nightly tests. Maybe you could use $reg$$FloatRegister as in the other rules. Best regards, Goetz. > -----Original Message----- > From: hotspot-compiler-dev [mailto:hotspot-compiler-dev- > bounces at openjdk.java.net] On Behalf Of Doerr, Martin > Sent: Mittwoch, 14. Dezember 2016 17:59 > To: 'hotspot-compiler-dev at openjdk.java.net' dev at openjdk.java.net> > Subject: RFR(M): 8171244: PPC64: Make interpreter's math entries > consistent with C1 and C2 and support FMA > > Hi, > > > > as discussed in [1], floating point computations should produce > consistent results regardless of whether the Java code gets > interpreted or is compiled by any JIT-compiler. > > In addition, JDK9 introduced new floating point multiply-accumulate > intrinsics which are currently missing on PPC64. > > > > Webrev is here: > > http://cr.openjdk.java.net/~mdoerr/8171244_PPC64_fma/webrev.00/ > > > > > Note: The current version of the change removes the function > "math_entry_available" from shared code which was only used by PPC. > > I can either leave it there or ask somebody from Oracle to sponsor. > > > > Please review. > > > > Best regards, > > Martin > > > > > > [1] http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2016- > December/025073.html compiler-dev/2016-December/025073.html> > > From goetz.lindenmaier at sap.com Thu Dec 15 15:33:43 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 15 Dec 2016 15:33:43 +0000 Subject: RFR(M): 8171244: PPC64: Make interpreter's math entries consistent with C1 and C2 and support FMA In-Reply-To: <0abeddf7f58a48f1b97daa65efb3b8af@dewdfe13de06.global.corp.sap> References: <0abeddf7f58a48f1b97daa65efb3b8af@dewdfe13de06.global.corp.sap> Message-ID: <59953fa2af154c388beb554867a06355@DEROTE13DE08.global.corp.sap> Hi Martin, thanks for investigation the other rule. All fine. Best regards, Goetz. > -----Original Message----- > From: Doerr, Martin > Sent: Donnerstag, 15. Dezember 2016 16:32 > To: Lindenmaier, Goetz ; 'hotspot-compiler- > dev at openjdk.java.net' > Subject: RE: RFR(M): 8171244: PPC64: Make interpreter's math entries > consistent with C1 and C2 and support FMA > > Hi, > > thank you very much for reviewing. > > I have added reviewer information and made minor changes. > The as_FloatRegister usages are replaced, now. > I have also removed the predicate(UseFMA). They don't make any sense > because the matcher doesn't have a choice. > The decision whether they should be used is done before, of course. > > New webrev is here: > http://cr.openjdk.java.net/~mdoerr/8171244_PPC64_fma/webrev.01/ > > I have also tried the match rules proposed by G?tz, but they didn't match. > Reason seems to be that the Fma nodes have a control input. > > Vladimir, you can push it if you're ok with it. Thank you very much for > sponsoring. > > Best regards, > Martin > > > -----Original Message----- > From: Lindenmaier, Goetz > Sent: Donnerstag, 15. Dezember 2016 12:00 > To: Doerr, Martin ; 'hotspot-compiler- > dev at openjdk.java.net' > Subject: RE: RFR(M): 8171244: PPC64: Make interpreter's math entries > consistent with C1 and C2 and support FMA > > Hi Martin, > > thanks for doing this change. > > I looked a while at the change in the ad file: > Would it make sense to add match rules with outermost Neg? > > // -src1 * src2 - src3 = -(src1*src2+src3) instruct mnaddF_reg_reg(regF dst, > regF src1, regF src2, regF src3) %{ > predicate(UseFMA); > match(Set dst (FmaF (NegF src3) (Binary (NegF src1) src2))); > match(Set dst (FmaF (NegF src3) (Binary src1 (NegF src2)))); > + match(Set dst Neg(FmaF src3 (Binary src1 src2))); > > Besides that the change looks good. Please run it through our nightly tests. > Maybe you could use $reg$$FloatRegister as in the other rules. > > Best regards, > Goetz. > > > -----Original Message----- > > From: hotspot-compiler-dev [mailto:hotspot-compiler-dev- > > bounces at openjdk.java.net] On Behalf Of Doerr, Martin > > Sent: Mittwoch, 14. Dezember 2016 17:59 > > To: 'hotspot-compiler-dev at openjdk.java.net' > dev at openjdk.java.net> > > Subject: RFR(M): 8171244: PPC64: Make interpreter's math entries > > consistent with C1 and C2 and support FMA > > > > Hi, > > > > > > > > as discussed in [1], floating point computations should produce > > consistent results regardless of whether the Java code gets > > interpreted or is compiled by any JIT-compiler. > > > > In addition, JDK9 introduced new floating point multiply-accumulate > > intrinsics which are currently missing on PPC64. > > > > > > > > Webrev is here: > > > > http://cr.openjdk.java.net/~mdoerr/8171244_PPC64_fma/webrev.00/ > > > > > > > > > > Note: The current version of the change removes the function > > "math_entry_available" from shared code which was only used by PPC. > > > > I can either leave it there or ask somebody from Oracle to sponsor. > > > > > > > > Please review. > > > > > > > > Best regards, > > > > Martin > > > > > > > > > > > > [1] http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2016- > > December/025073.html > compiler-dev/2016-December/025073.html> > > > > From dmitrij.pochepko at oracle.com Thu Dec 15 17:24:51 2016 From: dmitrij.pochepko at oracle.com (Dmitrij Pochepko) Date: Thu, 15 Dec 2016 20:24:51 +0300 Subject: RFR(XS): 8170886 - compiler/ciReplay/TestSAServer.java intermittently throws NumberFormatException Message-ID: Hi, please review small fix for 8170886 - compiler/ciReplay/TestSAServer.java intermittently throws NumberFormatException Test has thrown NFE once, because of replay file parsing logic of this test couldn't handle case of inlining information present. Test expected 6th column to be last, which is true for non-inlining case only. This fix modifies logic to specifically get 6th column of compilation string instead of "last" column. webrev: http://cr.openjdk.java.net/~dpochepk/8170886/webrev.01/ CR: https://bugs.openjdk.java.net/browse/JDK-8170886 I've tested it on linux-x64. Thanks, Dmitrij From tobias.hartmann at oracle.com Thu Dec 15 17:35:26 2016 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Thu, 15 Dec 2016 18:35:26 +0100 Subject: RFR(XS): 8170886 - compiler/ciReplay/TestSAServer.java intermittently throws NumberFormatException In-Reply-To: References: Message-ID: <5852D45E.6080202@oracle.com> Hi Dmitrij, On 15.12.2016 18:24, Dmitrij Pochepko wrote: > Hi, > > please review small fix for 8170886 - compiler/ciReplay/TestSAServer.java intermittently throws NumberFormatException > > Test has thrown NFE once, because of replay file parsing logic of this test couldn't handle case of inlining information present. > > Test expected 6th column to be last, which is true for non-inlining case only. This fix modifies logic to specifically get 6th column of compilation string instead of "last" column. > > webrev: http://cr.openjdk.java.net/~dpochepk/8170886/webrev.01/ Looks good to me! Thanks, Tobias > > CR: https://bugs.openjdk.java.net/browse/JDK-8170886 > > I've tested it on linux-x64. > > Thanks, > > Dmitrij > From vladimir.kozlov at oracle.com Thu Dec 15 19:01:35 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 15 Dec 2016 11:01:35 -0800 Subject: [9] RFR(XS) 8171276: More problems in compiler/aot/RecompilationTest.java tests Message-ID: <5852E88F.80807@oracle.com> http://cr.openjdk.java.net/~kvn/8171276/webrev/ https://bugs.openjdk.java.net/browse/JDK-8171276 Kim Barrett pointed that he still see the problem after JDK-8171187 [1] is fixed: on exception 'STATIC_TEST: expected compilation level after compilation to be no less than 1 for STATIC_TEST: expected -1 >= 1': I should disable inlining of all methods SimpleTestCaseHelper. Verified with objdump of generated test's AOT libraries. Thanks, Vladimir [1] https://bugs.openjdk.java.net/browse/JDK-8171187 From igor.veresov at oracle.com Fri Dec 16 06:22:15 2016 From: igor.veresov at oracle.com (Igor Veresov) Date: Thu, 15 Dec 2016 22:22:15 -0800 Subject: [9] RFR(XS) 8171276: More problems in compiler/aot/RecompilationTest.java tests In-Reply-To: <5852E88F.80807@oracle.com> References: <5852E88F.80807@oracle.com> Message-ID: <21377C0C-3641-4120-B87E-849E8D1CB492@oracle.com> Seems fine. igor > On Dec 15, 2016, at 11:01 AM, Vladimir Kozlov wrote: > > http://cr.openjdk.java.net/~kvn/8171276/webrev/ > https://bugs.openjdk.java.net/browse/JDK-8171276 > > Kim Barrett pointed that he still see the problem after JDK-8171187 [1] is fixed: > > on exception 'STATIC_TEST: expected compilation level after compilation to be no less than 1 for STATIC_TEST: expected -1 >= 1': > > I should disable inlining of all methods SimpleTestCaseHelper. > Verified with objdump of generated test's AOT libraries. > > Thanks, > Vladimir > > [1] https://bugs.openjdk.java.net/browse/JDK-8171187 From kavitha.natarajan at linaro.org Fri Dec 16 10:28:15 2016 From: kavitha.natarajan at linaro.org (Kavitha Natarajan) Date: Fri, 16 Dec 2016 15:58:15 +0530 Subject: RFR: JDK-8169177 Aarch64: SIGSEGV when "-XX:+ZeroTLAB" is specified along with GC options In-Reply-To: References: Message-ID: Thanks Andrew. Regards, Kavitha On 15 December 2016 at 15:34, Andrew Haley wrote: > On 15/12/16 09:55, Kavitha Natarajan wrote: > > Below is the webrev for the aarch64 changes: > > > > http://people.linaro.org/~kavitha.natarajan/8169177/webrev.00/ > > This is OK. > > Andrew. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From felix.yang at linaro.org Fri Dec 16 11:59:19 2016 From: felix.yang at linaro.org (Felix Yang) Date: Fri, 16 Dec 2016 19:59:19 +0800 Subject: RFR: JDK-8169177 Aarch64: SIGSEGV when "-XX:+ZeroTLAB" is specified along with GC options In-Reply-To: References: Message-ID: Hi, Thanks for fixing the bug. New webrev created on behalf of Kavitha: http://cr.openjdk.java.net/~fyang/8169177/webrev.01/ Tested again with JTreg hotspot, no regressions. OK to push? Thanks for your help, Felix On 16 December 2016 at 18:28, Kavitha Natarajan < kavitha.natarajan at linaro.org> wrote: > Thanks Andrew. > > Regards, > Kavitha > > On 15 December 2016 at 15:34, Andrew Haley wrote: > >> On 15/12/16 09:55, Kavitha Natarajan wrote: >> > Below is the webrev for the aarch64 changes: >> > >> > http://people.linaro.org/~kavitha.natarajan/8169177/webrev.00/ >> >> This is OK. >> >> Andrew. >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kavitha.natarajan at linaro.org Fri Dec 16 12:17:10 2016 From: kavitha.natarajan at linaro.org (Kavitha Natarajan) Date: Fri, 16 Dec 2016 17:47:10 +0530 Subject: RFR: JDK-8169177 Aarch64: SIGSEGV when "-XX:+ZeroTLAB" is specified along with GC options In-Reply-To: References: Message-ID: Thanks a lot Felix for creating the patch, as I do not have access to this system. Regards, Kavitha On 16 December 2016 at 17:29, Felix Yang wrote: > Hi, > > Thanks for fixing the bug. New webrev created on behalf of Kavitha: > http://cr.openjdk.java.net/~fyang/8169177/webrev.01/ > Tested again with JTreg hotspot, no regressions. OK to push? > > Thanks for your help, > Felix > > On 16 December 2016 at 18:28, Kavitha Natarajan < > kavitha.natarajan at linaro.org> wrote: > >> Thanks Andrew. >> >> Regards, >> Kavitha >> >> On 15 December 2016 at 15:34, Andrew Haley wrote: >> >>> On 15/12/16 09:55, Kavitha Natarajan wrote: >>> > Below is the webrev for the aarch64 changes: >>> > >>> > http://people.linaro.org/~kavitha.natarajan/8169177/webrev.00/ >>> >>> This is OK. >>> >>> Andrew. >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmitrij.pochepko at oracle.com Fri Dec 16 13:23:27 2016 From: dmitrij.pochepko at oracle.com (Dmitrij Pochepko) Date: Fri, 16 Dec 2016 16:23:27 +0300 Subject: RFR(XS): 8170886 - compiler/ciReplay/TestSAServer.java intermittently throws NumberFormatException In-Reply-To: <5852D45E.6080202@oracle.com> References: <5852D45E.6080202@oracle.com> Message-ID: <4d0fafd6-2d2f-02b4-1d0f-32871a55f462@oracle.com> Thank you! On 15.12.2016 20:35, Tobias Hartmann wrote: > Hi Dmitrij, > > On 15.12.2016 18:24, Dmitrij Pochepko wrote: >> Hi, >> >> please review small fix for 8170886 - compiler/ciReplay/TestSAServer.java intermittently throws NumberFormatException >> >> Test has thrown NFE once, because of replay file parsing logic of this test couldn't handle case of inlining information present. >> >> Test expected 6th column to be last, which is true for non-inlining case only. This fix modifies logic to specifically get 6th column of compilation string instead of "last" column. >> >> webrev: http://cr.openjdk.java.net/~dpochepk/8170886/webrev.01/ > Looks good to me! > > Thanks, > Tobias > >> CR: https://bugs.openjdk.java.net/browse/JDK-8170886 >> >> I've tested it on linux-x64. >> >> Thanks, >> >> Dmitrij >> From david.d.leopoldseder at oracle.com Fri Dec 16 13:44:37 2016 From: david.d.leopoldseder at oracle.com (David Leopoldseder) Date: Fri, 16 Dec 2016 14:44:37 +0100 Subject: RFR: 8166125: [JVMCI] Missing JVMCI flag default values In-Reply-To: <49305203-6D6F-4B5D-B5E6-9530A16E669F@twitter.com> References: <57a99e49-68ad-8e21-0736-8fda150bb7f4@oracle.com> <03D19E4E-8D70-4D43-A8EC-C4F5BD9505DF@twitter.com> <139FEE17-8C56-4E3F-A289-670D34A061D1@oracle.com> <49305203-6D6F-4B5D-B5E6-9530A16E669F@twitter.com> Message-ID: <39701ea3-c465-ae24-756d-1f686b5ef19a@oracle.com> Hi, Sorry for any delay caused by not pushing this change earlier. The RFR http://cr.openjdk.java.net/~davleopo/JDK-8166125/webrev.001/ has previously been reviewed already. We will push it now. - david Am 09/15/2016 um 08:40 PM schrieb Christian Thalinger: > Crazy :-) Well, better late than never. Looks good. > >> On Sep 15, 2016, at 8:38 AM, Doug Simon wrote: >> >> David noticed this while investigating some performance regressions that occurred around the time we switched from a separate JVMCI VM binary (i.e. COMPILERJVMCI) to -XX:+UseJVMCICompiler. >> >> -Doug >> >>> On 15 Sep 2016, at 20:34, Christian Thalinger wrote: >>> >>> Nobody noticed until now? >>> >>>> On Sep 15, 2016, at 4:10 AM, David Leopoldseder wrote: >>>> >>>> Hi, >>>> >>>> Please review this patch. >>>> >>>> Bug: >>>> During the initial commit for the JVMCI JEP some options JVMCI sets differently than c2 have been forgotten. >>>> Fix: >>>> Set the options if INCLUDE_JVMCI is true and -XX:+UseJVMCICompiler. >>>> >>>> http://cr.openjdk.java.net/~davleopo/JDK-8166125/webrev.001/ >>>> https://bugs.openjdk.java.net/browse/JDK-8166125 >>>> >>>> - david From martin.doerr at sap.com Sat Dec 17 10:18:16 2016 From: martin.doerr at sap.com (Doerr, Martin) Date: Sat, 17 Dec 2016 10:18:16 +0000 Subject: RFR(M): 8171398: s390x: Make interpreter's math entries consistent with C1 and C2 and support FMA Message-ID: <3d02956d0fa9481fa7a5d19c02c0b431@dewdfe13de06.global.corp.sap> Hi, I'd like to address the same issue as on PPC64 on s390x. As discussed in [1], floating point computations should produce consistent results regardless of whether the Java code gets interpreted or is compiled by any JIT-compiler. In addition, JDK9 introduced new floating point multiply-accumulate intrinsics which are currently missing on s390x. Webrev is here: http://cr.openjdk.java.net/~mdoerr/8171398_s390_FMA/webrev.00/ I have included a bugfix for parameter handling in an aes decrypt stub. Please review. Best regards, Martin [1] http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2016-December/025073.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From lutz.schmidt at sap.com Mon Dec 19 15:57:51 2016 From: lutz.schmidt at sap.com (Schmidt, Lutz) Date: Mon, 19 Dec 2016 15:57:51 +0000 Subject: RFR(M): 8171398: s390x: Make interpreter's math entries consistent with C1 and C2 and support FMA In-Reply-To: <3d02956d0fa9481fa7a5d19c02c0b431@dewdfe13de06.global.corp.sap> References: <3d02956d0fa9481fa7a5d19c02c0b431@dewdfe13de06.global.corp.sap> Message-ID: Hi Martin, your change looks good. I have one minor suggestions, though. - in s390.ad: please adapt comments in all "instruct msub*" to say "CC unchanged by MUL-SUB" Thanks, Lutz From: hotspot-compiler-dev > on behalf of "Doerr, Martin (martin.doerr at sap.com)" > Date: Samstag, 17. Dezember 2016 um 11:18 To: "'hotspot-compiler-dev at openjdk.java.net'" > Subject: RFR(M): 8171398: s390x: Make interpreter's math entries consistent with C1 and C2 and support FMA Hi, I'd like to address the same issue as on PPC64 on s390x. As discussed in [1], floating point computations should produce consistent results regardless of whether the Java code gets interpreted or is compiled by any JIT-compiler. In addition, JDK9 introduced new floating point multiply-accumulate intrinsics which are currently missing on s390x. Webrev is here: http://cr.openjdk.java.net/~mdoerr/8171398_s390_FMA/webrev.00/ I have included a bugfix for parameter handling in an aes decrypt stub. Please review. Best regards, Martin [1] http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2016-December/025073.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From igor.veresov at oracle.com Mon Dec 19 20:40:35 2016 From: igor.veresov at oracle.com (Igor Veresov) Date: Mon, 19 Dec 2016 12:40:35 -0800 Subject: RFR(XXS) 8171394: [AOT] failed AOT compilation in compiler/aot/RecompilationTest.java Message-ID: <2712C4DE-8AE9-46D5-A143-D66F5D38635F@oracle.com> This is tiny change to fix the types of the arguments to tiered callbacks. The same change is now being pushed to graal-core. JBS: https://bugs.openjdk.java.net/browse/JDK-8171394 Webrev: http://cr.openjdk.java.net/~iveresov/8171394/webrev.00/ igor -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladimir.kozlov at oracle.com Mon Dec 19 20:49:53 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 19 Dec 2016 12:49:53 -0800 Subject: RFR(XXS) 8171394: [AOT] failed AOT compilation in compiler/aot/RecompilationTest.java In-Reply-To: <2712C4DE-8AE9-46D5-A143-D66F5D38635F@oracle.com> References: <2712C4DE-8AE9-46D5-A143-D66F5D38635F@oracle.com> Message-ID: <6ae2fa2e-3f85-163c-f6b5-729f95765fd0@oracle.com> Looks good. Thanks, Vladimir On 12/19/16 12:40 PM, Igor Veresov wrote: > This is tiny change to fix the types of the arguments to tiered callbacks. > The same change is now being pushed to graal-core. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8171394 > Webrev: http://cr.openjdk.java.net/~iveresov/8171394/webrev.00/ > > > igor From dean.long at oracle.com Mon Dec 19 21:22:22 2016 From: dean.long at oracle.com (dean.long at oracle.com) Date: Mon, 19 Dec 2016 13:22:22 -0800 Subject: RFR(S) 8169938: [AOT] SIGSEGV at ~BufferBlob::vtable chunks Message-ID: AOT code, like C2 code, can reallocate objects during deoptimization, because of escape analysis. To support this, we need to set the "return_oop" flag on the scope correctly. https://bugs.openjdk.java.net/browse/JDK-8169938 http://cr.openjdk.java.net/~dlong/8169938/webrev/ dl From vladimir.kozlov at oracle.com Mon Dec 19 21:50:01 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 19 Dec 2016 13:50:01 -0800 Subject: RFR(S) 8169938: [AOT] SIGSEGV at ~BufferBlob::vtable chunks In-Reply-To: References: Message-ID: <7bfd84b2-9a26-8a17-3646-906e73f86fee@oracle.com> Thank you, Dean, for finding the cause. Looks good to me. CCing to Graal since it affects it. I am curious why Labs did not hit it before. Thanks, Vladimir On 12/19/16 1:22 PM, dean.long at oracle.com wrote: > AOT code, like C2 code, can reallocate objects during deoptimization, > because of escape analysis. To support this, we need to set the > "return_oop" flag on the scope correctly. > > https://bugs.openjdk.java.net/browse/JDK-8169938 > http://cr.openjdk.java.net/~dlong/8169938/webrev/ > > dl > From tom.rodriguez at oracle.com Tue Dec 20 06:49:27 2016 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Mon, 19 Dec 2016 22:49:27 -0800 Subject: RFR 8171173: EXCEPTION_ACCESS_VIOLATION running VirtualObjectDebugInfoTest.java Message-ID: <12297F80-AD0E-4BD8-9045-86BB7F7DF7C3@oracle.com> http://cr.openjdk.java.net/~never/8171173/webrev https://bugs.openjdk.java.net/browse/JDK-8171173 This appears to be a test bug. Any oops mentioned in debug info for rematerialized objects must also appear in the oop maps. Since these are being constructed by hand that was being missed. I wasn?t able to reproduce the crash but the code is clearly wrong and the hs_err supports the notion that a GC occurred at an unusual time. Tested by inspected the generated code debug info and oop maps. tom From vladimir.kozlov at oracle.com Tue Dec 20 09:13:55 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 20 Dec 2016 01:13:55 -0800 Subject: RFR(M): 8171398: s390x: Make interpreter's math entries consistent with C1 and C2 and support FMA In-Reply-To: References: <3d02956d0fa9481fa7a5d19c02c0b431@dewdfe13de06.global.corp.sap> Message-ID: <39c49254-5ad4-3d61-4e95-63e101d16d5f@oracle.com> Hi Martin, It could be pushed directly (after review) since it has only s390 changes. Thanks, Vladimir On 12/19/16 7:57 AM, Schmidt, Lutz wrote: > Hi Martin, > > your change looks good. I have one minor suggestions, though. > > - in s390.ad: please adapt comments in all ?instruct msub*? to say ?CC > unchanged by MUL-SUB? > > Thanks, > Lutz > > > From: hotspot-compiler-dev > > on behalf of > "Doerr, Martin (martin.doerr at sap.com )" > > > Date: Samstag, 17. Dezember 2016 um 11:18 > To: "'hotspot-compiler-dev at openjdk.java.net > '" > > > Subject: RFR(M): 8171398: s390x: Make interpreter's math entries > consistent with C1 and C2 and support FMA > > Hi, > > > > I?d like to address the same issue as on PPC64 on s390x. > > As discussed in [1], floating point computations should produce > consistent results regardless of whether the Java code gets interpreted > or is compiled by any JIT-compiler. > > In addition, JDK9 introduced new floating point multiply-accumulate > intrinsics which are currently missing on s390x. > > > > Webrev is here: > > http://cr.openjdk.java.net/~mdoerr/8171398_s390_FMA/webrev.00/ > > > > I have included a bugfix for parameter handling in an aes decrypt stub. > > > > Please review. > > > > Best regards, > > Martin > > > > > > [1] > http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2016-December/025073.html > > > From yang.zhang at linaro.org Tue Dec 20 10:02:51 2016 From: yang.zhang at linaro.org (Yang Zhang) Date: Tue, 20 Dec 2016 18:02:51 +0800 Subject: [aarch64-port-dev ] RFR: 8169697: aarch64: vectorized MLA instruction not generated for some test cases In-Reply-To: References: <15b3b2dc-481f-98fd-c7db-f72f58d970e1@oracle.com> Message-ID: Hi Vladimir, Roland The patch has been updated in http://cr.openjdk.java.net/~njian/8169697/webrev.01/. Could you please help to review it again? Regards Yang On 12 December 2016 at 11:42, Yang Zhang wrote: > Hi Vladimir, > > Thanks for your review. > >> >> What about SubV* and MulV* nodes? >> > > After checking commut_op_list, I think MulV*, AndV, OrV and XorV nodes > can also be added. Should I add them all? > > SubV* nodes are not commutative, so I don't think they need to be > considered here. > >> >> I prefer shared code change but we would need to test on all platforms which support vectors. >> > Yeah, we need to test on all platforms. We already tested previous > patch on x86 and aarch64 platforms, but we don't have other platforms. > > Regards > Yang From goetz.lindenmaier at sap.com Tue Dec 20 11:08:12 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 20 Dec 2016 11:08:12 +0000 Subject: RFR(M): 8171398: s390x: Make interpreter's math entries consistent with C1 and C2 and support FMA In-Reply-To: <3d02956d0fa9481fa7a5d19c02c0b431@dewdfe13de06.global.corp.sap> References: <3d02956d0fa9481fa7a5d19c02c0b431@dewdfe13de06.global.corp.sap> Message-ID: <7f45ce82c6804631a1178a13078bf68f@DEROTE13DE08.global.corp.sap> Hi Martin, thanks for implementing this. Change looks good and I know you ran it through our tests. Could you please adapt the comments in the ad file, they use 'src3' which probably means the dst use-def source. (no new webrev needed). Best regards, Goetz. From: hotspot-compiler-dev [mailto:hotspot-compiler-dev-bounces at openjdk.java.net] On Behalf Of Doerr, Martin Sent: Samstag, 17. Dezember 2016 11:18 To: 'hotspot-compiler-dev at openjdk.java.net' Subject: RFR(M): 8171398: s390x: Make interpreter's math entries consistent with C1 and C2 and support FMA Hi, I'd like to address the same issue as on PPC64 on s390x. As discussed in [1], floating point computations should produce consistent results regardless of whether the Java code gets interpreted or is compiled by any JIT-compiler. In addition, JDK9 introduced new floating point multiply-accumulate intrinsics which are currently missing on s390x. Webrev is here: http://cr.openjdk.java.net/~mdoerr/8171398_s390_FMA/webrev.00/ I have included a bugfix for parameter handling in an aes decrypt stub. Please review. Best regards, Martin [1] http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2016-December/025073.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From martin.doerr at sap.com Tue Dec 20 14:04:05 2016 From: martin.doerr at sap.com (Doerr, Martin) Date: Tue, 20 Dec 2016 14:04:05 +0000 Subject: RFR(M): 8171398: s390x: Make interpreter's math entries consistent with C1 and C2 and support FMA In-Reply-To: <39c49254-5ad4-3d61-4e95-63e101d16d5f@oracle.com> References: <3d02956d0fa9481fa7a5d19c02c0b431@dewdfe13de06.global.corp.sap> <39c49254-5ad4-3d61-4e95-63e101d16d5f@oracle.com> Message-ID: <969700ad2b3347d0a506641e67f4bdab@dewdfe13de06.global.corp.sap> Hi, thanks, Vladimir, for your support. Especially for pushing my PPC64 change. Thanks, everyone, for reviewing. Best regards, Martin -----Original Message----- From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] Sent: Dienstag, 20. Dezember 2016 10:14 To: Schmidt, Lutz ; Doerr, Martin ; 'hotspot-compiler-dev at openjdk.java.net' Subject: Re: RFR(M): 8171398: s390x: Make interpreter's math entries consistent with C1 and C2 and support FMA Hi Martin, It could be pushed directly (after review) since it has only s390 changes. Thanks, Vladimir On 12/19/16 7:57 AM, Schmidt, Lutz wrote: > Hi Martin, > > your change looks good. I have one minor suggestions, though. > > - in s390.ad: please adapt comments in all "instruct msub*" to say > "CC unchanged by MUL-SUB" > > Thanks, > Lutz > > > From: hotspot-compiler-dev > > on behalf of > "Doerr, Martin (martin.doerr at sap.com )" > > > Date: Samstag, 17. Dezember 2016 um 11:18 > To: "'hotspot-compiler-dev at openjdk.java.net > '" > > > Subject: RFR(M): 8171398: s390x: Make interpreter's math entries > consistent with C1 and C2 and support FMA > > Hi, > > > > I'd like to address the same issue as on PPC64 on s390x. > > As discussed in [1], floating point computations should produce > consistent results regardless of whether the Java code gets > interpreted or is compiled by any JIT-compiler. > > In addition, JDK9 introduced new floating point multiply-accumulate > intrinsics which are currently missing on s390x. > > > > Webrev is here: > > http://cr.openjdk.java.net/~mdoerr/8171398_s390_FMA/webrev.00/ > > > > I have included a bugfix for parameter handling in an aes decrypt stub. > > > > Please review. > > > > Best regards, > > Martin > > > > > > [1] > http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2016-Decem > ber/025073.html > > > From vladimir.kozlov at oracle.com Tue Dec 20 18:11:02 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 20 Dec 2016 10:11:02 -0800 Subject: RFR 8171173: EXCEPTION_ACCESS_VIOLATION running VirtualObjectDebugInfoTest.java In-Reply-To: <12297F80-AD0E-4BD8-9045-86BB7F7DF7C3@oracle.com> References: <12297F80-AD0E-4BD8-9045-86BB7F7DF7C3@oracle.com> Message-ID: Looks good. Thank you for fixing this. Vladimir On 12/19/16 10:49 PM, Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/8171173/webrev > https://bugs.openjdk.java.net/browse/JDK-8171173 > > This appears to be a test bug. Any oops mentioned in debug info for rematerialized objects must also appear in the oop maps. Since these are being constructed by hand that was being missed. I wasn?t able to reproduce the crash but the code is clearly wrong and the hs_err supports the notion that a GC occurred at an unusual time. Tested by inspected the generated code debug info and oop maps. > > tom > From igor.veresov at oracle.com Tue Dec 20 18:22:58 2016 From: igor.veresov at oracle.com (Igor Veresov) Date: Tue, 20 Dec 2016 10:22:58 -0800 Subject: RFR(M) 8168792: [AOT] problems in MethodHandle with aot-compiled java.base Message-ID: This basically adds assertions support for AOT. It operates as follows: 1. By default the asserts are compiled away. That is the load from $assertionsDisabled is replaced with a true constant. At runtime if the user enables assertions for the class that is in the AOT library, that class is rejected and all AOT dependees are made not entrant and deopted. 2. If ?enable-assertions flag is specified to jaotc, the loads from $assertionsDisabled are not folded. The resulting code is good for executing with or without assertions enabled. Webrev: http://cr.openjdk.java.net/~iveresov/8168792/webrev.00/ igor -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladimir.kozlov at oracle.com Tue Dec 20 18:45:55 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 20 Dec 2016 10:45:55 -0800 Subject: RFR(M) 8168792: [AOT] problems in MethodHandle with aot-compiled java.base In-Reply-To: References: Message-ID: Can you explain removal of code in HotSpotNodePlugin.java ? Otherwise changes seem fine. Thanks, Vladimir On 12/20/16 10:22 AM, Igor Veresov wrote: > This basically adds assertions support for AOT. It operates as follows: > 1. By default the asserts are compiled away. That is the load from > $assertionsDisabled is replaced with a true constant. At runtime if the > user enables assertions for the class that is in the AOT library, that > class is rejected and all AOT dependees are made not entrant and deopted. > 2. If ?enable-assertions flag is specified to jaotc, the loads from > $assertionsDisabled are not folded. The resulting code is good for > executing with or without assertions enabled. > > Webrev: http://cr.openjdk.java.net/~iveresov/8168792/webrev.00/ > > > igor From igor.veresov at oracle.com Tue Dec 20 19:06:16 2016 From: igor.veresov at oracle.com (Igor Veresov) Date: Tue, 20 Dec 2016 11:06:16 -0800 Subject: RFR(M) 8168792: [AOT] problems in MethodHandle with aot-compiled java.base In-Reply-To: References: Message-ID: <2BD580DD-A2EB-4F3E-B52B-7F6B8635DAF9@oracle.com> It was hack that was added to fold through loads of $assertionsDisabled (otherwise aot doesn?t fold loads, that?s an exception). So the load would become a false constant if assertions where enabled for jaotc or true if they were disabled. With how we want handle assertions now it?s not needed anymore. I?ll push the appropriate change to graal-core as well. igor > On Dec 20, 2016, at 10:45 AM, Vladimir Kozlov wrote: > > Can you explain removal of code in HotSpotNodePlugin.java ? > > Otherwise changes seem fine. > > Thanks, > Vladimir > > On 12/20/16 10:22 AM, Igor Veresov wrote: >> This basically adds assertions support for AOT. It operates as follows: >> 1. By default the asserts are compiled away. That is the load from >> $assertionsDisabled is replaced with a true constant. At runtime if the >> user enables assertions for the class that is in the AOT library, that >> class is rejected and all AOT dependees are made not entrant and deopted. >> 2. If ?enable-assertions flag is specified to jaotc, the loads from >> $assertionsDisabled are not folded. The resulting code is good for >> executing with or without assertions enabled. >> >> Webrev: http://cr.openjdk.java.net/~iveresov/8168792/webrev.00/ >> >> >> igor From vladimir.kozlov at oracle.com Tue Dec 20 19:24:21 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 20 Dec 2016 11:24:21 -0800 Subject: RFR(M) 8168792: [AOT] problems in MethodHandle with aot-compiled java.base In-Reply-To: <2BD580DD-A2EB-4F3E-B52B-7F6B8635DAF9@oracle.com> References: <2BD580DD-A2EB-4F3E-B52B-7F6B8635DAF9@oracle.com> Message-ID: Okay. Good. Thanks, Vladimir On 12/20/16 11:06 AM, Igor Veresov wrote: > It was hack that was added to fold through loads of $assertionsDisabled (otherwise aot doesn?t fold loads, that?s an exception). So the load would become a false constant if assertions where enabled for jaotc or true if they were disabled. With how we want handle assertions now it?s not needed anymore. I?ll push the appropriate change to graal-core as well. > > igor > >> On Dec 20, 2016, at 10:45 AM, Vladimir Kozlov wrote: >> >> Can you explain removal of code in HotSpotNodePlugin.java ? >> >> Otherwise changes seem fine. >> >> Thanks, >> Vladimir >> >> On 12/20/16 10:22 AM, Igor Veresov wrote: >>> This basically adds assertions support for AOT. It operates as follows: >>> 1. By default the asserts are compiled away. That is the load from >>> $assertionsDisabled is replaced with a true constant. At runtime if the >>> user enables assertions for the class that is in the AOT library, that >>> class is rejected and all AOT dependees are made not entrant and deopted. >>> 2. If ?enable-assertions flag is specified to jaotc, the loads from >>> $assertionsDisabled are not folded. The resulting code is good for >>> executing with or without assertions enabled. >>> >>> Webrev: http://cr.openjdk.java.net/~iveresov/8168792/webrev.00/ >>> >>> >>> igor > From igor.veresov at oracle.com Tue Dec 20 19:27:29 2016 From: igor.veresov at oracle.com (Igor Veresov) Date: Tue, 20 Dec 2016 11:27:29 -0800 Subject: RFR(M) 8168792: [AOT] problems in MethodHandle with aot-compiled java.base In-Reply-To: References: <2BD580DD-A2EB-4F3E-B52B-7F6B8635DAF9@oracle.com> Message-ID: Thanks, Vladimir! igor > On Dec 20, 2016, at 11:24 AM, Vladimir Kozlov wrote: > > Okay. Good. > > Thanks, > Vladimir > > On 12/20/16 11:06 AM, Igor Veresov wrote: >> It was hack that was added to fold through loads of $assertionsDisabled (otherwise aot doesn?t fold loads, that?s an exception). So the load would become a false constant if assertions where enabled for jaotc or true if they were disabled. With how we want handle assertions now it?s not needed anymore. I?ll push the appropriate change to graal-core as well. >> >> igor >> >>> On Dec 20, 2016, at 10:45 AM, Vladimir Kozlov wrote: >>> >>> Can you explain removal of code in HotSpotNodePlugin.java ? >>> >>> Otherwise changes seem fine. >>> >>> Thanks, >>> Vladimir >>> >>> On 12/20/16 10:22 AM, Igor Veresov wrote: >>>> This basically adds assertions support for AOT. It operates as follows: >>>> 1. By default the asserts are compiled away. That is the load from >>>> $assertionsDisabled is replaced with a true constant. At runtime if the >>>> user enables assertions for the class that is in the AOT library, that >>>> class is rejected and all AOT dependees are made not entrant and deopted. >>>> 2. If ?enable-assertions flag is specified to jaotc, the loads from >>>> $assertionsDisabled are not folded. The resulting code is good for >>>> executing with or without assertions enabled. >>>> >>>> Webrev: http://cr.openjdk.java.net/~iveresov/8168792/webrev.00/ >>>> >>>> >>>> igor >> From dean.long at oracle.com Tue Dec 20 19:36:04 2016 From: dean.long at oracle.com (dean.long at oracle.com) Date: Tue, 20 Dec 2016 11:36:04 -0800 Subject: RFR(S) 8169938: [AOT] SIGSEGV at ~BufferBlob::vtable chunks In-Reply-To: <7bfd84b2-9a26-8a17-3646-906e73f86fee@oracle.com> References: <7bfd84b2-9a26-8a17-3646-906e73f86fee@oracle.com> Message-ID: Thanks Vladimir. dl On 12/19/16 1:50 PM, Vladimir Kozlov wrote: > Thank you, Dean, for finding the cause. > > Looks good to me. > > CCing to Graal since it affects it. I am curious why Labs did not hit > it before. > > Thanks, > Vladimir > > On 12/19/16 1:22 PM, dean.long at oracle.com wrote: >> AOT code, like C2 code, can reallocate objects during deoptimization, >> because of escape analysis. To support this, we need to set the >> "return_oop" flag on the scope correctly. >> >> https://bugs.openjdk.java.net/browse/JDK-8169938 >> http://cr.openjdk.java.net/~dlong/8169938/webrev/ >> >> dl >> From edward.nevill at gmail.com Tue Dec 20 21:01:52 2016 From: edward.nevill at gmail.com (Edward Nevill) Date: Tue, 20 Dec 2016 21:01:52 +0000 Subject: RFR: 8171537: aarch64: compiler/c1/Test6849574.java generates guarantee failure in C1 Message-ID: <1482267712.2307.11.camel@gmail.com> Hi, Please review the following webrev http://cr.openjdk.java.net/~enevill/8171537/webrev JIRA Issue:?https://bugs.openjdk.java.net/browse/JDK-8171537 This fixes an issue where the JTreg hotspot test compiler/c1/Test6849574.java fails with a guarantee failure when run with -XX:TieredStopAtLevel=1 to force use of C1. # A fatal error has been detected by the Java Runtime Environment:? #? # Internal Error (assembler_aarch64.hpp:232), pid=8576, tid=8601? # guarantee(val < (1U << nbits)) failed: Field too big for insn? The problem is the following call in?LIR_Assembler::atomic_op in?src/cpu/aarch64/vm/c1_LIRAssembler_aarch64.cpp ? Address addr = as_Address(src->as_address_ptr(), noreg); (noreg has the value -1) as_Address looks like Address LIR_Assembler::as_Address(LIR_Address* addr, Register tmp) { .... ? ? intptr_t addr_offset = intptr_t(addr->disp()); ????if (Address::offset_ok_for_immed(addr_offset, addr->scale())) ??????return Address(base, addr_offset, Address::lsl(addr->scale())); ????else { ??????__ mov(tmp, addr_offset); ?<<<<< tmp is used here, but has value -1 ??????return Address(base, tmp, Address::lsl(addr->scale())); ????} } The proposed solution is to change the call to ? Address addr = as_Address(src->as_address_ptr()); which calls the two argument form with rscratch1 as the tmp register instead of -1. All the best, Ed. From aph at redhat.com Tue Dec 20 21:24:47 2016 From: aph at redhat.com (Andrew Haley) Date: Tue, 20 Dec 2016 21:24:47 +0000 Subject: RFR: 8171537: aarch64: compiler/c1/Test6849574.java generates guarantee failure in C1 In-Reply-To: <1482267712.2307.11.camel@gmail.com> References: <1482267712.2307.11.camel@gmail.com> Message-ID: <76c988e6-307e-5f7f-814a-7b6926ee3d53@redhat.com> On 20/12/16 21:01, Edward Nevill wrote: > http://cr.openjdk.java.net/~enevill/8171537/webrev > > JIRA Issue: https://bugs.openjdk.java.net/browse/JDK-8171537 This is great, thanks. It must go in by tomorrow to meet the freeze deadline. Andrew. From vladimir.kozlov at oracle.com Tue Dec 20 21:43:22 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 20 Dec 2016 13:43:22 -0800 Subject: RFR: 8171537: aarch64: compiler/c1/Test6849574.java generates guarantee failure in C1 In-Reply-To: <76c988e6-307e-5f7f-814a-7b6926ee3d53@redhat.com> References: <1482267712.2307.11.camel@gmail.com> <76c988e6-307e-5f7f-814a-7b6926ee3d53@redhat.com> Message-ID: <7e80851c-d996-1172-37e9-df4febbf5df0@oracle.com> Only P4 and P5 bugs are affected by "Rampdown Start" January 5. That is what we talking about now. As usual Hotspot should have these fixes 2 weeks before January 5 to have time for fixes propagation into master jdk9/jdk9. We can still push P1-P3 bugs fixes until ZBB, Feb 16 (or 2 weeks before for Hotspot): http://openjdk.java.net/projects/jdk9/ So make your bugs at least P3 if you need to push them into JDK 9. Regards, Vladimir On 12/20/16 1:24 PM, Andrew Haley wrote: > On 20/12/16 21:01, Edward Nevill wrote: >> http://cr.openjdk.java.net/~enevill/8171537/webrev >> >> JIRA Issue: https://bugs.openjdk.java.net/browse/JDK-8171537 > > This is great, thanks. It must go in by tomorrow to meet the > freeze deadline. > > Andrew. > From tom.rodriguez at oracle.com Tue Dec 20 21:44:07 2016 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 20 Dec 2016 13:44:07 -0800 Subject: RFR(S) 8169938: [AOT] SIGSEGV at ~BufferBlob::vtable chunks In-Reply-To: <7bfd84b2-9a26-8a17-3646-906e73f86fee@oracle.com> References: <7bfd84b2-9a26-8a17-3646-906e73f86fee@oracle.com> Message-ID: <5936E0A9-A6CB-4436-BCEC-CA0D3E2B8D71@oracle.com> > On Dec 19, 2016, at 1:50 PM, Vladimir Kozlov wrote: > > Thank you, Dean, for finding the cause. > > Looks good to me. > > CCing to Graal since it affects it. I am curious why Labs did not hit it before. Not sure either, though AOT?s been running for a while without seeing it either. I?m a unsure that this is the right logic though. If you look at how C2 is setting this flag it?s driven by lower level code generation details. Basically it?s looking at the underlying call object at the debug info site to determine if that call is returning an oop. Will that produce the same answer as checking the return type of the call? For any site which is a normal method invoke I think it will but what about other calls like a vm entry point? tom > > Thanks, > Vladimir > > On 12/19/16 1:22 PM, dean.long at oracle.com wrote: >> AOT code, like C2 code, can reallocate objects during deoptimization, >> because of escape analysis. To support this, we need to set the >> "return_oop" flag on the scope correctly. >> >> https://bugs.openjdk.java.net/browse/JDK-8169938 >> http://cr.openjdk.java.net/~dlong/8169938/webrev/ >> >> dl >> From vladimir.kozlov at oracle.com Tue Dec 20 23:34:34 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 20 Dec 2016 15:34:34 -0800 Subject: RFR(S) 8169938: [AOT] SIGSEGV at ~BufferBlob::vtable chunks In-Reply-To: <5936E0A9-A6CB-4436-BCEC-CA0D3E2B8D71@oracle.com> References: <7bfd84b2-9a26-8a17-3646-906e73f86fee@oracle.com> <5936E0A9-A6CB-4436-BCEC-CA0D3E2B8D71@oracle.com> Message-ID: <171869bf-ae4a-b133-97f6-0c36918115b2@oracle.com> On 12/20/16 1:44 PM, Tom Rodriguez wrote: > >> On Dec 19, 2016, at 1:50 PM, Vladimir Kozlov wrote: >> >> Thank you, Dean, for finding the cause. >> >> Looks good to me. >> >> CCing to Graal since it affects it. I am curious why Labs did not hit it before. > > Not sure either, though AOT?s been running for a while without seeing it either. > > I?m a unsure that this is the right logic though. If you look at how C2 is setting this flag it?s driven by lower level code generation details. Basically it?s looking at the underlying call object at the debug info site to determine if that call is returning an oop. Will that produce the same answer as checking the return type of the call? For any site which is a normal method invoke I think it will but what about other calls like a vm entry point? I agree, C2 is checking is_ptr() which include metadata pointers. In such case we need help from you. I think pointer return information can be recorded in DebugInfo or Call class. Thanks, Vladimir > > tom > >> >> Thanks, >> Vladimir >> >> On 12/19/16 1:22 PM, dean.long at oracle.com wrote: >>> AOT code, like C2 code, can reallocate objects during deoptimization, >>> because of escape analysis. To support this, we need to set the >>> "return_oop" flag on the scope correctly. >>> >>> https://bugs.openjdk.java.net/browse/JDK-8169938 >>> http://cr.openjdk.java.net/~dlong/8169938/webrev/ >>> >>> dl >>> > From dean.long at oracle.com Wed Dec 21 03:01:52 2016 From: dean.long at oracle.com (dean.long at oracle.com) Date: Tue, 20 Dec 2016 19:01:52 -0800 Subject: RFR(S) 8169938: [AOT] SIGSEGV at ~BufferBlob::vtable chunks In-Reply-To: <171869bf-ae4a-b133-97f6-0c36918115b2@oracle.com> References: <7bfd84b2-9a26-8a17-3646-906e73f86fee@oracle.com> <5936E0A9-A6CB-4436-BCEC-CA0D3E2B8D71@oracle.com> <171869bf-ae4a-b133-97f6-0c36918115b2@oracle.com> Message-ID: <215fa525-0aeb-f20a-b9d4-7449a28565a0@oracle.com> On 12/20/16 3:34 PM, Vladimir Kozlov wrote: > On 12/20/16 1:44 PM, Tom Rodriguez wrote: >> >>> On Dec 19, 2016, at 1:50 PM, Vladimir Kozlov >>> wrote: >>> >>> Thank you, Dean, for finding the cause. >>> >>> Looks good to me. >>> >>> CCing to Graal since it affects it. I am curious why Labs did not >>> hit it before. >> >> Not sure either, though AOT?s been running for a while without seeing >> it either. >> >> I?m a unsure that this is the right logic though. If you look at how >> C2 is setting this flag it?s driven by lower level code generation >> details. Basically it?s looking at the underlying call object at the >> debug info site to determine if that call is returning an oop. Will >> that produce the same answer as checking the return type of the >> call? For any site which is a normal method invoke I think it will >> but what about other calls like a vm entry point? > Is there a VM entry point that returns an oop in a register? > I agree, C2 is checking is_ptr() which include metadata pointers. > It must be an oop, not metadata: oop result = deoptee.saved_oop_result(&map); assert(result == NULL || result->is_oop(), "must be oop"); dl > In such case we need help from you. I think pointer return information > can be recorded in DebugInfo or Call class. > > Thanks, > Vladimir > >> >> tom >> >>> >>> Thanks, >>> Vladimir >>> >>> On 12/19/16 1:22 PM, dean.long at oracle.com wrote: >>>> AOT code, like C2 code, can reallocate objects during deoptimization, >>>> because of escape analysis. To support this, we need to set the >>>> "return_oop" flag on the scope correctly. >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8169938 >>>> http://cr.openjdk.java.net/~dlong/8169938/webrev/ >>>> >>>> dl >>>> >> From vladimir.kozlov at oracle.com Wed Dec 21 04:19:30 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 20 Dec 2016 20:19:30 -0800 Subject: [9] RFR(S) 8171807: 8170761 fix should be applied to ARM code after 8168503 Message-ID: <9f4ccccf-1a5b-bbbd-fa92-74e2909e8822@oracle.com> https://bugs.openjdk.java.net/browse/JDK-8171807 http://cr.openjdk.java.net/~kvn/8171807/webrev/ 8168503: JEP 297: Unified arm32/arm64 Port moved closed code into open. It was pushed into jdk9/dev. At the same time closed changes for 8170761 were pushed into jdk9/hs. After 8168503 changes merged into jdk9/hs closed changes for 8170761 were not applied to simplify the merge. 8170761 closed changes should be applied to now open ARM code. Note, 8170761 fixed warnings produced by code analysis tool. Thanks, Vladimir From tom.rodriguez at oracle.com Wed Dec 21 04:30:53 2016 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 20 Dec 2016 20:30:53 -0800 Subject: RFR(S) 8169938: [AOT] SIGSEGV at ~BufferBlob::vtable chunks In-Reply-To: <215fa525-0aeb-f20a-b9d4-7449a28565a0@oracle.com> References: <7bfd84b2-9a26-8a17-3646-906e73f86fee@oracle.com> <5936E0A9-A6CB-4436-BCEC-CA0D3E2B8D71@oracle.com> <171869bf-ae4a-b133-97f6-0c36918115b2@oracle.com> <215fa525-0aeb-f20a-b9d4-7449a28565a0@oracle.com> Message-ID: <1182298D-0703-4F6C-A0B6-D23865233792@oracle.com> > On Dec 20, 2016, at 7:01 PM, dean.long at oracle.com wrote: > > On 12/20/16 3:34 PM, Vladimir Kozlov wrote: > >> On 12/20/16 1:44 PM, Tom Rodriguez wrote: >>> >>>> On Dec 19, 2016, at 1:50 PM, Vladimir Kozlov wrote: >>>> >>>> Thank you, Dean, for finding the cause. >>>> >>>> Looks good to me. >>>> >>>> CCing to Graal since it affects it. I am curious why Labs did not hit it before. >>> >>> Not sure either, though AOT?s been running for a while without seeing it either. >>> >>> I?m a unsure that this is the right logic though. If you look at how C2 is setting this flag it?s driven by lower level code generation details. Basically it?s looking at the underlying call object at the debug info site to determine if that call is returning an oop. Will that produce the same answer as checking the return type of the call? For any site which is a normal method invoke I think it will but what about other calls like a vm entry point? >> > > Is there a VM entry point that returns an oop in a register? From the perspective of code generation the allocation paths do this. But to answer my own question, I think c2 may be setting it to true under conditions where it will never be consulted. Any VM entry point that actually returns an oop uses a stub to handle it and passes the value through vm_result so it?s handled across the safe point. You can't actually stop at the call site pc when you deoptimize. I think a correct value is only required for real Java invoke sites. > >> I agree, C2 is checking is_ptr() which include metadata pointers. >> > > It must be an oop, not metadata: > > oop result = deoptee.saved_oop_result(&map); > assert(result == NULL || result->is_oop(), "must be oop?); The code is using isa_ptr() so any pointer return value will set it to true which is clearly wrong. I suspect any path which might set this incorrectly simply will never consult the value. So I think your fix for JVMCI looks right. And the existing C2 code is benignly wrong. tom > > dl > >> In such case we need help from you. I think pointer return information can be recorded in DebugInfo or Call class. >> >> Thanks, >> Vladimir >> >>> >>> tom >>> >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 12/19/16 1:22 PM, dean.long at oracle.com wrote: >>>>> AOT code, like C2 code, can reallocate objects during deoptimization, >>>>> because of escape analysis. To support this, we need to set the >>>>> "return_oop" flag on the scope correctly. >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8169938 >>>>> http://cr.openjdk.java.net/~dlong/8169938/webrev/ >>>>> >>>>> dl -------------- next part -------------- An HTML attachment was scrubbed... URL: From dean.long at oracle.com Wed Dec 21 04:35:29 2016 From: dean.long at oracle.com (dean.long at oracle.com) Date: Tue, 20 Dec 2016 20:35:29 -0800 Subject: RFR(S) 8169938: [AOT] SIGSEGV at ~BufferBlob::vtable chunks In-Reply-To: <1182298D-0703-4F6C-A0B6-D23865233792@oracle.com> References: <7bfd84b2-9a26-8a17-3646-906e73f86fee@oracle.com> <5936E0A9-A6CB-4436-BCEC-CA0D3E2B8D71@oracle.com> <171869bf-ae4a-b133-97f6-0c36918115b2@oracle.com> <215fa525-0aeb-f20a-b9d4-7449a28565a0@oracle.com> <1182298D-0703-4F6C-A0B6-D23865233792@oracle.com> Message-ID: Thanks Tom. dl On 12/20/16 8:30 PM, Tom Rodriguez wrote: > >> On Dec 20, 2016, at 7:01 PM, dean.long at oracle.com >> wrote: >> >> On 12/20/16 3:34 PM, Vladimir Kozlov wrote: >> >>> On 12/20/16 1:44 PM, Tom Rodriguez wrote: >>>> >>>>> On Dec 19, 2016, at 1:50 PM, Vladimir Kozlov >>>>> > >>>>> wrote: >>>>> >>>>> Thank you, Dean, for finding the cause. >>>>> >>>>> Looks good to me. >>>>> >>>>> CCing to Graal since it affects it. I am curious why Labs did not >>>>> hit it before. >>>> >>>> Not sure either, though AOT?s been running for a while without >>>> seeing it either. >>>> >>>> I?m a unsure that this is the right logic though. If you look at >>>> how C2 is setting this flag it?s driven by lower level code >>>> generation details. Basically it?s looking at the underlying call >>>> object at the debug info site to determine if that call is >>>> returning an oop. Will that produce the same answer as checking >>>> the return type of the call? For any site which is a normal method >>>> invoke I think it will but what about other calls like a vm entry >>>> point? >>> >> >> Is there a VM entry point that returns an oop in a register? > > From the perspective of code generation the allocation paths do this. > But to answer my own question, I think c2 may be setting it to true > under conditions where it will never be consulted. Any VM entry point > that actually returns an oop uses a stub to handle it and passes the > value through vm_result so it?s handled across the safe point. You > can't actually stop at the call site pc when you deoptimize. I think > a correct value is only required for real Java invoke sites. > >> >>> I agree, C2 is checking is_ptr() which include metadata pointers. >>> >> >> It must be an oop, not metadata: >> >> oop result = deoptee.saved_oop_result(&map); >> assert(result == NULL || result->is_oop(), "must be oop?); > > The code is using isa_ptr() so any pointer return value will set it to > true which is clearly wrong. I suspect any path which might set this > incorrectly simply will never consult the value. > > So I think your fix for JVMCI looks right. And the existing C2 code > is benignly wrong. > > tom > >> >> dl >> >>> In such case we need help from you. I think pointer return >>> information can be recorded in DebugInfo or Call class. >>> >>> Thanks, >>> Vladimir >>> >>>> >>>> tom >>>> >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> On 12/19/16 1:22 PM, dean.long at oracle.com >>>>> wrote: >>>>>> AOT code, like C2 code, can reallocate objects during deoptimization, >>>>>> because of escape analysis. To support this, we need to set the >>>>>> "return_oop" flag on the scope correctly. >>>>>> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8169938 >>>>>> http://cr.openjdk.java.net/~dlong/8169938/webrev/ >>>>>> >>>>>> dl > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rwestrel at redhat.com Wed Dec 21 09:21:32 2016 From: rwestrel at redhat.com (Roland Westrelin) Date: Wed, 21 Dec 2016 10:21:32 +0100 Subject: [9] RFR(S) 8171807: 8170761 fix should be applied to ARM code after 8168503 In-Reply-To: <9f4ccccf-1a5b-bbbd-fa92-74e2909e8822@oracle.com> References: <9f4ccccf-1a5b-bbbd-fa92-74e2909e8822@oracle.com> Message-ID: > http://cr.openjdk.java.net/~kvn/8171807/webrev/ That looks good to me. Roland. From boris.molodenkov at oracle.com Wed Dec 21 13:43:03 2016 From: boris.molodenkov at oracle.com (Boris Molodenkov) Date: Wed, 21 Dec 2016 16:43:03 +0300 Subject: RFR: 8170918 Remove shell script from test/compiler/c2/cr7200264/TestIntVect.java Message-ID: <585A86E7.2080603@oracle.com> Hi All, Could you please review shell script removal from compiler test. Test was divided into two separate tests for SSE2 and SSE4 vectorization. Corresponded jtreg 'requires' were added. JBS: https://bugs.openjdk.java.net/browse/JDK-8170918 Webrev: http://cr.openjdk.java.net/~bmoloden/8170918/webrev.00/ Thanks, Boris From vladimir.kozlov at oracle.com Wed Dec 21 15:58:52 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 21 Dec 2016 07:58:52 -0800 Subject: [9] RFR(S) 8171807: 8170761 fix should be applied to ARM code after 8168503 In-Reply-To: References: <9f4ccccf-1a5b-bbbd-fa92-74e2909e8822@oracle.com> Message-ID: <0ed032d5-105a-5d62-dd01-6423bbdef7e2@oracle.com> Thank you, Roland Vladimir On 12/21/16 1:21 AM, Roland Westrelin wrote: > >> http://cr.openjdk.java.net/~kvn/8171807/webrev/ > > That looks good to me. > > Roland. > From vladimir.kozlov at oracle.com Wed Dec 21 16:19:31 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 21 Dec 2016 08:19:31 -0800 Subject: RFR: 8170918 Remove shell script from test/compiler/c2/cr7200264/TestIntVect.java In-Reply-To: <585A86E7.2080603@oracle.com> References: <585A86E7.2080603@oracle.com> Message-ID: <8c396205-2d1f-ded1-1e2f-fb1257be06bb@oracle.com> Thank you Boris for fixing it. Changes looks good. Vladimir On 12/21/16 5:43 AM, Boris Molodenkov wrote: > Hi All, > > Could you please review shell script removal from compiler test. > > Test was divided into two separate tests for SSE2 and SSE4 vectorization. > Corresponded jtreg 'requires' were added. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8170918 > Webrev: http://cr.openjdk.java.net/~bmoloden/8170918/webrev.00/ > > Thanks, > Boris > From daniel.daugherty at oracle.com Wed Dec 21 17:38:56 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 21 Dec 2016 10:38:56 -0700 Subject: RFR(M): 8169373: Work around linux NPTL stack guard error. In-Reply-To: <9dd3c7f1e021445e8fd0abfaf552d8d7@DEROTE13DE08.global.corp.sap> References: <821371d77c7c4e6d966901b461b3d6a1@DEROTE13DE08.global.corp.sap> <49acd657-aefa-b935-1b2c-195fc2d125ba@oracle.com> <04825132c7fd4f92a06057cecc3f9329@DEROTE13DE08.global.corp.sap> <4abd1e03-27a2-4778-d1b0-09a952ccb525@oracle.com> <1111dc02-5d8f-3b50-b5f3-160c33474ace@oracle.com> <6ded66cf-558e-f6ce-7dff-7441992eb2ea@oracle.com> <371058eb-4e55-3ebd-6ce3-848628f96764@oracle.com> <8377024f345c46009b33a1f0db9deb9f@DEROTE13DE08.global.corp.sap> <462496af-d1b2-2c1f-f869-a98dc48120fb@oracle.com> <9dd3c7f1e021445e8fd0abfaf552d8d7@DEROTE13DE08.global.corp.sap> Message-ID: Changset pushed last night after the JDK9-dev -> JDK9-hs sync-down. Thanks for your patience. Dan On 12/13/16 9:24 AM, Lindenmaier, Goetz wrote: > Hi, > > I rebased 8169373 to the recent changes in hotspot: > http://cr.openjdk.java.net/~goetz/wr16/8169373-ppc-stackFix/webrev.09/ > > The patch is still in our test patch queue for the nightly tests, and there > were no failures I can attribute to this change. > > Best regards, > Goetz. > >> -----Original Message----- >> From: Daniel D. Daugherty [mailto:daniel.daugherty at oracle.com] >> Sent: Montag, 5. Dezember 2016 23:13 >> To: Lindenmaier, Goetz ; David Holmes >> ; Vladimir Kozlov ; >> hotspot-compiler-dev at openjdk.java.net; 'hotspot-runtime- >> dev at openjdk.java.net' >> Subject: Re: RFR(M): 8169373: Work around linux NPTL stack guard error. >> >> On 12/5/16 3:09 PM, Lindenmaier, Goetz wrote: >>> Hi Dan, >>> >>> thanks for the testing! Sorry I can't help ... >> No worries. We'll get there... >> >> JPRT passed with the appropriate closed changes... Thanks to David H. for >> suggesting the changes to make. I've got an internal review thread going >> on that. I also kicked off a "full RBT" run which is the equivalent of a >> nightly test run. >> >> Dan >> >> >>> Best regards, >>> Goetz. >>> >>>> -----Original Message----- >>>> From: Daniel D. Daugherty [mailto:daniel.daugherty at oracle.com] >>>> Sent: Monday, December 05, 2016 7:38 PM >>>> To: David Holmes ; Lindenmaier, Goetz >>>> ; Vladimir Kozlov >>>> ; hotspot-compiler-dev at openjdk.java.net; >>>> 'hotspot-runtime-dev at openjdk.java.net' >>> 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_.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 ; Lindenmaier, Goetz >>>>>>>> ; David Holmes >>>> ; >>>>>>>> hotspot-compiler-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 >>>>>>>>>>>>> ; hotspot-compiler- >>>>>>>> dev at openjdk.java.net; >>>>>>>>>>>>> 'hotspot-runtime-dev at openjdk.java.net' >>>>>>>>>>>> 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 ; >>>>>>>>>>>>>>>> hotspot-compiler- >>>>>>>>>>>>>>>> dev at openjdk.java.net; 'hotspot-runtime- >>>> dev at openjdk.java.net' >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 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 ; >>>>>>>> hotspot- >>>>>>>>>>>>> compiler- >>>>>>>>>>>>>>>>>> dev at openjdk.java.net; 'hotspot-runtime- >>>>>>>> dev at openjdk.java.net' >>>>>>>>>>>>> >>>>>>>>>>>>>>>>> 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 ; >>>>>>>>>>>>>>>>>>>> 'daniel.daugherty at oracle.com' >>>>>>>> ; >>>>>>>>>>>>>>>> 'hotspot- >>>>>>>>>>>>>>>>>>>> runtime-dev at openjdk.java.net' >>>>>>>>>>>> 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 ; >>>>>>>>>>>>>>>>>>>>>> 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 >>>> ; >>>>>>>>>>>>>>>>>>>>>>> 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 >>>> ; >>>>>>>> David >>>>>>>>>>>>>>>> Holmes >>>>>>>>>>>>>>>>>>>>>>>>> ; 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 ; >>>>>>>>>>>>>>>>>>>>>>>>>>> Lindenmaier, >>>>>>>>>>>>>>>> Goetz >>>>>>>>>>>>>>>>>>>>>>>>>>> ; 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 >>>>>>>> ; >>>>>>>>>>>>>>>> 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: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > From vladimir.kozlov at oracle.com Thu Dec 22 03:46:14 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 21 Dec 2016 19:46:14 -0800 Subject: RFR(M) 8168792: [AOT] problems in MethodHandle with aot-compiled java.base In-Reply-To: References: <2BD580DD-A2EB-4F3E-B52B-7F6B8635DAF9@oracle.com> Message-ID: <637ece10-254e-6ee1-342e-1cd90db49293@oracle.com> Igor, I want to update docs according to this changes and I am thinking may be we should call flag: --compile-with-assertions It matches other flags: --compile-for-tiered, --compile-commands What do you think? Thanks, Vladimir On 12/20/16 11:27 AM, Igor Veresov wrote: > Thanks, Vladimir! > > igor > >> On Dec 20, 2016, at 11:24 AM, Vladimir Kozlov wrote: >> >> Okay. Good. >> >> Thanks, >> Vladimir >> >> On 12/20/16 11:06 AM, Igor Veresov wrote: >>> It was hack that was added to fold through loads of $assertionsDisabled (otherwise aot doesn?t fold loads, that?s an exception). So the load would become a false constant if assertions where enabled for jaotc or true if they were disabled. With how we want handle assertions now it?s not needed anymore. I?ll push the appropriate change to graal-core as well. >>> >>> igor >>> >>>> On Dec 20, 2016, at 10:45 AM, Vladimir Kozlov wrote: >>>> >>>> Can you explain removal of code in HotSpotNodePlugin.java ? >>>> >>>> Otherwise changes seem fine. >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 12/20/16 10:22 AM, Igor Veresov wrote: >>>>> This basically adds assertions support for AOT. It operates as follows: >>>>> 1. By default the asserts are compiled away. That is the load from >>>>> $assertionsDisabled is replaced with a true constant. At runtime if the >>>>> user enables assertions for the class that is in the AOT library, that >>>>> class is rejected and all AOT dependees are made not entrant and deopted. >>>>> 2. If ?enable-assertions flag is specified to jaotc, the loads from >>>>> $assertionsDisabled are not folded. The resulting code is good for >>>>> executing with or without assertions enabled. >>>>> >>>>> Webrev: http://cr.openjdk.java.net/~iveresov/8168792/webrev.00/ >>>>> >>>>> >>>>> igor >>> > From igor.veresov at oracle.com Thu Dec 22 06:50:20 2016 From: igor.veresov at oracle.com (Igor Veresov) Date: Wed, 21 Dec 2016 22:50:20 -0800 Subject: RFR(M) 8168792: [AOT] problems in MethodHandle with aot-compiled java.base In-Reply-To: <637ece10-254e-6ee1-342e-1cd90db49293@oracle.com> References: <2BD580DD-A2EB-4F3E-B52B-7F6B8635DAF9@oracle.com> <637ece10-254e-6ee1-342e-1cd90db49293@oracle.com> Message-ID: Ok, no problem, I haven?t pushed it yet. Changing to --compile-with-assertions. igor > On Dec 21, 2016, at 7:46 PM, Vladimir Kozlov wrote: > > Igor, I want to update docs according to this changes and I am thinking may be we should call flag: > > --compile-with-assertions > > It matches other flags: --compile-for-tiered, --compile-commands > > What do you think? > > Thanks, > Vladimir > > On 12/20/16 11:27 AM, Igor Veresov wrote: >> Thanks, Vladimir! >> >> igor >> >>> On Dec 20, 2016, at 11:24 AM, Vladimir Kozlov wrote: >>> >>> Okay. Good. >>> >>> Thanks, >>> Vladimir >>> >>> On 12/20/16 11:06 AM, Igor Veresov wrote: >>>> It was hack that was added to fold through loads of $assertionsDisabled (otherwise aot doesn?t fold loads, that?s an exception). So the load would become a false constant if assertions where enabled for jaotc or true if they were disabled. With how we want handle assertions now it?s not needed anymore. I?ll push the appropriate change to graal-core as well. >>>> >>>> igor >>>> >>>>> On Dec 20, 2016, at 10:45 AM, Vladimir Kozlov wrote: >>>>> >>>>> Can you explain removal of code in HotSpotNodePlugin.java ? >>>>> >>>>> Otherwise changes seem fine. >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> On 12/20/16 10:22 AM, Igor Veresov wrote: >>>>>> This basically adds assertions support for AOT. It operates as follows: >>>>>> 1. By default the asserts are compiled away. That is the load from >>>>>> $assertionsDisabled is replaced with a true constant. At runtime if the >>>>>> user enables assertions for the class that is in the AOT library, that >>>>>> class is rejected and all AOT dependees are made not entrant and deopted. >>>>>> 2. If ?enable-assertions flag is specified to jaotc, the loads from >>>>>> $assertionsDisabled are not folded. The resulting code is good for >>>>>> executing with or without assertions enabled. >>>>>> >>>>>> Webrev: http://cr.openjdk.java.net/~iveresov/8168792/webrev.00/ >>>>>> >>>>>> >>>>>> igor >>>> >> From boris.molodenkov at oracle.com Thu Dec 22 11:43:32 2016 From: boris.molodenkov at oracle.com (Boris Molodenkov) Date: Thu, 22 Dec 2016 14:43:32 +0300 Subject: RFR: 8170918 Remove shell script from test/compiler/c2/cr7200264/TestIntVect.java In-Reply-To: <8c396205-2d1f-ded1-1e2f-fb1257be06bb@oracle.com> References: <585A86E7.2080603@oracle.com> <8c396205-2d1f-ded1-1e2f-fb1257be06bb@oracle.com> Message-ID: <6bc0776c-4ade-b610-5d20-7b5c9e2c515e@oracle.com> Thank you for review. On 21.12.2016 19:19, Vladimir Kozlov wrote: > Thank you Boris for fixing it. > > Changes looks good. > > Vladimir > > On 12/21/16 5:43 AM, Boris Molodenkov wrote: >> Hi All, >> >> Could you please review shell script removal from compiler test. >> >> Test was divided into two separate tests for SSE2 and SSE4 >> vectorization. >> Corresponded jtreg 'requires' were added. >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8170918 >> Webrev: http://cr.openjdk.java.net/~bmoloden/8170918/webrev.00/ >> >> Thanks, >> Boris >> From vivek.r.deshpande at intel.com Fri Dec 23 20:11:17 2016 From: vivek.r.deshpande at intel.com (Deshpande, Vivek R) Date: Fri, 23 Dec 2016 20:11:17 +0000 Subject: RFR(XS): x86: 8171974: Fix for R10 Register clobbering with usage of ExternalAddress Message-ID: <53E8E64DB2403849AFD89B7D4DAC8B2A5F8B59CA@ORSMSX106.amr.corp.intel.com> Hi I have bug fix for R10 Register clobbering with usage of ExternalAddress in the instructions. Webrev for the fix: http://cr.openjdk.java.net/~vdeshpande/8171974/webrev.00/ I have also updated the JBS entry. https://bugs.openjdk.java.net/browse/JDK-8171974 Would you please review and sponsor it. Regards, Vivek -------------- next part -------------- An HTML attachment was scrubbed... URL: From martin.doerr at sap.com Fri Dec 30 13:29:03 2016 From: martin.doerr at sap.com (Doerr, Martin) Date: Fri, 30 Dec 2016 13:29:03 +0000 Subject: RFR(S): 8172145: C2: anti dependence missed because store hidden by membar Message-ID: <72ca6f96ff7e4b2691c939d7b709b0c1@dewdfe13de06.global.corp.sap> Hi, we found a C2 Compiler bug which leads to incorrect reordering of memory accesses on PPC64 due to missing anti-dependency. Details are described here: https://bugs.openjdk.java.net/browse/JDK-8172145 Just a remark: In this case, it would be ok to reorder the load with the membar because the Java Memory Model allows that (normal load followed by volatile load, see [1]). The problem is that the membar hides the path to the store. The issue can be fixed by this webrev: http://cr.openjdk.java.net/~mdoerr/8172145_C2_antidep/webrev.00/ This change enables the path which sets LCA=early for the described situation. Then, the load gets scheduled in the same basic block as the membar (just in front of it). Please review. I will also need a sponsor, please. Thanks and best regards, Martin [1] http://g.oswego.edu/dl/jmm/cookbook.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From igor.ignatyev at oracle.com Fri Dec 30 13:51:03 2016 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Fri, 30 Dec 2016 16:51:03 +0300 Subject: RFR(S) : 8172149 : CTW library should call System::exit Message-ID: http://cr.openjdk.java.net/~iignatyev/8172149/webrev.00/ > 61 lines changed: 30 ins; 5 del; 26 mod; CTW might provoke execution, some (e.g. sun.tools.jconsole.OutputViewer[1]) can create new threads and hence cause CTW to hang. This fix updates CTW to call System::exit when all compilation tasks are completed. since jtreg does not like when tests call System::exit, testlibrary_tests/ctw tests have to be updated to start CTW from driver code rather than from jtreg test description. JBS: https://bugs.openjdk.java.net/browse/JDK-8172149 webrev: http://cr.openjdk.java.net/~iignatyev/8172149/webrev.00/ testing: affected tests locally [1] https://bugs.openjdk.java.net/browse/JDK-8159155 Thanks, ? Igor From aph at redhat.com Fri Dec 30 15:34:26 2016 From: aph at redhat.com (Andrew Haley) Date: Fri, 30 Dec 2016 15:34:26 +0000 Subject: RFR(S): 8172145: C2: anti dependence missed because store hidden by membar In-Reply-To: <72ca6f96ff7e4b2691c939d7b709b0c1@dewdfe13de06.global.corp.sap> References: <72ca6f96ff7e4b2691c939d7b709b0c1@dewdfe13de06.global.corp.sap> Message-ID: Hi, On 30/12/16 13:29, Doerr, Martin wrote: > > we found a C2 Compiler bug which leads to incorrect reordering of > memory accesses on PPC64 due to missing anti-dependency. Details are > described here: https://bugs.openjdk.java.net/browse/JDK-8172145 Another missing anti-dependency! > The issue can be fixed by this webrev: > http://cr.openjdk.java.net/~mdoerr/8172145_C2_antidep/webrev.00/ Wouldn't it make more sense to calculate is_Mach_MemBarVolatile lazily? Andrew. From vladimir.x.ivanov at oracle.com Fri Dec 30 16:51:02 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 30 Dec 2016 19:51:02 +0300 Subject: RFR(S) : 8172149 : CTW library should call System::exit In-Reply-To: References: Message-ID: Looks good. Best regards, Vladimir Ivanov On 12/30/16 4:51 PM, Igor Ignatyev wrote: > http://cr.openjdk.java.net/~iignatyev/8172149/webrev.00/ >> 61 lines changed: 30 ins; 5 del; 26 mod; > > CTW might provoke execution, some (e.g. sun.tools.jconsole.OutputViewer[1]) can create new threads and hence cause CTW to hang. This fix updates CTW to call System::exit when all compilation tasks are completed. since jtreg does not like when tests call System::exit, testlibrary_tests/ctw tests have to be updated to start CTW from driver code rather than from jtreg test description. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8172149 > webrev: http://cr.openjdk.java.net/~iignatyev/8172149/webrev.00/ > testing: affected tests locally > > [1] https://bugs.openjdk.java.net/browse/JDK-8159155 > > Thanks, > ? Igor > From dmitrij.pochepko at oracle.com Fri Dec 30 18:05:08 2016 From: dmitrij.pochepko at oracle.com (dmitrij pochepko) Date: Fri, 30 Dec 2016 21:05:08 +0300 Subject: RFR(S) : 8172149 : CTW library should call System::exit In-Reply-To: References: Message-ID: <8c85c861-6171-2d08-11b1-8a96a16be32b@oracle.com> Hi, looks good Thanks, Dmitrij On 30.12.2016 16:51, Igor Ignatyev wrote: > http://cr.openjdk.java.net/~iignatyev/8172149/webrev.00/ >> 61 lines changed: 30 ins; 5 del; 26 mod; > CTW might provoke execution, some (e.g. sun.tools.jconsole.OutputViewer[1]) can create new threads and hence cause CTW to hang. This fix updates CTW to call System::exit when all compilation tasks are completed. since jtreg does not like when tests call System::exit, testlibrary_tests/ctw tests have to be updated to start CTW from driver code rather than from jtreg test description. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8172149 > webrev: http://cr.openjdk.java.net/~iignatyev/8172149/webrev.00/ > testing: affected tests locally > > [1] https://bugs.openjdk.java.net/browse/JDK-8159155 > > Thanks, > ? Igor