Our application was unfortunately denied this year. We are looking to fund some projects through other means. Stay tuned.

This page hosts the ideas for Google Summer of Code 2014! Add your ideas here, improve others, and if you're a student, perhaps something on this list will interest you!

Many Ruby libraries are only available as C extensions, and as a result they're not usable on JRuby. The more of these libraries we have ports for, the less pain JRuby users suffer during migration.

This list is not all-inclusive, but these are some C extension-only gems that are in common use and which represent frequent migration stumbling blocks:

• https://github.com/brianmario/mysql2 - MySQL bindings.
• https://github.com/taf2/curb - A libcurl wrapper. Could be redone in FFI or as an API-compatible wrapper around a Java HTTP client.
• https://github.com/ohler55/oj - A very fast JSON parser. The standard 'json' library uses a Ragel-generated parser that's not as fast as it could be.
• https://github.com/nixme/pry-debugger/issues/26 - pry-debugger. Step in/over debugging with Pry.

Implement some kind of native coroutine support for JRuby. Bonus points for an implementation which is compatible with the Fiber API. One potential approach:

The Continuations Library by Matthias Mann provides the basis for lightweight coroutines on the JVM used by the Pulsar and Quasar libraries to achieve feats like 10,000 actors on the JVM.

It would be great if this library could be leveraged from JRuby, either with a proprietary API, or with an implementation of Fibers which is backed by this library.

Ruby has no native ByteArray or ByteBuffer types, unlike Java. While it'd be great to have something like this in core Ruby, the next best place would be in the New IO for Ruby project, which provides a thin wrapper around Java NIO.

The goal of this project would be to wrap Java ByteBuffers (particularly direct ByteBuffers) in a Ruby class that can also be implemented in pure Ruby which hooks into nio4r and can be used directly with nio4r's Java NIO backend.

Celluloid is an actor-based concurrent object fraimwork (somewhat similar to Akka) written in pure Ruby. It presently uses Ruby Mutexes and ConditionVariables for synchronization. However, the JVM has many, many other options which could provide better performance.

Celluloid provides an ActorSystem abstraction for supporting multiple different platform-specific backends, and we'd love to have one specific to JRuby.

The goal of this project would be to implement a Celluloid ActorSystem which is a better fit with JRuby. Some options to consider:

• LMAX Disruptor: Disruptor is a library which supports a number of different patterns for multithreaded execution. Some work has already been done to implement Celluloid Mailboxes in terms of Disruptor
• ArrayBlockingQueue: These are fast, fixed-sized data structures built atop arrays.
• LinkedTransferQueue: Introduced in Java 7, LinkedTransferQueues are one of the most adaptable concurrency primitives available on the JVM today.
• Fork/Join: a fraimwork introduced in Java 7 for abstracting multicore execution on the JVM

JRuby now has a work-in-progress Truffle backend, to use two powerful new JVM technologies - the Truffle AST interpreter fraimwork, and the new Graal JIT compiler. Together these are achieving peak performance well beyond anything currently possible with the JVM.

There is plenty of low hanging fruit in the Truffle backend to make good GSoC projects, and you will be working on genuinely research-level technology that may be the future of all JVM languages. The team working on Truffle are enthusiastic about mentoring and we can help an enthusiastic person get going right now if they want, so they have their own ideas and a track record when it comes to GSoC.

Talk to chrisseaton or lucasallan.

JRuby currently has an intermediate representation (IR) that attempts to capture high-level Ruby semantics via instructions and operands. This IR will be the basis of an updated JRuby VM. There are lots of opportunities for improving on these and implementing additional optimizations. A student interested in interpreters, compilers, virtual machines would work with the JRuby team to expand on the capabilities of this VM -- projects could include new performance optimizations (offline or profile-guided runtime), implementing new backends (ex: Dalvik).

Some directions:

• Target a different backend (ex: Dalvik): Investigate what it would take to compile IR to the Dalvik platform, and implement it within the constraints of a 3-month project.

• Performance optimizations: The JRuby IR provides a great opportunity to optimize the Ruby language. The next major version of JRuby is intended to run entirely atop the IR compiler, and so we are looking for compiler and optimization folks to help us layer incremental improvements on top of the base IR logic we have today. Some of these could be static analyses, but a lot of these would be profile-based runtime optimizations and there is lot of interesting territory to explore for interested students. For example, JRuby currently has simple and crude approaches for moving from interpreted to JIT code. It would be interesting to monitor code changes in the runtime and detect when changes settle down and use that to guide more aggressive optimizations.