Re: [BC ABI] For entertainment purposes only: gcj-JIT

[Tom Tromey <tromey at redhat dot com>]

Tom> It occurs to me that before we can reference a static field, we must
Tom> initialize the target class.  What if at these places we call a
Tom> special (new) function that both initializes the target class and
Tom> updates all atable references to static fields of that class?

I've been thinking about this more, and it occurred to me there are a
couple other viable approaches.

One idea is to have the atable entry for a static field reference be a
function pointer.  The first call via this pointer would be to a
function that initializes the target class, resolves the field, and
then changes the atable entry to point to something like "return
*slot;".  Perhaps two slots would be needed for this (one for the
function pointer, one for the pointer to the resolved field).

A second, related, idea is to arrange things so that the compiler can
do optimizations on top of this.  The idea is that if one reference to
a static field dominates all other references to that same field, then
all subsequent references can be turned into simple dereferences of
that second atable slot.  There is a complication, though, if
resolution of the field fails and user code catches the exception;
we'd have to make sure that this use of the field would not be
considered to dominate.

For this stuff to be reliable it would be nice to have a way to
indicate that a given pointer assignment has to be atomic.  I'm not
sure what is involved in doing this, maybe nothing.


Maybe the simplest way to do all this is just introduce a new pure
function (or whatever the idempotent attribute is) that handles
resolving a single atable slot for a static field reference.  Then
tree-ssa ought to remove the redundant calls automatically (I've got
something similar for checkcast calls sitting on the laptop... this
works pretty well but will be better once VRP is around).

Tom