Thank you, Vladimir!
/Claes
On 2015-11-17 11:25, Vladimir Ivanov wrote:
Looks good!
Best regards,
Vladimir Ivanov
PS: I'm impressed by your courage and persistence, Claes :-) Untwining
bootstrapping knot is notoriously hard, especially when you are new to
the code.
On 11/16/15 7:17 PM, Cl
> On 17 Nov 2015, at 11:25, Vladimir Ivanov
> wrote:
>
> Looks good!
>
> Best regards,
> Vladimir Ivanov
>
> PS: I'm impressed by your courage and persistence, Claes :-) Untwining
> bootstrapping knot is notoriously hard, especially when you are new to the
> code.
>
+1 to that.
Paul.
Looks good!
Best regards,
Vladimir Ivanov
PS: I'm impressed by your courage and persistence, Claes :-) Untwining
bootstrapping knot is notoriously hard, especially when you are new to
the code.
On 11/16/15 7:17 PM, Claes Redestad wrote:
Thanks for the explanation, and patience, Vladimir!
R
Thanks for the explanation, and patience, Vladimir!
Reworked:
http://cr.openjdk.java.net/~redestad/8142334/webrev.09/
/Claes
On 2015-11-16 13:49, Vladimir Ivanov wrote:
The trick here is @Stable annotation.
If the @Stable field is written to non-default value in constructor,
it should be equ
On 11/16/2015 01:49 PM, Vladimir Ivanov wrote:
The trick here is @Stable annotation.
If the @Stable field is written to non-default value in constructor,
it should be equivalent to final field initialization.
That changes my view completely. Thanks for clarifying.
Regards, Peter
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 simplifi
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 res
The trick here is @Stable annotation.
If the @Stable field is written to non-default value in constructor, it
should be equivalent to final field initialization.
If the field is written to later, the initialization should be either
idempotent or properly synchronized. I'd like to note that th
Hi Vladimir,
On 11/14/2015 12:59 AM, 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
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
r
Hi,
On 2015-11-12 19:10, Paul Sandoz wrote:
Hi Peter,
This stuff always gives me a headache :-)
Yes. :-)
IIUC it’s all idempotent stuff, and the final field in NamedFunction should
take care of certain things.
That's been my understanding, as well.
Claes, was it intentional that you
On 11/12/2015 07:50 PM, Claes Redestad wrote:
Paul,
On 2015-11-12 19:34, Claes Redestad wrote:
Claes, was it intentional that you call function.resolve() after the
array store? You might need to reverse that and place a
Unsafe.storeFence between them if it is required that the published
a
Paul,
On 2015-11-12 19:34, Claes Redestad wrote:
Claes, was it intentional that you call function.resolve() after the
array store? You might need to reverse that and place a
Unsafe.storeFence between them if it is required that the published
and visible function be resolved.
This however w
Hi Peter,
This stuff always gives me a headache :-)
IIUC it’s all idempotent stuff, and the final field in NamedFunction should
take care of certain things.
Claes, was it intentional that you call function.resolve() after the array
store? You might need to reverse that and place a Unsafe.store
Hi Claes,
It might be ok as you say, but then I don't understand the need to
pre-resolve() NamedFunctions in original code. Do you?
Regards, Peter
On Nov 12, 2015 6:44 PM, "Claes Redestad" wrote:
> Hi,
>
> On 2015-11-12 17:26, Peter Levart wrote:
>
>> Hi Claes,
>>
>> I have one concern...
>>
>>
Hi,
On 2015-11-12 17:26, Peter Levart wrote:
Hi Claes,
I have one concern...
645 private static NamedFunction getConstantFunction(int idx) {
646 NamedFunction function = FUNCTIONS[idx];
647 if (function != null) {
648 return function;
649 }
650
Hi Claes,
I have one concern...
645 private static NamedFunction getConstantFunction(int idx) {
646 NamedFunction function = FUNCTIONS[idx];
647 if (function != null) {
648 return function;
649 }
650 return setCachedFunction(idx, makeConstant
On 2015-11-12 14:47, Paul Sandoz wrote:
On 11 Nov 2015, at 15:32, Claes Redestad wrote:
Paul,
On 2015-11-10 11:55, Paul Sandoz wrote:
DirectMethodHandle
—
682 private static @Stable NamedFunction[] FUNCTIONS = new
NamedFunction[NF_LIMIT];
Invokers
—
442 private static @Stable N
> On 11 Nov 2015, at 15:32, Claes Redestad wrote:
>
> Paul,
>
> On 2015-11-10 11:55, Paul Sandoz wrote:
>> DirectMethodHandle
>> —
>> 682 private static @Stable NamedFunction[] FUNCTIONS = new
>> NamedFunction[NF_LIMIT];
>>
>> Invokers
>> —
>> 442 private static @Stable NamedFunctio
Hi Peter,
On 2015-11-11 17:13, Peter Levart wrote:
Hi Claes,
Would constructing NamedFunction(s) using MemberName(s) directly,
bypassing reflection, make any sense (for example in DMH):
private static NamedFunction makeConstantFunction(int idx) {
try {
switch (idx) {
Hi Claes,
On 11/11/2015 03:32 PM, Claes Redestad wrote:
Paul,
On 2015-11-10 11:55, Paul Sandoz wrote:
DirectMethodHandle
—
682 private static @Stable NamedFunction[] FUNCTIONS = new
NamedFunction[NF_LIMIT];
Invokers
—
442 private static @Stable NamedFunction[] FUNCTIONS = new
N
Paul,
On 2015-11-10 11:55, Paul Sandoz wrote:
DirectMethodHandle
—
682 private static @Stable NamedFunction[] FUNCTIONS = new
NamedFunction[NF_LIMIT];
Invokers
—
442 private static @Stable NamedFunction[] FUNCTIONS = new
NamedFunction[NF_LIMIT];
MethodHandleImpl
—
1627 privat
> On 9 Nov 2015, at 20:48, Claes Redestad wrote:
>
> Hi Peter,
>
> nice catch:
>
> http://cr.openjdk.java.net/~redestad/8142334/webrev.02
>
DirectMethodHandle
—
682 private static @Stable NamedFunction[] FUNCTIONS = new
NamedFunction[NF_LIMIT];
Invokers
—
442 private static @Stab
Hi Peter,
nice catch:
http://cr.openjdk.java.net/~redestad/8142334/webrev.02
/Claes
On 2015-11-09 20:26, Peter Levart wrote:
Hi Claes,
I see you apply this pattern consistently:
private static NamedFunction getConstantFunction(int idx) {
NamedFunction function = FUNCTIONS[idx];
Hi Claes,
I see you apply this pattern consistently:
private static NamedFunction getConstantFunction(int idx) {
NamedFunction function = FUNCTIONS[idx];
if (function != null) {
return function;
}
return makeConstantFunction(idx);
}
priva
25 matches
Mail list logo
