[webkit-dev] reclaim of number cells

[Zoltan Herczeg]

Hi Maciej

Thank you for your reply.
The algorithm itself is very simple. Think about the following expression:
a = b + c + d. The result of (b+c) is just a temporay value, which is not
used anymore after this expression is evaluated. From technical viewpoint,
a shadow register file tracks those numbers cells, which reference counter
is exatly one. If a reference counter increases (caused by instructions
like mov, put_by_id, call...), we remove the particular number cell from
this shadow register file. However, if a new value is stored in a
register, and a number cell is pointed by its shadow register, we can
safely reclaim that number cell. The perfromance drawback is that we
always perfrom this check after some selected instructions (like add, sub,
mul, div, mod, ...) even if  the current benchmark never allocates a
number cell.

Your idea of 64 bit VM registers are interesting. That makes this patch a
complete waste. Since most of our systems are 64 bit systems, we already
have 64 bit VM registers :) That makes me wondering, how do you plan to
store a 64 bit pointer using a 64 bit VM register?

Cheers,
zoltan

> Hi Zoltan,
>
> The performance results are certainly interesting. Would you mind
> explaining the algorithm a bit more?
>
> Also, do you know why it is slowing down the tests that it does? In
> general the tests that seem hurt in performance are ones that would
> use a lot of immediate numbers. I can understand why they would not
> benefit from reducing allocation of number cells, but why do they get
> slower? If we understand that, we might be able to come up with a
> version that has the upsides but not the downsides of your patch.
>
> I should also note, we are considering using 64-bit VM registers (with
> a special encoding that well let us store a double, a pointer or an
> int without a separate type tag, basically all non-double types would
> look like a NaN but not the standard NaN, so the low 48 or so bits are
> free.) In such a scheme, number cells would be GC-allocated only if
> the number is stored in an object (or possibly not at all if we decide
> we can make objects and arrays bigger).
>
> That's probably a few weeks off though, so I'd be interested in
> whether we can make your patch work.
>
> Regards,
> Maciej
>
> On Jun 26, 2008, at 2:38 AM, Zoltan Herczeg wrote:
>
>> Hi All,
>>
>> I am Zoltan Herczeg, working for the Dept. of Soft. Eng., Univ. of
>> Szeged.
>> I am currently investigating the JavaScriptCore engine to find some
>> speed-up solutions. During my investigation, I have encountered an
>> interesting issue for the Garbage Collector. Namely, in the case of
>> some
>> sunspider benchmark programs, the GC is frequently called. For
>> example,
>> the runtime of 3d-cube is 121 msec, and it calls the slow Collect()
>> function about 170 times. Thus, the garbage collecting takes the large
>> portion of its runtime (~30%). Such benchmarks cunsume the available
>> Number Cells in a short time, so the GC has a lot of work to reclaim
>> these
>> cells. My idea is to have a simple algorithm, which can reclaim many
>> of
>> these cells without the help of the GC. I have attached an
>> experimental
>> patch, and the performance-results as well. As you can see, it is a
>> rather
>> selective patch. Some programs benefit from it (25% performance
>> improve
>> for 3d-cube), while some do not (like controlflow-recursive, which
>> does
>> not allocate any number cells at all). Perhaps this approach could
>> be a
>> custom-speedup, which should be turned on, when a treshold value is
>> reached. (Number of collects() in a given time is greater than a
>> pre-defined value.) However, the mainloop (Machine:: PrivateExecute)
>> should be duplicated in this case, which is not an easy task because
>> of
>> the computed gotos. Do you have any other idea to make this patch
>> useful?
>>
>> Regards,
>> Zoltan<gc-
>> improve
>> -34737
>> .patch><compare.txt>_______________________________________________
>> webkit-dev mailing list
>> webkit-dev at lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev