[webkit-dev] reclaim of number cells

[Zoltan Herczeg]

Hi Maciej,

It seems you are right, my patch can afford some tweaks. As you can see,
the gain is doubled compared to the original one.

By the way, I was thinking another issue. In the current build, every JS
object stores its own string lookup table. Is it possible to merge these
string tables into a global one? I hope it will decrease both the memory
consumption and the runtime, since we only need pointer comparison instead
of string comparison.

Regards,
Zoltan

>
> On Jun 26, 2008, at 5:20 AM, Zoltan Herczeg wrote:
>
>> 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.
>
> Is it possible to skip the check in the fast path for immediate
> numbers that these instructions have? That would probably remove the
> drawback.
>
>>
>> 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?
>
> The only pointers that have to be stored will be into the JavaScript
> heap, and we can use VM allocation tricks to ensure that it is limited
> to 48 bits or so of real address information in the 64-bit case.
> (Collector memory already uses low-level mechanisms to allocate
> directly from the VM subsystem.)
>
>   - Maciej
>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: compare-2.txt
Url: http://lists.webkit.org/pipermail/webkit-dev/attachments/20080627/0d9c9111/attachment.txt 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gc-improve-34737-2.patch
Type: application/octet-stream
Size: 18507 bytes
Desc: not available
Url : http://lists.webkit.org/pipermail/webkit-dev/attachments/20080627/0d9c9111/attachment.obj