8050044: (process) Increase reaper thread native stack size by a factor of 2

[Rob McKenna]

Hi folks,

A very simple change suggested by Martin a while back in another review. 
I'm just getting around to it now:


bug: https://bugs.openjdk.java.net/browse/JDK-8050044
webrev: http://cr.openjdk.java.net/~robm/8050044/webrev.01/

Martins comments: 
http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-March/025943.html


-Rob

Re: 8050044: (process) Increase reaper thread native stack size by a factor of 2

[Martin Buchholz]

Looks good to me!


On Tue, Jul 15, 2014 at 10:46 AM, Rob McKenna 
wrote:

> Hi folks,
>
> A very simple change suggested by Martin a while back in another review.
> I'm just getting around to it now:
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8050044
> webrev: http://cr.openjdk.java.net/~robm/8050044/webrev.01/
>
> Martins comments: http://mail.openjdk.java.net/
> pipermail/core-libs-dev/2014-March/025943.html
>
> -Rob
>
>

Re: 8050044: (process) Increase reaper thread native stack size by a factor of 2

[roger riggs]

Hi Rob,

Is there any evidence that needs more space?  Is there any way to tell 
how much of

the existing 32k is being used?
The reaper has very limited processing to do and there is one thread for 
every process spawned.


Roger


On 7/15/2014 1:46 PM, Rob McKenna wrote:

Hi folks,

A very simple change suggested by Martin a while back in another 
review. I'm just getting around to it now:


bug: https://bugs.openjdk.java.net/browse/JDK-8050044
webrev: http://cr.openjdk.java.net/~robm/8050044/webrev.01/

Martins comments: 
http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-March/025943.html


-Rob

Re: 8050044: (process) Increase reaper thread native stack size by a factor of 2

[roger riggs]

Hi Martin,

Wait a minute,  can you provide more motivation, observation. etc.
it really does not seem necessary and just because everything is bigger 
is pretty weak.


Thanks, Roger


On 7/15/2014 1:48 PM, Martin Buchholz wrote:

Looks good to me!


On Tue, Jul 15, 2014 at 10:46 AM, Rob McKenna 
wrote:


Hi folks,

A very simple change suggested by Martin a while back in another review.
I'm just getting around to it now:

bug: https://bugs.openjdk.java.net/browse/JDK-8050044
webrev: http://cr.openjdk.java.net/~robm/8050044/webrev.01/

Martins comments: http://mail.openjdk.java.net/
pipermail/core-libs-dev/2014-March/025943.html

 -Rob

Re: 8050044: (process) Increase reaper thread native stack size by a factor of 2

[Martin Buchholz]

The fear is that stack sizes and alignments have grown over time, and
thread stacks are acquiring things like guard pages, and those pages may
(incorrectly) end up getting included in the stack size.  I'm particularly
afraid of the hotspot guard page code.

It may be worthwhile seeing how low you can make the stack size on popular
platforms before the jtreg tests for process fall over, then multiply by 10
at least.

We are approaching the 64-bit only era, when address space restrictions
won't be a problem (for a while)


On Tue, Jul 15, 2014 at 10:51 AM, roger riggs 
wrote:

> Hi Rob,
>
> Is there any evidence that needs more space?  Is there any way to tell how
> much of
> the existing 32k is being used?
> The reaper has very limited processing to do and there is one thread for
> every process spawned.
>
> Roger
>
>
>
> On 7/15/2014 1:46 PM, Rob McKenna wrote:
>
>> Hi folks,
>>
>> A very simple change suggested by Martin a while back in another review.
>> I'm just getting around to it now:
>>
>> bug: https://bugs.openjdk.java.net/browse/JDK-8050044
>> webrev: http://cr.openjdk.java.net/~robm/8050044/webrev.01/
>>
>> Martins comments: http://mail.openjdk.java.net/
>> pipermail/core-libs-dev/2014-March/025943.html
>>
>> -Rob
>>
>>
>

Re: 8050044: (process) Increase reaper thread native stack size by a factor of 2

[Rob McKenna]

So doing a bit of homework should probably have been my first approach.

Interestingly, we are never actually going to have only 32k allocated 
for the stack. The VM will allocate the 
os::Solaris|Linux|etc::min_stack_allowed size which is a minimum of 48k 
on some platforms but generally 64k+. Windows goes to the trouble of 
calculating the value based on the guard pages and some other variables.


In effect, with the 32k value we're asking the (more specifically, our) 
VM to allocate the minimum possible stack which is calculated on a 
per-platform basis. Perhaps the "fix" for this bug should really just be 
a comment acknowledging that this is a minimum acceptable value and the 
VM will likely determine the actual size?


-Rob

On 15/07/14 18:58, Martin Buchholz wrote:

The fear is that stack sizes and alignments have grown over time, and
thread stacks are acquiring things like guard pages, and those pages may
(incorrectly) end up getting included in the stack size.  I'm particularly
afraid of the hotspot guard page code.

It may be worthwhile seeing how low you can make the stack size on popular
platforms before the jtreg tests for process fall over, then multiply by 10
at least.

We are approaching the 64-bit only era, when address space restrictions
won't be a problem (for a while)


On Tue, Jul 15, 2014 at 10:51 AM, roger riggs 
wrote:


Hi Rob,

Is there any evidence that needs more space?  Is there any way to tell how
much of
the existing 32k is being used?
The reaper has very limited processing to do and there is one thread for
every process spawned.

Roger



On 7/15/2014 1:46 PM, Rob McKenna wrote:


Hi folks,

A very simple change suggested by Martin a while back in another review.
I'm just getting around to it now:

bug: https://bugs.openjdk.java.net/browse/JDK-8050044
webrev: http://cr.openjdk.java.net/~robm/8050044/webrev.01/

Martins comments: http://mail.openjdk.java.net/
pipermail/core-libs-dev/2014-March/025943.html

 -Rob

Re: 8050044: (process) Increase reaper thread native stack size by a factor of 2

[Martin Buchholz]

Alright, we can abandon this change.  In practice, tests on different
platforms will usually catch SOE before users encounter it, because the
stacks are all almost identical.  Unless there is e.g. a hotspot bug that
causes thread local variables to be allocated inside the stack size instead
of outside.

Is there monitoring available that can warn when e.g. stack high-water mark
is ever more than 50%?


On Fri, Jul 18, 2014 at 7:40 AM, Rob McKenna  wrote:

> So doing a bit of homework should probably have been my first approach.
>
> Interestingly, we are never actually going to have only 32k allocated for
> the stack. The VM will allocate the os::Solaris|Linux|etc::min_stack_allowed
> size which is a minimum of 48k on some platforms but generally 64k+.
> Windows goes to the trouble of calculating the value based on the guard
> pages and some other variables.
>
> In effect, with the 32k value we're asking the (more specifically, our) VM
> to allocate the minimum possible stack which is calculated on a
> per-platform basis. Perhaps the "fix" for this bug should really just be a
> comment acknowledging that this is a minimum acceptable value and the VM
> will likely determine the actual size?
>
> -Rob
>
>
> On 15/07/14 18:58, Martin Buchholz wrote:
>
>> The fear is that stack sizes and alignments have grown over time, and
>> thread stacks are acquiring things like guard pages, and those pages may
>> (incorrectly) end up getting included in the stack size.  I'm particularly
>> afraid of the hotspot guard page code.
>>
>> It may be worthwhile seeing how low you can make the stack size on popular
>> platforms before the jtreg tests for process fall over, then multiply by
>> 10
>> at least.
>>
>> We are approaching the 64-bit only era, when address space restrictions
>> won't be a problem (for a while)
>>
>>
>> On Tue, Jul 15, 2014 at 10:51 AM, roger riggs 
>> wrote:
>>
>>  Hi Rob,
>>>
>>> Is there any evidence that needs more space?  Is there any way to tell
>>> how
>>> much of
>>> the existing 32k is being used?
>>> The reaper has very limited processing to do and there is one thread for
>>> every process spawned.
>>>
>>> Roger
>>>
>>>
>>>
>>> On 7/15/2014 1:46 PM, Rob McKenna wrote:
>>>
>>>  Hi folks,

 A very simple change suggested by Martin a while back in another review.
 I'm just getting around to it now:

 bug: https://bugs.openjdk.java.net/browse/JDK-8050044
 webrev: http://cr.openjdk.java.net/~robm/8050044/webrev.01/

 Martins comments: http://mail.openjdk.java.net/
 pipermail/core-libs-dev/2014-March/025943.html

  -Rob



>

Re: RFR: 8050044: (process) Increase reaper thread native stack size by a factor of 2

[Rob McKenna]

And as in that review you have managed to intercept me before I made a 
small correction. In this case to the subject.


I'm beginning to suspect you're a highly sophisticated bot.

-Rob

On 15/07/14 18:48, Martin Buchholz wrote:

Looks good to me!


On Tue, Jul 15, 2014 at 10:46 AM, Rob McKenna > wrote:


Hi folks,

A very simple change suggested by Martin a while back in another
review. I'm just getting around to it now:

bug: https://bugs.openjdk.java.net/browse/JDK-8050044
webrev: http://cr.openjdk.java.net/~robm/8050044/webrev.01/


Martins comments:
http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-March/025943.html

-Rob

Re: RFR: 8050044: (process) Increase reaper thread native stack size by a factor of 2

[Rob McKenna]

I have not made any empirical measurements. I was following up on 
Martins suggestion. I'll try to put some time aside for testing later 
this week though.


-Rob

On 15/07/14 18:51, roger riggs wrote:

Hi Rob,

Is there any evidence that needs more space?  Is there any way to tell 
how much of

the existing 32k is being used?
The reaper has very limited processing to do and there is one thread 
for every process spawned.


Roger


On 7/15/2014 1:46 PM, Rob McKenna wrote:

Hi folks,

A very simple change suggested by Martin a while back in another 
review. I'm just getting around to it now:


bug: https://bugs.openjdk.java.net/browse/JDK-8050044
webrev: http://cr.openjdk.java.net/~robm/8050044/webrev.01/

Martins comments: 
http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-March/025943.html


-Rob