Minimum stack size..

[Thomas Stüfe]

Oops, did not read your message carefully enough. My bad. I thought your
problem was on AIX.

Everything I said about LDR_CNTRL was only for AIX.


On Thu, Apr 18, 2013 at 8:17 AM, Steve Poole <spoole at linux.vnet.ibm.com>wrote:

> I don't think I'm setting LDR_CNTRL but I will check..
>
> On AIX the minimum stack size being reported is 768k
>
>
>
> On 17 Apr 2013, at 19:22, Thomas Stüfe <thomas.stuefe at gmail.com> wrote:
>
> Hi,
>
> Steve, did you maybe set LDR_CNTRL in your environment? If yes, and it
> forces C-heap pages to 64K, this may be the reason for the high default
> (1920k are 30 64K pages). A workaround may be to switch off 64K pages for
> the C-Heap (LDR_CNTRL="..DATAPSIZE=4K..")
>
> Stacks for java threads on AIX are allocated by the pthread library from
> C-heap and are therefore subject to the C-heap data page size, which can be
> either 4K or 64K. This depends on the setting you are running in - it can
> be changed via the LDR_CNTRL environment variable (eg
> LDR_CNTRL="..DATAPSIZE=64K..", see
> http://publib.boulder.ibm.com/infocenter/javasdk/v6r0/index.jsp?topic=%2Fcom.ibm.java.doc.user.aix32.60%2Fuser%2Faix_ldr_cntrl_page_sizes.html)
> or in the XCOFF itself (with ldedit, I think).
>
> I think the SAPJVM is able to cope with 64K pages in the C-Heap - we put
> some work into this - but the usual mode of operation is a C Heap page size
> of 4K. I think the wasteful stacks are the reason for that. For stacks, you
> want small pages.
>
> Note that all this stuff is independent from -XX:+UseLargePages, which
> changes the page size of the java heap but leaves the C heap page size
> alone.
>
> Kind Regards, Thomas
>
>
>
> On Wed, Apr 17, 2013 at 7:40 PM, Volker Simonis <volker.simonis at gmail.com>wrote:
>
>> Hi Steve,
>>
>> I suspected you'll come back with this issue, especially after I
>> pretended that it will be easy to fix :)
>>
>> You're actually right, the minimum stack size is computed at VM
>> startup from various other parameters one of which is the OS page
>> size.
>> It's a long standing problem in HotSpot that at various places it is
>> assumed that the default OS page size is 4k. That's obviously not true
>> anymore (on Linux/PPC it's usually 64k) and that leads to such kind of
>> errors (if you'd divide 1920k by 16 you'd get 120k which would be
>> reasonable).
>>
>> We've already changes this behavior in our SAP JVM  but that's quite a
>> large shared code change which we've omitted from the port so far.
>> Please let me discuss this with Goetz tomorrow to see haw we can fix
>> this for our port - but I think it would be reasonable to fix it in
>> the HotSpot and not in the test.
>>
>> Regards,
>> Volker
>>
>> On Wed, Apr 17, 2013 at 6:30 PM, Steve Poole <spoole at linux.vnet.ibm.com>
>> wrote:
>> >
>> > hi.  we are  working though the last remaining jtreg test failures for
>> > PPCAIX.
>> >
>> > I have some that are failing on Linux PPC as the  test explicitly sets
>> the
>> > minimum stack size  to "-Xss256k" . The VM then fails to launch with the
>> > usual error
>> >
>> > The stack size specified is too small, Specify at least 1920k
>> >   Error: Could not create the Java Virtual Machine.
>> >   Error: A fatal exception has occurred. Program will exit.
>> >
>> >
>> >
>> > So I can adjust the stack size in the testcases to suit this number or
>> > remove it altogether.  But...
>> >
>> > 1 - This number of 1920k seems a trifle  excessive  - is it something
>> I'm
>> > doing wrong in building hotspot or is this actually a reasonable number?
>> > 2 - Since it seems from reading the hotspot code that this number is
>> > calculated is there any Java API I can use to get this number so I can
>> make
>> > the tests more flexible?
>> >
>> >
>> > Cheers
>> >
>> >
>> >
>>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/attachments/20130418/d4f95d4e/attachment.html