1 (l) proper java native interface (JNI)
2 -> atm just hackish solution.
3 -> also, arguments are passed in the wrong order
4 -> estimated effort: 3-4 days
7 -> for gnu classpath absolutely necessary
8 -> estimated effort: unknown
10 (l) replace signals with "nice traps"?
11 pro -> don't rely on operating system anymore
12 pro -> maybe better ghci behaviour?
13 cons -> at some point, signals are useful for debugging?
14 cons -> better "template" tricks are needed, as we cannot insert more
15 instructions or want to place nop's at production code path
17 (l) gnu classpath integration
19 -> depends on: exceptions, jni (?)
20 -> estimated effort: unknown
23 -> for "frontEnd analysis"
24 -> transition to MIR (Mate IR)?
26 (h) switch statement (basically lookupswitch insn)
28 (m) testing: hunit? quickcheck? other?
29 -> we have `make tests' now, but it should be only considered as
30 high-level test. we need something
31 -> estimated effort: for infrastructure, 2-3 days
33 (l) instanceof, checkcast
34 -> typechecking at runtime. with displays or something
35 -> depends on: exceptions (not absolutely necessary, but preferable)
36 -> estimated effort: 1 day
38 (h) bug (?): can there be a namespace clash with static and non-static methods?
39 -> the signature doesn't contain the static modifier
40 -> estimated effort: some hours (if a fix is needed)
43 -> it's an stupid and ugly hack. we don't want that.
44 -> estimated effort: unknown. research for a solution is needed
48 (h) so much cleanup...
49 -> define constant for native size stuff
52 (m) enable easy recompiliation of a method
53 -> we need a map where all callers are stored
54 in order to patch those to the new address
55 -> free old code region. maybe replace it with
56 some magic values, e.g. which produce a signal
57 in order to enable easier debugging
60 -> it's C. we don't want that.
61 -> at the moment System.Posix.Signal isn't powerful enough
62 -> wait for: http://hackage.haskell.org/trac/ghc/ticket/2451
64 (l) check different types (byte, long, ...)
66 (l) floating point support
68 (h) better code generation
69 -> at least peephole optimazation would be nice (e.g. kill `push eax; pop
71 -> but we want more!!11 ;-)
72 -> estimated effort: 2-3 weeks
74 (m) benchmark for presentation
76 (l) get rid of missingh
77 -> huge dependency and we just need one function of it
79 (l) get more details what takes time
80 -> use Data.Time.Clock
81 -> seperate analysis, jit, execution, ...
82 -> maybe use ghc profiling? (it doesn't measure native execution, but well)
86 (m) ... medium priority
90 what we won't do anytime soon:
91 ( ) garbage collection
98 Design Meeting - 21.March.2012
101 1) Compile on Basic Blocks on Demand or complete Methods (check how cacao, mono works)
102 2) Calling-Conventions - Standard wegen den Sprüngen (why does Cacao use strange CallingConventions)
103 3) Capture Meta-Information by Instruction and Basics-Block
104 4) Benchmark Suits - what features do we need?
105 5) Boehm GC? using Haskell GC? From Scratch GC? GC option
106 6) hs-java reinschauen - kann das schon BBA
109 TODO: Basic-Block Analyis, Dereferencing .class file shit - during or after BBA,