On Apr 7, 2014, at 7:23 PM, Mike Duigou 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 (which is a "typ
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 bec
On Apr 8, 2014, at 1:53 AM, Vladimir Ivanov
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 concrete BMH classes in
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 if
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.
http://cr.openjdk.j
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 qu
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 che
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 str
On Apr 8, 2014, at 1:03 AM, Paul Sandoz wrote:
>
> On Apr 7, 2014, at 7:23 PM, Mike Duigou 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 scope of Java 9.
>> Adding additio
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 wrote:
>
> On Apr 8, 2014, at 1:03 AM, Paul Sandoz 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 the SEGV (since we're in the sync block) but
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 the
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 block
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
particula
On 8 Apr 2014, at 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 th
On 4/8/14 11:33 AM, Chris Hegarty wrote:
On 8 Apr 2014, at 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 un
On 8 Apr 2014, at 19:41, Xueming Shen wrote:
> On 4/8/14 11:33 AM, Chris Hegarty wrote:
>> On 8 Apr 2014, at 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 synchroni
On 8 Apr 2014, at 18:57, Xueming Shen 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 bytes in zentr
On Apr 8 2014, at 01:03 , Paul Sandoz wrote:
>
> On Apr 7, 2014, at 7:23 PM, Mike Duigou 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 val
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
ext
Hi Martin,
As you might have seen in my later reply to Roger, there's still hope on
that front: setpgid() + wait(-pgid, ...) might be the answer. I'm
exploring in that direction. Shells are doing it, so why can't JDK?
It's a little trickier for Process API, since I imagine that shells form
a
21 matches
Mail list logo
