+1. We ran into one of these performance anomalies when code and data were intermingled a long time ago. It was pretty mystifying -- running experiments in my directory on the same machine was significantly faster than running it in the grad student's directory (different length of environment = different code offsets = cache conflicts for him but not for me). We resolved this by separating out the code and data for our MC^2 paper in OOPSLA 2004 (p.89-90) -- http://dl.acm.org/citation.cfm?doid=1035292.1028984 -- and Dave is so right -- no one should have to waste time dealing with that sort of thing :).

Professor Emery Berger
School of Computer Science
University of Massachusetts, Amherst

On Mon, Apr 21, 2014 at 2:10 PM, David P Grove <groved@us.ibm.com> wrote:

Nathan Ricci <vhalros@gmail.com> wrote on 04/16/2014 02:42:09 PM:

>    I was wondering what is actually allocated in the small code
> space? And are objects allocated there handled any differently than
> those in any other MarkSweepSpace?



The actual machine instructions (JITed code) for most methods (those that are not "too big", which go in a large code space).

You can find the original motivation and experiments for a separate code space described here: http://dx.doi.org/10.1145/1133956.1133980

The life time of code tends to be longer than many small objects, so there are some minor benefits to segregating it.  The main benefit though is to separate code from data to avoid stumbling over odd/annoying micro-architectural "features" that can cause performance lost when code and data is tightly intermixed.


Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
Jikesrvm-researchers mailing list