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

Vitaly Davidovich vitalyd at gmail.com
Mon Dec 7 09:35:35 EST 2015


Right, Hotspot uses traditional OS stacks with guard pages.  As for size
checks, prior to calling a method the stack is probed to see if guard page
access is tripped (i.e. stack banging).

sent from my phone
On Dec 7, 2015 8:35 AM, "Alex Otenko" <oleksandr.otenko at gmail.com> wrote:

> 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
>
> Rust discussion on them:
> 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> wrote:
>
>> For my benefit, what is a segmented stack?
>>
>> Alex
>>
>> On 3 Dec 2015, at 00:45, Vitaly Davidovich <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>
>> wrote:
>>
>>>
>>>
>>> On Wed, Dec 2, 2015 at 9:40 AM, Nathan Reynolds <
>>> 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
>>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>>>
>>>
>> _______________________________________________
>> Concurrency-interest mailing list
>> Concurrency-interest at cs.oswego.edu
>> 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/b2edec3e/attachment.html>


More information about the Concurrency-interest mailing list