Google Summer of Code 2013
This page hosts the ideas for Google Summer of Code 2013! Add your ideas here, improve others, and if you're a student, perhaps something on this list will interest you!
The JRuby organization's page in the Google Summer of Code app will let you apply as a mentor or student. If you can't be a mentor or student, we hope you will pass this information on to others.
Of course we'd love to have a ton of great JRuby work come out of GSoC, but we'd also like that work to benefit the larger Ruby community where possible. Many of the ideas listed below apply equally to JRuby and other implementations.
We also hope that students will continue to be JRuby contributors long after GSoC 2013 is complete. We're looking to help students grow their resumes and help the JRuby project grow its community.
Our primary focus is on making sure students get a good summer's work and education out of the project.
The full, official calendar is here: https://google-melange.appspot.com/gsoc/events/google/gsoc2013
-
April 9 - 21: Mentors can apply and students should start talking with mentors and JRuby team members about ideas.
-
April 22 - May 3: Students can apply to work on a JRuby GSoC project.
-
May 4 - 6: Mentors review and accept student proposals.
-
May 8: GSoC provides JRuby with a count of slots for student projects.
-
May 9-22: Slot juggling; available slots are assigned to student projects.
-
May 24: Final decisions on slots and students.
-
May 28 - June 16: Students get familiar with their mentors and start planning out the summer. NOTE: We expect students to start talking with mentors and JRuby team members long before this time.
-
June 17: Students begin work on their projects. Starting before this date is encouraged :-)
-
July 29 - August 2: Midterm reviews; mentors grade students on progress thus far.
-
September 16: Soft "pencils down" date. Students should be finished or nearly-finished with their projects.
-
September 23: Hard "pencils down" date. Students must be done with the official GSoC portion of their project. We strongly encourage students to continue working with the JRuby community after GSoC, but this ends the graded portion of the project.
-
Sepember 23 - 27: Mentors submit final reviews of student projects.
JRuby's GSoC communications take place (at least initially) on the jruby-gsoc Google Group. Once projects get going, most mentors and students will take their discussions offline, but while we're preparing for the summer most conversations happen on that list.
We also strongly encourage interested students and mentors to start communicating with the JRuby team as early as possible, either on the JRuby mailing lists or in our Freenode #jruby IRC channel.
Here's some classic ideas to get you started:
JRuby is already a great Ruby implementation, but we mask or exclude many Ruby behavioral tests for features that are incomplete or unimplemented. These missing features can be found in the spec/ruby/tags and test/ruby/externals/**/excludes directories. There are several projects along these lines:
-
Help fill out RubySpec with missing features and behaviors from Ruby 1.9 and Ruby 2.0. This benefits all Ruby implementations.
-
Help implement missing or incomplete features related to currently-excluded specs and tests. This helps JRuby itself become a better, more compatible implementation.
There's easily enough work to do here for multiple students.
Over the years, JRuby has gotten better and better at running Rails, but there remains work to do. This project would involve gathering existing benchmarks and "standard" applications (Redmine, etc) and using them to find remaining perf issues in JRuby. Some possible areas that could use improvement:
-
ActiveRecord-JDBC, the library that JRuby uses to wrap JDBC with ActiveRecord's ORM API. We have done various performance investigations over the years, but a concentrated effort to make it consistently faster across databases has never really been attempted.
-
jruby-rack and other servers. A JRuby on Rails app can only serve requests quickly if the server frontend is fast. There's always more that we can do to improve the speed of these requests, in jruby-rack (used for serving JRuby in existing app servers like Tomcat) or in purpose-built servers like Torquebox (JRuby for JBoss), Puma, Passenger, and others.
-
Data format libraries like json and yaml. More and more users of Rails are building JSON-based RESTful APIs atop it, and again the performance of one library (json) can be the limiting factor.
-
Templating libraries like Haml. In order to render results quickly to the browser, these libraries need to be fast. Haml in particular employs a number of Ruby code patterns that can severely impact performance. We need to investigate the performance of all these libraries and ensure that we run them as fast as possible.
-
Other libraries commonly used in Rails apps, such as for accessing caching servers like memcached, nosql databases like mongo, and queues like zeromq.
-
or wrap a Java lib?
-
@headius's wrapper around spymemcached needs a nice compatible Ruby API.
-
The Ragel-generated JSON gem for JRuby is currently slower than C versions because Ragel does not generate gotos (since Java has no gotos). Investigate ways to improve perf, possibly by adding JVM bytecode support (JVM bytecode has goto) to Ragel.
-
jruby-openssl needs better compatibility with MRI's implementations
-
eventmachine's TLS/SSL support is missing, currently just stubbed out
Ruboto is working, and has a solid IRB application and tools for generating apps. But there's more we can do, like shrinking the app, improving performance, and building better tooling.
- Improve startup time. Anything done here will make Ruboto more usable.
- Reduce runtime size. Find ways to reduce the amount of .class data we ship to devices.
- Straight-line performance. Android devices are very resource-limited, and we would like to improve the performance of JRuby on Android to address this fact.
- JIT compilation. Increase execution speed and reduce stack usage.
- AOT compilation. Faster startup and increased execution speed.
There's a few good JVMs that work on embedded devices, which means there's an opportunity for JRuby to expand into embedded applications.
JRuby has great java integration but it's a pain having to manage java dependencies manually. Making Rubygems and Bundler aware of Maven on JRuby would be awesome!
Vert.x provides an evented environment very similar to node.js, but without many of its flaws. JRuby is supported, but performance is not where we'd like it. There's a good summer's worth of work on better integrating JRuby and Vert.x so they can act as a high-performance evented Ruby environment.
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. While some optimizations are already in place including dead code elimination, method and block inlining (incomplete), 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 work on the interpreter, new performance optimizations, implementing new backends (ex: Dalvik).
A couple sample projects:
-
Optimize IR for interpretation: The IR is optimized for performance optimizations and for the JIT which want explicit state in IR, complex instructions broken down into simpler primitive instructions. But, interpreter wants fewer instructions since each extra instruction adds to interpretation overhead. Implement IR transformations that optimize IR right before interpretation (ex: collapse instruction chains within a basic block into expression trees, collapse multiple simple instructions into single complex instructions, etc.). Some of this functionality is in place in bits and pieces in very preliminary form, but it has not been integrated, tested, thought through.
-
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.
-
IR compiler optimizations: The JRuby IR provides a great opportunity to optimize the Ruby language, both by statically analyzing code and by gathering runtime profiles. 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.
Shoes is a cross-platform toolkit for writing graphical apps easily and artfully using Ruby. Unlike most other GUI toolkits, Shoes is designed to be easy and straightforward without losing power. Really, it’s easy! Shoes needs you! The shoes community gathered to write shoes4 together. Shoes4 is a complete rewrite of the Shoes DSL allowing exchangeable GUI-backends. The first and default backend is using JRuby and SWT. There are many interesting projects to tackle within the area of shoes4. You could work on video support, general support for more Shoes constructs or packaging stand alone applications.
You can have a look at the original Shoes4 Idea List over at the shoes4 list to get a more complete overview of ideas for shoes4 projects.
Moreover have a look at the shoes4 issues to see where help might be needed. If you want to get in touch otherwise join #shoes on freenode or send an email to shoes@librelist.com
Celluloid is an actor-based concurrent object framework (somewhat similar to Akka) written in pure Ruby. This means it presently uses Ruby Mutexes and ConditionVariables for synchronization. However, the JVM has many, many other options which could provide better performance.
The goal of this project would be to implement a duck type of the Celluloid::Mailbox class that leverages native JVM facilities to improve performance. Some examples to consider might be:
- ArrayBlockingQueue: These are fast, fixed-sized data structures built atop arrays. Their bounded size might require some semantic changes to Celluloid (see this ticket for discussion on bounded mailboxes) but are probably the simplest way to improve performance on Celluloid.
- LinkedTransferQueue: Introduced in Java 7, LinkedTransferQueue could provide Celluloid's existing unbounded semantics with better performance than Java's previous linked queues. LinkedTransferQueues are a bit complicated and support lots of different modes of operation, so mapping them specifically to Celluloid's semantics might be a bit difficult.
- LMAX Disruptor: Disruptor is a library which supports a number of different patterns for multithreaded execution. The main way LMAX could benefit Celluloid would be providing a way to preallocate and recycle inter-actor messages, storing them in a RingBuffer and providing cache-friendly operation while reducing the allocation rate and thus the demands on the GC. It's unclear if Disruptor's concurrency model could map to Celluloid's well, but it could be used in conjunction with the above data structures specifically for the purposes of leveraging preallocation.
- JRuby native IO and Process APIs
JRuby currently uses Java's standard NIO and ProcessBuilder APIs for doing all IO and process management. We've managed to hack this well enough over the years, but there are many features we can't easily support using only Java's APIs.
The Java Native Runtime provides an FFI layer to Java that JRuby uses for many basic POSIX functions. One of its subprojects, jnr-enxio, provides NIO-compatible wrappers around standard native IO operations, allowing things like selectable stdio (Java's stdio is not selectable), UNIX sockets (jnr-unixsocket), and the potential for us to spawn subprocesses using functions like posix_spawn (which can carry parent descriptors through to children).
JRuby would benefit from work on a process-management and IO subsystem based on JNR, for cases where the Java APIs simply are not suitable.
- Additional platform support
JRuby supports calling native libraries across many platforms, but there are platforms we don't support. For example, we have never worked on or tested JRuby + JNI + FFI on Android, which could make all of the native APIs of Android available to JRuby-on-Android users. We're looking for folks interested in managed/unmanaged integration, dynamic language binding, and late-bound native invocation optimization to help us improve this situation.
The Java parts of krypt ensure that JRuby no longer has to emulate the OpenSSL library. It uses Java's own JCE instead to implement a library-agnostic interface that provides full access to Ruby cryptography. If you are interested in cryptography in general, there is a wide variety of topics for you to work on - ranging from Authenticated Encryption modes, providing alternative implementations to the JCE provider on to XML or PDF signatures using Nokogiri for the former and Java open-source PDF libraries for the latter. If you are specializing in a particular topic and would like to apply it in reality, we'd enjoy to give you a playground to work on. If you are still looking for topics, here are some more ideas to get you started:
-
Help finishing the Provider API. This is the heart of krypt, a general-purpose API that integrates all sorts of different cryptography libraries under one common interface.
-
Further extend krypt-ossl to replace more and more of the OpenSSL extension in JRuby with krypt functionality
-
JRuby support for FuzzBert
-
Implement different cipher modes, most notably for Authenticated Encryption
-
Implement padding schemes for Digital Signatures and Ciphers
-
Refactor the ASN.1 parser/encoder to use more Ruby code. The current version is written entirely in Java (C for the MRI part), but it should be possible to replace much of that code with Ruby code while still keeping comparable performance.
-
Develop a Java bridge for integrating Providers that are written in C(++) using Java Native Access (JNA)
-
Design and implement a modern, fully RFC 5280-compliant PKIX certificate validation mechanism
Ruby 2.0 is here. That means JRuby needs to ensure that our libraries (both core and standard) are as compatible to it as possible. The work will involve surveying MRI's libraries, writing missing RubySpec specs, and implementing them.
Improving the build/dist process overall.
Even if we already have maven support for the build, we still store some binaries and host a parallel ant build.
The idea is to continue improving that process, by moving the dependencies to maven central and in the ant build case, making it download the deps on the first run.
Asciidoctor is a Ruby implementation of AsciiDoc. It can be used as a full replacement for the Python implementation and also has support for running on JRuby. You can find the projects on the Github Asciidoctor Organization. Specifically we'd be looking at the asciidoctor-java-integration, asciidoctor-maven-plugin and the asciidoctor-gradle-plugin for consideration for GSoC 2013 projects.
Ideas include, improvements, new features, better testing, live preview and any others people can dream up.