allocateMightFail allocates new nursery blocks as long as you don't hit the heap limit, so it returns NULL less often than you might think. In particular, it doesn't return NULL when the nursery is full, instead it allocates a new block and adds it to the nursery.
I'd do the GC triggering part in Cmm code instead of C code -- I'm not sure if it's possible to do this in C code. There should be some functions in PrimOps.cmm that do heap allocation, maybe look there. I'd look for uses of ALLOC_PRIM. The file HeapStackCheck.cmm may also be helpful (may at least give an idea of how a GC is triggered). Ömer David Feuer <[email protected]>, 20 Eyl 2018 Per, 12:34 tarihinde şunu yazdı: > > If it returns NULL, then I need to back off what I'm doing and trigger a GC. > How do I do the latter? > > On Thu, Sep 20, 2018, 5:31 AM Ömer Sinan Ağacan <[email protected]> wrote: >> >> allocateMightFail does the heap check for you and returns NULL. For the >> current >> capability you can use MyCapability() in Cmm and pass the value to the RTS >> function you're implementing. >> >> Ömer >> >> David Feuer <[email protected]>, 20 Eyl 2018 Per, 12:26 tarihinde >> şunu yazdı: >> > >> > 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. >> > >> > On Thu, Sep 20, 2018, 5:16 AM Ömer Sinan Ağacan <[email protected]> >> > wrote: >> >> >> >> Have you seen Storage.c:allocateMightFail ? >> >> >> >> Ömer >> >> >> >> >> >> David Feuer <[email protected]>, 20 Eyl 2018 Per, 11:32 tarihinde >> >> şunu yazdı: >> >> > >> >> > 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? >> >> > _______________________________________________ >> >> > ghc-devs mailing list >> >> > [email protected] >> >> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs _______________________________________________ ghc-devs mailing list [email protected] http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
