Bringing Martin's JEP comment (https://bugs.openjdk.java.net/browse/JDK-8046936)
to the lists:
Approximately 100% of the cases of StackOverflowError (SOE) we
hear about lately on concurrency-interest are due to long chains
of CompletableFutures that exist because of the lack of
tail-recursion loopification by compilers. I don't think
any of these have involved ReentrantLocks, but some hit problems
due to lack of finally { ... } cleanup inside Executors upon SOE.
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?
-Doug
