For First Time GSoC Applicants

Google Summer of Code for 2009 has been announced. In GSoC 2008, I applied and worked for Jato. It was really fun. Moreover it helped me to be a better developer than I had been. While doing my GSoC, I have learned git, under-the-hood details about Java and become a more matured C programmer. It also helped to shake off the initial intimidation factors in joining open source community as a developer for the first time. Before GSoC, I didn't even know the name of Jato, but now I am an active developer continuing my GSoC works.

Thats why I want to share what I have learned. I know there are plenty of resources available for GSoC wanna be applicants, but for the first-timers the initial process may be very confusing. Thats the audience on which I will focus.

So here it goes.

1. Start Early

Yes, start early, start Now ! Do not wait for the last moment. Go through the faqs, tutorials. Dig into the previous 2008, 2007, 2006, 2005 GSoC pages. Get an idea about the mentors that participated and projects that have been proposed. But it is important to keep in mind that no previous mentor organization is guaranteed to have a slot in GSoC.


2. Come up with a short list

As there are many organizations participating in GSoC now, it is necessary to make a list of organizations that you think suits you most. And I think, its better to make that list even before the announcement of accepted mentor list. Because without any sort of prior list and plan, you may run out of time if you need to go through all the accepted mentors and their projects one by one. Of course, there is a certain not-so-amazing possibility that your selected mentor failed to get a slot this year but, hey, you can certainly make changes in that case.

You can start sorting by using language. If you abhor loosely typed language there is no point in applying php, JavaScript focused mentors. Here is a list of mentors in 2008, categorized by language.

Another important factor in choosing the mentors apart from language that they use, might be the type of the work they do. Are you interested in working on compilers ? How about diving into GPS/Geospatial projects? Here is another nice categorized list of 2008 mentors that might help you to guess.

While traversing previous years' mentors list, you can find that even though officially no mentoring organization is guaranteed to have a slot, most well known mentors, for example apache, mozilla or pidgin, are almost sure to have slots. Thats the source of another dilemma. Because, well known mentors mean more fierce competition, while lesser known mentors are less likely to have slots. I had to face this problem. I chose to work on Plan 9 from Bell Labs. After reading lots of documents, doing lots of trying and testing with Inferno, it failed to get a grant. So, my advice is to come up with a balanced list.


3. Get in touch now

After choosing the list, its necessary to get in touch with the organization. Join the mailing list, hang in the IRC channel.

Read the mails carefully, watch the conversations in IRC. Most probably the 'hot' topics for upcoming gsoc will be discussed. Find out the steps and protocols for committing code.

And most importantly, try to get the culture in the organization. Some organization may be very strict. You might get burnt for Top-Posting or get a sharp 'RTFM' reply for asking something which has been answered else where. But thicken your skin for that. We all certainly make mistake, do say things which we later regret. The important thing is to learn from the mistakes and not to let the intimidation factor trade on you.

And particularly if this is your first approach to an open source community, you may lay low for few days both in IRC and mailing lists. Try to understand the environment, the pattern of conversations, which is allowed to ask and which is not. But don't hesitate to participate if the topic is in your level. It'll certainly help you to bond with your new developer colleagues.



4. Land on an Idea

Try hard to come up with an idea. Certainly, you can choose ideas from the proposed idea-list. But coming up with an idea can and will boost your chance to get accepted. While proposing idea, try hard to come up with original and ambitious idea which the organization actually 'needs'.

To come up with such ideas, you may need to start reading the development docs and go through few source code files. It is necessary to do so to find out how and where your idea fits and whether its feasible to complete within the GSoC time line (3 months approximately).

After coming up with an idea, the most important thing is to communicate with the organization. Propose the idea in details, get a feedback. That will make a strong case for your application.

I think it concludes the initial preparation. The next important step will be writing application. Here is some link for that

1. http://drupal.org/node/59037
2. http://inkscape.org/wiki/index.php/SOC_Writing_Project_Proposals
3. http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/194477
4. http://www.postgresql.org/developer/summerofcodeadvice.html
5. http://developer.pidgin.im/wiki/SoCDiscussions
   

Providing synchronization support in Jato

When I started to work on monitorenter and monitorexit, I thought it would be quite easy. Get the reference, call the lock/unlock function, done. But, soon after beginning, I was chanting "nothing-is-what-it-seems" mantra.

For monitorenter and monitorexit, it is necessary to provide support for goto and athrow bytecode instructions. Here is why.

Providing support for athrow instruction was easy. As Jato still does not support exception handling, actually nothing but function for bytecode consuming and dummy instruction selection rule was necessary.

But, for goto, I ran into a bug in control flow analyzer. So, after few hours of debugging, did fix that bug. And every thing was easy there after.

Then sent flood of patches! YAY !

( I made some nasty formatting horrors, which were fixed by Pekka. Thanks Pekka. )

Update On Jato

Well , everything seems little scattered.

<*>store and <*>load is almost done , but cant check whether it actually works or not because of its dependency on register allocation.

instanceof is done but a little code re-structuring is needed.


For monitorenter and monitorexit , parsing and code generation is done, but need to handle athrow as well.


Haven't looked into checkcast yet.

And the deadline is August 18. Gotta run !.

multianewarray byte instruction in Jato

I think, multianewarray instruction was the most tough one that I have confronted so far while working on Jato. But with the help of Pekka Enberg, finally I was able to creep out of the abyss.

Initially , I assumed (very naively) that the counts for multianewarray instruction would be pushed in expression stack as EXPR_VALUE expressions. But then, Pekka pointed out that it does not work for every situation. For example, it will break in the following code :

   public int[][] newArray(int x, int y) {
   return new int[x][y];
   }

The better way would be, as Pekka suggested, to 'abuse' the EXPR_ARG. That is , converting each count expression to argument expression, so that instruction selector can automatically push appropriate values on the stack.

So in multianewarrray byte code handler, what I do is, after popping dimension values from the expression stack, wrap each expression into EXPR_ARGS. Then, in instruction selection and code emission phase, as all the count values are already pushed on stack, all I need to do is, make a call to array allocation function in jamvm.

Easy as pie , when you are in right track !

Debugging Jato

In last few weeks , while working on arraylength bytecode instruction , I had to debug Jato . But instruction provided in readme file is rather obsolete . So I had to go through the run-suite.sh and ''reinvent the wheel" .

To debug , you have to point gnu.classpath.boot.library.path to <gnu_classpath_root>/lib/classpath and bootclasspath should contain <gnu_classpath_root>/share/classpath/glibj.zip and <jato_root>/lib/classes.zip.

The easiest way to do so is , setting the following values

GNU_CLASSPATH_ROOT=`<JATO_ROOT>/tools/classpath-config`

GLIBJ=$GNU_CLASSPATH_ROOT/share/classpath/glibj.zip

BOOTCLASSPATH=<JATO_ROOT>/lib/classes.zip:$GLIBJ

then applying usual gdb command ,i.e.,

gdb --args <JATO_ROOT>/java \
-Dgnu.classpath.boot.library.path=:$GNU_CLASSPATH_ROOT/lib/classpath \
-Xbootclasspath:$BOOTCLASSPATH -cp <JATO_ROOT>/regression class_file_name_to_debug

will launch it in debug mode. You can additionally pass any other command line option ( -Xint , -Xtrace:jit ... ) also.

Jato , The First Look

Usually looking into any OpenSource project is rather intimidating. But ,Jato, at the first look, did not seem that scary to me. The code base is not that large and I was somehow familiar with the field (at least I thought that !). And particularly the project owner was very nice to work with.

So , armed with git , I downloaded the source code , and started to hack on it (Who wants to go to the beach in a sunny day , when you can code ;) ) So far I have submitted patch for anewarray .

Initially ,it took times to grasp the idea . But thanks to Pekka Enberg , with his help , the ride so far is fun.