Reference SUB/SEP Value question

[David Chase]

On 2014-11-12, at 9:49 AM, Angela Lin <angela_lin at ca.ibm.com> wrote:

> Have I got this straight?
> 
> - ComplexGeneratedProxy is the runtime-generated thing that knows how to pull structured data out of some memory.
> - ComplexValue is the interface generated by the groveller. This is the type that the Java programmer can use directly?

I think the Groveler creates both ComplexValue and ComplexRef, plus a little language description of the layout.
Maybe that’s wrong — perhaps the little language should be encoded into static methods of the ComplexRef type.
(Another option, besides strings or data structures).

I’m not 100% sure of the need for ComplexValue.  I know we need ComplexRef and the generated proxy class.

> - Complex is the layout that is returned from the layout factory.  This is also generated at runtime?

I think that the layout factory returns a ComplexGeneratedProxy which is always a ComplexRef.

> - Ref supplies base behaviour for all layouts.

Yes — a lot of it common to the unsafe machinery at the bottom, like “address” and “size” and “align”.

> Why the need for ComplexRef and ComplexValue to be separate entities?  What are the methods of each?

ComplexRef has more methods, in particular it has setter methods and may have ref methods to its own fields.
ComplexValue only has getters.

We were discussing this last night, and I don’t feel certain of my opinions,
and that’s why I laid out both “SEP” and “SUB” hierarchies.

The problem I’m trying to sort out are the tradeoffs between too darn many entities,
versus what we know programmers will want to do with them,
versus the downward-aimed aliasing firearms that we hand out to programmers.
Making FooRef subtype FooValue guarantees value-aliasing problems; separating
them allows the implementation to create them in the obvious way when you ask
a FooRef for its FooValue, but does not require it.

It may be the case that we want to make a cleaner distinction between those things that
are “values” and those that are “references”, and not have anything be both.
So for example, maybe we regard Complex as a “value” in which case there is
no way to separately set the two fields within the layout — you can get them,
you can get the whole Complex as a “value”, but you cannot set them separately.

-> this implies a not quite the same ComplexGeneratedProxy, since it will have no setters.
-> and maybe we need a name for the “value” type that you get from dereferencing such
a thing.

But for (say) in IP header, you probably do want to monkey with some of the fields in place,
so it would be an IPHeaderRef (need to see the setter methods) and the IPHeaderGeneratedProxy
would also implement those.  Maybe don’t ever need to regard the IPHeaderRef as if it were
a “value”.

Have I stated my problem clearly enough?

David


> Thanks,
> Angela
> 
> David Chase <david.r.chase at oracle.com> wrote on 11/06/2014 04:58:45 PM:
> 
> > From: David Chase <david.r.chase at oracle.com>
> > To: Angela Lin/Ottawa/IBM at IBMCA
> > Cc: panama-spec-experts at openjdk.java.net
> > Date: 11/06/2014 04:58 PM
> > Subject: Reference SUB/SEP Value question
> > 
> > Here’s a first stab at clarifying the problem.
> > We might need to stab it some more before we are done.
> > 
> > >> 3) I spent some time experimenting with the relationship between a
> > >> so-called ?Ref? type and a so-called
> > >> ?Value? type, thought I had some answers, but after whacking on the
> > > 
> > > I don't quite understand 3).  Would it help to post some javadoc/test code
> > > snippets to illustrate?  If you haven't got this handy, we can scrounge
> > > something out of our prototypes.
> > 
> > I think there are two choices, refSUBvalue and refSEPvalue.
> > 
> > For SUB, you might have a hierarchy that looks like this:
> > 
> >   interface ComplexValue
> >      class Complex implements ComplexValue
> >   interface ComplexRef extends ComplexValue, Ref
> >      class ComplexGeneratedProxy implements ComplexRef
> > 
> > You can do this because a Reference can support all the
> > methods of Value by fetching the relevant fields etc, plus
> > it has some more methods for setting those fields.
> > 
> > For SEP, you might have a hierarchy that looks like this:
> > 
> >   interface ComplexValue
> >      class Complex implements ComplexValue
> > 
> >   interface ComplexRef extends Ref {
> >      ComplexValue get(); // canonical connection between Ref and Value
> >   }
> >      class ComplexGeneratedProxy implements ComplexRef
> > 
>