On 03/06/2014 04:12 PM, Valerie (Yu-Ching) Peng wrote:
Last time when I was debugging/observing the session pools, it's not
just one or two sessions in the queue. It's at least hundreds possibly
thousands when I ran one of the SSL stress tests.
1) line 273, do you really mean to return when the
Last time when I was debugging/observing the session pools, it's not
just one or two sessions in the queue. It's at least hundreds possibly
thousands when I ran one of the SSL stress tests.
1) line 273, do you really mean to return when the
oldestSession.isLive() returns false??
2) line 275
On 03/06/2014 11:24 AM, Valerie (Yu-Ching) Peng wrote:
Tony,
I like this version better - a local "instance" session pool for
P11Cipher is a bit excessive I think.
One thing that I noticed with this change is that by switching to the
ConcurrentLinkedQueue, you are retrieving sessions from the h
Tony,
I like this version better - a local "instance" session pool for
P11Cipher is a bit excessive I think.
One thing that I noticed with this change is that by switching to the
ConcurrentLinkedQueue, you are retrieving sessions from the head and put
them back at the end. This is different
So I ran a stress test creating a number of keys and did not see much
different memory wise. But what I did notice that the performance was
dependent on the number Cipher.init() calls. If each thread only has
one Cipher.init() call, it performed 5x better (170k vs 844k ops/m), but
as soon as
On 02/21/2014 02:38 PM, Valerie (Yu-Ching) Peng wrote:
Where can I find the updated webrev?
Oops.. thought I included it:
http://cr.openjdk.java.net/~ascarpino/7107611/webrev.01/
As for the performance test, I think we can probably try a "worse-case"
(say 5000 Cipher objects which we don't
Where can I find the updated webrev?
As for the performance test, I think we can probably try a "worse-case"
(say 5000 Cipher objects which we don't re-use, just create, do
operation, and then discard) and "best-case" (same # of objects, but
re-use) against both impls and see how much a diffe
I've updated the webrev, removing the unneeded methods, and also adding
back some rather important pool cleanup code I hadn't noticed the patch
removed.
http://cr.openjdk.java.net/~ascarpino/7107611/webrev.01/
Tony
On 02/13/2014 11:16 AM, Anthony Scarpino wrote:
On 02/11/2014 02:18 PM, Vale
On 02/11/2014 02:18 PM, Valerie (Yu-Ching) Peng wrote:
Please see comments inline.
On 02/10/14 16:30, Anthony Scarpino wrote:
On 02/10/2014 03:04 PM, Valerie (Yu-Ching) Peng wrote:
Well, there are some changes that look strange which I need more time to
figure out.
For example, the purpose f
Please see comments inline.
On 02/10/14 16:30, Anthony Scarpino wrote:
On 02/10/2014 03:04 PM, Valerie (Yu-Ching) Peng wrote:
Well, there are some changes that look strange which I need more time to
figure out.
For example, the purpose for the 2 new pkg private methods of poll(Pool)
and relea
On 02/10/2014 03:04 PM, Valerie (Yu-Ching) Peng wrote:
Well, there are some changes that look strange which I need more time to
figure out.
For example, the purpose for the 2 new pkg private methods of poll(Pool)
and release(Pool, Session) of the static class Pool.
New methods are for supporti
Well, there are some changes that look strange which I need more time to
figure out.
For example, the purpose for the 2 new pkg private methods of poll(Pool)
and release(Pool, Session) of the static class Pool.
Also, now that every P11Cipher "object" has its own session pool, will
this have
Hi,
I'm requesting a review of these changes. It is mostly from the patch
that Intel provided, but I have made some cosmetic changes. The changes
significantly improve performance in multithreaded application using pkcs11.
http://cr.openjdk.java.net/~ascarpino/7107611/webrev.00/
thanks
To
13 matches
Mail list logo
