Point
, the VM would allocate storage for the x
and y
components in the hosting class, rather than a reference to a Point
box. (This can be viewed as object inlining or flattening.) Similarly, an array of Point
s would be laid out as a packed array of alternating x
and y
values, rather than a series of references.--
You received this message because you are subscribed to the Google Groups "mechanical-sympathy" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mechanical-symp...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
To unsubscribe from this group and stop receiving emails from it, send an email to mechanical-sympathy+unsub...@googlegroups.com.
To unsubscribe from this group and stop receiving emails from it, send an email to mechanical-sympathy+unsub...@googlegroups.com.
Containment
To unsubscribe from this group and stop receiving emails from it, send an email to mechanical-symp...@googlegroups.com.
I haven't finished reading the entire writeup (reached the byte code description section) but this very much sounds like value types in .net, which have been around for 10+ years now. That's fine - it's a good model for java.
Structs are mutable in .net, but this is a highly discouraged practice since it leads to lots of subtle bugs, precisely due to loss of identity and copy by value semantics. So even though mutability is allowed there, it's not that common in usage. If the JIT is good enough at scalarizing them, then this may not be a problem (e.g. an accumulator struct used on stack, think a convenience around building hashcodes or something).
Sent from my phone
To unsubscribe from this group and stop receiving emails from it, send an email to mechanical-symp...@googlegroups.com.
They can have references; what they can't have is fields of their own type. Can you elaborate on locality issue? From what I read this far they will definitely provide locality and that's one of the goals of the whole thing.
Sent from my phone
To unsubscribe from this group and stop receiving emails from it, send an email to mechanical-symp...@googlegroups.com.
Also a value does not have its own pointer, or a least such a pointer is a secret inside the VM’s implementation. Therefore there are certain additional operations that also either need to be disallowed or assigned a new meaning."
It looks as they can:Containment
- Can a value class contain a field of reference type? Yes. (Because a value codes like a class.)
On Fri, May 2, 2014 at 2:54 PM, Martin Thompson <mjp...@gmail.com> wrote:
This work is useful but does not address locality of reference in all the important dimensions. For example, the value types cannot contain references and thus restricts their use from building efficient B+ and B* trees.
While the immutable support is great for some classes of usage it severely restricts others in data structure design.
On Friday, 2 May 2014 13:12:39 UTC+1, Jimmy Jia wrote:
Eh? Isn'tIf another class declared a field of typePoint
, the VM would allocate storage for thex
andy
components in the hosting class, rather than a reference to aPoint
box. (This can be viewed as object inlining or flattening.) Similarly, an array ofPoint
s would be laid out as a packed array of alternatingx
andy
values, rather than a series of references.
All you need in terms of locality of reference?
On Fri, May 2, 2014 at 4:37 AM, Richard Warburton <richard....@gmail.com> wrote:
Hi,
I suspect some people have seen it already, but there's a value types proposal up at:
http://cr.openjdk.java.net/~jrose/values/values-0.html
Seems to have more detail than previous posts on the topic. The emphasis is still on immutability though, so it doesn't seem as useful for solving locality of reference problems as it might be.
--
You received this message because you are subscribed to the Google Groups "mechanical-sympathy" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mechanical-sympathy+unsubscribe...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "mechanical-sympathy" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mechanical-sympathy+unsub...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
Tomasz Kowalczewski
Value type interaction with generics will be an interesting bit; definitely don't want boxing in those cases. In .net (reified generics though, so it's easier to do I guess) generic methods taking a type parameter with a constraint will not cause boxing of a value type invocation (e.g. generic method takes a T that must implement an interface).
Sent from my phone
--
You received this message because you are subscribed to the Google Groups "mechanical-sympathy" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mechanical-symp...@googlegroups.com.
I guess you'd have to stick them into arrays and model the higher level abstraction around that.
Sent from my phone
To unsubscribe from this group and stop receiving emails from it, send an email to mechanical-symp...@googlegroups.com.
To unsubscribe from this group and stop receiving emails from it, send an email to mechanical-symp...@googlegroups.com.
--
You received this message because you are subscribed to the Google Groups "mechanical-sympathy" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mechanical-symp...@googlegroups.com.
To unsubscribe from this group and stop receiving emails from it, send an email to mechanical-sympathy+unsub...@googlegroups.com.
I tend to agree with this.
Escape analysis should work fantastically to reduce GC and Gil/Martin object layout would deal with the performance aspect.
Language would be unchanged - kept simple.
I would love to see this happening.
Is escape analysis impossible to implement with great benefits or just poorly implemented right now?
Cheers
Georges
To unsubscribe from this group and stop receiving emails from it, send an email to mechanical-symp...@googlegroups.com.
Hi,
On Wed, May 7, 2014 at 1:26 PM, Georges Gomes <george...@gmail.com> wrote:
Escape analysis should work fantastically to reduce GC and Gil/Martin object layout would deal with the performance aspect.
Language would be unchanged - kept simple.
I would love to see this happening.
Escape Analysis as currently implemented is apparently based on the flow-insensitive escape analysis algorithm, which means that it misses a lot of opportunities for optimization. Oracle published a paper for partial escape analysis that could be better and may be implemented in future versions. However, escape analysis will never be as good or as predictable or the same as using value types. This is because it requires runtime profiling and optimizing and the opportunity for that is not without bounds - the resources used by the runtime to optimize something means that those resources aren’t used for optimizing something else or for the application to make progress.