<div dir="ltr">On 13 April 2013 00:18, Dmitry Olshansky <span dir="ltr"><<a href="mailto:dmitry.olsh@gmail.com" target="_blank">dmitry.olsh@gmail.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">12-Apr-2013 18:12, Manu пишет:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im">
On 13 April 2013 00:01, Regan Heath <<a href="mailto:regan@netmail.co.nz" target="_blank">regan@netmail.co.nz</a><br></div><div class="im">
<mailto:<a href="mailto:regan@netmail.co.nz" target="_blank">regan@netmail.co.nz</a>>> wrote:<br>
<br>
    So...<br>
<br>
    If the GC were to have a hook function for allocation and for free,<br>
    and if when these were in use it would not itself trigger collection.<br>
<br>
    Then...<br>
<br>
    Manu could supply hook functions, use the alloc function to supply<br>
    pre-allocated memory, and trigger collection as/when convenient.<br>
<br>
<br></div><div class="im">
Believe it or not, I'm not actually a fan of over-complexity. And I'm<br>
focusing here on totally unnecessary allocations.<br>
Isn't using the stack where applicable just a whole low easier? That's<br>
what it's there for.<br>
</div></blockquote>
<br>
'cause nobody can tell you how big it is. This knowledge is only available to end user and there is still no easy way to "tell" that to the library. The end result is utterly useless as library can't reliably use stack space.<br>
</blockquote><div><br></div><div style>Filenames, strings, etc have a fairly predictable size. Allocate slightly above that, and fallback to the heap upon overflow.</div><div style>I think it's safe to assume the stack is 'big enough' if you apply some common sense.<br>
</div><div style>It measures in the megabytes on PC's, I'm used to working on machines with ~32k stack, I use it aggressively, and I don't tend to run out.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

In the end if one library thinks it's fine to burn say 32K of stack with alloca but then it calls into another one that burns another chunk with alloca and so on untill happily stack overflowing (sometimes, on some systems at the right time!). Call graphs to calculate this is only available for the final app.<br>

<br>
Maybe just adding a separate thread-local growable stack for data would work - at least it wouldn't depend on sheer luck and particular OS settings.</blockquote><div><br></div><div>If you're saying the stack is a limited resource, therefore it's unsafe to use it, then you might as well argue that calling any function is an unsafe process.</div>
<div style>Some common sense is required. I wouldn't personally burn more than 1k in a single function, unless I knew it was close to a leaf by design (which many library calls are).</div><div style>90% of what we're dealing with here are strings, and they tend to measure in the 10s of bytes.</div>
</div></div></div>