Hi Dave,
> I'm sorry to say that I've been tied up with other pressing issues. I will
> have some feedback more worthwhile than this by Fri/15.
I don't have any stress with this.
No need to hurry, if theres no time left ... theres no time left ;)
Thanks, lg Clemens
Hi Clemens,
I'm sorry to say that I've been tied up with other pressing issues. I will
have some feedback more worthwhile than this by Fri/15.
Sorry for the delay,
Dave
Clemens Eisserer wrote:
Hi again,
Did anybody have some time to look at my patches?
I also thought about implement
Hi again,
Did anybody have some time to look at my patches?
I also thought about implementing striding in the CRC32/Adler32
classes which basically suffer from the same block-the-gc behaviour as
Inflater/Deflater did before they were "fixed" ;)
Furthermore do you have good ideas for regression te
Sorry, sent the wrong files and found some bugs. Will re-send the
updated files soon -sorry for the traffic.
lg Clemens
2008/1/9, Clemens Eisserer <[EMAIL PROTECTED]>:
> Hi again,
>
> I've finished a very early draft of the native stride+copy
> implementation of Deflater.
> Its still very early a
Hi again,
I've finished a very early draft of the native stride+copy
implementation of Deflater.
Its still very early and is not tested a lot (so don't wory about I
would think this should go in as is ;) ), but seems to perform quite
well.
I just post it ... well ... to get some critics and advise
Clemens Eisserer wrote:
:
PS: The striding+GetPrimitive... is even used by NIO for copying
java-arrays into direct-ByteBuffers:
while (length > 0) {
size = (length > MBYTE ? MBYTE : length);
GETCRITICAL(bytes, env, dst);
memcpy(bytes + dstPos, (void *)srcAddr, size);
Hello again,
I implemented two prototypes of the striding to see how they perform
and how complex the code would be. Both prototypes implement the
striding on the java-side (call JNI method for each stride) which I
plan to change to minimize overhead and hide the striding (except Sun
would like to
Clemens Eisserer wrote:
Hello again,
jdk/test/java/util/zip/FlaterTest.java can be used to compare different JVMs;
I'm sorry but I don't think we have a better test. See also the code in
6364346 and/or 6507183.
Sorry if that sounds a bit dumb, how can I access
jdk/test/java/util/zip/FlaterTes
Hello again,
> jdk/test/java/util/zip/FlaterTest.java can be used to compare different JVMs;
> I'm sorry but I don't think we have a better test. See also the code in
> 6364346 and/or 6507183.
Sorry if that sounds a bit dumb, how can I access
jdk/test/java/util/zip/FlaterTest.java?
I rewrote the
Clemens Eisserer wrote:
Hi Dave,
Prior to 1.5.0_u7 the *Critical* function were used, but for the sake of
6206933, their use was replaced with data copying.
Thanks a lot for all the feedback, it really helps to understand the
reasons why the code is as it is. I also thought about the
DirectBy
Hi Dave,
> Prior to 1.5.0_u7 the *Critical* function were used, but for the sake of
> 6206933, their use was replaced with data copying.
Thanks a lot for all the feedback, it really helps to understand the
reasons why the code is as it is. I also thought about the
DirectByteBuffers and I also did
Hi Ig,
Thanks for the suggestions. Here's some more history.
Clemens Eisserer wrote:
Hi again,
Sun engineers have tried to get reasonable performance
without using JNI_Get*Critical, since that introduces other
serious performance problems. It was my belief that any
pathological n^2 performa
Hi Clemens,
(Thank you very much for working on this problem)
Clemens Eisserer wrote:
> Hi again,
>
>>Sun engineers have tried to get reasonable performance
>>without using JNI_Get*Critical, since that introduces other
>>serious performance problems. It was my belief that any
>>pathological n^2
Hi again,
> Sun engineers have tried to get reasonable performance
> without using JNI_Get*Critical, since that introduces other
> serious performance problems. It was my belief that any
> pathological n^2 performance problems had been truly fixed.
At least the code in JDK7u23 looks like (n^2)/2
A thorny problem.
Here is a list of related bugs "fixed" in 5.0 updates:
6348045: REGRESSION: serious performance degradation as GZIPInputStream
is slower
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6348045
6206933: GZipOutputStream/InputStream goes critical(calls
JNI_Get*Critical) and cau
Clemens Eisserer a écrit :
Hello,
Sombody posted at
http://forums.java.net/jive/thread.jspa?messageID=251006 that he has
problems with the performance of java.util.zip.Deflater starting with
version 1.5.0_07.
Hi Clements,
This bug has a long history,
http://bugs.sun.com/bugdatabase/view_bug.
16 matches
Mail list logo
