Re: [rvm-research] Jikesrvm-researchers Digest, Vol 71, Issue 4

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 454-5900

Hi:
   With gcc compiled code, oprofile may be able to collect those events. A fork of rvm supports oprofile.

DaFENG
Coder
Telecommunication && Network Industry
Gmail:sun...@gm...

________________________________
 From: Xin Tong <xer...@gm...>
To: jik...@li... 
Sent: Saturday, April 14, 2012 10:37 PM
Subject: Re: [rvm-research] Jikesrvm-researchers Digest, Vol 71, Issue 4

see comments below.

On Sat, Apr 14, 2012 at 6:56 AM,
<jik...@li...> wrote:
> Send Jikesrvm-researchers mailing list submissions to
>        jik...@li...
>
> To subscribe or unsubscribe via the World Wide Web, visit
>        https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers
> or, via email, send a message with subject or body 'help' to
>        jik...@li...
>
> You can reach the person managing the list at
>        jik...@li...
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Jikesrvm-researchers digest..."
>
>
> Today's Topics:
>
>   1. Re: Instruction Cache Optimization For Transaction Based
>      Workloads (Erik Brangs)
>   2. Re: Jikesrvm-researchers Digest, Vol 71, Issue 2 (Da Feng)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sat, 14 Apr 2012 10:32:58 +0200
> From: Erik Brangs <eri...@gm...>
> Subject: Re: [rvm-research] Instruction Cache Optimization For
>        Transaction Based Workloads
> To: "General discussion of Jikes RVM design, implementation, issues,
>        and plans" <jik...@li...>
> Message-ID: <4F8...@gm...>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Hi,
>
>> 2. RVM Java threads are multiplexed onto OS threads, which is
>> different from the implementation I know in which a java thread is
>> statically bounded to an OS thread.
>
> Jikes RVM uses native threading since 3.1.0, i.e. a Java thread is
> statically bound to a pthread. There are some places where the
> documentation has not been updated yet. If you find such a place, please
> let us know.
>
>
> Kind regards,
>
> Erik Brangs

How easy would it be to separate the Java thread from the pthread.
i.e. i want to be able to dynamically bound a java thread to a
pthread. then i can build a scheduler between the java thread and
pthread for my purposes.

Xin

>
>
>
> ------------------------------
>
> Message: 2
> Date: Sat, 14 Apr 2012 03:56:29 -0700 (PDT)
> From: Da Feng <jvf...@ya...>
> Subject: Re: [rvm-research] Jikesrvm-researchers Digest, Vol 71, Issue
>        2
> To: "General discussion of Jikes RVM design, implementation, issues,
>        and plans" <jik...@li...>
> Message-ID:
>        <133...@we...>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Hi:
> ?? Inlining and code reordering can help with prefetching and branch predictions. RVM has done those. May be you need to know the root cause of L1i misses. Can RVM pass daytrader with classpath lib? I think lots of bugs need to be fixed and even dacapo configuration files need to be modified to pass those tests. It's a different problem with openJdk. Each transaction can follow a different code path, and RVM recompile code on-the-fly.
>
> ?
> DaFENG
> Coder
> Telecommunication && Network Industry
> Gmail:sun...@gm...
>
>
As i said, I am new to the RVM community. RVM has been there for 10+
years, why would it have trouble running daytrader ? can it run
specjbb ?.

lets assume i just want to measure steady state performance. i.e. all
important methods compiled to the highest level of optimizations.
indeed, i need some measurements on the real numbers and causes of the
instruction misses before we can continue with this discussion
further.

the idea originally comes from optimizing TPC workloads. TPC workloads
are statically compiled. so once the instructions are generated, they
can not be modified. However, one of the advantages of Java workloads
is that the JIT is free to generate and regenerate instructions.

Xin

>
> ________________________________
>  From: Xin Tong <xer...@gm...>
> To: jik...@li...
> Sent: Saturday, April 14, 2012 12:24 PM
> Subject: Re: [rvm-research] Jikesrvm-researchers Digest, Vol 71, Issue 2
>
> see comments below.
>
>
> On Fri, Apr 13, 2012 at 9:47 PM,
> <jik...@li...> wrote:
>> Send Jikesrvm-researchers mailing list submissions to
>> ? ? ? ?jik...@li...
>>
>> To subscribe or unsubscribe via the World Wide Web, visit
>> ? ? ? ?https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers
>> or, via email, send a message with subject or body 'help' to
>> ? ? ? ?jik...@li...
>>
>> You can reach the person managing the list at
>> ? ? ? ?jik...@li...
>>
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of Jikesrvm-researchers digest..."
>>
>>
>> Today's Topics:
>>
>> ? 1. CFP: GPCE'12 - International Conference on Generative
>> ? ? ?Programming and Component Engineering (Matthias Hauswirth)
>> ? 2. [ jikesrvm-Research Archive-3515590 ] cross compile ? ? ? rvm for
>> ? ? ?ppc, using qemu and guestfs (SourceForge.net)
>> ? 3. cross compile rvm for ppc32 (Da Feng)
>> ? 4. Instruction Cache Optimization For Transaction Based
>> ? ? ?Workloads (Xin Tong)
>> ? 5. Re: Instruction Cache Optimization For Transaction ? ? ? ?Based
>> ? ? ?Workloads (Da Feng)
>>
>>
>> ----------------------------------------------------------------------
>>
>> Message: 1
>> Date: Thu, 5 Apr 2012 19:38:02 +0200
>> From: Matthias Hauswirth <Mat...@us...>
>> Subject: [rvm-research] CFP: GPCE'12 - International Conference on
>> ? ? ? ?Generative Programming and Component Engineering
>> To: "General discussion of Jikes RVM design, implementation, issues,
>> ? ? ? ?and ? ? plans" <jik...@li...>
>> Message-ID:
>> ? ? ? ?<CABO-EQQeoSuWj0OXvvP=1YCdkJwCFyxuNM=Xtp...@ma...>
>> Content-Type: text/plain; charset="UTF-8"
>>
>> Dear Jikes RVM Researchers,
>>
>> While GPCE is not a VM conference per se, some of us might be working
>> on problems very closely related to the GPCE'12 topics (see below).
>>
>> The abstract submission deadline is April 23, papers are due April 30.
>>
>> Best regards,
>> -Matthias Hauswirth
>>
>>
>> ------------------------------------------------------------------------
>> ? ? ? ? ? ? ? ? ? ? ? ? CALL FOR PAPERS
>> ? ? ? ? ? ? ? Eleventh International Conference on
>> ? ? ? ?Generative Programming and Component Engineering
>> ? ? ? ? ? ? ? ? ? ? ? ? ? (GPCE 2012)
>> ? ? ? ? ? ? ? ? ? ? ? September 24-27, 2012
>> ? ? ? ? ? ? ? ? ? ? ? ? Dresden, Germany
>> ? ? ? ? ? ? ? ? ? ?(collocated with SLE 2012)
>>
>> ? ? ? ? ? ? ? ? ? ? ? ? http://gpce.org/
>>
>> ? ? ? ? ? ? ? ? ? ?http://twitter.com/GPCECONF
>> ? ? ? ? ? ? ?http://www.facebook.com/GPCEConference
>> ------------------------------------------------------------------------
>>
>>
>> Important Dates
>>
>> ? Submission of abstracts: Monday, April 23, 2012; 23:55 Honolulu time
>> ? ? ? ? ? ? ? ? ? ? ? ? ? ?(hard deadline)
>> ? Submission of papers: ? ?Monday, April 30, 2012; 23:55 Honolulu time
>> ? ? ? ? ? ? ? ? ? ? ? ? ? ?(hard deadline)
>> ? Author notification: ? ? Monday, June 4, 2012
>>
>> Scope
>>
>> Generative and component approaches are revolutionizing software
>> development just as automation and componentization revolutionized
>> manufacturing. Key technologies for automating program development are
>> Generative Programming for program synthesis, Component Engineering for
>> modularity, and Domain-Specific Languages (DSLs) for compact problem-
>> oriented programming notations.
>>
>> The International Conference on Generative Programming and Component
>> Engineering is a venue for researchers and practitioners interested in
>> techniques that use program generation and component deployment to increase
>> programmer productivity, improve software quality, and shorten the time-to-
>> market of software products. In addition to exploring cutting-edge
>> techniques of generative and component-based software, our goal is to
>> foster further cross-fertilization between the software engineering and the
>> programming languages research communities.
>>
>>
>> Submissions
>>
>> Research papers
>>
>> 10 pages in SIGPLAN proceedings style with 10 pt. font size
>> (sigplanconf.cls with the [10pt] option, see
>> http://www.sigplan.org/authorInformation.htm) reporting original and
>> unpublished results of theoretical, empirical, conceptual, or experimental
>> research that contributes to scientific knowledge in the areas listed below
>> (the PC chair can advise on appropriateness).
>>
>> Tool demonstrations
>>
>> Tool demonstrations should present tools that implement generative and
>> component-based software engineering techniques, and are available for use.
>> Any of the GPCE'12 topics of interest are appropriate areas for tool
>> demonstrations. Purely commercial tool demonstrations will not be accepted.
>> Submissions have to contain a tool description of 4 pages in SIGPLAN
>> proceedings style with 10 pt. font size (sigplanconf.cls with the [10pt]
>> option) and a demonstration outline including screenshots of up to 4 pages.
>> The four page tool description will, if the demonstration is accepted, be
>> published in the proceedings. The four page demonstration outline will only
>> be used by the program committee for evaluating the submission.
>>
>> Tech talks
>>
>> Tech talks are about an hour in length and, similarly to tutorials, do not
>> need to present original new research material. Unlike longer tutorials,
>> these talks cannot be very interactive, and should instead aim to be
>> 'keynote' style presentations. Please see the tech talks call for
>> contributions for details:
>> http://program-transformation.org/GPCE12/CallForTechTalks
>>
>> Workshops
>>
>> Please contact the chairs (ch...@gp...) if you would like to organize a
>> workshop of interest to the GPCE audience.
>>
>>
>> Special issue: Science of Computer Programming
>>
>> After the conference, the authors of distinguished papers will be invited
>> to submit extended versions of their papers to a GPCE special issue of the
>> journal Science of Computer Programming.
>>
>> Topics
>>
>> GPCE seeks contributions in software engineering and in programming
>> languages related (but not limited) to:
>>
>> * Generative programming
>> ?+ Reuse, meta-programming, partial evaluation, multi-stage and multi-
>> ? level languages, step-wise refinement, generic programming, automated
>> ? code generation
>> ?+ Semantics, type systems, symbolic computation, linking and explicit
>> ? substitution, in-lining and macros, templates, program transformation
>> ?+ Runtime code generation, compilation, active libraries, synthesis from
>> ? specifications, development methods, generation of non-code artifacts,
>> ? formal methods, reflection
>>
>> * Generative techniques for
>> ?+ Product-line architectures
>> ?+ Distributed, real-time and embedded systems
>> ?+ Model-driven development and architecture
>> ?+ Resource bounded/safety critical systems.
>>
>> * Component-based software engineering
>> ?+ Reuse, distributed platforms and middleware, distributed systems,
>> ? evolution, patterns, development methods, deployment and configuration
>> ? techniques, formal methods
>>
>> * Integration of generative and component-based approaches
>>
>> * Domain engineering and domain analysis
>> ?+ Domain-specific languages including visual and UML-based DSLs
>>
>> * Separation of concerns
>> ?+ Aspect-oriented and feature-oriented programming,
>> ?+ Intentional programming and multi-dimensional separation of concerns
>>
>> * Applications of the above in industrial scenarios or to real-world
>> ?problems, bridging the gap between theory and practice
>>
>> * Empirical studies
>> ?+ Original work in any of the areas above where there is a substantial
>> ? empirical dimension to the work being presented. Such contributions
>> ? might take the form of a case/field study, comparative analysis,
>> ? controlled experiment, survey or meta-analysis of previous studies.
>>
>> Incremental improvements over previously published work should have been
>> evaluated through systematic, comparative, empirical, or experimental
>> evaluation. Submissions must adhere to SIGPLAN's republication policy
>> (http://www.sigplan.org/republicationpolicy.htm). Please contact the
>> program chair if you have any questions about how this policy applies to
>> your paper (ch...@gp...).
>>
>>
>> Organization
>>
>> Chairs (ch...@gp...)
>>
>> ? General Chair: Klaus Ostermann (University of Marburg, Germany)
>> ? Program Chair: Walter Binder (University of Lugano, Switzerland)
>> ? Publicity Chair: Matthias Hauswirth (University of Lugano, Switzerland)
>>
>> Program Committee
>>
>> ? Benoit Baudry (INRIA, France)
>> ? Alexandre Bergel (University of Chile, Chile)
>> ? Eric Bodden (TU Darmstadt, Germany)
>> ? Shigeru Chiba (Tokyo Institute of Technology, Japan)
>> ? Grzegorz Czajkowski (Google Inc., USA)
>> ? Elisabetta Di Nitto (Politecnico di Milano, Italy)
>> ? Erik Ernst (University of Aarhus, Denmark)
>> ? Michael Franz (University of California Irvine, USA)
>> ? Ronald Garcia (University of British Columbia, Canada)
>> ? Thomas Gross (ETH Zurich, Switzerland)
>> ? Michael Haupt (Oracle Labs, Germany)
>> ? Christian K?stner (University of Marburg, Germany)
>> ? Andreas Krall (Vienna University of Technology, Austria)
>> ? Doug Lea (State University of New York at Oswego, USA)
>> ? Yanhong Annie Liu (State University of New York at Stony Brook, USA)
>> ? Nicolas Loriant (Imperial College, UK)
>> ? Hidehiko Masuhara (University of Tokyo, Japan)
>> ? Oscar Nierstrasz (University of Bern, Switzerland)
>> ? Nathaniel Nystrom (University of Lugano, Switzerland)
>> ? Ulrik Pagh Schultz (University of Southern Denmark, Denmark)
>> ? Jens Palsberg (University of California Los Angeles, USA)
>> ? Ina Schaefer (TU Braunschweig, Germany)
>> ? Sibylle Schupp (Hamburg University of Technology, Germany)
>> ? Mario S?dholt (?cole des Mines de Nantes, France)
>> ? Paul Tarau (University of North Texas, USA)
>> ? Eli Tilevich (Virginia Tech, USA)
>> ? Petr T?ma (Charles University, Czech Republic)
>> ? Alex Villaz?n (Universidad Privada Boliviana, Bolivia)
>> ? Eric Wohlstadter (University of British Columbia, Canada)
>> ? Jianjun Zhao (Shanghai Jiao Tong University, China)
>>
>>
>>
>> ------------------------------
>>
>> Message: 2
>> Date: Fri, 06 Apr 2012 16:21:39 -0700
>> From: SourceForge.net <no...@so...>
>> Subject: [rvm-research] [ jikesrvm-Research Archive-3515590 ] cross
>> ? ? ? ?compile rvm for ppc, using qemu and guestfs
>> To: SourceForge.net <no...@so...>
>> Message-ID:
>> ? ? ? ?<mai...@li...>
>>
>> Content-Type: text/plain; charset=UTF-8
>>
>> Research Archive item #3515590, was opened at 2012-04-06 16:21
>> Message generated for change (Tracker Item Submitted) made by vondart
>> You can respond by visiting:
>> https://sourceforge.net/tracker/?func=detail&atid=723235&aid=3515590&group_id=128805
>>
>> Please note that this message will contain a full copy of the comment thread,
>> including the initial issue submission, for this request,
>> not just the latest update.
>> Category: None
>> Group: None
>> Status: Open
>> Priority: 5
>> Private: No
>> Submitted By: Da Feng (vondart)
>> Assigned to: Nobody/Anonymous (nobody)
>> Summary: cross compile rvm for ppc, using qemu and guestfs
>>
>> Initial Comment:
>> A document, a patch and some scripts to build rvm for ppc32. The patch is only intended as reference of modification, as rvm has not considered configuration of cross compiler, and the patch will break native builds. So to support native compile and cross compile together, rvm build scripts need redesign.
>>
>> The general principal is to use --with-sysroot and --sysroot options to point to mounted qcow2 image. Environment variables effecting pkg-config and configure is also changed. Since rvm bootImage builds doesn't use these autotool, it's necessary to create symbol links in cross tool directory for target system internal links. ?Without manually made links, target link will point to host root, and some times can't find gcc-x.x.x directories.
>>
>> ----------------------------------------------------------------------
>>
>> You can respond by visiting:
>> https://sourceforge.net/tracker/?func=detail&atid=723235&aid=3515590&group_id=128805
>>
>>
>>
>> ------------------------------
>>
>> Message: 3
>> Date: Fri, 6 Apr 2012 16:34:04 -0700 (PDT)
>> From: Da Feng <jvf...@ya...>
>> Subject: [rvm-research] cross compile rvm for ppc32
>> To: Generaldiscussionof Jikes RVMdesign implementation issues andplans
>> ? ? ? ?<jik...@li...>
>> Message-ID:
>> ? ? ? ?<133...@we...>
>> Content-Type: text/plain; charset=iso-8859-1
>>
>> Hi:
>> ?? I've finished the document, and catTrack still don't respond. So I just submit the document,https://sourceforge.net/tracker/?func=detail&aid=3515590&group_id=128805&atid=723235
>>
>> ?
>> DaFENG
>> Coder
>> Telecommunication && Network Industry
>> Gmail:sun...@gm...
>>
>
> Prefetching will definitely help. However, there are two problems i
> see with prefetching instructions.
>
> 1. prefetching instructions take time to finish. it could take up to
> hundreds of clock cycles if the instructions are not in cache.
>
> 2. prefetching instructions are generated based on behavior of the
> application at just-in-time compile time. this behavior could change.
> my proposed core switching technique discovers the code that is going
> to be executed dynamically and the code that is going to be executed
> is readily in the code cache.
>
> Xin
>>
>>
>>
>> ------------------------------
>>
>> Message: 4
>> Date: Fri, 13 Apr 2012 20:45:52 -0400
>> From: Xin Tong <xer...@gm...>
>> Subject: [rvm-research] Instruction Cache Optimization For Transaction
>> ? ? ? ?Based ? Workloads
>> To: jik...@li...
>> Message-ID:
>> ? ? ? ?<CALKntY0_ysR+PGzXQ_dMyv8x9+SJBN2=N94CrSG=yxU...@ma...>
>> Content-Type: text/plain; charset=ISO-8859-1
>>
>> Hello
>>
>> I am new to the RVM community. I have an research project I will be
>> doing this summer, I would like to seek some advices.
>>
>> In a transaction based java workload, i.e. daytrader, specjbb.
>> instructions for transactions typically do not fit in the first level
>> instruction cache. ?i.e. the instructions used at the beginning of the
>> transaction is usually kicked out of the cache when the transaction
>> reaches its middle point or later. when the next transaction running
>> similar instructions comes in. It will suffer the compulsory icache
>> misses for the evicted instructions.
>>
>> The idea is as follow. what if we begin to spread the transaction code
>> among icache of multiple processor cores. say transaction A comes in,
>> the first part of it is executed on core #1, the second part of it is
>> executed on core #2, etc. and when transaction B comes in, assuming it
>> is executing the same code as transaction A, the first part of it will
>> execute on core #1 and second part execute on core #2, etc. This way,
>> we save on a lot of cache misses.
>>
>> However, there are two things we do suffer. 1. data misses. the
>> transaction is moving from core to core. 2. transition overhead. the
>> overhead involves in moving a transaction from core to core. I do not
>> want to argue how much these two factors will account for and whether
>> this approach will give any beneficial results at all at the moment.
>> I just would like to know whether this is doable in RVM. what about
>> openJDK ? What are some of the advantages RVM has over openJDK in this
>> project, and vice versa.
>>
>> Two advantages RVM has i can think of right now is that
>> 1. faster development.
>> 2. RVM Java threads are multiplexed onto OS threads, which is
>> different from the implementation I know in which a java thread is
>> statically bounded to an OS thread.
>>
>> Any comments, suggestions, ideas are welcome and will be greatly appreciated.
>>
>> Cheers
>>
>> Xin
>>
>>
>>
>> ------------------------------
>>
>> Message: 5
>> Date: Fri, 13 Apr 2012 18:47:45 -0700 (PDT)
>> From: Da Feng <jvf...@ya...>
>> Subject: Re: [rvm-research] Instruction Cache Optimization For
>> ? ? ? ?Transaction ? ? Based Workloads
>> To: "General discussion of Jikes RVM design, implementation, issues,
>> ? ? ? ?and plans" <jik...@li...>
>> Message-ID:
>> ? ? ? ?<133...@we...>
>> Content-Type: text/plain; charset="iso-8859-1"
>>
>> Hi:
>> ?? How about prefetching? If prefetched instructions are ready before execution, pipeline will not slow down, given enough bandwidth.
>>
>> ?
>> DaFENG
>> Coder
>> Telecommunication && Network Industry
>> Gmail:sun...@gm...
>>
>>
>>
>> ________________________________
>> ?From: Xin Tong <xer...@gm...>
>> To: jik...@li...
>> Sent: Saturday, April 14, 2012 8:45 AM
>> Subject: [rvm-research] Instruction Cache Optimization For Transaction Based Workloads
>>
>> Hello
>>
>> I am new to the RVM community. I have an research project I will be
>> doing this summer, I would like to seek some advices.
>>
>> In a transaction based java workload, i.e. daytrader, specjbb.
>> instructions for transactions typically do not fit in the first level
>> instruction cache.? i.e. the instructions used at the beginning of the
>> transaction is usually kicked out of the cache when the transaction
>> reaches its middle point or later. when the next transaction running
>> similar instructions comes in. It will suffer the compulsory icache
>> misses for the evicted instructions.
>>
>> The idea is as follow. what if we begin to spread the transaction code
>> among icache of multiple processor cores. say transaction A comes in,
>> the first part of it is executed on core #1, the second part of it is
>> executed on core #2, etc. and when transaction B comes in, assuming it
>> is executing the same code as transaction A, the first part of it will
>> execute on core #1 and second part execute on core #2, etc. This way,
>> we save on a lot of cache misses.
>>
>> However, there are two things we do suffer. 1. data misses. the
>> transaction is moving from core to core. 2. transition overhead. the
>> overhead involves in moving a transaction from core to core. I do not
>> want to argue how much these two factors will account for and whether
>> this approach will give any beneficial results at all at the moment.
>> I just would like to know whether this is doable in RVM. what about
>> openJDK ? What are some of the advantages RVM has over openJDK in this
>> project, and vice versa.
>>
>> Two advantages RVM has i can think of right now is that
>> 1. faster development.
>> 2. RVM Java threads are multiplexed onto OS threads, which is
>> different from the implementation I know in which a java thread is
>> statically bounded to an OS thread.
>>
>> Any comments, suggestions, ideas are welcome and will be greatly appreciated.
>>
>> Cheers
>>
>> Xin
>>
>> ------------------------------------------------------------------------------
>> For Developers, A Lot Can Happen In A Second.
>> Boundary is the first to Know...and Tell You.
>> Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
>> http://p.sf.net/sfu/Boundary-d2dvs2
>> _______________________________________________
>> Jikesrvm-researchers mailing list
>> Jik...@li...
>> https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>>
>> ------------------------------
>>
>> ------------------------------------------------------------------------------
>> For Developers, A Lot Can Happen In A Second.
>> Boundary is the first to Know...and Tell You.
>> Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
>> http://p.sf.net/sfu/Boundary-d2dvs2
>>
>> ------------------------------
>>
>> _______________________________________________
>> Jikesrvm-researchers mailing list
>> Jik...@li...
>> https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers
>>
>>
>> End of Jikesrvm-researchers Digest, Vol 71, Issue 2
>> ***************************************************
>
> ------------------------------------------------------------------------------
> For Developers, A Lot Can Happen In A Second.
> Boundary is the first to Know...and Tell You.
> Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
> http://p.sf.net/sfu/Boundary-d2dvs2
> _______________________________________________
> Jikesrvm-researchers mailing list
> Jik...@li...
> https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers
> -------------- next part --------------
> An HTML attachment was scrubbed...
>
> ------------------------------
>
> ------------------------------------------------------------------------------
> For Developers, A Lot Can Happen In A Second.
> Boundary is the first to Know...and Tell You.
> Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
> http://p.sf.net/sfu/Boundary-d2dvs2
>
> ------------------------------
>
> _______________________________________________
> Jikesrvm-researchers mailing list
> Jik...@li...
> https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers
>
>
> End of Jikesrvm-researchers Digest, Vol 71, Issue 4
> ***************************************************

------------------------------------------------------------------------------
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
_______________________________________________
Jikesrvm-researchers mailing list
Jik...@li...
https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers