> On 9 Jan 2018, at 15:11, Martin Buchholz <[email protected]> wrote: > > > > On Tue, Jan 9, 2018 at 2:42 PM, Paul Sandoz <[email protected] > <mailto:[email protected]>> wrote: > > > > On 9 Jan 2018, at 14:20, Martin Buchholz <[email protected] > > <mailto:[email protected]>> wrote: > > > > The memory model is already too hard to reason about, but here the VM can > > assume that the final fields will never be mutated - yet they are! > > Because of reflection and Field/AccessibleObject.setAccessible the VM is > conservative and does not in general assume final fields are really final. > Because of that we miss out on some juicy optimisations. We have made some > inroads into limiting the use of setAccessible. If we can deprecate and > remove it we can make progress on generally applying "final means final” to > all Java code (which also means tackling the case of deserialisation). > > > Will there be a principled way to handle "final means final" for > MethodHandle.form? Maybe a new annotation that means "mutable BUT compile as > if final" ? >
Yes, i could imagine in the future removing the final modifier and adding the @Stable annotation or some variant of for the more “relaxed" form of finality that is currently supported. In fact it might be clearer if we do that now (make non-final and add @Stable). > > > With the special j.l.invoke guarantees, there should be no need for final > > fields to additionally have @Stable annotations, yet many do! > > In j.l.invoke I only found one redundant @Stable annotated field on > MethodType: > > private final @Stable Class<?> rtype; > > All the others are on non-final fields or array fields where the stable > semantics are propagated to array elements. > > Yes, I had forgotten that subtlety with @Stable. > > > > LambdaForm is a mutable class, so publishing it via a plain Unsafe write is > > a (tiny, hard to detect) data race. I would feel much more comfortable > > replacing the Unsafe put with a putVolatile and dropping the fence. > > Whenever the form field is read, perhaps it should be explicitly read via a > > volatile or acquire read for safety. > > That would incur a cost. j.l.invoke contains code that has carefully arranged > interactions with the runtime compilers, this is one of those cases. > > (we already have a full fence on writes!) > True, but the writes should be rare compared to the reads and as Vladimir points out the customisation should not change the functionality. Paul. > As it stands, MethodHandle.form is published via a data race which seems > dangerous to me, but may be safe in practice because no one is running Java > on an early Alpha machine.
