MIPS atomic memory operations

Robert O'Callahan robert at ocallahan.org
Wed Jan 16 09:44:27 UTC 2019

On Wed, Jan 16, 2019 at 10:22 PM Leslie Zhai <zhaixiang at loongson.cn> wrote:

> I simply read your technical report and noticed that porting RR to ARM
> failed due to ARM atomic memory operations use such as LL/SC
> "load-linked/store-conditional" instructions, perhaps it is the same
> issue for OpenJDK MIPS porting.  For example, emit_compare_and_swap
> http://hg.loongnix.org/jdk8-mips64-public/hotspot/file/dca904de5de5/src/cpu/mips/vm/c1_LIRAssembler_mips.cpp#l3912
> The same LL/SC "story"...
> http://hg.loongnix.org/jdk8-mips64-public/hotspot/file/dca904de5de5/src/cpu/mips/vm/macroAssembler_mips.cpp#l2692

Yes, it is very likely MIPS has the same problem.

Maybe you could convince the hardware designers to add a feature to
optionally generate a synchronous trap when a SC instruction fails. That
would be enough to make rr work.

Hi Robert,
> Please teach me how to modify rr's design philosophy?  It is sure a lot
> of work but balanced cost/benefit for hunting the self-modifying code's
> bug when porting OpenJDK HotSpot JIT compilers to MIPS backend.

I'm sure porting the Hotspot JIT to MIPS creates some very hard bugs, but I
think even if you found a way around the LL/SC problem, porting rr to MIPS
would be a lot of work. I guess it would take at least six months. It's
unlikely it would be worth it just to fix Hotspot JIT bugs.

Su ot deraeppa sah dna Rehtaf eht htiw saw hcihw, efil lanrete eht uoy ot
mialcorp ew dna, ti ot yfitset dna ti nees evah ew; deraeppa efil eht. Efil
fo Drow eht gninrecnoc mialcorp ew siht - dehcuot evah sdnah ruo dna ta
dekool evah ew hcihw, seye ruo htiw nees evah ew hcihw, draeh evah ew
hcihw, gninnigeb eht morf saw hcihw taht.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rr-dev/attachments/20190116/f869eba2/attachment.html>

More information about the rr-dev mailing list