[aarch64-port-dev ] icedtea7-aarch64 port changeset 5662 : make static stubs load methodOop in cpool to avoid problems at GC

[Andrew Dinn]

On 25/10/14 09:26, Andrew Haley wrote:
> On 21/10/14 11:18, Andrew Dinn wrote:
>> jdk7 needs to insert method oops for static/virtual calls using movoop
>> instead of movptr. the same applies for static stubs. we would like to
>> use a simple mov immediate with no oop record to do the patching but
>> that falls foul of the reloc code.
>>
>> we can use a mov immediate /with/ an oop record for the static/virtual
>> call. however if we do that for the stub load then the oop does not
>> get updated and a GC causes the patched stub oop to be reverted to
>> movz/k 0x0000. in order to avoid this we have to do the stub oop load
>> via the cpool using a ldr.
> 
> This does not sound right.  Do you know why the patching doesn't
> work?

Hmm, well sort of . . . I don't think I have fully understood all the
details of patching.

At first when planting the stub call I tried using movoop to install the
stub oop in the oop recorder (which JDK7 shared code requires) while
planting a movz/k sequence to install the oop in a register. When the
patching code rewrites the stub call it updates the movz/k insns but it
does not update the 0x000000000000 value recorded in the cpool (n.b. of
course, in jdk8 there is no cpool entry to update).

Subsquently, when a GC relocates the cpool data the reloc code is
supplied with the zero oop originally inserted into the cpool and
repatches the stub call movz/k insns back to 0x0000.

If the patching code were to update the cpool entry we would be ok. I
did not think it was possible for the stub rewrite code to do so (lack
of relevant cpool info in the right place at the right time).

So, instead I planted a ldr to load the oop via the cpool. Since the oop
is in the cpool the ldr uses always the correct oop.

I am not really clear why this same problem does not arise for the oop
data encoded in the static/virtual call which redirects to the stub.
Initially it is provided with the oop value (jobject)-1. That call does
use a movz/k sequence and the GC does not seem to rewrite it to -1. But,
then again, maybe it does get rewritten to -1 and we just perform the
patching again?

Your advice and expertise is very welcome (even more so your patches :-)

regards,


Andrew Dinn
-----------