[jsc-dev] bmalloc freelist from JIT code

[Filip Pizlo]

> On Nov 2, 2017, at 1:10 PM, Yusuke SUZUKI <utatane.tea at gmail.com> wrote:
> 
> Thanks1
> 
> On Fri, Nov 3, 2017 at 5:01 AM, Geoffrey Garen <ggaren at apple.com <mailto:ggaren at apple.com>> wrote:
>> On Fri, Nov 3, 2017 at 4:49 AM, Filip Pizlo <fpizlo at apple.com <mailto:fpizlo at apple.com>> wrote:
>> I think he means: expose whatever the bmalloc fast path is to the JIT.  I didn’t take it to mean literally add a free list.
>> 
>> Yeah, right. My question is: is that feasible to add an interface to allocate bmalloc memory from JIT code?
>> Is there any known concern about this direction?
> 
> I see.
> 
> I tend to agree with Phil that inlining bmalloc allocation is possible but it is better to avoid doing so unless we meet a high burden of proof.
> 
> FWIW, in MallocBench benchmarks I haven’t seen a significant speedup from inlining the allocation path — even though doing so allows you to constant-fold the allocator selection math.
> 
> Great,
>  
> 
> I guess you could start by just inlining the Slice and Substring operations, and then seen how much additional speedup you got by inlining the allocation too.
> 
> Geoff
> 
> Phil's idea, allocating StringImpl part in JSString sounds really nice as a future direction.
> I think handling JSString specially in our GC is good.
> JSString is a primitive value in JS. This has super nice property since it cannot create a reference to the other JSObject.
> It may have a reference to the other JSString. By structuring JSString & JSRopeString carefully, we can ensure there are no cyclic references in JSStrings.

I don’t think that’s super useful.

> Maybe, in this situation, respecting reference counting of JSString's StringImpl would be not so difficult.
> I don't have a detailed algorithm right now, but this direction sounds the best.

We do not want to make JSString strictly reference counted.  JSString would be *both* reference-counted and traced.  When the GC runs, it would check if any strings had non-zero reference counts.  If so, it will mark them.  Thus, JSString would stay either if it is referenced from JS or if is referenced from C++.  The way to make this scalable is to give MarkedBlock an extra bitvector that tells which objects ever had a non-zero ref count.  JSString::ref() would set the bit if it’s being called for the first time.

In this world, it’s JSRopeString would refer to other JSStrings using the GC style: no ref counting, just a visitChildren method.  If the JSRopeString is ref()’d from C++, the GC will mark it, causing its visitChildren method to mark any strings it references.

-Filip


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/jsc-dev/attachments/20171102/e8aba0a6/attachment-0001.html>