RFR(M): 8170655: [posix] Fix minimum stack size computations
Lindenmaier, Goetz
goetz.lindenmaier at sap.com
Wed Dec 21 09:10:43 UTC 2016
Hi Dan,
it's in the repo, thanks a lot for your help, especially testing and making the closed changes!
Best regards,
Goetz
> -----Original Message-----
> From: Daniel D. Daugherty [mailto:daniel.daugherty at oracle.com]
> Sent: Wednesday, December 14, 2016 4:05 PM
> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; David Holmes
> <david.holmes at oracle.com>; Coleen Phillimore
> <coleen.phillimore at oracle.com>; hotspot-runtime-dev at openjdk.java.net
> Subject: Re: RFR(M): 8170655: [posix] Fix minimum stack size computations
>
> Thanks for the confirmation.
>
> Dan
>
>
> On 12/14/16 12:09 AM, Lindenmaier, Goetz wrote:
> > Hi Dan,
> >
> > Yes, that's the final versions including the errno->error fix.
> >
> > Best regards,
> > Goetz.
> >
> >
> >
> >> -----Original Message-----
> >> From: Daniel D. Daugherty [mailto:daniel.daugherty at oracle.com]
> >> Sent: Dienstag, 13. Dezember 2016 17:49
> >> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; David Holmes
> >> <david.holmes at oracle.com>; Coleen Phillimore
> >> <coleen.phillimore at oracle.com>; hotspot-runtime-
> dev at openjdk.java.net
> >> Subject: Re: RFR(M): 8170655: [posix] Fix minimum stack size
> computations
> >>
> >> Goetz,
> >>
> >> Does this latest webrev include the last of the code review changes that
> >> you were holding onto?
> >>
> >> Dan
> >>
> >>
> >> On 12/13/16 9:22 AM, Lindenmaier, Goetz wrote:
> >>> I messed up the link, the rebased webrev of 8170655 is
> >>> http://cr.openjdk.java.net/~goetz/wr16/8170655-
> >> compilerGuardFix/webrev.03/
> >>> Best regards,
> >>> Goetz.
> >>>
> >>> (I'll resend the mail on the other mail thread anyways ...)
> >>>
> >>>> -----Original Message-----
> >>>> From: Lindenmaier, Goetz
> >>>> Sent: Dienstag, 13. Dezember 2016 17:16
> >>>> To: 'daniel.daugherty at oracle.com' <daniel.daugherty at oracle.com>;
> David
> >>>> Holmes <david.holmes at oracle.com>; Coleen Phillimore
> >>>> <coleen.phillimore at oracle.com>; hotspot-runtime-
> dev at openjdk.java.net
> >>>> Subject: RE: RFR(M): 8170655: [posix] Fix minimum stack size
> computations
> >>>>
> >>>> Hi,
> >>>>
> >>>> I rebased 8170655 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: Dienstag, 13. Dezember 2016 16:45
> >>>>> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; David Holmes
> >>>>> <david.holmes at oracle.com>; Coleen Phillimore
> >>>>> <coleen.phillimore at oracle.com>; hotspot-runtime-
> dev at openjdk.java.net
> >>>>> Subject: Re: RFR(M): 8170655: [posix] Fix minimum stack size
> computations
> >>>>>
> >>>>> The current set of RBT test results looks bad. I suspect a mismatch
> >>>>> between current test suite version(s) and the baseline that I used.
> >>>>> I created the repo for 8169373 back on 2016.12.02 and the last
> >>>>> changeset in hotspot at that time was dated 2016.11.30... so the
> >>>>> baseline on which I applied your changes is almost 2 weeks out of
> >>>>> date (pre-dates the latest Jigsaw refresh)...
> >>>>>
> >>>>> > Should I rebase the changes to the latest repo version?
> >>>>>
> >>>>> If you don't mind rebasing both patches (8169373 and 8170655) to the
> >>>>> current JDK9-hs, that would be appreciated. Thanks!
> >>>>>
> >>>>> Dan
> >>>>>
> >>>>>
> >>>>>
> >>>>> On 12/13/16 8:17 AM, Daniel D. Daugherty wrote:
> >>>>>> Both 8169373 and 8170655 are bug fixes so they do not have to be
> >>>>>> in by the extended Feature Complete deadline. If they did, I would
> >>>>>> be going through more Tums than I already am... :-)
> >>>>>>
> >>>>>> Dan
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> On 12/13/16 8:02 AM, Lindenmaier, Goetz wrote:
> >>>>>>> Hi Dan,
> >>>>>>>
> >>>>>>> that sounds bad ... thanks for your update! Yes, I also have the
> >>>>>>> Feature
> >>>>>>> Complete deadline in mind, that's why I would like to see the
> changes
> >>>>>>> committed :) But obviously I currently can't help.
> >>>>>>>
> >>>>>>> Thanks,
> >>>>>>> Goetz.
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>> -----Original Message-----
> >>>>>>>> From: Daniel D. Daugherty [mailto:daniel.daugherty at oracle.com]
> >>>>>>>> Sent: Dienstag, 13. Dezember 2016 15:56
> >>>>>>>> To: David Holmes <david.holmes at oracle.com>; Lindenmaier,
> Goetz
> >>>>>>>> <goetz.lindenmaier at sap.com>; Coleen Phillimore
> >>>>>>>> <coleen.phillimore at oracle.com>; hotspot-runtime-
> >> dev at openjdk.java.net
> >>>>>>>> Subject: Re: RFR(M): 8170655: [posix] Fix minimum stack size
> >>>>>>>> computations
> >>>>>>>>
> >>>>>>>> Hi Goetz,
> >>>>>>>>
> >>>>>>>> JDK9-hs is still closed for the run up to extended Feature Complete.
> >>>>>>>> Should be open again sometime soon.
> >>>>>>>>
> >>>>>>>> I kicked off a "full RBT" run on 8169373 last Monday. It ran for
> four
> >>>>>>>> days before it collided with a maintenance window on the Aurora
> DB.
> >>>>>>>> I kicked off a "full RBT" run on 8170655 last Tuesday. It ran for
> three
> >>>>>>>> days before it collided with the same brick wall.
> >>>>>>>>
> >>>>>>>> Neither RBT run is complete; in fact there are entire platforms
> with
> >>>>>>>> zero results so they are pretty much useless. Normally RBT runs
> don't
> >>>>>>>> take more than a couple of days, but our internal test systems are
> a
> >>>>>>>> bit swamped due to the upcoming extended Feature Complete
> >> deadline.
> >>>>>>>> I did start another "full RBT" run on 8169373 on Sunday, but it is
> >>>>>>>> not complete either. I was hoping to have all the testing done by
> >>>>>>>> the time JDK9-hs reopened, but it looks like that is not going to
> >>>>>>>> happen.
> >>>>>>>>
> >>>>>>>> Dan
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On 12/13/16 1:41 AM, David Holmes wrote:
> >>>>>>>>> On 13/12/2016 6:16 PM, Lindenmaier, Goetz wrote:
> >>>>>>>>>> Hi Dan,
> >>>>>>>>>>
> >>>>>>>>>> what's the status of my changes? I think hs is open again, at
> least
> >>>>>>>>>> I see changes popping up ... just a gentle reminder :)
> >>>>>>>>> Actually it is closed (again?) other than for selective changes as
> we
> >>>>>>>>> had to pull down the big jigsaw update from dev, and merge in
> with
> >>>> AOT
> >>>>>>>>> push, and a couple of other approved changes, and need things
> to
> >>>>>>>>> stabilise so we can push up to dev.
> >>>>>>>>>
> >>>>>>>>> David
> >>>>>>>>>
> >>>>>>>>>> Should I rebase the changes to the latest repo version?
> >>>>>>>>>>
> >>>>>>>>>> Best regards,
> >>>>>>>>>> Goetz.
> >>>>>>>>>>
> >>>>>>>>>>> -----Original Message-----
> >>>>>>>>>>> From: Daniel D. Daugherty
> [mailto:daniel.daugherty at oracle.com]
> >>>>>>>>>>> Sent: Dienstag, 6. Dezember 2016 22:15
> >>>>>>>>>>> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>;
> Coleen
> >>>>>>>>>>> Phillimore
> >>>>>>>>>>> <coleen.phillimore at oracle.com>; hotspot-runtime-
> >>>>> dev at openjdk.java.net
> >>>>>>>>>>> Subject: Re: RFR(M): 8170655: [posix] Fix minimum stack size
> >>>>>>>>>>> computations
> >>>>>>>>>>>
> >>>>>>>>>>> On 12/6/16 1:31 PM, Lindenmaier, Goetz wrote:
> >>>>>>>>>>>> Hi Dan,
> >>>>>>>>>>>>
> >>>>>>>>>>>> I fixed the comment. I will post a new webrev once the other
> >>>>>>>>>>>> change is pushed so that I can make a real change.
> >>>>>>>>>>> I'll resync my repo to the webrev.02 version and restart my
> >>>>>>>>>>> testing on this fix. I'm hoping we have only comment changes
> >>>>>>>>>>> after the webrev.02 version...
> >>>>>>>>>>>
> >>>>>>>>>>> Also gotta check the test results on 8169373.
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>>> Meta question: Now _java_thread_min_stack_allowed
> is
> >>>>>>>>>>>>> specific to an
> >>>>>>>>>>>>> OS/CPU platform (as are the other two). That OS/CPU
> >>>>>>>>>>>>> platform
> >>>>>>>>>>>>> enumeration
> >>>>>>>>>>>>> doesn't take into account whether C1 or C2 is in play.
> We
> >>>>>>>>>>>>> used to add
> >>>>>>>>>>>>> just a little more space via the COMPILER2_PRESENT()
> >> macro,
> >>>>>>>>>>>>> but now
> >>>>>>>>>>> we
> >>>>>>>>>>>>> don't. Yes, I know that you've done a bunch of testing
> and
> >>>>>>>>>>>>> I'm running
> >>>>>>>>>>>>> our usual batch of tests also, but this subtle change is
> >>>>>>>>>>>>> bothering
> >>>>>>>>>>>> Yep, I could have made sizing with C1, then C2, then
> >>>>>>>>>>>> TieredCompilation,
> >>>>>>>>>>>> but I don't think that would make a change.
> >>>>>>>>>>>> This extra size was meant for the compiler thread. 83251780
> >> moved
> >>>>>>>>>>>> it to the
> >>>>>>>>>>>> Java threads. I think it was there because C2 used to have
> >>>>>>>>>>>> recursive
> >>>>>>>>>>> algorithms.
> >>>>>>>>>>>> But it only would have had an effect in rare situations
> because the
> >>>>>>>>>>>> other MAX
> >>>>>>>>>>>> should mostly be used on systems with large pages, where
> the
> >>>>>>>>>>>> alignement
> >>>>>>>>>>>> would bring more than these 4K. The compiler gained the
> >>>> alignment
> >>>>>>>>>>>> of the
> >>>>>>>>>>>> vm_default_page_size() region plus the space gained by
> bigger
> >>>>>>>>>>> StackShadowPages
> >>>>>>>>>>>> which were huge at some point (20+ pages * 64K ...).
> Remember
> >> the
> >>>>>>>>>>> compiler does
> >>>>>>>>>>>> no stack banging and thus could use the shadow region.
> >>>>>>>>>>>>
> >>>>>>>>>>>> The original code looked like this:
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>
> http://hg.openjdk.java.net/jdk8/jdk8/hotspot/file/87ee5ee27509/src/os/linu
> x/v
> >>>>>>>>>>> m/os_linux.cpp
> >>>>>>>>>>>> os::Linux::min_stack_allowed =
> >>>>>>>>>>>> MAX2(os::Linux::min_stack_allowed,
> >>>>>>>>>>>>
> (size_t)(StackYellowPages+StackRedPages+StackShadowPages) *
> >>>>>>>>>>> Linux::page_size() +
> >>>>>>>>>>>> (2*BytesPerWord COMPILER2_PRESENT(+1)) *
> >>>>>>>>>>> Linux::vm_default_page_size());
> >>>>>>>>>>>
> >>>>>>>>>>> I'm good with this explanation. Coleen?
> >>>>>>>>>>>
> >>>>>>>>>>> Dan
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>> Best regards,
> >>>>>>>>>>>> Goetz.
> >>>>>>>>>>>>
> >>>>>>>>>>>>> -----Original Message-----
> >>>>>>>>>>>>> From: Daniel D. Daugherty
> >> [mailto:daniel.daugherty at oracle.com]
> >>>>>>>>>>>>> Sent: Tuesday, December 06, 2016 8:32 PM
> >>>>>>>>>>>>> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>;
> Coleen
> >>>>>>>> Phillimore
> >>>>>>>>>>>>> <coleen.phillimore at oracle.com>; hotspot-runtime-
> >>>>>>>> dev at openjdk.java.net
> >>>>>>>>>>>>> Subject: Re: RFR(M): 8170655: [posix] Fix minimum stack
> size
> >>>>>>>>>>>>> computations
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> On 12/6/16 2:35 AM, Lindenmaier, Goetz wrote:
> >>>>>>>>>>>>>> Hi Coleen,
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> thanks for looking at this change!
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> New webrev:
> >>>>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8170655-
> >>>>>>>>>>>>> compilerGuardFix/webrev.02/
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> 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
> >>>>>>>>>>>>> L1112: // It dependes on word size, platform calling
> >>>>>>>>>>>>> conventions, C
> >>>>>>>>>>>>> frame layout and
> >>>>>>>>>>>>> Typo: 'dependes' -> 'depends'
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> If you put "It" at the end of the sentence on the
> >>>>>>>>>>>>> previous
> >>>>>>>>>>>>> line, then the formatting will look better. :-)
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Meta question: Now _java_thread_min_stack_allowed
> is
> >>>>>>>>>>>>> specific to an
> >>>>>>>>>>>>> OS/CPU platform (as are the other two). That OS/CPU
> >>>>>>>>>>>>> platform
> >>>>>>>>>>>>> enumeration
> >>>>>>>>>>>>> doesn't take into account whether C1 or C2 is in play.
> We
> >>>>>>>>>>>>> used to add
> >>>>>>>>>>>>> just a little more space via the COMPILER2_PRESENT()
> >> macro,
> >>>>>>>>>>>>> but now
> >>>>>>>>>>> we
> >>>>>>>>>>>>> don't. Yes, I know that you've done a bunch of testing
> and
> >>>>>>>>>>>>> I'm running
> >>>>>>>>>>>>> our usual batch of tests also, but this subtle change is
> >>>>>>>>>>>>> bothering
> >>>>>>>>>>>>> me...
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> src/os/posix/vm/os_posix.hpp
> >>>>>>>>>>>>> No comments.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> src/os_cpu/aix_ppc/vm/os_aix_ppc.cpp
> >>>>>>>>>>>>> No comments.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> 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
> >>>>>>>>>>>>> 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/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
> >>>>>>>>>>>>> No comments.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Dan
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> See my comments inline.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> -----Original Message-----
> >>>>>>>>>>>>>>> From: hotspot-runtime-dev [mailto:hotspot-runtime-dev-
> >>>>>>>>>>>>>>> bounces at openjdk.java.net] On Behalf Of Coleen
> Phillimore
> >>>>>>>>>>>>>>> Sent: Dienstag, 6. Dezember 2016 01:00
> >>>>>>>>>>>>>>> To: hotspot-runtime-dev at openjdk.java.net
> >>>>>>>>>>>>>>> Subject: Re: RFR(M): 8170655: [posix] Fix minimum stack
> size
> >>>>>>>>>>>>> computations
> >>>>>>>>>>>>>>> On 12/5/16 6: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...
> >>>>>>>>>>>>>>> Thank you, Dan for sponsoring this.
> >>>>>>>>>>>>>>>> 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.
> >>>>>>>>>>>>>>> Yes, I think with refactoring, this is dead code. I think you
> >>>>>>>>>>>>>>> should
> >>>>>>>>>>>>>>> remove it, and make 8161093 a duplicate so it can be
> closed
> >>>> with
> >>>>>>>>>>>>>>> this fix.
> >>>>>>>>>>>>>> I removed the code and closed the bug as duplicate.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> The changes in this file (adding the guard_size and
> >> shadow_size)
> >>>>>>>>>>>>>>> are a
> >>>>>>>>>>>>>>> lot cleaner than the max of some random number of
> pages
> >>>>> someone
> >>>>>>>>>>>>>>> calculated a long time ago.
> >>>>>>>>>>>>>> Thanks!
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> There's a comment above this function that should be
> >>>>>>>>>>>>>>> rewritten also
> >>>>>>>>>>>>> though:
> >>>>>>>>>>>>>>> // Check minimum allowable stack sizes for thread
> creation
> >>>>>>>>>>>>>>> and to
> >>>>>>>>>>>>> initialize
> >>>>>>>>>>>>>>> // the java system classes, including StackOverflowError -
> >>>>>>>>>>>>>>> depends on
> >>>>>>>>>>>>> page
> >>>>>>>>>>>>>>> // size. Add two 4K pages for compiler2 recursion in main
> >>>>>>>>>>>>>>> thread.
> >>>>>>>>>>>>>>> // Add in 4*BytesPerWord 4K pages to account for VM
> stack
> >>>>> during
> >>>>>>>>>>>>>>> // class initialization depending on 32 or 64 bit VM.
> >>>>>>>>>>>>>> Dan saw this too. I wrote a summary of the text in the bug.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8170655-
> >>>>>>>>>>>>>>>
> >>
> compilerGuardFix/webrev.01/src/os_cpu/linux_sparc/vm/os_linux_sparc.cpp
> >>>>>>>>>>>>> .u
> >>>>>>>>>>>>>>> diff.html
> >>>>>>>>>>>>>>> This seems small. I don't think it should be reduced
> because I
> >>>>>>>>>>>>>>> don't
> >>>>>>>>>>>>>>> think we have a lot of testing for this platform.
> >>>>>>>>>>>>>> I changed it to 64K. I can't test on this platform, so this
> >>>>>>>>>>>>>> probably really is
> >>>>>>>>>>>>> better.
> >>>>>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8170655-
> >>>>>>>>>>>>>>>
> >>
> compilerGuardFix/webrev.01/src/os_cpu/linux_x86/vm/os_linux_x86.cpp.ud
> >>>>>>>>>>>>> iff.
> >>>>>>>>>>>>>>> html
> >>>>>>>>>>>>>>> Why is DEBUG_ONLY( + 4) removed? We do run native
> JVM
> >>>> code
> >>>>>>>> with
> >>>>>>>>>>>>>>> debugging on in Java threads also, although the +4 seems
> >>>>>>>>>>>>>>> arbitrary.
> >>>>>>>>>>>>>> I checked startup and ran jvm98 and did not find any
> >>>>>>>>>>>>>> differences in
> >>>>>>>>>>>>> slowdebug/opt
> >>>>>>>>>>>>>> variants. So I thought I should get rid of this. Also, this kind
> >>>>>>>>>>>>>> of accounts for
> >>>>>>>>>>>>> the
> >>>>>>>>>>>>>> extra space of shadow pages in dbg builds, which now is no
> >> more
> >>>>>>>>>>>>>> included
> >>>>>>>>>>>>> in that
> >>>>>>>>>>>>>> number.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> If you're removing the concept of DEBUG_ONLY to these
> sizes,
> >> it
> >>>>>>>>>>>>>>> still
> >>>>>>>>>>>>>>> remains in this change:
> >>>>>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8170655-
> >>>>>>>>>>>>>>>
> >>
> compilerGuardFix/webrev.01/src/os_cpu/linux_s390/vm/os_linux_s390.cpp.
> >>>>>>>>>>>>> udi
> >>>>>>>>>>>>>>> ff.html
> >>>>>>>>>>>>>> On s390, I quickly ran into stack overflows with the debug
> build.
> >>>>>>>>>>>>>> Therefore
> >>>>>>>>>>>>>> I increased the sizes.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> I assume that all these minimum stack sizes have been
> tested
> >> in
> >>>>>>>>>>>>>>> your lab.
> >>>>>>>>>>>>>> Yes, the change is running with our nighly tests on the
> platforms
> >>>>>>>>>>>>>> we have
> >>>>>>>>>>>>> available.
> >>>>>>>>>>>>>> This includes jck tests and hotspot jtreg tests.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> This seems like a good change but I hope this is the last of
> >>>>>>>>>>>>>>> these until
> >>>>>>>>>>>>>>> JDK10 opens.
> >>>>>>>>>>>>>> :) Yes, stack changes kind of got my special hobby ... I
> >>>>>>>>>>>>>> still have
> >>>>>>>>>>>>> implementing
> >>>>>>>>>>>>>> StackReservedPages support on s390 on my list, but that
> should
> >> be
> >>>>>>>>>>>>> platform-only.
> >>>>>>>>>>>>>> Also I'm not sure whether I'll find time for that.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Best regards,
> >>>>>>>>>>>>>> Goetz.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Thanks,
> >>>>>>>>>>>>>>> Coleen
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> 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.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> <pre>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> 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
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> </pre>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
More information about the hotspot-runtime-dev
mailing list