On 07/06/2012 08:48 PM, Mark Roos wrote:
> From Rémi on static analysis for loops
>
>         Not having such kind of analysis is almost a crime.
>
> For a language like Smalltalk I was thinking that having such an analysis
> would be the work of the gods.
>
> With user overridable methods, reflection and run time code creation I 
> have only found a few
> places where I could do such an static analysis.  And those are fragile.
>
> So do you have a good paper that would apply?  I have looked at many 
> from the 80s/90s and
> have yet to find a general approach for a Smalltalk style language.
>
> I am thinking of adding a mutable flag to integers so I can share a 
> body but 'lazy' freeze to
> a real integer but it seems like I'll be adding lots of checks just to 
> fix what could be a small problem
> over an entire application.

yes, i don't think it's a good idea too because it's too late,
you want to avoid boxing not try to share boxes.

>
> I also have a thought to allocate a few primitive slots in each stack 
> frame to pass real primitives
> but again I have to test everywhere for which slot is valid.

First the idea is to use an analysis but not to answer to the question, 
"is this variable is an integer or not"
but to answer to the question "is this variable may be an integer or not".
Once the analysis done, you know how many supplementary slots you need.
And now the trick, there is a nice way (several in fact) to explain to 
the JIT
that even if the bytecode contains tests, if the variable contains 
effectively an int,
it's a good idea to remove them.

>
> The best thought may be to add patterns to the language to avoid the 
> use of visible integers
> as indexes  ( e.g. instead of '1 to:3 do:[aBlock over a collection]' 
> do 'aCollection from:1 to:3 do:[ aBlock on each indexed item]')
> Now I can do the static analysis.  As they say 'If it hurts don't do it'

> regards
> mark

cheers,
Rémi

_______________________________________________
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

Reply via email to