Hi Vladimir,
On 02.06.2014 19:38, Vladimir Ivanov wrote:
On 6/2/14 9:23 PM, Christian Thalinger wrote:
On Jun 2, 2014, at 6:29 AM, Vladimir Ivanov
wrote:
Tobias, I'll take care of it.
Are you also taking care of the backports?
Yes. I'll backport into 8u myself and for 7 I'll ask help fr
On 6/2/14 9:23 PM, Christian Thalinger wrote:
On Jun 2, 2014, at 6:29 AM, Vladimir Ivanov
wrote:
Tobias, I'll take care of it.
Are you also taking care of the backports?
Yes. I'll backport into 8u myself and for 7 I'll ask help from Sustaining.
Best regards,
Vladimir Ivanov
Best rega
On Jun 2, 2014, at 6:29 AM, Vladimir Ivanov
wrote:
> Tobias, I'll take care of it.
Are you also taking care of the backports?
>
> Best regards,
> Vladimir Ivanov
>
> On 6/2/14 10:04 AM, Tobias Hartmann wrote:
>>
>> On 28.05.2014 12:48, Vladimir Ivanov wrote:
>>> Looks good.
>>>
>>> It sho
Tobias, I'll take care of it.
Best regards,
Vladimir Ivanov
On 6/2/14 10:04 AM, Tobias Hartmann wrote:
On 28.05.2014 12:48, Vladimir Ivanov wrote:
Looks good.
It should be safe to sync on MTF instance since it's not accessible
outside (MTF and MT.form() are package-private).
Best regards,
V
On 28.05.2014 12:48, Vladimir Ivanov wrote:
Looks good.
It should be safe to sync on MTF instance since it's not accessible
outside (MTF and MT.form() are package-private).
Best regards,
Vladimir Ivanov
Thank you, Vladimir.
Could someone please push the patch?
Thanks,
Tobias
On 5/28/1
Looks good.
It should be safe to sync on MTF instance since it's not accessible
outside (MTF and MT.form() are package-private).
Best regards,
Vladimir Ivanov
On 5/28/14 1:49 PM, Tobias Hartmann wrote:
Hi,
thanks everyone for the feedback!
@Remi: I agree with Paul. This is not a problem be
Hi,
thanks everyone for the feedback!
@Remi: I agree with Paul. This is not a problem because if the normal
read sees an outdated null value, a new LambdaForm is created and
setCachedLambdaForm(...) is executed. This will guarantee that the
non-null value is seen and used. The unnecessary cre
On May 16, 2014, at 4:56 AM, Tobias Hartmann wrote:
> Is it sufficient then to use synchronized (lambdaForms) { ... } in
> setCachedLambdaForm(..) and a normal read in cachedLambdaForm(..)?
Yes, that is how I see it. The fast path is a racy non-volatile read of a
safely-published structure.
On 05/16/2014 05:22 PM, Paul Sandoz wrote:
On May 16, 2014, at 5:05 PM, Remi Forax wrote:
On 05/16/2014 01:56 PM, Tobias Hartmann wrote:
Hi,
thanks to everyone for the feedback.
Is it sufficient then to use synchronized (lambdaForms) { ... } in
setCachedLambdaForm(..) and a normal read in
On May 16, 2014, at 5:05 PM, Remi Forax wrote:
>
> On 05/16/2014 01:56 PM, Tobias Hartmann wrote:
>> Hi,
>>
>> thanks to everyone for the feedback.
>>
>> Is it sufficient then to use synchronized (lambdaForms) { ... } in
>> setCachedLambdaForm(..) and a normal read in cachedLambdaForm(..)?
>
On 05/16/2014 01:56 PM, Tobias Hartmann wrote:
Hi,
thanks to everyone for the feedback.
Is it sufficient then to use synchronized (lambdaForms) { ... } in
setCachedLambdaForm(..) and a normal read in cachedLambdaForm(..)?
Thanks,
Tobias
no, it's not,
The memory model doesn't guarantee tha
On May 14, 2014, at 3:47 AM, Vladimir Ivanov
wrote:
> Tobias, I agree with your evaluation.
>
> My only concern is that @Stable doesn't work for AtomicReferenceArray, so JIT
> doesn't see what is stored in the array.
Now that is really unfortunate.
> Maybe use a lock instead?
>
> Best rega
On 5/14/14 4:12 PM, Paul Sandoz wrote:
On May 14, 2014, at 12:47 PM, Vladimir Ivanov
wrote:
Tobias, I agree with your evaluation.
V. tricky one to track down!
From @Stable:
* It is (currently) undefined what happens if a field annotated as stable
* is given a third value. In prac
On May 14, 2014, at 12:47 PM, Vladimir Ivanov
wrote:
> Tobias, I agree with your evaluation.
>
V. tricky one to track down!
From @Stable:
* It is (currently) undefined what happens if a field annotated as stable
* is given a third value. In practice, if the JVM relies on this annotation
Tobias, I agree with your evaluation.
My only concern is that @Stable doesn't work for AtomicReferenceArray,
so JIT doesn't see what is stored in the array. Maybe use a lock instead?
Best regards,
Vladimir Ivanov
On 5/14/14 2:33 PM, Tobias Hartmann wrote:
Hi Remi,
sorry, I accidentally reve
your patch doesn't work !
the array is still allocated as an classical array in the constructor.
cheers,
Remi
Envoyé avec AquaMail pour Android
http://www.aqua-mail.com
Le 14 mai 2014 11:04:41 Tobias Hartmann a écrit :
Hi,
please review the following patch for bug 8005873.
*Problem*
Bug:
16 matches
Mail list logo