Re: [rvm-research] Yield-point Implementation
"David P Grove" <[email protected]> Mon, 17 Dec 2018 13:19:46 -0500
| Newsgroups | gmane.comp.java.jikes.rvm.devel |
|---|---|
| Message-ID | <OF741FAB5B.3D5BA50E-ON85258366.0063E17D-85258366.0064AFD3@notes.na.collabserv.com> |
--===============0759024647782889646== Content-type: multipart/alternative; boundary="0__=0ABB09F5DFF067ED8f9e8a93df938690918c0ABB09F5DFF067ED" Content-Disposition: inline --0__=0ABB09F5DFF067ED8f9e8a93df938690918c0ABB09F5DFF067ED Content-type: text/plain; charset=US-ASCII Content-Transfer-Encoding: Quoted-printable Khaled Z Mahmoud <[email protected]> wrote on 12/15/2018 01:57:00 AM: > > 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. > Hi, One way to see how it works in Jikes RVM is to inspect the Java code in the baseline compiler that generates the machine code for a yieldpoint. For example, https://github.com/JikesRVM/JikesRVM/blob/b7f96145b006ed9a0d91435bc07f3927c= 1ebc3c6/rvm/src/org/jikesrvm/compilers/baseline/ia32/BaselineCompilerImpl.j= ava#L4191 The key point is that the hot-path test is just two instructions: compare & conditional branch. There is a register that is dedicated to hold a pointer to the RVMThread object for the executing thread and that object contains a flag which is set to a non-zero value when a branch is needed. The branch is infrequently taken, and thus likely to be correctly predicted. --dave --0__=0ABB09F5DFF067ED8f9e8a93df938690918c0ABB09F5DFF067ED Content-Transfer-Encoding: quoted-printable Content-type: text/html; charset=US-ASCII Content-Disposition: inline <html><body><p><tt><font size=3D"2">Khaled Z Mahmoud <kmahmou1@binghamto= n.edu> wrote on 12/15/2018 01:57:00 AM:</font></tt><br><tt><font size=3D= "2">> <br>> I have mimicked the implementation of a yieldpoint behavi= or through <br>> java instrumentation. Basically, I did have a a big arr= ay where the <br>> index is the id of the thread. There is a timer that = loops over this<br>> array and sets fields to true.</font></tt><br><tt><= font size=3D"2">> <br>> At the beginning of each method, it checks th= is array if a method <br>> should yield and sets the feild to false afte= r yielding. Yielding <br>> calls "SOmeClass.someYieldMethod()"= </font></tt><br><tt><font size=3D"2">> <br>> However, the overhead wa= s tremendous "Almost larger than 30%".</font></tt><br><tt><font s= ize=3D"2">> <br>> Just curious to know how the original yield-point f= unctionality <br>> avoids this performance penalty? It should have acces= s to lower <br>> level details to have almost negligible overhead. For e= xample, <br>> remaining certain values in registers, memory locations of= the yield<br>> points ...etc.</font></tt><br><tt><font size=3D"2">> = <br></font></tt><br><tt><font size=3D"2">Hi,</font></tt><br><br><tt><font s= ize=3D"2"> One way to see how it works in Jikes RVM is to inspect th= e Java code in the baseline compiler that generates the machine code for a = yieldpoint. For example, </font></tt><a href=3D"https://github.com/Ji= kesRVM/JikesRVM/blob/b7f96145b006ed9a0d91435bc07f3927c1ebc3c6/rvm/src/org/j= ikesrvm/compilers/baseline/ia32/BaselineCompilerImpl.java#L4191"><tt><font = size=3D"2">https://github.com/JikesRVM/JikesRVM/blob/b7f96145b006ed9a0d9143= 5bc07f3927c1ebc3c6/rvm/src/org/jikesrvm/compilers/baseline/ia32/BaselineCom= pilerImpl.java#L4191</font></tt></a><br><br><tt><font size=3D"2"> Th= e key point is that the hot-path test is just two instructions: compare &am= p; conditional branch. There is a register that is dedicated to hold a poin= ter to the RVMThread object for the executing thread and that object contai= ns a flag which is set to a non-zero value when a branch is needed. The bra= nch is infrequently taken, and thus likely to be correctly predicted.</font= ></tt><br><br><tt><font size=3D"2">--dave</font></tt><br><BR> </body></html> --0__=0ABB09F5DFF067ED8f9e8a93df938690918c0ABB09F5DFF067ED-- --===============0759024647782889646== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline --===============0759024647782889646== 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 --===============0759024647782889646==--