GSoC 2015: I want to volunteer. need organization

[Christopher Friedt]

Hi again Mario & (finally!) Martijn as well as the rest of the
openjdk-adoption list,

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 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

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

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 changed codebase 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
in order to complete my application.

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