[jsc-dev] bmalloc freelist from JIT code

[Yusuke SUZUKI]

Thanks1

On Fri, Nov 3, 2017 at 5:01 AM, Geoffrey Garen <ggaren at apple.com> wrote:

> On Fri, Nov 3, 2017 at 4:49 AM, Filip Pizlo <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.
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/jsc-dev/attachments/20171103/ab37df79/attachment.html>