<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 6 February 2014 01:32,  <span dir="ltr"><<a href="mailto:"Ola Fosheim Grøstad\" <ola.fosheim.grostad+dlang@gmail.com>"@puremagic.com" target="_blank">"Ola Fosheim Grøstad\" <ola.fosheim.grostad+dlang@gmail.com>"@puremagic.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Wednesday, 5 February 2014 at 15:01:27 UTC, Manu wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Or I wonder if there's opportunity to pinch a single bit from pointers to<br>
mark that it is raw or RC allocated? Probably fine on 64bit.<br>
</blockquote>
<br></div>
Yes, on 64 bit that is ok. I think current x86 map something like 53 bits, the top and bottom half of the 64 bit address space. The middle is unused. Anyway, you could have two heaps if the OS allows you to.<div class="im">
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
32bit probably needs to match a bit pattern or something.<br>
</blockquote>
<br></div>
Or one could forget about 32 bit for ARC.</blockquote><div><br></div><div>The applications I describe where it is a necessity will often be 32bit systems.</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Aligned data is a challenge. I have often wondered if it would be feasible<br>
to access the RC via a pointer hash or something, and keep it in a side<br>
table... sounds tricky, but I wonder if it's possible.<br>
</blockquote>
<br></div>
If you have your own allocator you probably could? Segment memory regions into allocations of a particular size and have a RC-count index at the start indexed by the masked MSBs of the pointer address and have smart pointers that know the object size. Kind of tricky to get acceptable speed, but possible to do. The problem is that you will get a latency of perhaps 200+ cycles on a cache miss. Then again, you could probably make do with 32 bit counters and they are probably accessed in proximity if they hold the same type of object. One cache line is 64 bytes, so you get 16 counters per cache line. With smart allocation you might get good cache locality of the counters (8MB of L3 cache is quite a bit).<br>
</blockquote><div><br></div><div>Cache locality is a problem that can easily be refined. It would just need lots of experimental data.</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

(I guess alignment is primarily a problem when you want 4KiB alignment (page size), maybe not worth worrying about.)<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Rather than (allocated_base, offset), I suspect (pointer, offset_from_base)<br>
would be better; typical dereferences would have no penalty.<br>
</blockquote>
<br></div>
Yes, probably. I was thinking about avoiding GC of internal pointers too. I think scanning might be easier if all pointers point to the allocation base. That way the GC does not have to consider offsets.<div class="im"><br>

<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
You mean like the smart pointer double indirection? I really don't like the<br>
double indirection, but it's a possibility. Or did I misunderstand?<br>
</blockquote>
<br></div>
Yes:<br>
<br>
struct {<br>
    void* object_ptr;<br>
    /* offset */<br>
    uint weakcounter;<br>
    uint strongcounter;<br>
}<br>
<br>
The advantage is that it works well with RC ignorant collectors/allocators. "if in doubt just set the pointer to null and forget about freeing".</blockquote><div><br></div><div>I see. Well, I don't like it :) ... but it's an option.</div>
<div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I'm sure there's a clever solution out there which would allow the ARC to<br>
detect if it's a raw C pointer or not...<br>
</blockquote>
<br></div>
Well, for a given OS/architecture you could probably always allocate your heap in a fixed memory range on 64 bit systems then test against that range.<br>
</blockquote></div><br></div></div>