Re: [rvm-research] Cloning of library methods for application and VM contexts

Hi Mohammad,

Man Cao (a PhD student working with me) compared the performance with 
and without cloning and found that cloning slows programs by 2% on 
average. That's for the 2006 and 2009 DaCapo Benchmarks + the JBBs 
(actually only the parallel ones, since we've been focusing on them for 
our work) on an AMD Opteron 6272 with 4 16-core processors, with 20 
trials (and verified that the confidence intervals look small enough to 
have confidence in the result).

We don't know the reason for the slowdown. Increased compile time 
doesn't seem to be the culprit, which makes sense since both versions of 
library methods get compiled at boot image build time. Possible culprits 
include (1) possible time overhead added to class loading-related 
activities like looking up resolved methods and doing interface call 
lookups and (2) extra instruction cache/TLB pressure.

Cloning also bloats the boot image and slows down boot image 
compilation, as one would expect, but the slowdown for building 
(FastAdaptive) is not really that much considering that all library 
methods are getting compiled twice. Maybe all those @Inlines in MMTk :) 
make VM code take relatively longer to compile than library code?

Cheers,
Mike

On 04/04/2013 06:48 AM, Mohammad Reza Azadmanesh wrote:
> Hi Michael,
>
> That's an interesting job. I just wonder if you have any statistics regarding the performance degradations as a result of applying this new infrastructure to Jikes with no instrumentation provided?
>
> Best,
> Mohammad
>
> On Apr 3, 2013, at 4:45 PM, Michael Bond <[email protected]<mailto:[email protected]>> wrote:
>
> Dear Researchers,
>
> I wanted to let you know about a patch recently added to the Research Archive that addresses challenges related to the fact that in Jikes RVM, the same Java libraries are called by both the VM and the application. In patched Jikes RVM, there are two versions of every library method: one called from the "VM context" and one called from the "application context." This makes it straightforward to instrument or modify only library methods called by the application, but not the VM, since the compiler just needs to check which version of a library method it's compiling.
>
> http://sourceforge.net/p/jikesrvm/research-archive/39/
>
> There's a README in the patch that provides more details about the implementation, as well as acknowledgments.
>
> Questions, suggestions, improvements to the patch, and other feedback are greatly appreciated.
>
> Cheers,
> Mike
> ------------------------------------------------------------------------------
> Minimize network downtime and maximize team effectiveness.
> Reduce network management and security costs.Learn how to hire
> the most talented Cisco Certified professionals. Visit the
> Employer Resources Portal
> http://www.cisco.com/web/learning/employer_resources/index.html_______________________________________________
> Jikesrvm-researchers mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers
>
>
> ------------------------------------------------------------------------------
> Minimize network downtime and maximize team effectiveness.
> Reduce network management and security costs.Learn how to hire
> the most talented Cisco Certified professionals. Visit the
> Employer Resources Portal
> http://www.cisco.com/web/learning/employer_resources/index.html
> _______________________________________________
> Jikesrvm-researchers mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers


------------------------------------------------------------------------------
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis & visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter