What the JVM needs
Revision as of 22:47, 28 July 2010 by Kreide
Notes from Rich Hickey's workshop
user mode limitations
- please optimize this
- typestate: now immutable - especially arrays (typically encapsulated in non-writing header, a la java.lang.String)
- Why Tailcalls: as a guarantee, not just an optimization
- dynamic vs. inline
- fixnums (say, 28-bit small ints encoded as (x >> 28) == -1) http://blogs.sun.com/jrose/entry/fixnums_in_the_vm
- need a uniform entry/exit types (Object => boxing)
- Hacker's delight overflow detection is OK (only for add/sub); need a static method that throws overflow-exception?
- Unsigned <
- floating garbage foo(o, o=null); is tailcall a solution?
- concurrent collection of PermGen (only in HotSpot). This is especially important for big server applications (large heap) which uses concurrent GC to avoid long GC pauses; when PermGen fills up a Full GC has to occur which can pause the VM for 10-30 seconds or more which can be unacceptably long for interactive requests.
- 31-bit arrays
- 16-bit instructions
- static data structures (array literals)
- structs (efficient pointerless element selection)
- value types (below)
The C#'s struct might be a source of ideas (though that's not necessarily how we want it)
no mutability, acmp-identity, id-hashcode, monitorenter
- immutable arrays == array-like value types
- issue: intermediate early array construction states interact with memory model
- perhaps need a typestate distinction: under construction vs. immutable