[Dennis - hope you don't mind me quoting you back to the list. It is
a reasonable question that would be of interest to others]
At 9:53 AM -0700 6/24/99, Dennis Sosnoski wrote:
>Bill Pugh wrote:
> >
> > - Provide a new safety guarantee of initialization safety:
>Assuming you don't
> > shoot yourself in the foot, no code outside the construction
>of object X
> > should be able to see an incompletely constructed version of
>X. Shooting
> > yourself in the foot would involve storing a reference to X during the
> > construction of X, or passing a reference to X to a function during the
> > construction of X.
> >
> > Note here that any constructors you chain to (via super() or
>this() calls)
> > are considered part of construction. If your super() shoots
>you in the foot,
> > you are shot.
> >
>
>I've got a couple of concerns on this. First is that it probably will require
>some sort of flush to memory after every level of chained
>constructor, adding to
>the construction overhead. Second is that in a very large number of
>cases it's
>unnecessary, since the object will only be used by the thread that constructed
>it.
A naive implementation of this requirement would be to place a memory
barrier at the end of each constructor, which might be expensive.
But we can be smarter. Put the burden on the person invoking the
constructor to place the barrier. Thus, in a constructor for class
Foo, you don't need to place a barrier after your call to super(...)
if you are safe (you don't pass the reference to a function or store
the reference). Thus, for well written code, very little analysis
will result in only having a barrier after the outermost constructor.
You can be even smarter. If you see than an object is constructed,
but can guarantee that the object is never made visible to another
thread, you can omit the barrier altogether. If you see that a bunch
of objects are constructed, and then after they are all constructed
they are made visible, you can get away with just one barrier.
>
>Have you considered alternatives to this approach? One that comes to mind is
>some way of telling the JVM that you want all updates to the variables in an
>object to immediately be written to memory, say "flush(object)".
>This could be
>used after a constructor call for a shared object, and could also be used for
>such things as making sure that an atomic change to an object's state has been
>written to memory before continuing on in code. Allowing any
>variable to be the
>target (rather than just an object reference) would be even more useful.
The initialization safety guarantee is intended as a safety property.
It is difficult to write secure code, not open to attack, unless you
have initialization safety. Thus, we shouldn't require any particular
code style to guarantee initialization safety (although we can't
protect you from shooting your self in the foot).
Also, another requirement for a new memory model is that it should
roughly match the current programming styles, and make most existing
programs initialization safe. Adding a flush(object) method wouldn't
be acceptable.
Bill
-------------------------------
This is the JavaMemoryModel mailing list, managed by Majordomo 1.94.4.
To send a message to the list, email JavaMemoryModel@cs.umd.edu
To send a request to the list, email majordomo@cs.umd.edu and put
your request in the body of the message (use the request "help" for help).
For more information, visit http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:12 EDT