approach.
>> ObjectLayout is a little special here, because it can run with any
>> Java VM in which case it will still use the default reference model.
>> But it can potentially be optimized by some VM's to provide the flat
>> object layout. I expect these optimizations to be
classes and/or fields which you want to allocate "inline". Once you've
>> done that you have no choice with the PackedObjects approach.
>> ObjectLayout is a little special here, because it can run with any
>> Java VM in which case it will still use the defau
e annotation.
>> > This would be controlled via a cmdline flag, as you say, similar to perhaps
>> > how compressed oops are enabled (or not). Note that I'm talking about
>> > purely layout of reference types, not value types.
>> >
>> > The "concern&q
hat you annotate the fields that you'd like inlined and
> then also
> >> > use special API to construct those objects. I'm wondering whether,
> >> > instead, all private final fields are automatically inlined, and only
> cases
> >> > where you'd l
>> with various degrees of freedom to optionally choose value semantics.
>> >>
>> >> Regards,
>> >> Volker
>> >>
>> >> [1] http://cr.openjdk.java.net/~jrose/values/values-0.html
>> >>
>> >> On
t;
> > wrote:
> >
> >> Hi Vitaly,
> >>
> >> for PackedObjects/ObjectLayout you need to specially annotate the
> >> classes and/or fields which you want to allocate "inline". Once you've
> >> done that you have no choice with the
ses and/or fields which you want to allocate "inline". Once you've
> >> done that you have no choice with the PackedObjects approach.
> >> ObjectLayout is a little special here, because it can run with any
> >> Java VM in which case it will still use
t;inline". Once you've
>> done that you have no choice with the PackedObjects approach.
>> ObjectLayout is a little special here, because it can run with any
>> Java VM in which case it will still use the default reference model.
>> But it can potentially be optimiz
ava VM in which case it will still use the default reference model.
> But it can potentially be optimized by some VM's to provide the flat
> object layout. I expect these optimizations to be controllable by a
> command line option.
>
> With the "Value Types for Java&qu
ava VM in which case it will still use the default reference model.
But it can potentially be optimized by some VM's to provide the flat
object layout. I expect these optimizations to be controllable by a
command line option.
With the "Value Types for Java" [1] approach you'll
All your comments have been clear and reasonable and are much
> appreciated. Please find my additional answers inline:
>
> On Thu, Jan 29, 2015 at 6:05 PM, Brian Goetz
> wrote:
> >> Question: is JEP 169 still under active development or has it been
> >> merged into the more ge
:
>> Question: is JEP 169 still under active development or has it been
>> merged into the more general "Value types for Java" proposal below?
>
>
> It has been merged into the more general Value Types for Java proposal.
>
Then maybe this JEP should be closed to avoid
Hi Daniel,
thanks a lot for sharing your point of view.
I haven't been aware of the fact that Project Panama is also working
on similar topics (I always thought it is only about the Foreign
Function Interface and the next generation JNI). In [1,2] John Rose
nicely explains that new data layouts i
Question: is JEP 169 still under active development or has it been
merged into the more general "Value types for Java" proposal below?
It has been merged into the more general Value Types for Java proposal.
The "Value types for Java" approach clearly seems to be the most
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
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
develope
n: is JEP 169 still under active development or has it been
merged into the more general "Value types for Java" proposal below?
2. "Value types for Java" / "State of the Values" [2]
- By J. Rose, B. Goetz and Guy Stele
- Based on earlier ideas from "Value T
Kenneth Russell wrote:
> I would be concerned about the semantic change of
> pass-by-value and what that would mean for the easy readability and
> understanding of Java source code
I would point to the CLR as a successful example here. Value types and
references types mingle fairly painlessly i
Miles Sabin wrote:
> On Wed, Jun 18, 2008 at 9:28 AM, Ben Hutchison <[EMAIL PROTECTED]> wrote:
>
>> The example case I have in mind is an interaction between a Java
>> process and a 3D graphics driver. Eg a Java process would be
>> writing/updating triangle data in the buffer, and the graphics d
On Wed, Jun 18, 2008 at 9:28 AM, Ben Hutchison <[EMAIL PROTECTED]> wrote:
> The example case I have in mind is an interaction between a Java
> process and a 3D graphics driver. Eg a Java process would be
> writing/updating triangle data in the buffer, and the graphics driver
> rendering it. (I admi
It's possible to do what you want with the existing NIO Buffer classes
and a helper tool. GlueGen (http://gluegen.dev.java.net/) generates Java
classes to access C data structures. These accessor classes wrap
ByteBuffers and provide setter / getter methods for accessing the fields
of the struct
Miles Sabin wrote:
> On Wed, Jun 18, 2008 at 6:15 AM, Ben Hutchison <[EMAIL PROTECTED]> wrote:
>
>> Also, in terms of what it doesn't do:
>>
>> 1. Hard to see any way to extend to interpret a ByteBuffer region as an
>> array of some value type, a feature ultimately needed for bulk interop
>> wit
On Wed, Jun 18, 2008 at 6:15 AM, Ben Hutchison <[EMAIL PROTECTED]> wrote:
> Also, in terms of what it doesn't do:
>
> 1. Hard to see any way to extend to interpret a ByteBuffer region as an
> array of some value type, a feature ultimately needed for bulk interop
> with external IO/processes, I feel
Miles Sabin wrote:
> On Tue, Jun 17, 2008 at 5:42 AM, Ben Hutchison <[EMAIL PROTECTED]> wrote:
>
>> Ive written up a post outlining my case for value type support:
>> http://benhutchison.wordpress.com/2008/06/15/the-jvm-needs-value-types/
>>
>
> Surely, in that very article you describe the
On Tue, Jun 17, 2008 at 5:42 AM, Ben Hutchison <[EMAIL PROTECTED]> wrote:
> Ive written up a post outlining my case for value type support:
> http://benhutchison.wordpress.com/2008/06/15/the-jvm-needs-value-types/
Surely, in that very article you describe the exact encoding that's
needed to get al
I would really like to see support for value types (aka "structs") added
to a JVM. My desire is for a more efficient way to store and process
bulk quantities of small, simple objects.
Its an issue with a very low profile in the Java community, it seems.
I'd be interested in hearing from others
I have just discovered John Rose's "Tuples in the VM" proposal. I have
wanted value types in Java for a long time, so this is of interest to
me. I am involved in two fields of software development, each with
differing motivations for value types.
I develop financial software that involves lots
27 matches
Mail list logo
