about JDK-8186628

[Peter Levart]

Hi Peter,

On 04/21/18 10:42, Peter wrote:
> I wrote caching software that decorated any Java collection with soft, 
> weak, timed or strong references, it utilised a background thread to 
> clean references from underlying collections.
>
> It was non blocking if the underlying collection was, although it 
> hasn't been updated to Java 8.
>
> Regarding patch comments, I don't mean to sound rude, but I don't 
> think there's such a thing as a harmless data race.
>
> Regards,
>
> Peter.

Perhaps harmless is not the right expression, but in this case, I think 
the data race(s) can do no "harm" to the correct / intended execution of 
program logic. That's my current belief, but you can prove me wrong if 
you want ;-) The data race is between CacheEntry.[getKey, getValue] and 
CacheIntry.invalidate that resets both key & value to null. When a 
CacheEntry is published, it is published without data race, with key & 
value being non-null. CacheEntry is private class, used only in 
MemoryCache, so it is never exposed to user code. User code only sees 
the result(s) of reading CacheEntry.[getKey, getValue] (returned from 
Cache.get(key) and from Cache.getCachedEntries()). The former allows 
null returns that logically mean an absence of value while the later 
constructs a map of live entries that are or were present in the cache 
at the time of invocation, filtering out null key(s)/value(s). The 
guarantees of those two methods are enough for correct functioning of 
user code (the SSL implementation), and this is what I called "harmless" 
data race because technically it is a data race.

Regards, Peter

>
> On 21/04/2018 3:45 AM, Ivan Gerasimov wrote:
>>
>> I'll go ahead with a review of the enhancement request JDK-8202086 
>> shortly on this list.
>>
>> And we'll still need to decide what has to be done in the earlier 
>> releases of JDK.
>>
>> With kind regards,
>>
>> Ivan
>>
>>
>> <https://bugs.openjdk.java.net/browse/JDK-8202086>
>>
>>
>> On 4/20/18 10:06 AM, nezih yigitbasi wrote:
>>> Ivan, thanks for the information. Any ideas about when one of these 
>>> solutions can be released?
>>>
>>> Nezih
>>>
>>> 2018-04-20 9:22 GMT-07:00 Ivan Gerasimov <ivan.gerasimov at oracle.com 
>>> <mailto:ivan.gerasimov at oracle.com>>:
>>>
>>>     Hello Nezih!
>>>
>>>     This issue is still being discussed off-list.
>>>     There have been two approaches proposed so far:  1) improve the
>>>     session cache and 2) provide an option to turn the cache off
>>>     completely.
>>>
>>>     The former one is good by itself, so I filed an enhancement
>>>     request [1] with a link to proposal made by Peter Levart [2].
>>>     However, as this is an enhancement, it seems unlikely it's going
>>>     to be backported to earlier releases of JDK.
>>>
>>>     With kind regards,
>>>     Ivan
>>>
>>>     [1] https://bugs.openjdk.java.net/browse/JDK-8202086
>>>     <https://bugs.openjdk.java.net/browse/JDK-8202086>
>>>     [2]
>>> http://mail.openjdk.java.net/pipermail/security-dev/2017-November/016512.html
>>> <http://mail.openjdk.java.net/pipermail/security-dev/2017-November/016512.html>
>>>
>>>
>>>     On 4/18/18 9:32 PM, nezih yigitbasi wrote:
>>>> Hi,
>>>>     We are hitting the scalability problem of the SSL session cache
>>>>     in production that JDK-8186628 is addressing.
>>>>     I see that JDK-8186628 has not been updated since Nov'17, so I
>>>>     just wanted to get information about what the current plans are
>>>>     regarding that issue.
>>>>
>>>>     Thanks,
>>>>     Nezih
>>>
>>>     --     With kind regards,
>>>     Ivan Gerasimov
>>>
>>>
>>
>> -- 
>> With kind regards,
>> Ivan Gerasimov
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20180421/b61a0c76/attachment.htm>