about JDK-8186628

[Peter]

Thanks for your explanation.

I worked on a lot of early java code circa Java 1.2 - 1.4, converting it 
to the post Java 5 memory model.   Latent race conditions caused 
hundreds of bugs, and problems would occur in other unrelated parts of 
the code, it was very brittle, any changes to code would result in 
inexplicable test failures elsewhere.  In the end I eliminated every 
race condition I found, harmless or otherwise, using both visual 
inspection and static analysis, the code lost it's brittle nature and 
became much easier to maintain since.

Regards,

Peter.


On 21/04/2018 7:51 PM, Peter Levart wrote:
> 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
>>
>