RFR(m): 8220351: Cross-modifying code

[Doerr, Martin]

Hi Robbin,

> But that is whole new subject and let's keep that separate from this :)
Sure, we can keep the modification side discussion separate. This change is already difficult enough ��


Btw. I haven't sent the ppc/s390 instruction cache barriers. Here they are:

orderAccess_aix/linux_ppc.hpp:
inline void OrderAccess::instruction_pipeline() { inlasm_isync(); }

orderAccess_linux_s390.hpp:
inline void OrderAccess::instruction_pipeline() { inlasm_zarch_sync(); }


Thanks and best regards,
Martin


-----Original Message-----
From: Robbin Ehn <robbin.ehn at oracle.com> 
Sent: Mittwoch, 13. März 2019 20:30
To: Doerr, Martin <martin.doerr at sap.com>; David Holmes <david.holmes at oracle.com>; hotspot-dev at openjdk.java.net
Cc: Reingruber, Richard <richard.reingruber at sap.com>
Subject: Re: RFR(m): 8220351: Cross-modifying code

Hi,

On 2019-03-13 18:56, Doerr, Martin wrote:
> Hi everybody,
> 
> while discussing with a colleague the following question about the patch site on x86 came up:
> 
> nmethod::oops_do calls the closure f->do_oop(r->oop_addr()) for oops encoded into the instruction stream.
> I couldn't find a call to AbstractICache::invalidate_range.

Look for ICache::invalidate_range, I see 11 calls on x64.
And one call to AbstractICache/ICache::invalidate_word.
Btw I have spent some time looking at x86/icache_x86.cpp...
But that is whole new subject and let's keep that separate from this :)

I'll create issues for some of these topics, which if nothing else should be 
discussed.

/Robbin

> 
> Does anybody know where it is or if it's missing?
> 
> Best regards,
> Martin
>