Thanks Vladimir,
so something like this, then:
http://cr.openjdk.java.net/~redestad/8142334/webrev.06
I tried a similar approach after Peter's suggestions earlier, but got
into bootstrapping issues which I failed to resolve at the time. Not
having the DMH functions along for the ride simplifies greatly, so this
approach now seems to work and passes various jtreg tests. There might
even be a small initialization overhead improvement by not going via
reflection.
/Claes
On 2015-11-14 00:59, Vladimir Ivanov wrote:
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
