From: Kathryn M. <mck...@cs...> - 2009-12-12 20:15:58
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> </head> <body bgcolor="#ffffff" text="#000000"> Dear Andy & others using Jikes RVM,<br> <br> It is in your best interest to contribute all your code to Jikes RVM.<br> <br> YOU WILL BECOME MORE CITED & FAMOUS if you (1) contribute a research patch or (2) take the time to contribute to the head of Jikes RVM.<br> <br> WHY will this happen? <br> <ul> <li>By making your code available in the head, future researchers must build on it when they download the latest version. Thus, if they do something at all related to your work, they will need to cite your paper, and likely will also read it. ;-)</li> <li>If some researcher has an idea based on your work, now they can quickly implement and publish it. Your work is thus likely to have much more influence if it is available in code in Jikes RVM because it reduces the time others need to take to build on your ideas. (Together with my collaborators, we have an endless stream of examples on this front.)</li> <li>It builds your research reputation as a person/group who produces verifiable results that contribute to the scientific endeavor as both ideas and infrastructure, on which others can build.<br> </li> </ul> Please contribute all code that results in a publication to Jikes RVM as at least research patch, and at best, to the head.<br> <br> Kathryn S McKinley<br> Professor of Computer Science<br> The University of Texas at Austin,<br> <br> </body> </html> |
From: Michael H. <hi...@us...> - 2009-12-12 20:55:56
|
Kathryn McKinley <mck...@cs...> wrote on 12/12/2009 03:01:22 PM: > Dear Andy & others using Jikes RVM, > > It is in your best interest to contribute all your code to Jikes RVM. > > YOU WILL BECOME MORE CITED & FAMOUS if you (1) contribute a research > patch or (2) take the time to contribute to the head of Jikes RVM. > > WHY will this happen? > By making your code available in the head, future researchers must > build on it when they download the latest version. Thus, if they > do something at all related to your work, they will need to cite > your paper, and likely will also read it. ;-) > > If some researcher has an idea based on your work, now they can > quickly implement and publish it. Your work is thus likely to have > much more influence if it is available in code in Jikes RVM because > it reduces the time others need to take to build on your ideas. > (Together with my collaborators, we have an endless stream of > examples on this front.) > > It builds your research reputation as a person/group who produces > verifiable results that contribute to the scientific endeavor as > both ideas and infrastructure, on which others can build. > > Please contribute all code that results in a publication to Jikes > RVM as at least research patch, and at best, to the head. > > Kathryn S McKinley > Professor of Computer Science > The University of Texas at Austin, I fully agree with Kathryn. The time it takes to do this will be paid off in many ways. Please keep the big picture in mind. Mike _____________________________________________________________ Michael Hind, Senior Manager, Programming Technologies Department IBM T.J. Watson Research Center http://www.research.ibm.com/people/h/hind |
From: Steve B. <Ste...@an...> - 2009-12-23 02:21:33
|
On 13/12/2009, at 7:01 AM, Kathryn McKinley wrote: > It is in your best interest to contribute all your code to Jikes RVM. On that note, I want to highlight a very significant contribution from Laurence Hellyer of U Kent, which I've just committed to the code base (r15807-15809). Laurence wanted support for barriers on primitive values (currently we support read and write barriers on reference types only). Rather than hack up a string and glue solution for his private use, Laurence re-worked the underlying infrastructure thoroughly and contributed that reworking to the code base. Now Laurence's framework is rock solid (not string and glue), and is tested in our nightly regression cycle. Of course the rest of us benefit too---since we can all now leverage his barrier infrastructure. It wasn't easy to do this. He had to work with me ;-) and I was not always very responsive, and his chance was non-trivial (> 250KB of change in his patches). I think Laurence's effort is a great example to us all. Cheers, --Steve |
From: Richard J. <R.E...@ke...> - 2009-12-23 10:37:40
|
Steve Thanks for your very kind note about Laurence's contribution. At this end, we also appreciate all the efforts that you have put into getting his non trivial changes into JikesRVM. We recognise the time it takes to read, check, test and quality assure contributions. Best wishes RIchard On 23 Dec 2009, at 02:21, Steve Blackburn wrote: > On 13/12/2009, at 7:01 AM, Kathryn McKinley wrote: >> It is in your best interest to contribute all your code to Jikes RVM. > > On that note, I want to highlight a very significant contribution from > Laurence Hellyer of U Kent, which I've just committed to the code base > (r15807-15809). > > Laurence wanted support for barriers on primitive values (currently we > support read and write barriers on reference types only). Rather > than hack up a string and glue solution for his private use, Laurence > re-worked the underlying infrastructure thoroughly and contributed > that reworking to the code base. Now Laurence's framework is rock > solid (not string and glue), and is tested in our nightly regression > cycle. Of course the rest of us benefit too---since we can all now > leverage his barrier infrastructure. > > It wasn't easy to do this. He had to work with me ;-) and I was not > always very responsive, and his chance was non-trivial (> 250KB of > change in his patches). > > I think Laurence's effort is a great example to us all. > > Cheers, > > --Steve > > ------------------------------------------------------------------------------ > This SF.Net email is sponsored by the Verizon Developer Community > Take advantage of Verizon's best-in-class app development support > A streamlined, 14 day to market process makes app distribution fast and easy > Join now and get one step closer to millions of Verizon customers > http://p.sf.net/sfu/verizon-dev2dev > _______________________________________________ > Jikesrvm-researchers mailing list > Jik...@li... > https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers Richard Jones | Reader in Computer Systems | University of Kent Computing Laboratory, University of Kent, Canterbury, Kent CT2 7NF, UK T +44 1227 827943 | F +44 1227 762811 | W http://www.cs.kent.ac.uk/~rej/ |
From: Steve B. <Ste...@an...> - 2009-12-24 01:18:01
|
I also want to highlight another not-so-glamorous-but-really-important contribution. Byeong Lee has sent in a number of patches that help get Jikes RVM working cleanly against the upcoming DaCapo 9.12 release. Byeong fixed probelms with Sunflow and Jython. Great work Byeong! If others can follow Byeong's lead, we'll have Jikes RVM working cleanly on all of the new benchmarks soon. --Steve |
From: Colin(Du Li) <daw...@gm...> - 2010-01-11 05:24:23
|
Dear Steve, Is this barrier implementation available now? I wanna use it now very much. How can I get it and run it? Thanks a lot! Du Li Steve Blackburn wrote: > > On 13/12/2009, at 7:01 AM, Kathryn McKinley wrote: >> It is in your best interest to contribute all your code to Jikes RVM. > > On that note, I want to highlight a very significant contribution from > Laurence Hellyer of U Kent, which I've just committed to the code base > (r15807-15809). > > Laurence wanted support for barriers on primitive values (currently we > support read and write barriers on reference types only). Rather > than hack up a string and glue solution for his private use, Laurence > re-worked the underlying infrastructure thoroughly and contributed > that reworking to the code base. Now Laurence's framework is rock > solid (not string and glue), and is tested in our nightly regression > cycle. Of course the rest of us benefit too---since we can all now > leverage his barrier infrastructure. > > It wasn't easy to do this. He had to work with me ;-) and I was not > always very responsive, and his chance was non-trivial (> 250KB of > change in his patches). > > I think Laurence's effort is a great example to us all. > > Cheers, > > --Steve > > ------------------------------------------------------------------------------ > This SF.Net email is sponsored by the Verizon Developer Community > Take advantage of Verizon's best-in-class app development support > A streamlined, 14 day to market process makes app distribution fast and > easy > Join now and get one step closer to millions of Verizon customers > http://p.sf.net/sfu/verizon-dev2dev > _______________________________________________ > Jikesrvm-researchers mailing list > Jik...@li... > https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers > > -- View this message in context: http://old.nabble.com/-rvm-research--Contribute-back-to-Jikes-RVM%21-tp26760794p27106055.html Sent from the jikesrvm-researchers mailing list archive at Nabble.com. |
From: Steve B. <Ste...@an...> - 2010-01-11 08:18:19
|
Du Li, > Is this barrier implementation available now? > I wanna use it now very much. How can I get it and run it? > Steve Blackburn wrote: >> On that note, I want to highlight a very significant contribution >> from >> Laurence Hellyer of U Kent, which I've just committed to the code >> base >> (r15807-15809). To see the code you need to use the Jikes RVM svn head, rather than the release. http://jikesrvm.org/Source+Control The code will be in the next release if you're prepared to wait. --Steve |
From: Colin(Du Li) <daw...@gm...> - 2010-01-11 23:14:34
|
Thanks a lot! I got the codes now. Du Li Steve Blackburn wrote: > > Du Li, > >> Is this barrier implementation available now? >> I wanna use it now very much. How can I get it and run it? > >> Steve Blackburn wrote: >>> On that note, I want to highlight a very significant contribution >>> from >>> Laurence Hellyer of U Kent, which I've just committed to the code >>> base >>> (r15807-15809). > > > To see the code you need to use the Jikes RVM svn head, rather than > the release. > > http://jikesrvm.org/Source+Control > > The code will be in the next release if you're prepared to wait. > > --Steve > > ------------------------------------------------------------------------------ > This SF.Net email is sponsored by the Verizon Developer Community > Take advantage of Verizon's best-in-class app development support > A streamlined, 14 day to market process makes app distribution fast and > easy > Join now and get one step closer to millions of Verizon customers > http://p.sf.net/sfu/verizon-dev2dev > _______________________________________________ > Jikesrvm-researchers mailing list > Jik...@li... > https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers > > -- View this message in context: http://old.nabble.com/-rvm-research--Contribute-back-to-Jikes-RVM%21-tp26760794p27119607.html Sent from the jikesrvm-researchers mailing list archive at Nabble.com. |
From: Laurence H. <L.H...@ke...> - 2010-01-11 11:33:36
|
On 11 Jan 2010, at 08:12, Steve Blackburn wrote: > >> Is this barrier implementation available now? >> I wanna use it now very much. How can I get it and run it? > > > To see the code you need to use the Jikes RVM svn head, rather than > the release. > > http://jikesrvm.org/Source+Control > > The code will be in the next release if you're prepared to wait. For those wanting to use primitive write barriers hopefully this might help: In the SVN head, r15805 commited the last of necessary changes to the compilers etc and supports primitive write barriers. The best place to get started with using the primitive write barrier code is to look at commit r15806, this commit added the UsePrimitiveWirteBarriers GC algorithm. UsePrimitiveWriteBarriers is really an extension of the SemiSpace GC that uses the primitive write barriers to unconditionally make primitive writes to the heap - the only real use of this GC is to test that the compilers are correctly calling the primitive write barriers. If you have further questions I will be happy to try to answer them. A couple of points to bear in mind when starting off: i) The primitive write barriers are for all primitive writes to the heap (objects and arrays). There are no barriers on static primitives (although I can't think why you would want one) ii) There currently is no support within the MMTk scripting language for testing primitive write barriers Kind regards Laurence Laurence Hellyer Research Student School of Computing University of Kent More info: http://www.cs.kent.ac.uk/people/rpg/lh243/ |
From: Colin(Du Li) <daw...@gm...> - 2010-01-11 23:15:40
|
Thanks for your explanation! I will turn to you if I encounter some problem. Du Li Laurence Hellyer wrote: > > > On 11 Jan 2010, at 08:12, Steve Blackburn wrote: > >> >>> Is this barrier implementation available now? >>> I wanna use it now very much. How can I get it and run it? >> >> >> To see the code you need to use the Jikes RVM svn head, rather than >> the release. >> >> http://jikesrvm.org/Source+Control >> >> The code will be in the next release if you're prepared to wait. > > For those wanting to use primitive write barriers hopefully this might > help: > > In the SVN head, r15805 commited the last of necessary changes to the > compilers etc and supports primitive write barriers. > > The best place to get started with using the primitive write barrier code > is to look at commit r15806, this commit added the > UsePrimitiveWirteBarriers GC algorithm. UsePrimitiveWriteBarriers is > really an extension of the SemiSpace GC that uses the primitive write > barriers to unconditionally make primitive writes to the heap - the only > real use of this GC is to test that the compilers are correctly calling > the primitive write barriers. > > If you have further questions I will be happy to try to answer them. A > couple of points to bear in mind when starting off: > > i) The primitive write barriers are for all primitive writes to the heap > (objects and arrays). There are no barriers on static primitives > (although I can't think why you would want one) > ii) There currently is no support within the MMTk scripting language for > testing primitive write barriers > > Kind regards > Laurence > > Laurence Hellyer > Research Student > School of Computing > University of Kent > > More info: http://www.cs.kent.ac.uk/people/rpg/lh243/ > > > ------------------------------------------------------------------------------ > This SF.Net email is sponsored by the Verizon Developer Community > Take advantage of Verizon's best-in-class app development support > A streamlined, 14 day to market process makes app distribution fast and > easy > Join now and get one step closer to millions of Verizon customers > http://p.sf.net/sfu/verizon-dev2dev > _______________________________________________ > Jikesrvm-researchers mailing list > Jik...@li... > https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers > > -- View this message in context: http://old.nabble.com/-rvm-research--Contribute-back-to-Jikes-RVM%21-tp26760794p27119621.html Sent from the jikesrvm-researchers mailing list archive at Nabble.com. |
From: David P G. <gr...@us...> - 2010-01-11 14:41:54
|
Steve Blackburn <Ste...@an...> wrote on 01/11/2010 03:12:22 AM: > > Du Li, > > > Is this barrier implementation available now? > > I wanna use it now very much. How can I get it and run it? > > > Steve Blackburn wrote: > >> On that note, I want to highlight a very significant contribution > >> from > >> Laurence Hellyer of U Kent, which I've just committed to the code > >> base > >> (r15807-15809). > > > To see the code you need to use the Jikes RVM svn head, rather than > the release. > > http://jikesrvm.org/Source+Control > > The code will be in the next release if you're prepared to wait. > We should probably get a release out relatively soon. Any one have bandwidth to try to fix some of the problems with the new DaCapo benchmarks over the next week or two, or should we just go ahead with a release soon and do another one later one the new DaCapo benchmarks run? --dave |
From: Colin(Du Li) <daw...@gm...> - 2010-01-11 23:23:18
|
Hi, Dave, Personally, I look forward to a release ASAP even it has some minor problems. Thanks a lot! Du Li David P Grove wrote: > > > Steve Blackburn <Ste...@an...> wrote on 01/11/2010 03:12:22 > AM: >> >> Du Li, >> >> > Is this barrier implementation available now? >> > I wanna use it now very much. How can I get it and run it? >> >> > Steve Blackburn wrote: >> >> On that note, I want to highlight a very significant contribution >> >> from >> >> Laurence Hellyer of U Kent, which I've just committed to the code >> >> base >> >> (r15807-15809). >> >> >> To see the code you need to use the Jikes RVM svn head, rather than >> the release. >> >> http://jikesrvm.org/Source+Control >> >> The code will be in the next release if you're prepared to wait. >> > > We should probably get a release out relatively soon. Any one have > bandwidth to try to fix some of the problems with the new DaCapo > benchmarks > over the next week or two, or should we just go ahead with a release soon > and do another one later one the new DaCapo benchmarks run? > > --dave > > ------------------------------------------------------------------------------ > This SF.Net email is sponsored by the Verizon Developer Community > Take advantage of Verizon's best-in-class app development support > A streamlined, 14 day to market process makes app distribution fast and > easy > Join now and get one step closer to millions of Verizon customers > http://p.sf.net/sfu/verizon-dev2dev > _______________________________________________ > Jikesrvm-researchers mailing list > Jik...@li... > https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers > > -- View this message in context: http://old.nabble.com/-rvm-research--Contribute-back-to-Jikes-RVM%21-tp26760794p27119737.html Sent from the jikesrvm-researchers mailing list archive at Nabble.com. |
From: Colin(Du Li) <daw...@gm...> - 2010-01-12 23:57:03
|
Dear Laurence, I assume you also implemented primitive read barriers. When can it be committed? Thanks a lot! Du Li Laurence Hellyer wrote: > > > For those wanting to use primitive write barriers hopefully this might > help: > > In the SVN head, r15805 commited the last of necessary changes to the > compilers etc and supports primitive write barriers. > > The best place to get started with using the primitive write barrier code > is to look at commit r15806, this commit added the > UsePrimitiveWirteBarriers GC algorithm. UsePrimitiveWriteBarriers is > really an extension of the SemiSpace GC that uses the primitive write > barriers to unconditionally make primitive writes to the heap - the only > real use of this GC is to test that the compilers are correctly calling > the primitive write barriers. > > If you have further questions I will be happy to try to answer them. A > couple of points to bear in mind when starting off: > > i) The primitive write barriers are for all primitive writes to the heap > (objects and arrays). There are no barriers on static primitives > (although I can't think why you would want one) > ii) There currently is no support within the MMTk scripting language for > testing primitive write barriers > > Kind regards > Laurence > > Laurence Hellyer > Research Student > School of Computing > University of Kent > > More info: http://www.cs.kent.ac.uk/people/rpg/lh243/ > > > ------------------------------------------------------------------------------ > This SF.Net email is sponsored by the Verizon Developer Community > Take advantage of Verizon's best-in-class app development support > A streamlined, 14 day to market process makes app distribution fast and > easy > Join now and get one step closer to millions of Verizon customers > http://p.sf.net/sfu/verizon-dev2dev > _______________________________________________ > Jikesrvm-researchers mailing list > Jik...@li... > https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers > > -- View this message in context: http://old.nabble.com/-rvm-research--Contribute-back-to-Jikes-RVM%21-tp26760794p27137132.html Sent from the jikesrvm-researchers mailing list archive at Nabble.com. |
From: Laurence H. <L.H...@ke...> - 2010-01-13 12:08:39
|
On 12 Jan 2010, at 23:56, Colin(Du Li) wrote: > > Dear Laurence, > > I assume you also implemented primitive read barriers. When can it be > committed? > Thanks a lot! > > Du Li Hi, Sorry, but for my work I merely implemented primitive write barriers. Are you wanting primitive read barriers for collecting statistics or for another purpose? (Collecting statistics can be done in many other ways) Jennifer Sartor (University of Texas) has been actively working on Arraylets and presumably this has involved implementing primitive read barriers (at least on array's). From my experience of implementing primitive write barriers the main difficulty is not so much modifying the compilers to emit the barrier but catching all places inside the RVM that write to the heap via Magic or JNI (field reflection code for starters). When creating my primitive write barriers to ensure correctness I write protected the heap and my primitive write barriers then wrote to a virtual memory alias to write the value into the heap - any RVM code that wrote to the heap directly caused a SIGSEGV (see [1] for a presentation on this). At the ISMM 2009 Wild and Crazy session I expanded upon this idea to suggest a read protected heap for debugging primitive read barriers. The big draw back of this approach is that *all* access to the heap (including status words, TIB's and alignment gaps) need some sort of barrier which leads to extra implementation effort. Daniel Frampton (Australian National University) has proposed (and I believe implemented) an alternative debugging tool that uses ValGrind and can selectively protect individual heap fields. If there is enough desire for primitive read barriers perhaps we can get a collaboration going to implement this last class of barriers in JikesRVM and MMTk. Kind regards Laurence [1] http://www.cs.kent.ac.uk/people/rpg/lh243/conferences/index.html#MM-NET09 > > > Laurence Hellyer wrote: >> >> >> For those wanting to use primitive write barriers hopefully this might >> help: >> >> In the SVN head, r15805 commited the last of necessary changes to the >> compilers etc and supports primitive write barriers. >> >> The best place to get started with using the primitive write barrier code >> is to look at commit r15806, this commit added the >> UsePrimitiveWirteBarriers GC algorithm. UsePrimitiveWriteBarriers is >> really an extension of the SemiSpace GC that uses the primitive write >> barriers to unconditionally make primitive writes to the heap - the only >> real use of this GC is to test that the compilers are correctly calling >> the primitive write barriers. >> >> If you have further questions I will be happy to try to answer them. A >> couple of points to bear in mind when starting off: >> >> i) The primitive write barriers are for all primitive writes to the heap >> (objects and arrays). There are no barriers on static primitives >> (although I can't think why you would want one) >> ii) There currently is no support within the MMTk scripting language for >> testing primitive write barriers >> >> Kind regards >> Laurence >> >> Laurence Hellyer >> Research Student >> School of Computing >> University of Kent >> >> More info: http://www.cs.kent.ac.uk/people/rpg/lh243/ >> >> >> ------------------------------------------------------------------------------ >> This SF.Net email is sponsored by the Verizon Developer Community >> Take advantage of Verizon's best-in-class app development support >> A streamlined, 14 day to market process makes app distribution fast and >> easy >> Join now and get one step closer to millions of Verizon customers >> http://p.sf.net/sfu/verizon-dev2dev >> _______________________________________________ >> Jikesrvm-researchers mailing list >> Jik...@li... >> https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers >> >> > > -- > View this message in context: http://old.nabble.com/-rvm-research--Contribute-back-to-Jikes-RVM%21-tp26760794p27137132.html > Sent from the jikesrvm-researchers mailing list archive at Nabble.com. > > > ------------------------------------------------------------------------------ > This SF.Net email is sponsored by the Verizon Developer Community > Take advantage of Verizon's best-in-class app development support > A streamlined, 14 day to market process makes app distribution fast and easy > Join now and get one step closer to millions of Verizon customers > http://p.sf.net/sfu/verizon-dev2dev > _______________________________________________ > Jikesrvm-researchers mailing list > Jik...@li... > https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers Laurence Hellyer Research Student School of Computing University of Kent More info: http://www.cs.kent.ac.uk/people/rpg/lh243/ |
From: Colin(Du Li) <daw...@gm...> - 2010-01-14 19:52:22
|
Dear Laurence, Thanks so much for your thorough explanation! It's quite interesting for me to try to get the last class of barriers done. We can discuss more later. Thanks again. Du Li Laurence Hellyer wrote: > > > On 12 Jan 2010, at 23:56, Colin(Du Li) wrote: > >> >> Dear Laurence, >> >> I assume you also implemented primitive read barriers. When can it be >> committed? >> Thanks a lot! >> >> Du Li > > Hi, > > Sorry, but for my work I merely implemented primitive write barriers. Are > you wanting primitive read barriers for collecting statistics or for > another purpose? (Collecting statistics can be done in many other ways) > > Jennifer Sartor (University of Texas) has been actively working on > Arraylets and presumably this has involved implementing primitive read > barriers (at least on array's). > >>From my experience of implementing primitive write barriers the main difficulty is not so much modifying the compilers to emit the barrier but catching all places inside the RVM that write to the heap via Magic or JNI (field reflection code for starters). When creating my primitive write barriers to ensure correctness I write protected the heap and my primitive write barriers then wrote to a virtual memory alias to write the value into the heap - any RVM code that wrote to the heap directly caused a SIGSEGV (see [1] for a presentation on this). At the ISMM 2009 Wild and Crazy session I expanded upon this idea to suggest a read protected heap for debugging primitive read barriers. > > The big draw back of this approach is that *all* access to the heap > (including status words, TIB's and alignment gaps) need some sort of > barrier which leads to extra implementation effort. Daniel Frampton > (Australian National University) has proposed (and I believe implemented) > an alternative debugging tool that uses ValGrind and can selectively > protect individual heap fields. > > If there is enough desire for primitive read barriers perhaps we can get a > collaboration going to implement this last class of barriers in JikesRVM > and MMTk. > > Kind regards > Laurence > > [1] > http://www.cs.kent.ac.uk/people/rpg/lh243/conferences/index.html#MM-NET09 > >> >> >> Laurence Hellyer wrote: >>> >>> >>> For those wanting to use primitive write barriers hopefully this might >>> help: >>> >>> In the SVN head, r15805 commited the last of necessary changes to the >>> compilers etc and supports primitive write barriers. >>> >>> The best place to get started with using the primitive write barrier >>> code >>> is to look at commit r15806, this commit added the >>> UsePrimitiveWirteBarriers GC algorithm. UsePrimitiveWriteBarriers is >>> really an extension of the SemiSpace GC that uses the primitive write >>> barriers to unconditionally make primitive writes to the heap - the >>> only >>> real use of this GC is to test that the compilers are correctly calling >>> the primitive write barriers. >>> >>> If you have further questions I will be happy to try to answer them. A >>> couple of points to bear in mind when starting off: >>> >>> i) The primitive write barriers are for all primitive writes to the heap >>> (objects and arrays). There are no barriers on static primitives >>> (although I can't think why you would want one) >>> ii) There currently is no support within the MMTk scripting language for >>> testing primitive write barriers >>> >>> Kind regards >>> Laurence >>> >>> Laurence Hellyer >>> Research Student >>> School of Computing >>> University of Kent >>> >>> More info: http://www.cs.kent.ac.uk/people/rpg/lh243/ >>> >>> >>> ------------------------------------------------------------------------------ >>> This SF.Net email is sponsored by the Verizon Developer Community >>> Take advantage of Verizon's best-in-class app development support >>> A streamlined, 14 day to market process makes app distribution fast and >>> easy >>> Join now and get one step closer to millions of Verizon customers >>> http://p.sf.net/sfu/verizon-dev2dev >>> _______________________________________________ >>> Jikesrvm-researchers mailing list >>> Jik...@li... >>> https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers >>> >>> >> >> -- >> View this message in context: >> http://old.nabble.com/-rvm-research--Contribute-back-to-Jikes-RVM%21-tp26760794p27137132.html >> Sent from the jikesrvm-researchers mailing list archive at Nabble.com. >> >> >> ------------------------------------------------------------------------------ >> This SF.Net email is sponsored by the Verizon Developer Community >> Take advantage of Verizon's best-in-class app development support >> A streamlined, 14 day to market process makes app distribution fast and >> easy >> Join now and get one step closer to millions of Verizon customers >> http://p.sf.net/sfu/verizon-dev2dev >> _______________________________________________ >> Jikesrvm-researchers mailing list >> Jik...@li... >> https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers > > > Laurence Hellyer > Research Student > School of Computing > University of Kent > > More info: http://www.cs.kent.ac.uk/people/rpg/lh243/ > > > ------------------------------------------------------------------------------ > This SF.Net email is sponsored by the Verizon Developer Community > Take advantage of Verizon's best-in-class app development support > A streamlined, 14 day to market process makes app distribution fast and > easy > Join now and get one step closer to millions of Verizon customers > http://p.sf.net/sfu/verizon-dev2dev > _______________________________________________ > Jikesrvm-researchers mailing list > Jik...@li... > https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers > > -- View this message in context: http://old.nabble.com/-rvm-research--Contribute-back-to-Jikes-RVM%21-tp26760794p27167131.html Sent from the jikesrvm-researchers mailing list archive at Nabble.com. |
From: Jagadish K. <jag...@gm...> - 2011-10-06 08:53:38
|
Hello Laurence/Colin, I am looking to implement Primitive read barriers to track all the reads of Java application objects. Just wanted to check if the read barriers have been implemented by someone after the previous post ? If not,Laurence I see in one of your previous reply that there are other ways to collect these stats. Do you infer using the tools like Valgrind? Can you help me by giving more details about other ways of collecting these stats ? Regards, Jagadish. Colin(Du Li) wrote: > > Dear Laurence, > > Thanks so much for your thorough explanation! > It's quite interesting for me to try to get the last class of barriers > done. We can discuss more later. > Thanks again. > > Du Li > > Laurence Hellyer wrote: >> >> >> On 12 Jan 2010, at 23:56, Colin(Du Li) wrote: >> >>> >>> Dear Laurence, >>> >>> I assume you also implemented primitive read barriers. When can it be >>> committed? >>> Thanks a lot! >>> >>> Du Li >> >> Hi, >> >> Sorry, but for my work I merely implemented primitive write barriers. >> Are you wanting primitive read barriers for collecting statistics or for >> another purpose? (Collecting statistics can be done in many other ways) >> >> Jennifer Sartor (University of Texas) has been actively working on >> Arraylets and presumably this has involved implementing primitive read >> barriers (at least on array's). >> >>>From my experience of implementing primitive write barriers the main difficulty is not so much modifying the compilers to emit the barrier but catching all places inside the RVM that write to the heap via Magic or JNI (field reflection code for starters). When creating my primitive write barriers to ensure correctness I write protected the heap and my primitive write barriers then wrote to a virtual memory alias to write the value into the heap - any RVM code that wrote to the heap directly caused a SIGSEGV (see [1] for a presentation on this). At the ISMM 2009 Wild and Crazy session I expanded upon this idea to suggest a read protected heap for debugging primitive read barriers. >> >> The big draw back of this approach is that *all* access to the heap >> (including status words, TIB's and alignment gaps) need some sort of >> barrier which leads to extra implementation effort. Daniel Frampton >> (Australian National University) has proposed (and I believe implemented) >> an alternative debugging tool that uses ValGrind and can selectively >> protect individual heap fields. >> >> If there is enough desire for primitive read barriers perhaps we can get >> a collaboration going to implement this last class of barriers in >> JikesRVM and MMTk. >> >> Kind regards >> Laurence >> >> [1] >> http://www.cs.kent.ac.uk/people/rpg/lh243/conferences/index.html#MM-NET09 >> >>> >>> >>> Laurence Hellyer wrote: >>>> >>>> >>>> For those wanting to use primitive write barriers hopefully this might >>>> help: >>>> >>>> In the SVN head, r15805 commited the last of necessary changes to the >>>> compilers etc and supports primitive write barriers. >>>> >>>> The best place to get started with using the primitive write barrier >>>> code >>>> is to look at commit r15806, this commit added the >>>> UsePrimitiveWirteBarriers GC algorithm. UsePrimitiveWriteBarriers is >>>> really an extension of the SemiSpace GC that uses the primitive write >>>> barriers to unconditionally make primitive writes to the heap - the >>>> only >>>> real use of this GC is to test that the compilers are correctly calling >>>> the primitive write barriers. >>>> >>>> If you have further questions I will be happy to try to answer them. A >>>> couple of points to bear in mind when starting off: >>>> >>>> i) The primitive write barriers are for all primitive writes to the >>>> heap >>>> (objects and arrays). There are no barriers on static primitives >>>> (although I can't think why you would want one) >>>> ii) There currently is no support within the MMTk scripting language >>>> for >>>> testing primitive write barriers >>>> >>>> Kind regards >>>> Laurence >>>> >>>> Laurence Hellyer >>>> Research Student >>>> School of Computing >>>> University of Kent >>>> >>>> More info: http://www.cs.kent.ac.uk/people/rpg/lh243/ >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> This SF.Net email is sponsored by the Verizon Developer Community >>>> Take advantage of Verizon's best-in-class app development support >>>> A streamlined, 14 day to market process makes app distribution fast and >>>> easy >>>> Join now and get one step closer to millions of Verizon customers >>>> http://p.sf.net/sfu/verizon-dev2dev >>>> _______________________________________________ >>>> Jikesrvm-researchers mailing list >>>> Jik...@li... >>>> https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers >>>> >>>> >>> >>> -- >>> View this message in context: >>> http://old.nabble.com/-rvm-research--Contribute-back-to-Jikes-RVM%21-tp26760794p27137132.html >>> Sent from the jikesrvm-researchers mailing list archive at Nabble.com. >>> >>> >>> ------------------------------------------------------------------------------ >>> This SF.Net email is sponsored by the Verizon Developer Community >>> Take advantage of Verizon's best-in-class app development support >>> A streamlined, 14 day to market process makes app distribution fast and >>> easy >>> Join now and get one step closer to millions of Verizon customers >>> http://p.sf.net/sfu/verizon-dev2dev >>> _______________________________________________ >>> Jikesrvm-researchers mailing list >>> Jik...@li... >>> https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers >> >> >> Laurence Hellyer >> Research Student >> School of Computing >> University of Kent >> >> More info: http://www.cs.kent.ac.uk/people/rpg/lh243/ >> >> >> ------------------------------------------------------------------------------ >> This SF.Net email is sponsored by the Verizon Developer Community >> Take advantage of Verizon's best-in-class app development support >> A streamlined, 14 day to market process makes app distribution fast and >> easy >> Join now and get one step closer to millions of Verizon customers >> http://p.sf.net/sfu/verizon-dev2dev >> _______________________________________________ >> Jikesrvm-researchers mailing list >> Jik...@li... >> https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers >> >> > > -- View this message in context: http://old.nabble.com/-rvm-research--Contribute-back-to-Jikes-RVM%21-tp26760794p32599846.html Sent from the jikesrvm-researchers mailing list archive at Nabble.com. |
From: Jagadish K. <jag...@gm...> - 2011-10-06 08:53:56
|
Hello Laurence/Colin, I am looking to implement Primitive read barriers to track all the reads of Java application objects. Just wanted to check if the read barriers have been implemented by someone after the previous post ? If not,Laurence I see in one of your previous reply that there are other ways to collect these stats. Do you infer using the tools like Valgrind? Can you help me by giving more details about other ways of collecting these stats ? Thank you for your help! Regards, Jagadish. Colin(Du Li) wrote: > > Dear Laurence, > > Thanks so much for your thorough explanation! > It's quite interesting for me to try to get the last class of barriers > done. We can discuss more later. > Thanks again. > > Du Li > > Laurence Hellyer wrote: >> >> >> On 12 Jan 2010, at 23:56, Colin(Du Li) wrote: >> >>> >>> Dear Laurence, >>> >>> I assume you also implemented primitive read barriers. When can it be >>> committed? >>> Thanks a lot! >>> >>> Du Li >> >> Hi, >> >> Sorry, but for my work I merely implemented primitive write barriers. >> Are you wanting primitive read barriers for collecting statistics or for >> another purpose? (Collecting statistics can be done in many other ways) >> >> Jennifer Sartor (University of Texas) has been actively working on >> Arraylets and presumably this has involved implementing primitive read >> barriers (at least on array's). >> >>>From my experience of implementing primitive write barriers the main difficulty is not so much modifying the compilers to emit the barrier but catching all places inside the RVM that write to the heap via Magic or JNI (field reflection code for starters). When creating my primitive write barriers to ensure correctness I write protected the heap and my primitive write barriers then wrote to a virtual memory alias to write the value into the heap - any RVM code that wrote to the heap directly caused a SIGSEGV (see [1] for a presentation on this). At the ISMM 2009 Wild and Crazy session I expanded upon this idea to suggest a read protected heap for debugging primitive read barriers. >> >> The big draw back of this approach is that *all* access to the heap >> (including status words, TIB's and alignment gaps) need some sort of >> barrier which leads to extra implementation effort. Daniel Frampton >> (Australian National University) has proposed (and I believe implemented) >> an alternative debugging tool that uses ValGrind and can selectively >> protect individual heap fields. >> >> If there is enough desire for primitive read barriers perhaps we can get >> a collaboration going to implement this last class of barriers in >> JikesRVM and MMTk. >> >> Kind regards >> Laurence >> >> [1] >> http://www.cs.kent.ac.uk/people/rpg/lh243/conferences/index.html#MM-NET09 >> >>> >>> >>> Laurence Hellyer wrote: >>>> >>>> >>>> For those wanting to use primitive write barriers hopefully this might >>>> help: >>>> >>>> In the SVN head, r15805 commited the last of necessary changes to the >>>> compilers etc and supports primitive write barriers. >>>> >>>> The best place to get started with using the primitive write barrier >>>> code >>>> is to look at commit r15806, this commit added the >>>> UsePrimitiveWirteBarriers GC algorithm. UsePrimitiveWriteBarriers is >>>> really an extension of the SemiSpace GC that uses the primitive write >>>> barriers to unconditionally make primitive writes to the heap - the >>>> only >>>> real use of this GC is to test that the compilers are correctly calling >>>> the primitive write barriers. >>>> >>>> If you have further questions I will be happy to try to answer them. A >>>> couple of points to bear in mind when starting off: >>>> >>>> i) The primitive write barriers are for all primitive writes to the >>>> heap >>>> (objects and arrays). There are no barriers on static primitives >>>> (although I can't think why you would want one) >>>> ii) There currently is no support within the MMTk scripting language >>>> for >>>> testing primitive write barriers >>>> >>>> Kind regards >>>> Laurence >>>> >>>> Laurence Hellyer >>>> Research Student >>>> School of Computing >>>> University of Kent >>>> >>>> More info: http://www.cs.kent.ac.uk/people/rpg/lh243/ >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> This SF.Net email is sponsored by the Verizon Developer Community >>>> Take advantage of Verizon's best-in-class app development support >>>> A streamlined, 14 day to market process makes app distribution fast and >>>> easy >>>> Join now and get one step closer to millions of Verizon customers >>>> http://p.sf.net/sfu/verizon-dev2dev >>>> _______________________________________________ >>>> Jikesrvm-researchers mailing list >>>> Jik...@li... >>>> https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers >>>> >>>> >>> >>> -- >>> View this message in context: >>> http://old.nabble.com/-rvm-research--Contribute-back-to-Jikes-RVM%21-tp26760794p27137132.html >>> Sent from the jikesrvm-researchers mailing list archive at Nabble.com. >>> >>> >>> ------------------------------------------------------------------------------ >>> This SF.Net email is sponsored by the Verizon Developer Community >>> Take advantage of Verizon's best-in-class app development support >>> A streamlined, 14 day to market process makes app distribution fast and >>> easy >>> Join now and get one step closer to millions of Verizon customers >>> http://p.sf.net/sfu/verizon-dev2dev >>> _______________________________________________ >>> Jikesrvm-researchers mailing list >>> Jik...@li... >>> https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers >> >> >> Laurence Hellyer >> Research Student >> School of Computing >> University of Kent >> >> More info: http://www.cs.kent.ac.uk/people/rpg/lh243/ >> >> >> ------------------------------------------------------------------------------ >> This SF.Net email is sponsored by the Verizon Developer Community >> Take advantage of Verizon's best-in-class app development support >> A streamlined, 14 day to market process makes app distribution fast and >> easy >> Join now and get one step closer to millions of Verizon customers >> http://p.sf.net/sfu/verizon-dev2dev >> _______________________________________________ >> Jikesrvm-researchers mailing list >> Jik...@li... >> https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers >> >> > > -- View this message in context: http://old.nabble.com/-rvm-research--Contribute-back-to-Jikes-RVM%21-tp26760794p32599848.html Sent from the jikesrvm-researchers mailing list archive at Nabble.com. |
From: Jagadish K. <jag...@gm...> - 2011-10-06 08:54:43
|
Hello Laurence/Colin, I am looking to implement Primitive read barriers to track all the reads of Java application objects. Just wanted to check if the read barriers have been implemented by someone after the previous post ? If not,Laurence I see in one of your previous reply that there are other ways to collect these stats. Do you infer using the tools like Valgrind? Can you help me by giving more details about other ways of collecting these stats ? Thankyou for your help! Regards, Jagadish. Colin(Du Li) wrote: > > Dear Laurence, > > Thanks so much for your thorough explanation! > It's quite interesting for me to try to get the last class of barriers > done. We can discuss more later. > Thanks again. > > Du Li > > Laurence Hellyer wrote: >> >> >> On 12 Jan 2010, at 23:56, Colin(Du Li) wrote: >> >>> >>> Dear Laurence, >>> >>> I assume you also implemented primitive read barriers. When can it be >>> committed? >>> Thanks a lot! >>> >>> Du Li >> >> Hi, >> >> Sorry, but for my work I merely implemented primitive write barriers. >> Are you wanting primitive read barriers for collecting statistics or for >> another purpose? (Collecting statistics can be done in many other ways) >> >> Jennifer Sartor (University of Texas) has been actively working on >> Arraylets and presumably this has involved implementing primitive read >> barriers (at least on array's). >> >>>From my experience of implementing primitive write barriers the main difficulty is not so much modifying the compilers to emit the barrier but catching all places inside the RVM that write to the heap via Magic or JNI (field reflection code for starters). When creating my primitive write barriers to ensure correctness I write protected the heap and my primitive write barriers then wrote to a virtual memory alias to write the value into the heap - any RVM code that wrote to the heap directly caused a SIGSEGV (see [1] for a presentation on this). At the ISMM 2009 Wild and Crazy session I expanded upon this idea to suggest a read protected heap for debugging primitive read barriers. >> >> The big draw back of this approach is that *all* access to the heap >> (including status words, TIB's and alignment gaps) need some sort of >> barrier which leads to extra implementation effort. Daniel Frampton >> (Australian National University) has proposed (and I believe implemented) >> an alternative debugging tool that uses ValGrind and can selectively >> protect individual heap fields. >> >> If there is enough desire for primitive read barriers perhaps we can get >> a collaboration going to implement this last class of barriers in >> JikesRVM and MMTk. >> >> Kind regards >> Laurence >> >> [1] >> http://www.cs.kent.ac.uk/people/rpg/lh243/conferences/index.html#MM-NET09 >> >>> >>> >>> Laurence Hellyer wrote: >>>> >>>> >>>> For those wanting to use primitive write barriers hopefully this might >>>> help: >>>> >>>> In the SVN head, r15805 commited the last of necessary changes to the >>>> compilers etc and supports primitive write barriers. >>>> >>>> The best place to get started with using the primitive write barrier >>>> code >>>> is to look at commit r15806, this commit added the >>>> UsePrimitiveWirteBarriers GC algorithm. UsePrimitiveWriteBarriers is >>>> really an extension of the SemiSpace GC that uses the primitive write >>>> barriers to unconditionally make primitive writes to the heap - the >>>> only >>>> real use of this GC is to test that the compilers are correctly calling >>>> the primitive write barriers. >>>> >>>> If you have further questions I will be happy to try to answer them. A >>>> couple of points to bear in mind when starting off: >>>> >>>> i) The primitive write barriers are for all primitive writes to the >>>> heap >>>> (objects and arrays). There are no barriers on static primitives >>>> (although I can't think why you would want one) >>>> ii) There currently is no support within the MMTk scripting language >>>> for >>>> testing primitive write barriers >>>> >>>> Kind regards >>>> Laurence >>>> >>>> Laurence Hellyer >>>> Research Student >>>> School of Computing >>>> University of Kent >>>> >>>> More info: http://www.cs.kent.ac.uk/people/rpg/lh243/ >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> This SF.Net email is sponsored by the Verizon Developer Community >>>> Take advantage of Verizon's best-in-class app development support >>>> A streamlined, 14 day to market process makes app distribution fast and >>>> easy >>>> Join now and get one step closer to millions of Verizon customers >>>> http://p.sf.net/sfu/verizon-dev2dev >>>> _______________________________________________ >>>> Jikesrvm-researchers mailing list >>>> Jik...@li... >>>> https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers >>>> >>>> >>> >>> -- >>> View this message in context: >>> http://old.nabble.com/-rvm-research--Contribute-back-to-Jikes-RVM%21-tp26760794p27137132.html >>> Sent from the jikesrvm-researchers mailing list archive at Nabble.com. >>> >>> >>> ------------------------------------------------------------------------------ >>> This SF.Net email is sponsored by the Verizon Developer Community >>> Take advantage of Verizon's best-in-class app development support >>> A streamlined, 14 day to market process makes app distribution fast and >>> easy >>> Join now and get one step closer to millions of Verizon customers >>> http://p.sf.net/sfu/verizon-dev2dev >>> _______________________________________________ >>> Jikesrvm-researchers mailing list >>> Jik...@li... >>> https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers >> >> >> Laurence Hellyer >> Research Student >> School of Computing >> University of Kent >> >> More info: http://www.cs.kent.ac.uk/people/rpg/lh243/ >> >> >> ------------------------------------------------------------------------------ >> This SF.Net email is sponsored by the Verizon Developer Community >> Take advantage of Verizon's best-in-class app development support >> A streamlined, 14 day to market process makes app distribution fast and >> easy >> Join now and get one step closer to millions of Verizon customers >> http://p.sf.net/sfu/verizon-dev2dev >> _______________________________________________ >> Jikesrvm-researchers mailing list >> Jik...@li... >> https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers >> >> > > -- View this message in context: http://old.nabble.com/-rvm-research--Contribute-back-to-Jikes-RVM%21-tp26760794p32599847.html Sent from the jikesrvm-researchers mailing list archive at Nabble.com. |