a better selection heuristic for register allocation?

[xiaoming gu <xi...@gmail.com>]

Hi, all. I did some study of register allocation these days. In current
version, there are two kinds of register allocation - bin-packing (BP) and
coloring-graph (CG). In client modes (client and opt), only BP is used. In
server modes (server, server_aggressive and server_static), BP and CG are
two choices for the being compiled function. If the number of operands in
the function is less than a threshold, CG is selected. Otherwise, BP is
selected. The default value for this threshold is 2000 and in
server_aggressive it's set to 10000.

My question is that is it better to make the selection heuristic for BP/CG
more meaningful? An intuitive is to use CG for hot functions. What's your
opinions? Thanks.

Xiaoming

Re: a better selection heuristic for register allocation?

[xiaoming gu <xi...@gmail.com>]

Thanks, Aleksey. The information is very helpful. -Xiaoming

On Mon, Sep 22, 2008 at 2:25 PM, Aleksey Shipilev <
aleksey.shipilev@gmail.com> wrote:

> Hi, Xiaoming!
>
> AFAIU, the real problem is the compilation time when CG is enabled.
> You might experiment though: take server.emconf, walk around disabling
> BP in SD2_OPT (i.e. set the threshold to 0) and see the difference.
> There's also an interesting question, what methods would go to SD2_OPT
> pipeline, but there should be only hot methods. The hottness is
> defined by profiler constraints there.
>
> I'm recalling that some workloads like OC4J fail (fatal exceptions in
> WebMaker) when threshold is less than 2500 -- I believe that was the
> reason of having 10000 in server_aggressive.
>
> Thanks,
> Aleksey.
>
>
> On 9/20/08, xiaoming gu <xi...@gmail.com> wrote:
> > Hi, all. I did some study of register allocation these days. In current
> > version, there are two kinds of register allocation - bin-packing (BP)
> and
> > coloring-graph (CG). In client modes (client and opt), only BP is used.
> In
> > server modes (server, server_aggressive and server_static), BP and CG are
> > two choices for the being compiled function. If the number of operands in
> > the function is less than a threshold, CG is selected. Otherwise, BP is
> > selected. The default value for this threshold is 2000 and in
> > server_aggressive it's set to 10000.
> >
> > My question is that is it better to make the selection heuristic for
> BP/CG
> > more meaningful? An intuitive is to use CG for hot functions. What's your
> > opinions? Thanks.
> >
> > Xiaoming
> >
>

Re: a better selection heuristic for register allocation?

[Aleksey Shipilev <al...@gmail.com>]

Hi, Xiaoming!

AFAIU, the real problem is the compilation time when CG is enabled.
You might experiment though: take server.emconf, walk around disabling
BP in SD2_OPT (i.e. set the threshold to 0) and see the difference.
There's also an interesting question, what methods would go to SD2_OPT
pipeline, but there should be only hot methods. The hottness is
defined by profiler constraints there.

I'm recalling that some workloads like OC4J fail (fatal exceptions in
WebMaker) when threshold is less than 2500 -- I believe that was the
reason of having 10000 in server_aggressive.

Thanks,
Aleksey.


On 9/20/08, xiaoming gu <xi...@gmail.com> wrote:
> Hi, all. I did some study of register allocation these days. In current
> version, there are two kinds of register allocation - bin-packing (BP) and
> coloring-graph (CG). In client modes (client and opt), only BP is used. In
> server modes (server, server_aggressive and server_static), BP and CG are
> two choices for the being compiled function. If the number of operands in
> the function is less than a threshold, CG is selected. Otherwise, BP is
> selected. The default value for this threshold is 2000 and in
> server_aggressive it's set to 10000.
>
> My question is that is it better to make the selection heuristic for BP/CG
> more meaningful? An intuitive is to use CG for hot functions. What's your
> opinions? Thanks.
>
> Xiaoming
>