RFR(L): JDK-8046936 : JEP 270: Reserved Stack Areas for Critical Sections

[David Holmes]

On 6/12/2015 2:23 AM, Doug Lea wrote:
> On 12/03/2015 12:53 AM, David Holmes wrote:
>> On 3/12/2015 12:56 AM, Doug Lea wrote:
>>> In the absence of any of: tail-recursion support, reliable cleanup,
>>> or growable stacks, it seems reasonable to choose larger default
>>> stack sizes so that these long but finite chains of completions
>>> are far less likely to hit SOE.
>>>
>>> On 32bit systems the 1MB limit is completely defensible. But expanding
>>> to say 64MB on 64bit systems would reduce practical encounters with
>>> SOE in these kinds of constructions by a factor of 64 or so.
>>> Is there any reason not to do this?
>>
>> The same discussion on the concurrency-interest mailing list seems to
>> indicate
>> that there are indeed reasons to not do this.
>>
>> http://cs.oswego.edu/pipermail/concurrency-interest/2015-December/014596.html
>>
>>
>
> And all of them amount to arguments that it could interfere
> with other configuration assumptions and practices.
> Perhaps hotspot could at least support simpler ways that
> fluent/functionally-flavored programs could override defaults
> to start up with more friendly settings (as in "java -XX:+FP" ...)

So some kind of guided ergonomics beyond that implied by server/client 
or raw machine parameters? Is there such a set that would be of general 
enough use to warrant something like -XX:+FP, or should these simply be 
set in a configuration file determined at deployment time?

Thanks,
David

>
> -Doug
>
>
>
>