<div dir="auto"><div>I'm not sure I understand. Are you saying allocateMightFail ignores the usual nursery size? That's not my intention. It would actually be just fine to simply fail if GC would be required--I can then back off, fail out to CMM, trigger a GC there, and retry. Or I could perform an extra heap check before I start; that's a little silly, but I doubt it'll be expensive enough to really matter here.<br><br><div class="gmail_quote"><div dir="ltr">On Thu, Sep 20, 2018, 5:42 AM Ömer Sinan Ağacan <<a href="mailto:omeragacan@gmail.com">omeragacan@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">allocateMightFail allocates new nursery blocks as long as you don't hit the<br>
heap limit, so it returns NULL less often than you might think. In particular,<br>
it doesn't return NULL when the nursery is full, instead it allocates a new<br>
block and adds it to the nursery.<br>
<br>
I'd do the GC triggering part in Cmm code instead of C code -- I'm not sure if<br>
it's possible to do this in C code. There should be some functions in<br>
PrimOps.cmm that do heap allocation, maybe look there. I'd look for uses of<br>
ALLOC_PRIM. The file HeapStackCheck.cmm may also be helpful (may at least give<br>
an idea of how a GC is triggered).<br>
<br>
Ömer<br>
<br>
David Feuer <<a href="mailto:david.feuer@gmail.com" target="_blank" rel="noreferrer">david.feuer@gmail.com</a>>, 20 Eyl 2018 Per, 12:34 tarihinde<br>
şunu yazdı:<br>
><br>
> If it returns NULL, then I need to back off what I'm doing and trigger a GC. How do I do the latter?<br>
><br>
> On Thu, Sep 20, 2018, 5:31 AM Ömer Sinan Ağacan <<a href="mailto:omeragacan@gmail.com" target="_blank" rel="noreferrer">omeragacan@gmail.com</a>> wrote:<br>
>><br>
>> allocateMightFail does the heap check for you and returns NULL. For the current<br>
>> capability you can use MyCapability() in Cmm and pass the value to the RTS<br>
>> function you're implementing.<br>
>><br>
>> Ömer<br>
>><br>
>> David Feuer <<a href="mailto:david.feuer@gmail.com" target="_blank" rel="noreferrer">david.feuer@gmail.com</a>>, 20 Eyl 2018 Per, 12:26 tarihinde<br>
>> şunu yazdı:<br>
>> ><br>
>> > Aha! Okay. How do I get the current capability to pass to that? I guess I should probably perform a heap check before calling lookupSta bleName for simplicity, at least to start.<br>
>> ><br>
>> > On Thu, Sep 20, 2018, 5:16 AM Ömer Sinan Ağacan <<a href="mailto:omeragacan@gmail.com" target="_blank" rel="noreferrer">omeragacan@gmail.com</a>> wrote:<br>
>> >><br>
>> >> Have you seen Storage.c:allocateMightFail ?<br>
>> >><br>
>> >> Ömer<br>
>> >><br>
>> >><br>
>> >> David Feuer <<a href="mailto:david.feuer@gmail.com" target="_blank" rel="noreferrer">david.feuer@gmail.com</a>>, 20 Eyl 2018 Per, 11:32 tarihinde<br>
>> >> şunu yazdı:<br>
>> >> ><br>
>> >> > I'm working on re-implementing the stable name system. For the new design, it seems much cleaner to allocate stable names in lookupStableName (in rts/StableName.c) rather than in the C-- code that calls it. But I haven't seen RTS code that does heap allocation. Is it possible? If so, how do I do it?<br>
>> >> > _______________________________________________<br>
>> >> > ghc-devs mailing list<br>
>> >> > <a href="mailto:ghc-devs@haskell.org" target="_blank" rel="noreferrer">ghc-devs@haskell.org</a><br>
>> >> > <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" rel="noreferrer noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><br>
</blockquote></div></div></div>