This is the mail archive of the java-patches@gcc.gnu.org mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Tom Tromey wrote:
> 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).
> 

It has been a little while since I read the details about the BC ABI so
I could be a bit off base, but I was thinking that:

Could you have all uninitialized atable entries point to invalid memory
(perhaps NULL) so that they could be fixed up by the SIGSEGV handler?

When the first access to the static field happens the thread doing the
access would get SIGSEGV (by dereferencing the atable entry).  The
handler would somehow determine that the fault happened in an atable and
do the fixup (initializing the class if necessary) and then restart at
the instruction that faulted.  If the fault was not in an atable then a
normal NullPointerException would be generated.

After the atable slot was initialized access to the static variable
would just be indirect off of the atable slot value rather than a
function call.

On platforms that cannot trap bad memory accesses, you could still use
the function pointer technique.

The disadvantage of this technique is that signals might have more
overhead than a function call.

Also determining that a SIGSEGV came from an atable access would be
platform dependent.  The compiler would have to generate a fixed set of
recognizable idiomatic code sequences for any access to a static
variable that could not be proved to be using a valid atable entry.

Just my $0.02.

David Daney.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]