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

Doug Lea dl at cs.oswego.edu
Sat Dec 5 16:23:49 UTC 2015

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" ...)


More information about the hotspot-dev mailing list