Re: [rvm-research] Question about ideas for code contribution: improve efficiency of compiler phase

Hi,

On 11.03.2015 22:58, Ricardo Coelho wrote:
> I'm a member of a group of students that is currently attending University classes about Virtual Execution Environments.
> We are supposed to do a study about a virtual machine and we chose Jikes RVM. [...]
> Also if you think that this task might be very complex to be done in the context of a university subject, be free to tell us. We're only now going into this and we don't really have a very precise idea about this mechanisms yet so we might be aiming to high.
Well, it's hard to give concrete advice without knowing more about your university course. You'll have to decide for yourself if my advice applies for your situation.

In general, I would say that it is better to start small and broaden the scope later rather than the other way round. That's especially true if you don't have an advisor that has already verified that the task is generally feasible.

There might be some interesting tasks on our bugtracker (not necessarily limited to the optimizing compiler) but the issues aren't classified according to effort. It might take a sizable amount of research to find out if anything from there is feasible as a project.

You should also consider grading: in some courses at some universities, it is required that the task is divided in such a way that each student can be graded separately.

> We saw in "ideas for code contributions" page that one of the things that would be useful for the project is improving the efficiency of some optimizing compiler phase.
> Although you already suggest starting phases, we would like to ask if theres any particular data structure or structures that you would like us to work on.
I don't have any advice on this off the top of my head, but you can always look for TODOs and FIXMEs in compiler phases / packages that are interesting to you.

> We would like to know any information you could provide to us. It would be very helpful.
Here are a few hints in no particular order:

a) The main problem with the optimizing compiler is that it's not in a particularly good shape with regards to the current state of the art.

The memory management subystem (i.e. MMTk) is generally in a good shape because many researchers use it. Other parts of the Jikes RVM need work. You can get an overwiew at the project status page ( http://www.jikesrvm.org/Project+Status ) .

b) My advice would be to strongly consider writing test cases for whichever part of the system you are touching. AFAIK the general approach to testing (optimizing) compilers is to have lots of little test cases as black-box-tests. You can do this using our regression testing infrastructure (see "Testing the RVM" on the website or in the user guide). The infrastructure is a bit cumbersome but it works.

You can also write JUnit tests for classes (see the existing ones) or use the OptTestHarness (which is described in the user guide).

c) If you don't have any specific knowledge on debugging, I'd also advise you to read at least one book about it. It'll likely save you a lot of time in the long run. We also have a page about "Debugging the RVM" on the website. For the optimizing compiler specifically, you can also enable paranoid IR verification in the class org.jikesrvm.compilers.opt.ir.IR which can detect some classes of bugs. The main problem with that setting is that it wasn't used for some time so bugs have accumulated in standard configurations.

d) Liberal use of assertions can be a good way to catch bugs early.

e) Remember that the Jikes RVM is an open source project. If you don't understand why a particular piece of code is written in a certain way, you can try to look in the source code history. Mailing list archives can also be a source of useful information.

f) It might be worth it to look at some of the material linked from the "Presentations" page. AFAIK the optimizing compiler design hasn't changed much so most of it should still be reasonably current. It's also likely that you'll want to look at the presentation about the intermediate representation by Shane Brewer if you're working on the optimizing compiler.

g) Decide if you want to stay with a release or follow the current mainline of development. Staying on a release means you don't have to deal with merges. You may still have to cherry-pick patches from mainline from time to time, though. If you use the current mainline and merge regularly, it will be easier to contribute code back. You'll also detect problems early enough to complain to the development team. If you do want to use the current mainline, you should aim to follow our coding conventions and run checkstyle from time to time to catch problems.

h) If you want to measure improvements to compile time, you should look into CompilerDNA and the associated scripts.


Don't hesitate to ask on the mailing lists if you have further questions.


Kind regards,

Erik Brangs

------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/