Re: BC ABI: handling volatile

[Andrew Haley <aph at redhat dot com>]

David Daney writes:
 > 
 > How about a hybrid approach:
 > 
 > otable_entry e = _otable_p[i];
 > if (can_do_direct_access_p(e))
 > 	target = *(other_object + e);
 > else
 > 	target = (*e)();
 > 
 > 
 > At compile time you generate an accessor method if the volatile is 
 > accessible from outside of the class.  Since most fields are not 
 > volatile, this should not be too much overhead.

It's a bit more complicated than that because you might want to do
different things depending on whether you're reading or writing the
field.  But I get the idea.

 > At link time, fill in the otable entry with either the offset to
 > the field (if not volatile), or a pointer to the accessor function.
 > You also put a pointer to _Jv_ThrowNoSuchFieldError in the otable
 > slots where it would be appropriate.

That too.  However, at the present time offsets are just ints rather
than longs, so this would be an ABI change.  That's not a strong
objection, as we can be backward compatible by supporting both
formats.

 > The trick is to have a very efficient can_do_direct_access_p().  A naive 
 > implementation might be:
 > 
 > boolean inline can_do_direct_access_p(void *x) { return x & ~0xffff;}

I think it's quite hard to guarantee this, but I get the idea...  :-)

 > It might be possible to implement this as efficiently as the current 
 > otable accesses.

Hmm.  Yes, the idea of direct access if possible but making a call to
an access method if not certainly has some attactions.

Thanks!

Andrew.