From: Ian R. <ian...@ma...> - 2006-10-20 14:12:47
|
Hi, I just wanted to stimulate some discussion on this so I can know why the design is the way it is :-) Currently in the object model we mix reference and other primitive fields, we then iterate over the fields (when scanning) by holding an array of offsets for references within the object (see MMType). Every type (e.g. a particular class) has a different array of offsets. If we arranged the fields within the object so that reference fields were grouped together, rather than holding an array of offsets, we need merely hold a count of the number of references. I believe this would offer an advantage when scanning as: 1) we wouldn't need to read the offsets array 2) all references would be on the same cache line, so potentially better performance I know this idea isn't new, so I was wondering what the plan for the object model was? There don't appear to be any RFEs to improve it, is that because we're happy with the object model? Thanks for any feedback, Ian |
From: Eliot M. <mo...@cs...> - 2006-10-20 14:30:46
|
Ian -- You'd need to do separate groups of references (versus primitives) for different levels of subclasses that add field, so as to preserve the rule that all superclass fields precede fields of subclasses. I don't think this optimization is worth it. Also, the offset array approach has been used to good advantage to change the ORDER in which we process the fields, which changes heap traversal order, and thus (in a copying collector) object order. This can give a significant win in some cases (see Xianglong Huang's paper with Kathryn, Steve, and me as co-authors (I may not have that author list right from memory)). Another strategy we have not prusued in Jikes RVM is generating custom reference iteration methods for each class. This avoids iteration and the array lookup, so might well be the fastest technique, unless it gets into icache issues. (It defeats the re-ordering hack, too, but ...) -- Eliot |
From: Ian R. <ian...@ma...> - 2006-10-20 15:14:48
|
Thanks Eliot, firstly, I agree :-) My motivation may be a little warped, I'm thinking of doing scanning in hardware. I see the offset array and specialized methods as a possible encumbrance to this. As Dave describes, what I'm thinking of is a bidirectional approach, so subclasses add their new primitive fields say at a negative offset, reference fields at a positive offset. This approach of course means we need to know the size and "middle" of objects. References are to the middle of objects, the header is also in the middle of objects. I'm interested and will read the paper you reference. Thanks again, Ian Eliot Moss wrote: > Ian -- You'd need to do separate groups of references (versus primitives) > for different levels of subclasses that add field, so as to preserve the > rule that all superclass fields precede fields of subclasses. I don't think > this optimization is worth it. Also, the offset array approach has been > used to good advantage to change the ORDER in which we process the fields, > which changes heap traversal order, and thus (in a copying collector) > object order. This can give a significant win in some cases (see Xianglong > Huang's paper with Kathryn, Steve, and me as co-authors (I may not have > that author list right from memory)). > > Another strategy we have not prusued in Jikes RVM is generating custom > reference iteration methods for each class. This avoids iteration and the > array lookup, so might well be the fastest technique, unless it gets into > icache issues. (It defeats the re-ordering hack, too, but ...) > > -- Eliot > > ------------------------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > Jikesrvm-researchers mailing list > Jik...@li... > https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers > |
From: David P G. <gr...@us...> - 2006-10-20 14:34:11
|
Hi Ian, In the presence of subclassing, to segregate references/primitives you have to go with a bi-directional object layout. We used to have an object model where scalar objects were layed out in one direction (reverse) and arrays in the other (forward, like all objects are done now). This gave us a very minor performance boost on PPX/AIX since it enabled hardware trap based nullchecks (AIX maps page 0!!!). Several years back we changed to the current uni-directional object model because the GC folk _really_ wanted an easily scannable heap and the semi-bidirectional layout we had with scalars going one way and arrays going the other caused them a great deal of pain. Another experiment that Perry Cheng and I did several years ago was to specialize the tracing routines to the 18 common cases (all combinations of reference/non-reference fields for the first 4 slots of scalar objects plus primitive/reference arrays) plus one general case. In effect we made tracing be an invisible virtual method of java.lang.Object by adding TIB slots for it, and changing the GC loop to invoke via the TIB. We got some very hefty speedups in GC tracing rate by doing this (somewhere around 30%), but the details were ugly enough (we added a couple magics for invoking the scan routine) that we didn't check it in. I think I can still dredge up this patch and put it in the research archive if there is interest, but it's not something that could be committed as is. A better version of this could give most of the tracing improvement without losing the easy of heap scanning we have with the unidirectional layout. This is almost entirely a GC decision, so it's really up to the MMTk people to make a tradeoff of heap scannability vs. optimization of the primitive/reference slot tracing code and tell us what they want to do. The only thing I'm going to be somewhat insistent on is that we don't support both of them simultaneously unless we can do it very cleanly....at least the last time we tried that it looked really ugly and hard to understand. But, maybe we can build a cleaner abstraction this time around since we can use more OO features w/o losing performance. --dave > Currently in the object model we mix reference and other primitive > fields, we then iterate over the fields (when scanning) by holding an > array of offsets for references within the object (see MMType). Every > type (e.g. a particular class) has a different array of offsets. If we > arranged the fields within the object so that reference fields were > grouped together, rather than holding an array of offsets, we need > merely hold a count of the number of references. I believe this would > offer an advantage when scanning as: > 1) we wouldn't need to read the offsets array > 2) all references would be on the same cache line, so potentially better > performance > > I know this idea isn't new, so I was wondering what the plan for the > object model was? There don't appear to be any RFEs to improve it, is > that because we're happy with the object model? > |
From: Ian R. <ian...@ma...> - 2006-10-20 14:53:26
|
Hi Dave, thanks for the detailed response. David P Grove wrote: > Another experiment that Perry Cheng and I did several years > ago was to specialize the tracing routines to the 18 common cases (all > combinations of reference/non-reference fields for the first 4 slots > of scalar objects plus primitive/reference arrays) plus one general > case. In effect we made tracing be an invisible virtual method of > java.lang.Object by adding TIB slots for it, and changing the GC loop > to invoke via the TIB. We got some very hefty speedups in GC tracing > rate by doing this (somewhere around 30%), but the details were ugly > enough (we added a couple magics for invoking the scan routine) that > we didn't check it in. I think I can still dredge up this patch and > put it in the research archive if there is interest, but it's not > something that could be committed as is. A better version of this > could give most of the tracing improvement without losing the easy of > heap scanning we have with the unidirectional layout. This is interesting. I'd thought a similar thing would be possible using Jumbo: http://loome.cs.uiuc.edu/Jumbo/ Their paper on object serialization shows how they get a benefit by avoiding reflection scanning fields for serialization, and instead using runtime generated methods. Do you have any thoughts on cache behavior due to packing references? > This is almost entirely a GC decision, so it's really up to > the MMTk people to make a tradeoff of heap scannability vs. > optimization of the primitive/reference slot tracing code and tell us > what they want to do. The only thing I'm going to be somewhat > insistent on is that we don't support both of them simultaneously > unless we can do it very cleanly....at least the last time we tried > that it looked really ugly and hard to understand. But, maybe we can > build a cleaner abstraction this time around since we can use more OO > features w/o losing performance. I agree, I imagine ultimately MMTk is going to be used for a variety of object models in different systems. I imagine one of those would have a bidirectional organization, but I don't know if we should be pushing for this organization ourselves. Thanks again, Ian |
From: Eliot M. <mo...@cs...> - 2006-10-20 15:18:13
|
>>>>> "Ian" == Ian Rogers <ian...@ma...> writes: Ian> Do you have any thoughts on cache behavior due to packing references? Well, if you're copying the objects in a copying GC, obviously it doesn;t matter much. Also, given then average object size for many applications is about the size of a cache line, it's hard to imagine a lot of improvement. If objects were relatively larger, it would make a diference, but most large objects are arrays of primitives, which mostly don't get scanned. I would think larger objections would be levels of indirection (to TIB and thence to offset array). It is not clear that the control code here, versus the work in actually processing each pointer, is the overhead. And while we might get GC cost down a bit, in well-tuned systems the overall benefit will be small (GC cost is a small fraction of total cost, etc.). The speedup from per-class reference enumeration methods may be more worth it. -- Eliot |
From: Steve B. <Ste...@an...> - 2006-10-20 21:05:52
|
Robin, Daniel and I have done quite a bit of careful study of this issue over the years. Robin experimented with quite a few alternatives. I'll leave it to Robin or Daniel to comment on the detail because my memory for detail is pathetic. My feeling is/was that the best option is probably just to use a few bits in the header to encode the most common patterns and then to fall back to the tib for the rest. However the performance gain from this versus what we have now was, in Robin's experience, very marginal. My recollection was that Robin found that the performance was surprisingly insenstive to a whole range of alternatives. One of the lessons of that experiment is that it is very hard to second guess exactly how something like this will pan out on a give architecture. What dominates? Indirections? (if in L1, they tend to be surprisingly cheap) Branch mispredicts? (depending on the processor this can be significant) L2 misses due to the underlying walk of the object graph? etc etc etc. Modern architectures are complex. The best way to approach this is to do a detailed performance analysis. Robin did this and did not find anything sufficiently compelling that we rushed out and changed the object model. --Steve On 21/10/2006, at 1:18 AM, Eliot Moss wrote: >>>>>> "Ian" == Ian Rogers <ian...@ma...> writes: > > Ian> Do you have any thoughts on cache behavior due to packing > references? > > Well, if you're copying the objects in a copying GC, obviously it > doesn;t > matter much. Also, given then average object size for many > applications is > about the size of a cache line, it's hard to imagine a lot of > improvement. If objects were relatively larger, it would make a > diference, > but most large objects are arrays of primitives, which mostly don't > get > scanned. > > I would think larger objections would be levels of indirection (to > TIB and > thence to offset array). It is not clear that the control code > here, versus > the work in actually processing each pointer, is the overhead. And > while we > might get GC cost down a bit, in well-tuned systems the overall > benefit > will be small (GC cost is a small fraction of total cost, etc.). > > The speedup from per-class reference enumeration methods may be > more worth > it. > > -- Eliot > > ---------------------------------------------------------------------- > --- > Using Tomcat but need to do more? Need to support web services, > security? > Get stuff done quickly with pre-integrated technology to make your > job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache > Geronimo > http://sel.as-us.falkag.net/sel? > cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > Jikesrvm-researchers mailing list > Jik...@li... > https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers |
From: Eliot M. <mo...@cs...> - 2006-10-20 23:54:29
|
We may not want to change the object model, but custom reference iteration methods might be a speed win that does not involve any change to the layout. Cheers -- E |
From: Ian R. <ian...@ma...> - 2006-10-23 11:51:38
|
Eliot Moss wrote: > We may not want to change the object model, but custom reference iteration > methods might be a speed win that does not involve any change to the > layout. > > Cheers -- E > This would be good imo. I'm interested to see that Dave's custom iterators for objects shows a ~30% speed up for GC tracing, but Robin's experience has been that object layout has a marginal impact on performance. From a philosophical point-of-view I believe the code desires to be object model agnostic, which custom iterators would support. Regards, Ian |
From: David P G. <gr...@us...> - 2006-10-24 03:42:25
|
> Eliot Moss wrote: > > We may not want to change the object model, but custom reference iteration > > methods might be a speed win that does not involve any change to the > > layout. > > > > Cheers -- E > > > This would be good imo. I'm interested to see that Dave's custom > iterators for objects shows a ~30% speed up for GC tracing, but Robin's > experience has been that object layout has a marginal impact on > performance. From a philosophical point-of-view I believe the code > desires to be object model agnostic, which custom iterators would support. Remembering more of the details (it was 3 or 4 years ago :))...the 30% came on the FixedLive program, which fills the heap with MBs of objects of a single class (2 prim/2 reference slots in each I seem to recall). So, the 30% is more of a limit study result than what you'd see in practice on a real program. Perry and I were toying with the idea of trying to get the compiler to automatically generate specialized tracing routines based on heap demographics and wanted to see what the upper limits on the achievable speedup were. On the question of locality impact of bi-directional object layout. I agree with Steve that hardware is complex enough it's hard to make good guesses. I think Eliot's observation that many objects fit on one cache line is true....for any object that was all on the same cache line, the layout shouldn't really matter that much (could be some minor differences since it impacts the order the cache line is filled, and that could be worth a few cycles here and there). --dave |
From: Robin G. <rob...@an...> - 2006-10-24 23:35:50
|
>> Eliot Moss wrote: >> > We may not want to change the object model, but custom reference > iteration >> > methods might be a speed win that does not involve any change to the >> > layout. >> > >> > Cheers -- E >> > >> This would be good imo. I'm interested to see that Dave's custom >> iterators for objects shows a ~30% speed up for GC tracing, but Robin's >> experience has been that object layout has a marginal impact on >> performance. From a philosophical point-of-view I believe the code >> desires to be object model agnostic, which custom iterators would > support. > > Remembering more of the details (it was 3 or 4 years ago :))...the > 30% came on the FixedLive program, which fills the heap with MBs of > objects of a single class (2 prim/2 reference slots in each I seem to > recall). So, the 30% is more of a limit study result than what you'd see > in practice on a real program. Perry and I were toying with the idea of > trying to get the compiler to automatically generate specialized tracing > routines based on heap demographics and wanted to see what the upper > limits on the achievable speedup were. > > On the question of locality impact of bi-directional object layout. I > agree with Steve that hardware is complex enough it's hard to make good > guesses. I think Eliot's observation that many objects fit on one cache > line is true....for any object that was all on the same cache line, the > layout shouldn't really matter that much (could be some minor differences > since it impacts the order the cache line is filled, and that could be > worth a few cycles here and there). > > --dave > So, the 30% is more of a limit study result than what you'd see in practice on a real program. I'll second this. In my experience FixedLive is actually a very poor indicator of how effective GC optimization is in any given benchmark. The MMTk tracing loop (in particular wrt the MarkSweep collector) has changed significantly even since my work last year, and it's possible that that some of these optimizations might now have more effect. I too am very interested in exploring the custom scanning method. One consideration when looking at new object layouts is that we need a way to scan memory sequentially - Sable solves this by laying out pointers before the header, and guaranteeing that the object header has a word with a low bit set. -- robin |
From: Ian R. <ian...@ma...> - 2006-11-20 10:04:25
|
Hi, just in case anyone chases down this thread in the future. There's a description of a bidirectional object layout optimization in: http://jikesrvm.sourceforge.net/wiki/index.php/Publications#Relative_Factors_in_Performance_Analysis_of_JVMs It'd be great if Dayong Gu, Clark Verbrugge or Etienne M. Gagnon could add this code to the research archive. Ian |
From: Dayong Gu <dg...@cs...> - 2007-03-12 18:53:54
|
Hi, Just notice this thread. Sorry to reply so late. I have a patch of sable object layout at http://www.sable.mcgill.ca/~dgu1/bidirectional-patch/bi-patch.diff This is a patch from jikes 2.3.4 which is a very old version. It was originally provided to Robin Garner at ANU. He is working on implementing sable like object layout on the lastest Jikes RVM code. Hopefully, we will get it soon. Cheers, Dayong Ian Rogers wrote: >Hi, > >just in case anyone chases down this thread in the future. There's a >description of a bidirectional object layout optimization in: > >http://jikesrvm.sourceforge.net/wiki/index.php/Publications#Relative_Factors_in_Performance_Analysis_of_JVMs > >It'd be great if Dayong Gu, Clark Verbrugge or Etienne M. Gagnon could >add this code to the research archive. > >Ian > > >------------------------------------------------------------------------- >Take Surveys. Earn Cash. Influence the Future of IT >Join SourceForge.net's Techsay panel and you'll get the chance to share your >opinions on IT & business topics through brief surveys - and earn cash >http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV >_______________________________________________ >Jikesrvm-researchers mailing list >Jik...@li... >https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers > > |
From: Ian R. <ian...@ma...> - 2007-03-13 09:21:54
|
Thanks Dayong this is great! I don't believe there are vast changes that would make incorporating this patch difficult, I think the main issue would be how to have a configurable object model - ie some static final controlling whether objects should be bidirectional or not. I wonder what progress Robin has made with this, and whether we should set up a branch to work on its incorporation. Thanks again, Ian Dayong Gu wrote: > Hi, > > Just notice this thread. Sorry to reply so late. > > I have a patch of sable object layout at > > http://www.sable.mcgill.ca/~dgu1/bidirectional-patch/bi-patch.diff > > This is a patch from jikes 2.3.4 which is a very old version. > > It was originally provided to Robin Garner at ANU. He is working on > implementing sable like object layout on the lastest Jikes RVM code. > Hopefully, we will get it soon. > > > Cheers, > Dayong > > > > Ian Rogers wrote: > > >> Hi, >> >> just in case anyone chases down this thread in the future. There's a >> description of a bidirectional object layout optimization in: >> >> http://jikesrvm.sourceforge.net/wiki/index.php/Publications#Relative_Factors_in_Performance_Analysis_of_JVMs >> >> It'd be great if Dayong Gu, Clark Verbrugge or Etienne M. Gagnon could >> add this code to the research archive. >> >> Ian >> >> >> ------------------------------------------------------------------------- >> Take Surveys. Earn Cash. Influence the Future of IT >> Join SourceForge.net's Techsay panel and you'll get the chance to share your >> opinions on IT & business topics through brief surveys - and earn cash >> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV >> _______________________________________________ >> Jikesrvm-researchers mailing list >> Jik...@li... >> https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers >> >> >> > > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys-and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Jikesrvm-researchers mailing list > Jik...@li... > https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers > |
From: Dayong Gu <dg...@cs...> - 2007-03-13 13:40:54
|
Yes, Ian. To have a configurable object model is a very interesting idea. One simple solution is to only use bi-directional layout for those objects with a large number of references. I thought some kind of similar idea (decide the type of layout dynamically ) before, but now I am busy with my thesis and did not actually begin to try it. Cheers, Dayong Ian Rogers wrote: >Thanks Dayong this is great! I don't believe there are vast changes that >would make incorporating this patch difficult, I think the main issue >would be how to have a configurable object model - ie some static final >controlling whether objects should be bidirectional or not. I wonder >what progress Robin has made with this, and whether we should set up a >branch to work on its incorporation. > >Thanks again, > >Ian > >Dayong Gu wrote: > > >>Hi, >> >>Just notice this thread. Sorry to reply so late. >> >>I have a patch of sable object layout at >> >>http://www.sable.mcgill.ca/~dgu1/bidirectional-patch/bi-patch.diff >> >>This is a patch from jikes 2.3.4 which is a very old version. >> >>It was originally provided to Robin Garner at ANU. He is working on >>implementing sable like object layout on the lastest Jikes RVM code. >>Hopefully, we will get it soon. >> >> >>Cheers, >>Dayong >> >> >> >>Ian Rogers wrote: >> >> >> >> >>>Hi, >>> >>>just in case anyone chases down this thread in the future. There's a >>>description of a bidirectional object layout optimization in: >>> >>>http://jikesrvm.sourceforge.net/wiki/index.php/Publications#Relative_Factors_in_Performance_Analysis_of_JVMs >>> >>>It'd be great if Dayong Gu, Clark Verbrugge or Etienne M. Gagnon could >>>add this code to the research archive. >>> >>>Ian >>> >>> >>>------------------------------------------------------------------------- >>>Take Surveys. Earn Cash. Influence the Future of IT >>>Join SourceForge.net's Techsay panel and you'll get the chance to share your >>>opinions on IT & business topics through brief surveys - and earn cash >>>http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV >>>_______________________________________________ >>>Jikesrvm-researchers mailing list >>>Jik...@li... >>>https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers >>> >>> >>> >>> >>> >>------------------------------------------------------------------------- >>Take Surveys. Earn Cash. Influence the Future of IT >>Join SourceForge.net's Techsay panel and you'll get the chance to share your >>opinions on IT & business topics through brief surveys-and earn cash >>http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV >>_______________________________________________ >>Jikesrvm-researchers mailing list >>Jik...@li... >>https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers >> >> >> > > >------------------------------------------------------------------------- >Take Surveys. Earn Cash. Influence the Future of IT >Join SourceForge.net's Techsay panel and you'll get the chance to share your >opinions on IT & business topics through brief surveys-and earn cash >http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV >_______________________________________________ >Jikesrvm-researchers mailing list >Jik...@li... >https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers > > |
From: Robin G. <rob...@an...> - 2007-03-13 23:24:46
|
> I wonder what progress Robin has made with this, I put it in as an SOC project :) I hope to get Dayong's patch up to SVN head in then next few weeks (and I'll add it back to the tracker), but doing anything about making the object model pluggable will have to wait until after the ISMM deadline. -- robin > Yes, Ian. To have a configurable object model is a very > interesting idea. One simple solution is to only > use bi-directional layout for those objects with a large > number of references. I thought some kind of similar > idea (decide the type of layout dynamically ) before, > but now I am busy with my thesis and did not > actually begin to try it. > > > Cheers, Dayong > > > Ian Rogers wrote: > >>Thanks Dayong this is great! I don't believe there are vast changes that >>would make incorporating this patch difficult, I think the main issue >>would be how to have a configurable object model - ie some static final >>controlling whether objects should be bidirectional or not. I wonder >>what progress Robin has made with this, and whether we should set up a >>branch to work on its incorporation. >> >>Thanks again, >> >>Ian >> >>Dayong Gu wrote: >> >> >>>Hi, >>> >>>Just notice this thread. Sorry to reply so late. >>> >>>I have a patch of sable object layout at >>> >>>http://www.sable.mcgill.ca/~dgu1/bidirectional-patch/bi-patch.diff >>> >>>This is a patch from jikes 2.3.4 which is a very old version. >>> >>>It was originally provided to Robin Garner at ANU. He is working on >>>implementing sable like object layout on the lastest Jikes RVM code. >>>Hopefully, we will get it soon. >>> >>> >>>Cheers, >>>Dayong >>> >>> >>> >>>Ian Rogers wrote: >>> >>> >>> >>> >>>>Hi, >>>> >>>>just in case anyone chases down this thread in the future. There's a >>>>description of a bidirectional object layout optimization in: >>>> >>>>http://jikesrvm.sourceforge.net/wiki/index.php/Publications#Relative_Factors_in_Performance_Analysis_of_JVMs >>>> >>>>It'd be great if Dayong Gu, Clark Verbrugge or Etienne M. Gagnon could >>>>add this code to the research archive. >>>> >>>>Ian >>>> >>>> >>>>------------------------------------------------------------------------- >>>>Take Surveys. Earn Cash. Influence the Future of IT >>>>Join SourceForge.net's Techsay panel and you'll get the chance to share >>>> your >>>>opinions on IT & business topics through brief surveys - and earn cash >>>>http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV >>>>_______________________________________________ >>>>Jikesrvm-researchers mailing list >>>>Jik...@li... >>>>https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers >>>> >>>> >>>> >>>> >>>> >>>------------------------------------------------------------------------- >>>Take Surveys. Earn Cash. Influence the Future of IT >>>Join SourceForge.net's Techsay panel and you'll get the chance to share >>> your >>>opinions on IT & business topics through brief surveys-and earn cash >>>http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV >>>_______________________________________________ >>>Jikesrvm-researchers mailing list >>>Jik...@li... >>>https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers >>> >>> >>> >> >> >>------------------------------------------------------------------------- >>Take Surveys. Earn Cash. Influence the Future of IT >>Join SourceForge.net's Techsay panel and you'll get the chance to share >> your >>opinions on IT & business topics through brief surveys-and earn cash >>http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV >>_______________________________________________ >>Jikesrvm-researchers mailing list >>Jik...@li... >>https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers >> >> > > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share > your > opinions on IT & business topics through brief surveys-and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Jikesrvm-researchers mailing list > Jik...@li... > https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers > |