GSoC 2015: VMFlexArray for OpenJDK / IcedTea

[Christopher Friedt]

There are only 3 days left until the application deadline to be a
mentoring organization for GSoC 2015 [1].

I am entirely prepared to mentor a student in the process of creating
and submitting a patchset to OpenJDK (IcedTea) based on my FOSDEM
presentation [2]. However, I must somehow be affiliated with a
mentoring organization to do so. Technically, I could apply on behalf
of my company, MMB Networks, but we aren't really an open-source
company, I just tend to participate in a number of open-source
projects (with approval and no conflict-of-interest, of course)

Proposed Topic: VMFlexArray PatchSet for OpenJDK (IcedTea)

Although drawing to the Linux FrameBuffer was the primary focus of my
FOSDEM talk, an incidental aspect of my JamVM / Classpath patchset,
but practically the most important part is what I have called
"VMFlexArrays".

A blog post[3] from today describes why VMFlexArrays are so critical
in a "mathematically complete" sense of correct functionality of the
java.nio API. Consider (or even run) the following code snippet.

$ cat BufferFu.java
import java.nio.*;
import java.util.*;

public class BufferFu {
  public static void main( String[] arg ) {
    byte[] ba = new byte[] { (byte) 0xaa, (byte) 0xbb, (byte) 0xcc,
(byte) 0xdd };
    ByteBuffer bb = ByteBuffer.wrap( ba );
    IntBuffer ib = bb.asIntBuffer();
    int[] ia = ib.array();
    System.out.println( "ba: " + Arrays.asList( ba ) + ", ia: " +
Arrays.asList( ia ));
  }
}

$ java BufferFu
Exception in thread "main" java.lang.UnsupportedOperationException
at java.nio.IntBuffer.array(IntBuffer.java:994)
at BufferFu.main(BufferFu.java:9)

Why can't we represent the same physical / virtual memory with two
different array views when the backing storage is present and the
technology is available?

The patchset does not break or change the Java API, and in fact makes
the Java API work _better_!

VMFlexArrays also allow us to represent off-heap memory regions in
perfectly type-safe, managed java array objects. Such off-heap regions
include, but are not limited to
* arrays allocated by native libraries using malloc(3)
* special files like /dev/video0 mapped using mmap(2)
* process-specific heaps mapped using mmap(2)

The goal of the GSoC project is challenging, demanding, but would
greatly benefit the community at large.

The student will be expected to

0) demonstrate proficient understanding of C / C++ / Java, etc
1) transpose the proof-of-concept changes made to JamVM and GNU
Classpath into the OpenJDK x86 codebase (at least - ARM and
additionally PowerPC would also be helpful)
2) clearly document all changes
2) ensure that the proposed changeset passes any available and
applicable unit tests, or come up with a test suite that ensures the
changes are safe
3) provide example code for end users
4) benchmark performance improvements, and attempt additional
optimizations in a separate patchset

Naturally, since JamVM / Classpath and OpenJDK's codebase is quite
dramatically different, the student will really only have a conceptual
reference based on my original JamVM / Classpath proof-of-concept
work.

There are already people who have asked me to be their mentor for this
task. I simply need the umbrella of an OpenJDK affiliated organization
(e.g. IcedTea) in order to complete my application.

If nobody else is comfortable doing so, I could volunteer to
co-administer the IcedTea GSoC efforts for this year. It will require
1 other person. I could potentially have someone else in my
organization co-administer the GSoC this year as well, but it would be
beneficial to have another community member in a different time zone
(I'm in Canada / Eastern Standard Time).

Many thanks in advance,

Chris

[1] https://www.google-melange.com/gsoc/homepage/google/gsoc2015
[2] https://fosdem.org/2015/schedule/event/mapped_byte_buffer/
[3] http://perpetual-notion.blogspot.ca/2015/02/mappedbytebufferhurray-programming.html