At 11:42 AM 08/03/2001, Bill Pugh wrote:
>Sorry for the delay in leading this discussion along; I had a couple of
>other things on the stove.
>
>OK, first, an axiom about Java security
>
> Strings must be absolutely immutable
>
>Any code that can cause a String to mutate can essentially bootstrap its
>way to complete bypassing of the security manager. Therefore, we take it
>as an axiom that in the presence of untrusted code with a data race, we
>must preserve the immutability of Java Strings.
>
>Why do data races allow Strings to mutate?
>
>Consider the following code:
>
>Thread 1:
>StringBuffer b = ...;
>Foo.global = new String(b);
>
>
>Thread 2:
>String s = Foo.global;
>use s
>
>Now, this code has a data race. The effect of the data race is that Thread
>2 might see the new value for Foo.global, but not see some of the writes
>that initialized the String object. Later, thread 2 might see the rest of
>the writes, so it sees the String object change. I'm not going to go into
>how this can happen at length because it has been covered a number of
>times before. Check my 2001 JavaGrande paper for more details.
>
>OK, it would be possible to fix this by making all of the methods of the
>String synchronized. But that would impose unacceptable performance
>penalties, and is only needed when a user of the String class introduces
>their own data race, outside of the String class.
>
>So what we need is a way to allow immutable objects to be truly immutable,
>even in the presence of external data races. While the most obvious need
>for this is for the String class, there are likely a number of other
>immutable classes that need this guarantee. So we don't want to do
>something specific to the String class.
>
>We also want something that might require memory barriers at object
>construction time, but would not require memory barriers when accessing
>immutable objects, unless you are on platform with a very weak memory
>model (e.g., an Alpha SMP).
>
>The general informal consensus that has been reached includes the following:
>
>* If you have a class that is immutable, and all instance fields of that
>class are final, then you get special race-proof immutable semantics: Any
>thread that obtains, in any way, a reference to an instance of that class
>sees the initialization done by the constructor for that instance.
It had been my understanding of the previous material by Bill that the rule
was intended to be that if any field was final then you would get the
race-proof immutable semantics. Did I misunderstand or has there been a
change?
I think the "any" rule is better than the "all" rule because it is less
fragile for maintenance . That is, Java programmers will think they can add
a private non-final field to a class as long as they ensure all uses are
properly synchronized. This is the case under the "any" rule, but not
under the "all" rule.
>OK, now that is very informal, and not exactly correct.
>
>A little more detailed, this time with regards to a particular final field f
>of class A:
>
>* All writes visible to a thread when exiting the A constructor for an
>object x
>
>* Are visible to when any other thread reads x.f, or any variable derived
>from the value read from x.f.
>
>* A variable reference v is derived from a local l when
> v is referenced as a field or element of the object referenced by
> a local l' loaded from a variable derived from l
>
> For example, if p.a is an a reference to an array of arrays, then
> p.a[0][0] is derived from p.a.
>
>This writeup isn't very good, part of the reason I've been delaying
>sending it out. It is much easier to do informally in pictures. See slides
>27-38 of
>
> http://www.cs.umd.edu/~pugh/java/memoryModel/JavaOneBOF/BOF.pdf
>
>Does anyone want to raise issues, questions or objections to this approach
>for handling immutable objects?
>
> Bill
>-------------------------------
>JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:34 EDT