Re: Faster HashMap implementation

Also it should be mentioned that memory-wise my implementation uses more memory in resize: it need to copy 2 arrays of ~2*C size (C = capacity) and current HashMap needs only one array of C size, data in Entry structures are not copied. This can be addressed if it is important by (1) splitting inte

hg: jdk7/tl/langtools: 6854796: update JSR308 impl with latest code from type-annotations repo

Changeset: 7c154fdc3547 Author:jjg Date: 2009-06-26 19:47 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/7c154fdc3547 6854796: update JSR308 impl with latest code from type-annotations repo Reviewed-by: jjg, mcimadamore, darcy Contributed-by: mer...@cs.washington.edu, m

hg: jdk7/tl/langtools: 6855544: add missing files

Changeset: 664edca41e34 Author:jjg Date: 2009-06-26 19:12 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/664edca41e34 6855544: add missing files Reviewed-by: jjg, mcimadamore, darcy Contributed-by: mer...@cs.washington.edu, m...@csail.mit.edu, mp...@csail.mit.edu + sr

hg: jdk7/tl/langtools: 6843077: JSR 308: Annotations on types

Changeset: 03944ee4fac4 Author:jjg Date: 2009-06-26 18:51 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/03944ee4fac4 6843077: JSR 308: Annotations on types Reviewed-by: jjg, mcimadamore, darcy Contributed-by: mer...@cs.washington.edu, m...@csail.mit.edu, mp...@csail.m

hg: jdk7/tl/jdk: 6843077: JSR 308: Annotations on types

Changeset: a5f7d97c3f82 Author:jjg Date: 2009-06-26 18:39 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/a5f7d97c3f82 6843077: JSR 308: Annotations on types Reviewed-by: jjg, mcimadamore, darcy Contributed-by: mer...@cs.washington.edu, m...@csail.mit.edu, mp...@csail.mit.edu

Re: Review request for 6844054: (bf) Eliminate dependency on javax.management.ObjectName

Alan, Looks good. Thanks for making the change. I'll fix java.util.logging to eliminate such dependency. Mandy Alan Bateman wrote: Mandy - you do mind reviewing this change to eliminate the dependency in java.nio on javax.management.ObjectName that we've chatted about. The changes move th

Review request for 6844054: (bf) Eliminate dependency on javax.management.ObjectName

Mandy - you do mind reviewing this change to eliminate the dependency in java.nio on javax.management.ObjectName that we've chatted about. The changes move the creation of the management interfaces to ManagementFactoryHelper. The webrev is here: http://cr.openjdk.java.net/~alanb/6844054/webr

hg: jdk7/tl/langtools: 6593082: MirroredTypeException constructor does not throw NPE when type is null

Changeset: ca063536e4a6 Author:darcy Date: 2009-06-26 12:22 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/ca063536e4a6 6593082: MirroredTypeException constructor does not throw NPE when type is null Reviewed-by: jjg ! src/share/classes/javax/lang/model/type/MirroredTy

Re: Miscellaneous improvements to "jar".

Ulf Zibis wrote: Am 26.06.2009 17:47, Xueming Shen schrieb: Ulf, I do have a "prototype implementation" that uses buffer based read/write on Jar/ZipFile, it is not that "much" faster as you would have expected (basically the gain of using direct buffer comes from saving one or two memory copy

Re: Miscellaneous improvements to "jar".

Find suitable abstractions and refactor them into a separate piece of code. The win is a lot bigger if you make the new abstractions public supported parts of the API, but that is harder with the JDK. Yep, I agree. Often that's my motivation to report RFE's e.g.: http://bugs.sun.com/bugdatab

Re: Miscellaneous improvements to "jar".

Am 26.06.2009 17:47, Xueming Shen schrieb: Ulf, I do have a "prototype implementation" that uses buffer based read/write on Jar/ZipFile, it is not that "much" faster as you would have expected (basically the gain of using direct buffer comes from saving one or two memory copy of the content,

Re: Miscellaneous improvements to "jar".

Am 26.06.2009 18:45, Xueming Shen schrieb: Ulf Zibis wrote: Motivation: Xueming states: *"dat" based uses less disk space, but it has larger startup time, reading an additional "big" dat file during class loading/initializing actually takes much longer time than I expected (I hit the extreme

Re: Miscellaneous improvements to "jar".

The latest version looks good. 2 nit comments (1) it's reasonable to have createTempFileInSamDirectoryAs separate out, but I would keep the directoryOf within it. Yes, it's "clearer":-) (2)the "updateOK" in dumpIndex really serves nobody but "clearer":-) sherman btw, while you are here:-) d

Re: Miscellaneous improvements to "jar".

On Fri, Jun 26, 2009 at 09:31, Ulf Zibis wrote: > Martin, thanks for taking the time. > > Am 26.06.2009 15:53, Martin Buchholz schrieb: > > > > On Fri, Jun 26, 2009 at 01:37, Ulf Zibis wrote: > >> 1. Hopefully some volunteer would be found to fix >> http://bugs.sun.com/bugdatabase/view_bug.do?b

Re: Miscellaneous improvements to "jar".

Ulf Zibis wrote: Motivation: Xueming states: *"dat" based uses less disk space, but it has larger startup time, reading an additional "big" dat file during class loading/initializing actually takes much longer time than I expected (I hit the extreme when I worked on the EUC_TW, which I make t

Re: Miscellaneous improvements to "jar".

Oops, I'm not as fast as you two, writing in english. :-( -Ulf Am 26.06.2009 18:04, Martin Buchholz schrieb: Removing one layer of BufferedInputStream in my change saves one bulk copy per file. And reusing the same buffer saves on cache misses and GC. But bulk copy is actually very fast, (esp

Re: Miscellaneous improvements to "jar".

Martin, thanks for taking the time. Am 26.06.2009 15:53, Martin Buchholz schrieb: On Fri, Jun 26, 2009 at 01:37, Ulf Zibis > wrote: 1. Hopefully some volunteer would be found to fix http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6818737 before JDK7 AP

Re: Miscellaneous improvements to "jar".

Removing one layer of BufferedInputStream in my change saves one bulk copy per file. And reusing the same buffer saves on cache misses and GC. But bulk copy is actually very fast, (especially as memory is becoming more like disk), so the win is relatively small. I would be surprised if you could

Re: Miscellaneous improvements to "jar".

Martin Buchholz wrote: On Fri, Jun 26, 2009 at 01:37, Ulf Zibis > wrote: Am 26.06.2009 02:57, Martin Buchholz schrieb: I did some benchmarking, and found that my changes "only" make jar 10-20% faster. Disappointing - we expect an order of

hg: jdk7/tl/jdk: 6855297: Windows build breaks after 6811297

Changeset: 0b6571d4b4b5 Author:jccollet Date: 2009-06-26 16:50 +0200 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/0b6571d4b4b5 6855297: Windows build breaks after 6811297 Summary: re-introduced the mistakenly taken out authObj member Reviewed-by: chegar ! src/share/classes/sun/n

Re: Miscellaneous improvements to "jar".

On Fri, Jun 26, 2009 at 01:37, Ulf Zibis wrote: > Am 26.06.2009 02:57, Martin Buchholz schrieb: > >> I did some benchmarking, >> and found that my changes "only" make jar 10-20% faster. >> Disappointing - we expect an order of magnitude for every commit! >> > > 1. Hopefully some volunteer would b

jdk7/tl breakage

Just a heads up that jdk7/tl/jdk isn't currently buildable on Windows. One of the recent changeset seems to have accidentally deleted the hooks in the http protocol handler that are needed for NTLM authentication. Jessie is working on a fix now so if you had planned to sync up your forest today

Re: Miscellaneous improvements to "jar".

Am 26.06.2009 02:57, Martin Buchholz schrieb: I did some benchmarking, and found that my changes "only" make jar 10-20% faster. Disappointing - we expect an order of magnitude for every commit! 1. Hopefully some volunteer would be found to fix http://bugs.sun.com/bugdatabase/view_bug.do?bug_id