NamedFunction.resolvedHandle should be usually pre-resolved, but for
bootstrapping purposes it is done lazily in some cases. I don't see any
reason why NamedFunction.resolve() should be called on a freshly created
instance. Use proper constructor instead.
NamedFunction(MethodHandle resolvedHandle)
NamedFunction(MemberName member, MethodHandle resolvedHandle)
NamedFunction(MethodType basicInvokerType)
// The next 3 constructors are used to break circular
dependencies on MH.invokeStatic, etc.
// Any LambdaForm containing such a member is not interpretable.
// This is OK, since all such LFs are prepared with special
primitive vmentry points.
// And even without the resolvedHandle, the name can still be
compiled and optimized.
NamedFunction(Method method) {
this(new MemberName(method));
}
NamedFunction(Field field) {
this(new MemberName(field));
}
NamedFunction(MemberName member) {
this.member = member;
this.resolvedHandle = null;
}
There are 2 non-final fields in NamedFunction:
static class NamedFunction {
final MemberName member;
@Stable MethodHandle resolvedHandle;
@Stable MethodHandle invoker;
Repeated initialization of NamedFunction.invoker is benign since
NamedFunction.computeInvoker uses synchronized
MethodTypeForm.setCachedMethodHandle to populate the cache.
Regarding resolvedHandle, NamedFunction are usually constructed
pre-resolved, but for the limited number of lazily initialized
instances, I think we should force resolution right after bootstrapping
is over.
Or, if you want to save on resolvedHandle resolution, replace all direct
field accesses with accessor calls and synchronize when setting the
value.
Best regards,
Vladimir Ivanov
On 11/12/15 10:11 PM, Claes Redestad wrote:
On 2015-11-12 19:53, Peter Levart wrote:
Do you think this would work correctly w.r.t visibility:
FUNCTIONS[idx] = function;
function.resolve();
UNSAFE.storeFence();
This does not do anything useful.
What happens if you simply omit function.resolve() call. If lazy
resolving works and tests pass, then perhaps it's all ok.
Peter
Actually, I simply tried backing out the DirectMethodHandle changes
entirely, and measured how much we'd lose by leaving that particular
case alone: almost nothing, as it turns out (same number of LFs are
generated etc). I think the safest option is to leave DirectMethodHandle
alone:
http://cr.openjdk.java.net/~redestad/8142334/webrev.05/
/Claes
