BC ABI: handling volatile

Wed Jun 14 16:33:00 GMT 2006

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.