BC ABI: handling volatile

Wed Jun 14 17:02:00 GMT 2006

Andrew Haley wrote:
> 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.

perhaps you could arrange a constant offset between the the accessor for 
reading and the one for writing, that way you would not need two otable 
entries.
One thing that just occured to me is 'final' fields. They have similar 
problems to volatile.
Maybe you need an otable slot for reading and one for writing the field. 
 If the field were final, you put a pointer to 
_Jv_ThrowIllegalAccessError in write slot, but the field offset in the 
read slot. For volatile fileds you have the two accessor methods and 
for normal fields, the same offset en both the read and write slots.
>> > 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.
>
I was going to suggest patching the code at runtime, but thought better 
of it.
David Daney.