[jsc-dev] bmalloc freelist from JIT code
Filip Pizlo
fpizlo at apple.com
Thu Nov 2 13:18:36 PDT 2017
> 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>
More information about the jsc-dev
mailing list