More control on JIT behaviour

[GoogleCodeExporter]

Current implementation of u-s has several limitation on providing several
features to control how JIT should works. 

1. A more flexible hotness threshold value. The JIT compiler will be
executed on the fly when code request hit the threshold limit (known as
'hot'), this threshold limit was 100000 and each execution will increase
+10 point. basically this behaviour is OK, but there is no way to change
this default threshold value unless recompiling the interpreter itself. 

2. A More flexible optimization level. Default/Global optimization level
used to transform python code could not be change. we can, actually, change
this value on each code we prefer to force to compile (via _llvm module),
but we can't make this optimization value lower than the default one.

3. Provide control to specify maximum code size allowed to compile. Since
compilation process might takes time, u-s restrict the maximum code size
allowed to JITed to be no more than 5KB, if this value could be changed, it
would give us a wider range of exploration on how u-s could be optimized.

4. Provide control to specify maximum memory threshold. There is no way to
control maximum memory threshold allowed to hold IR code, this making
memory usage keeps growing until all functions compiled.

Original issue reported on code.google.com by jaimy.azle on 15 Dec 2009 at 6:39

[GoogleCodeExporter]

Hi Jaimy,

What are you trying to do with these features? What's your use-case? What 
problem are 
you trying to solve?

Collin

Original comment by collinwi...@google.com on 15 Dec 2009 at 6:51

[GoogleCodeExporter]

Two reason behind:

1. Short-term, as u-s is still in cooking, this features will provide a wider 
range
of possibility to us to explore, finding the most optimal usage of u-s.

2. Long-term, to provide a higher flexibility usage of u-s to cope with various
scenario in real applications.

Original comment by jaimy.azle on 16 Dec 2009 at 3:23

[GoogleCodeExporter]

So ... you're just speculating? You haven't seen a problem in a real 
application?

Feel free to send a patch anyway, since on the the first of these seems to have 
a chance 
of being actively harmful, and a benchmark run would answer that worry.

Original comment by jyass...@gmail.com on 16 Dec 2009 at 3:42

• Added labels: Priority-Low

[GoogleCodeExporter]

on my second (long-term) reason, the answer might be: No, at this time it is 
purely
my speculation, but i believe no one ever seen problem occurs in future. :) 

point #2 perhaps mainly to provide a wider range of exploration, but 1, 3, and 
4 I
believe would be important aspects in real-life application. for example, by 
defining
that 5KB, or 10000 hit is enough is same as claiming that "640Kb is enough!"

For now, i might be more focused on how i could explore u-s for its best usage, 
so I
gather a better information on purposing this new engine as part of our system 
in future.

Original comment by jaimy.azle on 16 Dec 2009 at 4:18

[GoogleCodeExporter]

I try to make a patch to solve issue 1, 2, 3. 

http://codereview.appspot.com/179076

for #4 I think it still too risky for me to get into the core of u-s deeper, i 
need
more time to learn and understand on how it works.

Original comment by jaimy.azle on 16 Dec 2009 at 8:08