Following Chris reminder, here is a list of projects that VMKit (hence
JnJVM and N3) would profit off.
Projects I can mentor: (no preferences)
1) Generating shared libraries in LLVM bitcode or in the ELF/MachO
format. This will enable many features such as not recompiling Java or
CLI bytecode, optimize memory footprint. We could also generate
executables and do a whole program analysis and transformation.
2) Hotspot like llvm: being able to switch between interpreter and
compiler, choosing which optimizations to perform on the code, doing
3) Virtual-machine optimizations: removal of null checks, implement
optimizations for the Isolate API (many apps executing on the same JVM),
removal of array bounds checks, implement thin locks
4) Port VMKit to different platforms: currently, it compiles and runs on
gentoo linux/x86 and linux/ppc . At least, it would be nice to have a
port of vmkit to darwin/ppc, darwin/x86, linux/x86_64, darwin/arm and
5) Do a test-suite for VMKit.
6) Make VMKit more robust: a better build system, code review and
cleanup, integrate LLVM patch in LLVM svn.
7) Implement generics in N3
8) Interface VMKit with LLVM's GC facilities
9) Interface VMKit with another classpath library: currently only
gnu-classpath is supported. One could add the open-sourced Sun library.
Projects I could mentor, but an other mentor would be best:
10) Implement a type-based alias analysis in LLVM
11) Implement non-call exception handling in LLVM
12) Implement a generational and accurate garbage collector with LLVM GC
Projects I can not mentor:
13) Implement arithmetic overflow detection in LLVM
> Projects I could mentor, but an other mentor would be best:
> 10) Implement a type-based alias analysis in LLVM
> 11) Implement non-call exception handling in LLVM
I could mentor exception handling work. As well as non-call
exceptions there's a bunch of stuff to be done to optimize
(1) Move the personality function out of eh.selector and
make it per function. Have it be specified as a function
attribute like the garbage collector gc annotation.
(2) Move the catch-all definition out of eh.selector and
stick it in the LLVM meta-data (there needs to be some
kind of personality -> catch-all map in the meta-data).
With (1) and (2) done, it is possible to eliminate
eh.selector calls if they have no uses, and also not
to generate them in the first place if they were only
there to provide the personality and the catch-all.
(3) Instead of outputting explicit calls to the unwinder
rewind function in llvm-gcc, use a rewind intrinsic or
the unwind instruction instead. Teach codegen to lower
this to the appropriate unwinder call (this depends on
(4) If the only thing in a landing pad is a rewind,
change the invoke into a normal call. The point of (1)-(3)
above is to be able to do this. You get pointless invokes
all the time due to constructors/destructors which don't
actually do anything (but you only discover this after
having created the invoke + landing pad etc). This would
allow them to be turned into normal calls for a nice code
size reduction and code simplification.
(5) Lots of other stuff, see PR1508, PR2157 and PR2154