• Build vmkit into libjvm.so, which means some engineering issues regarding -fPIC (particularly the assembly in nullpointerexception/stackoverflow handlers needs to be updated for this), but otherwise relatively minor.
• Implement JVM_CreateJavaVM and related, which implies an implementation of JVM_AttachCurrentThread. Given our current assertions about thread layout (the way we do TLS among other things) makes this more or less impossible since we don't control the creation of the thread we want to attach.

For now the 'j3' launcher works, but this would go a long way towards facilitating better integration with the OpenJDK tools and make vmkit more appealing to the community perhaps.

Need an implementation for JVM_GetSystemPackages, and remove hardcoded values from Classpath to match the newly introduced mechanism for tracking bootstrap packages.

Used to implement reflective access to annotations (JDK 1.5)

This causes the tomcat, tradebeans, and tradesoap benchmarks from dacapo-9.12-bach to fail.

Output:
===== DaCapo hsqldb starting =====

• PseudoJDBCBench v1.1 *

  ---

Scale factor value: 64
Number of clients: 20
Number of transactions per client: 40

Initializing dataset...null
java.lang.NullPointerException
»·at dacapo.hsqldb.PseudoJDBCBench.(PseudoJDBCBench.java:355)
»·at dacapo.hsqldb.PseudoJDBCBench.main(PseudoJDBCBench.java:208)
»·at dacapo.hsqldb.HsqldbHarness.iterate(HsqldbHarness.java:19)
»·at dacapo.Benchmark.run(Benchmark.java:126)
»·at dacapo.TestHarness.runBenchmark(TestHarness.java:302)
»·at dacapo.TestHarness.main(TestHarness.java:242)
»·at Harness.main(Harness.java:5)
Digest validation failed for stdout.log, expecting 0x68f2be9306913c92688b6b34f8454b6311de9310 found 0x73b485d99b573475caaaa46b3b050cdb9a1e88a6
Digest validation failed for stderr.log, expecting 0xda39a3ee5e6b4b0d3255bfef95601890afd80709 found 0x5e8ba9ecd7ad8d10a5db2b763fd0ac1e423d8190
===== DaCapo hsqldb FAILED =====
Validation FAILED for hsqldb default

The benchmark doesn't run successfully.

Using default vmkit, it runs out of memory, and increasing the heapsize results in similar failure to issue #6.

See http://java.sun.com/docs/books/jni/html/refs.html .

Needed for much native code shipped with OpenJDK, particularly awt/swing/etc.

The GC tracing logic presently assumes fat locks will be immediately deflated when the contention is gone, and so keeps objects associated with fat locks alive as long as the lock exists (no good removing object from underneath held lock).

However, as of e862ea9, we don't deflate fat locks any longer which means we keep objects associated with fat locks alive forever.

There is no documentation on how to configure the OpenJDK port beyond ./configure --help

After it all seems in order (bounce past Nicolas), update http://vmkit.llvm.org/get_started.html accordingly.

Support Xms and Xmx options for specifying min/max heapsize (used by many application wrappers to set reasonable heap sizes for the application)

OpenJDK expects annotations to be byte arrays, while GNU Classpath wants an array of objects (Object[], probably Annotation[]).

The shared code in Reflect.inc presently returns an empty Object[], which is wrong for OpenJDK and causes the following to throw an exception (instead of printing no annotations, which is the present behavior until the various annotation-related issues are fixed):

import java.lang.annotation.Annotation;

@deprecated
public class AnnotationTest {
public static void main(String args[]) {
for(Annotation a : AnnotationTest.class.getAnnotations()) {
System.out.println(a);
}
for(Annotation a : AnnotationTest.class.getDeclaredAnnotations()) {
System.out.println(a);
}
}
}

Exception in thread "main" java.lang.annotation.AnnotationFormatError: Unexpected end of annotations.
at sun.reflect.annotation.AnnotationParser.parseAnnotations(AnnotationParser.java:72)
at java.lang.Class.initAnnotationsIfNecessary(Class.java:3093)
at java.lang.Class.getAnnotations(Class.java:3073)
at AnnotationTest.main(AnnotationTest.java:7)

Which is a fairly tame/neat error considering we're returning an object array casted to a byte array :).

When constructing Constructor, Method, and Field objects, presently we don't populate fields such as signature, annotations, etc.

See:

There are many tests you run manually, but automating these would have two benefits:
a)you don't forget/do it wrong/easy to run full gauntlet
b)can throw it on a server somewhere, and track progress/regressions over time.

Doesn't need to be fancy, but would be useful to have a grip on.

Bonus points if includes performance measurements, as we're lagging behind the Classpath implementation ATM, and it'd be nice to see that fixed.