On Apr 7, 2014, at 7:23 PM, Mike Duigou mike.dui...@oracle.com wrote:
The issue is that the comparison is done upon the signed most significant and
least significant long values.
At minimum UUIDs should be compared as if they were 128-bit unsigned values.
Thanks.
Beyond that, version
Chris, sorry for the late reply.
Here's a version with the new naming scheme:
http://cr.openjdk.java.net/~vlivanov/8037210/webrev.03.naming
I like existing naming scheme and OBJECT/VOID/LONG/etc names are quite popular(e.g.
Wrapper ASM (Opcodes) use them).
Of course they are popular
On Apr 8, 2014, at 1:53 AM, Vladimir Ivanov vladimir.x.iva...@oracle.com
wrote:
Thanks, Chris.
I have to do one more iteration:
http://cr.openjdk.java.net/~vlivanov/8037210/webrev.05/
I have to revert changes related to BMH::reinvokerTarget.
Removal of reinvokerTarget in generated
On 04/07/2014 07:00 PM, Xueming Shen wrote:
On 04/04/2014 10:08 AM, Xueming Shen wrote:
On 4/3/14 4:43 PM, Jeremy Manson wrote:
Good catch, thanks.
I think we should probably just go with the (equivalent to the)
StringBuffer variant. I'm pretty loathe to modify the StringBuilder
directly
Paul, thanks for the feedback!
See my answers inline.
Updated webrevs:
http://cr.openjdk.java.net/~vlivanov/8037209/webrev.03/
http://cr.openjdk.java.net/~vlivanov/8038261/webrev.02/
On 4/4/14 3:33 PM, Paul Sandoz wrote:
Hi,
Reviews of two patches in the queue.
Paul.
Regarding:
http://download.java.net/jdk9/changes/jdk9-b06.html?q=download/jdk9/changes/jdk9-b06.html
Currently the release notes have all the bug tickets pointing to
bugs.java.com. At least when I try, none of the tickets load; I think this
may have something to do with the move to JIRA. So, my
A recently reported bug shows a race condition is possible on the rem ==
0 check in ZipFile.read(byte b[], int off, int len). A bad check can
result in referencing a jzentry structure that might already be freed
and hence result in a SEGV. The fix is trivial and involves moving the
rem == 0
Hi Sean,
It might be more explicit to check if (zentry == 0) here?
-Sherman
On 4/8/14 8:21 AM, Seán Coffey wrote:
A recently reported bug shows a race condition is possible on the rem
== 0 check in ZipFile.read(byte b[], int off, int len). A bad check
can result in referencing a jzentry
On Apr 8, 2014, at 1:03 AM, Paul Sandoz paul.san...@oracle.com wrote:
On Apr 7, 2014, at 7:23 PM, Mike Duigou mike.dui...@oracle.com wrote:
I also note that UUID does not currently support version 5, SHA-1, which it
should.
I am hoping to do other performance work on UUID within the
I am targeting to have the performance improvements you contributed to UUID
into 8u40 (around the end of the year). I expect to contribute the work into
OpenJDK 9 in June-Julyish.
Mike
On Apr 8 2014, at 09:34 , Steven Schlansker stevenschlans...@gmail.com wrote:
On Apr 8, 2014, at 1:03 AM,
Sherman,
I see rem == 0 condition becoming true before the zentry variable is set
to 0 (in close()) - in a multi threaded scenario like this one, we could
have zero remaining bytes in zentry and yet have a zentry != 0 - your
suggestion would prevent the SEGV (since we're in the sync block)
On 4/8/14 10:29 AM, Seán Coffey wrote:
Sherman,
I see rem == 0 condition becoming true before the zentry variable is
set to 0 (in close()) - in a multi threaded scenario like this one, we
could have zero remaining bytes in zentry and yet have a zentry != 0 -
your suggestion would prevent
Hi Sean, Sherman
as far as the client is using ZipFileInputStream in a multithreaded fashion (de
facto), don't we have to rethink synchronization for the machinery of
ZipFileInputStream.read? As far as I understand it's not enough to put this
particular read of 'rem' into the synchronized
On 08/04/2014 19:12, Pavel Rappo wrote:
Hi Sean, Sherman
as far as the client is using ZipFileInputStream in a multithreaded fashion (de
facto), don't we have to rethink synchronization for the machinery of
ZipFileInputStream.read? As far as I understand it's not enough to put this
On 8 Apr 2014, at 19:12, Pavel Rappo pavel.ra...@oracle.com wrote:
Hi Sean, Sherman
as far as the client is using ZipFileInputStream in a multithreaded fashion
(de facto), don't we have to rethink synchronization for the machinery of
ZipFileInputStream.read? As far as I understand it's
On 4/8/14 11:33 AM, Chris Hegarty wrote:
On 8 Apr 2014, at 19:12, Pavel Rappo pavel.ra...@oracle.com wrote:
Hi Sean, Sherman
as far as the client is using ZipFileInputStream in a multithreaded fashion (de
facto), don't we have to rethink synchronization for the machinery of
On 8 Apr 2014, at 19:41, Xueming Shen xueming.s...@oracle.com wrote:
On 4/8/14 11:33 AM, Chris Hegarty wrote:
On 8 Apr 2014, at 19:12, Pavel Rappo pavel.ra...@oracle.com wrote:
Hi Sean, Sherman
as far as the client is using ZipFileInputStream in a multithreaded fashion
(de facto), don't
On 8 Apr 2014, at 18:57, Xueming Shen xueming.s...@oracle.com wrote:
On 4/8/14 10:29 AM, Seán Coffey wrote:
Sherman,
I see rem == 0 condition becoming true before the zentry variable is set to
0 (in close()) - in a multi threaded scenario like this one, we could have
zero remaining
On Apr 8 2014, at 01:03 , Paul Sandoz paul.san...@oracle.com wrote:
On Apr 7, 2014, at 7:23 PM, Mike Duigou mike.dui...@oracle.com wrote:
The issue is that the comparison is done upon the signed most significant
and least significant long values.
At minimum UUIDs should be compared as
Chris,
ZipFileInputStream.skip(..) can also close out the stream and free up
the underlying jzentry resources.
Per Sherman's suggestion I substituted rem for jzentry == 0 check but
ran into issues with other tests [1]
Another simple change (and to preserve old behaviour) might be just to
20 matches
Mail list logo
