<div dir="ltr">On Wed, 26 Sep 2018 at 10:54, David Feuer <<a href="mailto:david.feuer@gmail.com">david.feuer@gmail.com</a>> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Simon seems a bit busy right now. Can anyone else advise me on the<br>
basics of heap allocation in primops?<br>
<br>
On Tue, Sep 25, 2018 at 1:42 PM, David Feuer <<a href="mailto:david.feuer@gmail.com" target="_blank">david.feuer@gmail.com</a>> wrote:<br>
> Let's forget about allocate(). I can definitely handle this part in<br>
> C--. But I'm still lost in the macros and such. For example, I'm very<br>
> unclear on the differences among the ALLOC, HP_CHK, and MAYBE_GC<br>
> classes of macro. I can't find anything in the commentary, and the<br>
> source code documentation is very sparse. I'm okay with either of the<br>
> following approaches, but either way I need a bit more info.<br></blockquote><div><br></div><div><div>The best way to understand these macros is to look 
at their implementations and see how they're used in other parts of the 
RTS.  MAYBE_GC doesn't bump Hp, it is used to ensure that we don't 
indefinitely call allocate() in primops that use it.  The ALLOC family 
are wrappers around the lower level HP_CHK functions, these bump Hp. 
Some of the variations are optimisations to generate less verbose code -
 again, see the other primops for examples.  It's always safe to use 
HP_CHK_GEN_TICKY(), but there might be better alternatives depending on 
the type of your primitive.</div><div><br></div><div>Cheers</div><div>Simon</div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> 1. First see if we need to allocate a StableName#. If so, check<br>
> whether GC would be required to allocate the StableName# (how?). If<br>
> so, drop the lock, run GC (how?) and start over. This looks cleanest<br>
> to me if it can be done easily.<br>
><br>
> 2. First run the GC if we're low on memory (how?). Then if we need to<br>
> allocate a StableName#, we'll be sure to have room.<br>
><br>
><br>
> On Tue, Sep 25, 2018 at 6:25 AM, Simon Marlow <<a href="mailto:marlowsd@gmail.com" target="_blank">marlowsd@gmail.com</a>> wrote:<br>
>> You can do it unconditionally before taking the lock, or you can do it<br>
>> conditionally as long as you release the lock if the heap check fails. I<br>
>> think in the latter case there might not be a macro that allows this, but<br>
>> you could use the `allocate()` method for allocating memory (like<br>
>> newByteArray#) and then you could write a heap check like the MAYBE_GC()<br>
>> macro. Doing it unconditionally is easier and probably not a big performance<br>
>> hit, but note that you'll have to retreat Hp if you don't use the memory.<br>
>><br>
>> Cheers<br>
>> Simon<br>
>><br>
>> On Sat, 22 Sep 2018 at 13:08, David Feuer <<a href="mailto:david.feuer@gmail.com" target="_blank">david.feuer@gmail.com</a>> wrote:<br>
>>><br>
>>> How do I check if GC will be required, and how do I trigger it? Should I<br>
>>> perform the check unconditionally at the beginning of the operation so I<br>
>>> don't have to drop the lock, GC, then retake? I don't know the right ways to<br>
>>> deal with this stuff, and the macros are mostly undocumented.<br>
>>><br>
>>> On Sep 22, 2018 3:53 AM, "Simon Marlow" <<a href="mailto:marlowsd@gmail.com" target="_blank">marlowsd@gmail.com</a>> wrote:<br>
>>><br>
>>> Yes, the current implementation looks like it creates the object after<br>
>>> adding the entry to the StableName table and releasing the lock, which is<br>
>>> unsafe because another thread could read that same entry before the object<br>
>>> has been created.  The easiest solution to that is to take and release the<br>
>>> lock in C-- in the right places instead of in the C lookupStableName()<br>
>>> function (you might need to make a separate version of lookupStableName()<br>
>>> that doesn't take the lock).<br>
>>><br>
>>> Cheers<br>
>>> Simon<br>
>>><br>
>>><br>
>>> On Fri, 21 Sep 2018 at 12:53, David Feuer <<a href="mailto:david.feuer@gmail.com" target="_blank">david.feuer@gmail.com</a>> wrote:<br>
>>>><br>
>>>> It seems awkward to do it in C--, but maybe you can help me work out how.<br>
>>>> The allocation facilities definitely seem much nicer there, and allocating a<br>
>>>> small heap object in C feels like an abuse of the facilities we have there.<br>
>>>> The essential challenge, as I see it, is that we need the key to point to a<br>
>>>> valid stable name object by the time we drop the hash table lock. The<br>
>>>> process, as I imagine it:<br>
>>>><br>
>>>> 1. Follow indirections, untag, choose the right generation. (All this is<br>
>>>> in C)<br>
>>>> 2. Take the appropriate hash table lock. (C)<br>
>>>> 3. Look up the key in the hash table (C).<br>
>>>><br>
>>>> Now there's a branch. If we found the key, then we don't need to allocate<br>
>>>> an SNO. We just drop the lock and return. Otherwise<br>
>>>><br>
>>>> 4. Allocate an SNO and set its info pointer (most easily done in C--). If<br>
>>>> this necessitates GC, we need to drop the lock first and might as well just<br>
>>>> go back to the very beginning afterwards.<br>
>>>> 5. Populate the SNO with its "hash value" (we can do this anywhere we<br>
>>>> like, I imagine).<br>
>>>> 6. Insert the key and SNO into the hash table and drop the hash table<br>
>>>> lock (C)<br>
>>>> 7. If necessary, insert the SNO into the remembered set (C)<br>
>>>><br>
>>>> How would you recommend structuring this back-and-forth?<br>
>>>><br>
>>>> On Fri, Sep 21, 2018, 3:19 AM Simon Marlow <<a href="mailto:marlowsd@gmail.com" target="_blank">marlowsd@gmail.com</a>> wrote:<br>
>>>>><br>
>>>>> I'm a bit sceptical that you need to allocate a heap object in C instead<br>
>>>>> of C--, but still, here's an example:<br>
>>>>> <a href="https://phabricator.haskell.org/diffusion/GHC/browse/master/rts%2FThreads.c$258-261" rel="noreferrer" target="_blank">https://phabricator.haskell.org/diffusion/GHC/browse/master/rts%2FThreads.c$258-261</a><br>
>>>>><br>
>>>>> It's slightly less efficient to do this in C than C--, because<br>
>>>>> `allocate()` is slower than allocating by bumping `Hp`.<br>
>>>>><br>
>>>>> On Mon, 17 Sep 2018 at 21:25, David Feuer <<a href="mailto:david.feuer@gmail.com" target="_blank">david.feuer@gmail.com</a>> wrote:<br>
>>>>>><br>
>>>>>> How can I allocate a heap object in C code in the rts? I've only seen<br>
>>>>>> heap objects allocated in C--, and doing that here would be lousy for<br>
>>>>>> performance and worse for clarity.<br>
>>>>>><br>
>>>>>> David<br>
>>><br>
>>><br>
>><br>
</blockquote></div></div>