8020860: cluster Hashtable/Vector field updates for better transactional memory behaviour

[Martin Buchholz]

I would prefer having separate changes that address different
concerns.  Here's a spec update that is not quite correct because the
ArrayStoreException depends on the runtime types (i.e. the Class
objects available at runtime), but these may be different from the
compile-time type parameters T and E.  The fact that arrays are
incorrectly covariant at compile time adds to the confusion.  There's
also a confusion between the type of a and the component type of a.
You could improve matters by introducing the word "component type" in
these sorts of specs.  I again think this kind of change should be
done across all the jdk classes.

http://docs.oracle.com/javase/specs/jls/se7/html/jls-10.html

All the components of an array have the same type, called
the*component type* of the array.

-     * @throws ArrayStoreException if the runtime type of a is not a supertype
-     * of the runtime type of every element in this Vector
+     * @throws ArrayStoreException if the runtime type of a, {@code
<T>}, is not
+     * a supertype of the runtime type, {@code <E>}, of every element in this
+     * Vector




On Fri, May 2, 2014 at 12:22 PM, Mike Duigou <mike.duigou at oracle.com> wrote:

> Thanks Martin and Martin;
>
> I have corrected this along with some additional documentation updates:
>
> http://cr.openjdk.java.net/~mduigou/JDK-8020860/3/webrev/
>
> Mike
>
>
> On Apr 16 2014, at 10:47 , Martin Buchholz <martinrb at google.com> wrote:
>
> Here you access elementCount outside the synchronized block, which is a data race
>
> +    public boolean addAll(int index, Collection<? extends E> c) {
>          if (index < 0 || index > elementCount)
>              throw new ArrayIndexOutOfBoundsException(index);
>
>
>
>
> On Wed, Apr 16, 2014 at 10:30 AM, Mike Duigou <mike.duigou at oracle.com>wrote:
>
>> Yes. This has been corrected.
>>
>> Mike
>>
>> On Apr 16 2014, at 08:19 , Martin Desruisseaux <
>> martin.desruisseaux at geomatys.fr> wrote:
>>
>> > Hello all
>> >
>> > Le 15/04/14 18:14, Mike Duigou a écrit :
>> >> I have updated the webrev with what I hope is the final form:
>> >>
>> >> http://cr.openjdk.java.net/~mduigou/JDK-8020860/1/webrev/
>> >
>> > The first changes in the javadoc contains "{@code #keys keys}" and
>> > "{@code #elements elements}". I presume that you mean {@link} instead of
>> > {@code}?
>> >
>> >    Martin
>> >
>>
>>
>
>