Given some recent changes to the class involved in this patch, in the
jdk repo (http://hg.openjdk.java.net/jdk/jdk), I noticed some merge
conflicts to this patch today. So I've now attached an updated patch
which resolves those merge issues. This has been tested with latest
jtreg (tip).
-Jaik
On 22 February 2018 at 14:38, Seán Coffey wrote:
> Thanks for looking at this one Andrew. I've had it on my to-do list.
>
> The patch looks fine.
>
> Regards,
> Sean.
>
Thanks. I had the patch around from fixing it in OpenJDK 7 so thought I may
as well post it.
Pushed: http://hg.openjdk.java.net
Hi Weijun,
I thought more about the performance impact. The impact may mainly come
from the big size of the cached entries.
The current implementation needs to go over the full list: find the 1st
expired item and then remove the rest. The previous one have an
additional round with entries.
Updated webrev at http://cr.openjdk.java.net/~weijun/8197518/webrev.01/.
> On Feb 23, 2018, at 9:02 AM, Weijun Wang wrote:
>
> You mean I can save it somewhere and only update it when a cleanup is
> performed?
>
> This should be better. Now there will be only isEmpty(), getFirst() and
> addFi
You mean I can save it somewhere and only update it when a cleanup is performed?
This should be better. Now there will be only isEmpty(), getFirst() and
addFirst(), and one less getLast().
Thanks
Max
> On Feb 23, 2018, at 1:45 AM, Xuelei Fan wrote:
>
> Looks like list synchronization is a fac
Updated to use package private HKDF implementation.
webrev (based on JDK-8185576):
http://cr.openjdk.java.net/~xuelei/8196584/webrev-step.01
webrev (including JDK-8185576):
http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.01
Thanks,
Xuelei
On 2/20/2018 11:57 AM, Xuelei Fan wr
Looks like list synchronization is a factor of the performance impact.
Maybe, you can have a private time for the oldest entry so don't
access/iterate/cleanup entries list until necessary. The "at most every
minute" may be not a good strategy in some situations.
Xuelei
On 2/22/2018 12:36 AM,
Thanks for looking at this one Andrew. I've had it on my to-do list.
The patch looks fine.
Regards,
Sean.
On 22/02/18 04:09, Andrew Hughes wrote:
Bug: https://bugs.openjdk.java.net/browse/JDK-8196952
Webrev: http://cr.openjdk.java.net/~andrew/openjdk8/8196952/webrev.01/
Review thread: N/A
Whe
> On Feb 22, 2018, at 8:14 PM, Seán Coffey wrote:
>
> This looks good to me Max. I think it'll solve the issue reported.
>
> line 109 : I guess this could turn negative if timeLimit was value < 60. I
> don't think that's possible unless we're dealing with a strange config!
Negative time migh
I have an update. :)
I've spoken with everyone I could find who deals with user
configurations which may include these cipher suites, and they all
agree that users are no longer using TLS KRB5 and that it is no longer
recommended either. So, from our perspective, it would be OK to drop
these afte
This looks good to me Max. I think it'll solve the issue reported.
line 109 : I guess this could turn negative if timeLimit was value < 60.
I don't think that's possible unless we're dealing with a strange config!
For the code comment, may a minor edit :
111 // Only trigger a cleanup
Ok, thanks Valerie!
Sorry for spam, I has supposed my previous email was not considered to be
patch.
Martin:
As this is way how it is initialized in other places, I has not considered
it.
http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/59e88d3b9b17/src/share/native/sun/security/jgss/wrapper/GSSLibSt
Please take a review at
http://cr.openjdk.java.net/~weijun/8197518/webrev.00/
Two notes:
1. I tried list.subList(here, end).clear() but it's not faster.
2. I have looked at ConcurrentHashMap + ConcurrentSkipListMap but will need
more time to verify its correctness and measure the performanc
13 matches
Mail list logo
