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.gerasi...@oracle.com <mailto:ivan.gerasi...@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



Reply via email to