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 would like to volunteer as a mentor for the following project topic
under the umbrella of the GNU Project.

Proposed Topic: VMFlexArray PatchSet for OpenJDK (IcedTea)

Although drawing to the Linux FrameBuffer was the primary focus of my
FOSDEM talk [2], 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 yesterday 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
3) 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
4) provide example code for end users
5) 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. Incidentally, there is a nice video of my proof-of-concept
available [4] and all of my code is on github [5].

There are already students who have asked me to be their mentor for
this task. I simply need the umbrella of an Free Java organization
(e.g. GNU, IcedTea) in order for the topic to be available for
prospective students.

Can GNU please allow me to mentor a student on this topic?

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
[4] https://plus.google.com/+ChristopherFriedt/posts/XkNYEfgESea
[5] https://github.com/cfriedt