Am 29.01.2015 12:02, schrieb Daniel Latrémolière:
I just want to quickly summarize my
current findings here and gently ask for feedback in case you think
I've totally misunderstood something. Of course any comments and
additional information is highly welcome as well.
I don't know if that can be useful, but here is my point of view of
developer oriented towards the question: "What feature for solving my
problem?". This contains probably some or many errors, but it is another
point of view (only mine), if useful.
[...]
3) JVM can not move or clone objects (Project Panama off heap /
PackedObjects)
Constraint: developer need to manage externally the full lifecycle of
object and need to choose when creating or destroying it. Object is
off-heap and an handle is on-heap for managing off-heap part.
Constraint: potential fragmentation of free memory when frequently
creating and removing objects not having the same size (taking attention
to object size vs. page size is probably important).
Use-case "GC Latency": big data structure inducing GC latency when moved
if stored in heap
- All big chunks of data, like Big Data or textures in games, etc.
- Few number of objects for being manageable more explicitly by
developer (without too much work).
Use-case "Native": communicate with native library
- Modern version of JNI
From that view it makes me wonder if that is really in the scope of JEP
169.
bye Jochen
--
Jochen "blackdrag" Theodorou - Groovy Project Tech Lead
blog: http://blackdragsview.blogspot.com/
german groovy discussion newsgroup: de.comp.lang.misc
For Groovy programming sources visit http://groovy-lang.org
_______________________________________________
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
