[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 = "SOmeClass.someYieldMethod()"</div><div><br></div><div>However, t= he overhead was tremendous "Almost larger than 30%".</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==--