[webkit-dev] reclaim of number cells

[Maciej Stachowiak]

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