[concurrency-interest] Default Stack Size on 64-bit JVMs

Alex Otenko oleksandr.otenko at gmail.com
Mon Dec 7 08:35:39 EST 2015


Got it. It looks quite different from what (I think) Java uses. Doesn’t HotSpot use “guard pages” rather than in-code stack size checks + linked lists of stack frames?

Alex

> On 7 Dec 2015, at 13:04, Vitaly Davidovich <vitalyd at gmail.com> wrote:
> 
> http://llvm.org/releases/3.0/docs/SegmentedStacks.html <http://llvm.org/releases/3.0/docs/SegmentedStacks.html>
> Rust discussion on them: https://mail.mozilla.org/pipermail/rust-dev/2013-November/006314.html <https://mail.mozilla.org/pipermail/rust-dev/2013-November/006314.html>
> sent from my phone
> 
> On Dec 7, 2015 4:39 AM, "Alex Otenko" <oleksandr.otenko at gmail.com <mailto:oleksandr.otenko at gmail.com>> wrote:
> For my benefit, what is a segmented stack?
> 
> Alex
> 
>> On 3 Dec 2015, at 00:45, Vitaly Davidovich <vitalyd at gmail.com <mailto:vitalyd at gmail.com>> wrote:
>> 
>> and of course start working on the difficult task of being able to move the stack so that if you run out of room, simply realloc and move elsewhere, like the competition is doing.
>> 
>> IIRC, Rust moved away from segmented stacks.  Go I guess still uses them? It's likely a performance loss for ordinary threading, but would be required for coroutine/fiber support (like Go has). 
>> 
>> On Wed, Dec 2, 2015 at 7:12 PM, Martin Buchholz <martinrb at google.com <mailto:martinrb at google.com>> wrote:
>> 
>> 
>> On Wed, Dec 2, 2015 at 9:40 AM, Nathan Reynolds <nathan.reynolds at oracle.com <mailto:nathan.reynolds at oracle.com>> wrote:
>> 
>> First, the larger stack size eats up address space.  As far as resources go, it is very cheap at this point in time on a 64-bit machine.  25 years ago we said the same thing about virtual address space on 32-bit machines.  We've got about 60 years before we will start exhausting the 64-bit address space.  So, let's ignore that for now.  Today's problem comes when doing sizing calculations.  People will see the address space size and figure that is what is needed for the process in terms of RAM.  Then the entire sizing calculation goes haywire and machines end up over sized.  As a cloud provider, I don't mind people spending more money on RAM they aren't using.  :)
>> 
>> The assumption is that the VM implementers can manage to spend _only_ address space.  Maybe mmap with PROT_NONE, maybe madvise(DONT_USE), whatever it takes to convince the OS (and ps!) that you're not really using that memory ... yet 
>> 
>> ... and of course start working on the difficult task of being able to move the stack so that if you run out of room, simply realloc and move elsewhere, like the competition is doing.
>> 
>> _______________________________________________
>> Concurrency-interest mailing list
>> Concurrency-interest at cs.oswego.edu <mailto:Concurrency-interest at cs.oswego.edu>
>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest <http://cs.oswego.edu/mailman/listinfo/concurrency-interest>
>> 
>> 
>> _______________________________________________
>> Concurrency-interest mailing list
>> Concurrency-interest at cs.oswego.edu <mailto:Concurrency-interest at cs.oswego.edu>
>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest <http://cs.oswego.edu/mailman/listinfo/concurrency-interest>
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20151207/eea644c3/attachment-0001.html>


More information about the Concurrency-interest mailing list