Hi Rémi, I think that even on Hotspot you can't guarantee it. The final optimized compiled code is probably safe, but the various intermediate forms most likely aren't. For example, I don't know for sure, but I assume the Hotspot bytecode interpreter can safepoint at any bytecode. Then there is also the interpreted lambda form, which is quite complicated and very likely to trigger a safepoint somewhere.
Regards, Jeroen > -----Original Message----- > From: Remi Forax [mailto:fo...@univ-mlv.fr] > Sent: Monday, February 17, 2014 9:27 > To: Jeroen Frijters; Da Vinci Machine Project > Subject: Re: JIT and invalidation > > On 02/17/2014 08:53 AM, Jeroen Frijters wrote: > > Hi Rémi, > > > > I believe this is not actually safe. There is no guarantee that when > SwitchPoint.invalidateAll() returns that all calls to GET_BYTE or > PUT_BYTE that were in flight have completed. > > > > Regards, > > Jeroen > > yes, you're right, > I've forgotten to say that this code is Hotspot specific. > > So let me re-phrase, I believe this code is safe if the VM is Hotspot > because invalidation is done at a safepoint so no GET_BYTE/PUT_BYTE can > be in flight. > > Rémi > > > > >> -----Original Message----- > >> From: mlvm-dev-boun...@openjdk.java.net [mailto:mlvm-dev- > >> boun...@openjdk.java.net] On Behalf Of Remi Forax > >> Sent: Sunday, February 16, 2014 22:54 > >> To: Da Vinci Machine Project > >> Subject: JIT and invalidation > >> > >> Hi John, Hi Christian, Hi all, > >> I don't know if you can test this little code, but when I run it on > >> my laptop (linux 64bits) it can terminate in 45s or 2 minutes, it > >> seems that it depends on the order the JIT compiles the method > handles. > >> https://gist.github.com/forax/9041030 > >> > >> Sometimes it also PrintCompilation can also prints 'COMPILE SKIPPED: > >> invalid non-klass dependency'. > >> > >> BTW, the code allows to safely* map and unmap a 32G file without not > >> always paying the cost of the runtime check that test if the array is > >> unmaped or not :) > >> > >> cheers, > >> Rémi > >> * I believe. > >> _______________________________________________ > >> mlvm-dev mailing list > >> mlvm-dev@openjdk.java.net > >> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev _______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
