Re: Math patch

[Chris Gray]

On Fri, 28 Feb 2003, Dalibor Topic wrote:

> hi Chris,
> 
> --- Chris Gray <address@hidden> wrote:
> > [...] SFAIK the only
> > legitimate inlining a 
> > bytecode compiler can do is for static final
> > constants.
> 
> I doubt even that is safe, as
> http://java.sun.com/j2se/1.4/docs/api/java/awt/event/MouseEvent.html#MOUSE_LAST
> this field surely changed between the java releases
> when they introduced mouse wheel support ;)

Nonetheless, javac certainly used to do that, and I'm pretty sure it still 
does. (I could swear that the JLS actually specifies this behaviour, but 
I'm darned if I can find the words now.)  Notoriously this causes 
applications to fail if the library they are run against uses different 
values for the static finals - this used to be a major problem for 
independent implementations, as Sun didn't publish the values they were 
using. It's still a snare for the unwary.
 
> In my opinion, the safest place to do constant 
> inlining is in a class loader, when you know that
> which specific implementation you're going to 'link'
> to. Method inlining is possible during class loading
> as well, but  would probably require a good heuristic
> to avoid a huge increase in code size. 

Yes, that's right: the logical place to do this would be in the phase we 
call "referencing", or maybe a bit later in a verifying/bytecode rewriting 
phase if one exists. In the latter case one could encode the actual value 
directly into the instruction, by-passing the constant pool entirely.

> I intend to experiment with that in kaffe, but I'm too 
> busy merging stuff in to do much development at the
> moment ;)

Know the feeling. ;> It's got me thinking too though - I might at least 
instrument Wonka to find out what the size distribution of static methods 
is. If there are a lot of one-liners or empty(!) methods then there may be 
some low-hanging fruit to be had ...

Cheers

-- 

Chris Gray

VM Architect, ACUNIA