<div dir="ltr">On 10 April 2013 23:45, Benjamin Thaut <span dir="ltr"><<a href="mailto:code@benjamin-thaut.de" target="_blank">code@benjamin-thaut.de</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Am 09.04.2013 14:00, schrieb Johannes Pfau:<div><div class="h5"><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Am Tue, 09 Apr 2013 11:29:09 +0100<br>
schrieb "Regan Heath" <<a href="mailto:regan@netmail.co.nz" target="_blank">regan@netmail.co.nz</a>>:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
A good & simple start would be a -vgc switch, similar to -vtls which<br>
prints out all hidden memory allocations. Custom allocators are<br>
still important for the library (toString etc). Apart from that I<br>
would just stay away from language features which allocate. For<br>
example instead of using the concatenate operators I'd just use<br>
something like appender (which should then support custom<br>
allocators).<br>
</blockquote>
<br>
Did you see Manu's problem case?  I can't recall the method name but<br>
it was not one which suggested it would allocate, and it didn't in<br>
the general case but in a very specific case it did.  As it stands,<br>
it's very hard to tell which language features allocate (without code<br>
inspection of the compiler and standard library) so it's hard to<br>
avoid.<br>
<br>
R<br>
<br>
</blockquote>
<br>
toUpperInPlace IIRC? Yes, -vgc would not directly help here as<br>
toUpperInPlace is a library function. But I think this is a library /<br>
documentation bug:<br>
<br>
1: We should explicitly document if a function is not supposed to<br>
    allocate<br>
2: If a function is called "inPlace" but can still allocate, it needs a<br>
    huge red warning.<br>
<br>
Those kind of things can be solved partially with correctly documented<br>
functions. But hidden allocations caused by the language (closures,<br>
array literals) are imho more dangerous and -vgc could help there.<br>
Without -vgc it's very difficult to verify if some code could call into<br>
the gc.<br>
<br>
Btw: implementing -vgc shouldn't be too difficult: We have to check all<br>
runtime hooks ( <a href="http://wiki.dlang.org/Runtime_Hooks" target="_blank">http://wiki.dlang.org/Runtime_<u></u>Hooks</a> ) for allocations,<br>
then check all places in dmd where calls to those hooks are emitted.<br>
<br>
</blockquote>
<br></div></div>
It's actually very easy to find hidden allocations. If you remove the gc entierly from the runtime hidden allocations will cause linker errors.<br></blockquote><div><br></div><div style>Not a particularly user-friendly approach. I'd rather think of some proper tools/mechanisms to help in this area :)</div>
</div></div></div>