Code Review Request for # 6975829 : Perf. of gzip in existing JDKs is too slower than in 1.3.1

Alan Bateman Alan.Bateman at oracle.com
Wed Oct 6 13:19:06 UTC 2010


Xueming Shen wrote:
> Alan,
>
> It appears we do have a regression test [1] in our repository to make 
> sure that
> we do NOT do round-trip more than necessary for "short" input. While 
> the change
> in http://cr.openjdk.java.net/~sherman/6975829/webrev 
> <http://cr.openjdk.java.net/%7Esherman/6975829/webrev.00/>.00 
> <http://cr.openjdk.java.net/%7Esherman/6975829/webrev.00/> does not 
> "break"
> anything, it does go to the inflater more than once for this corner case.
>
> I updated the webrev to add some "overhead" bytes. This "20 bytes" 
> overhead
> probably will make some other corner cases less optimistic, but that 
> would not
> be a regression.
>
> http://cr.openjdk.java.net/~sherman/6975829/webrev 
> <http://cr.openjdk.java.net/%7Esherman/6975829/webrev/>
>
> -Sherman
>
> [1] test/java/util/ZipFile/ShortRead.java
Yep, the zip code always manages to bite whoever touches it. Is it worth 
writing a few more tests to make sure that we don't have any regression 
in other corner cases?

Would be better to just initialize in_len to MIN(this_len, len + 20)? 
(and maybe define a constant for the size of the extra space?).

-Alan.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20101006/63cadf43/attachment.html>


More information about the core-libs-dev mailing list