Difference between revisions of "What the JVM needs"
From JVMLangSummit
Jump to navigationJump to searchLine 6: | Line 6: | ||
* typestate: now immutable - especially arrays (typically encapsulated in non-writing header, a la java.lang.String) | * 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 | * [[Why Tailcalls]]: as a guarantee, not just an optimization | ||
+ | * dynamic vs. inine | ||
+ | * safepoints | ||
=== numbers === | === numbers === |
Revision as of 11:53, 28 July 2010
Contents
Notes from Rich Hickey's workshop
user mode limitations
- please optimize this
- fences
- 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. inine
- safepoints
numbers
- fixnums
- 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?
storage management
- floating garbage foo(o, o=null); is tailcall a solution?
- concurrent collection of permgen
limits
- 31-bit arrays
- 16-bit instructions
- static data structures (array literals)
types
- structs (efficient pointerless element selection)
- value types (below)
value types
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