(l) proper java native interface (JNI)
	-> atm just hackish solution.
	-> also, arguments are passed in the wrong order
	-> estimated effort: 3-4 days

(l) exceptions
	-> for gnu classpath absolutely necessary
	-> estimated effort: unknown

(l) replace signals with "nice traps"?
	pro -> don't rely on operating system anymore
	pro -> maybe better ghci behaviour?
	cons -> at some point, signals are useful for debugging?
	cons -> better "template" tricks are needed, as we cannot insert more
	instructions or want to place nop's at production code path

(l) gnu classpath integration
	-> would be awwwesome
	-> depends on: exceptions, jni (?)
	-> estimated effort: unknown

(m) hoopl
	-> for "frontEnd analysis"
	-> transition to MIR (Mate IR)?

(h) switch statement (basically lookupswitch insn)

(m) testing: hunit? quickcheck? other?
	-> we have `make tests' now, but it should be only considered as
	   high-level test. we need something
	-> estimated effort: for infrastructure, 2-3 days

(l) instanceof, checkcast
	-> typechecking at runtime. with displays or something
	-> depends on: exceptions (not absolutely necessary, but preferable)
	-> estimated effort: 1 day

(h) bug (?): can there be a namespace clash with static and non-static methods?
	-> the signature doesn't contain the static modifier
	-> estimated effort: some hours (if a fix is needed)

(h) global map hack:
	-> it's an stupid and ugly hack. we don't want that.
	-> estimated effort: unknown. research for a solution is needed

(l) cabal file

(h) so much cleanup...
	-> define constant for native size stuff
	-> and much more

(m) enable easy recompiliation of a method
	-> we need a map where all callers are stored
	   in order to patch those to the new address
	-> free old code region. maybe replace it with
	   some magic values, e.g. which produce a signal
	   in order to enable easier debugging

(h) get rid of trap.c
	-> it's C. we don't want that.
	-> at the moment System.Posix.Signal isn't powerful enough
	-> wait for: http://hackage.haskell.org/trac/ghc/ticket/2451

(l) check different types (byte, long, ...)

(l) floating point support

(h) better code generation
	-> at least peephole optimazation would be nice (e.g. kill `push eax; pop
	eax')
	-> but we want more!!11 ;-)
	-> estimated effort: 2-3 weeks

(m) benchmark for presentation

(l) get rid of missingh
	-> huge dependency and we just need one function of it

(l) get more details what takes time
	-> use Data.Time.Clock
	-> seperate analysis, jit, execution, ...
	-> maybe use ghc profiling? (it doesn't measure native execution, but well)

(l) testing
	-> specjvm98
	-> dacapo benchmark suite


(l) ... low priority
(m) ... medium priority
(h) ... high priority


what we won't do anytime soon:
( ) garbage collection
( ) thread support
( ) verifier



/* old stuff */
Design Meeting - 21.March.2012


1) Compile on Basic Blocks on Demand or complete Methods (check how cacao, mono works)
2) Calling-Conventions - Standard wegen den Sprüngen (why does Cacao use strange CallingConventions)
3) Capture Meta-Information by Instruction and Basics-Block
4) Benchmark Suits - what features do we need?
5) Boehm GC? using Haskell GC? From Scratch GC? GC option
6) hs-java reinschauen - kann das schon BBA


TODO: Basic-Block Analyis, Dereferencing .class file shit - during or after BBA,