RFR(L): JDK-8046936 : JEP 270: Reserved Stack Areas for Critical Sections
david.holmes at oracle.com
Mon Dec 7 00:51:19 UTC 2015
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
>> that there are indeed reasons to not do this.
> 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?
More information about the hotspot-dev