[rvm-research] Yield-point Implementation

Khaled Z Mahmoud <[email protected]> Sat, 15 Dec 2018 01:57:00 -0500
Newsgroups gmane.comp.java.jikes.rvm.devel
Message-ID <CAER=_eVUiH2pFKSz=qrJsUqcoAL+Oh_pagiyNsT9i_3Y30Kfdw@mail.gmail.com>
--===============1614038014644423223==
Content-Type: multipart/alternative; boundary="0000000000009a72b9057d0a0e6f"

--0000000000009a72b9057d0a0e6f
Content-Type: text/plain; charset="UTF-8"

Hi,

I have mimicked the implementation of a yieldpoint behavior through java
instrumentation. Basically, I did have a a big array where the index is the
id of the thread. There is a timer that loops over this array and sets
fields to true.

At the beginning of each method, it checks this array if a method should
yield and sets the feild to false after yielding. Yielding calls
"SOmeClass.someYieldMethod()"

However, the overhead was tremendous "Almost larger than 30%".

Just curious to know how the original yield-point functionality avoids this
performance penalty? It should have access to lower level details to have
almost negligible overhead. For example, remaining certain values in
registers, memory locations of the yield points ...etc.

Any insights about that ?



-- 
Regards,
Khaled Mahmoud

--0000000000009a72b9057d0a0e6f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hi,</div><div><br></div><div>I have mimicked the impl=
ementation of a yieldpoint behavior through java instrumentation. Basically=
, I did have a a big array where the index is the id of the thread. There i=
s a timer that loops over this array and sets fields to true.</div><div><br=
></div><div>At the beginning of each method, it checks this array if a meth=
od should yield and sets the feild to false after yielding. Yielding calls =
&quot;SOmeClass.someYieldMethod()&quot;</div><div><br></div><div>However, t=
he overhead was tremendous &quot;Almost larger than 30%&quot;.</div><div><b=
r></div><div>Just curious to know how the original yield-point functionalit=
y avoids this performance penalty? It should have access to lower level det=
ails to have almost negligible overhead. For example, remaining certain val=
ues in registers, memory locations of the yield points ...etc.</div><div><b=
r></div><div>Any insights about that ?<br></div><div><br></div><div><br></d=
iv><div><br>-- <br><div dir=3D"ltr" class=3D"gmail_signature" data-smartmai=
l=3D"gmail_signature"><div dir=3D"ltr">Regards,<div>Khaled Mahmoud</div></d=
iv></div></div></div>

--0000000000009a72b9057d0a0e6f--


--===============1614038014644423223==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline


--===============1614038014644423223==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Jikesrvm-researchers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers

--===============1614038014644423223==--