[doc]Small modification on the WeakHashMap doc
Hi guys, In the Implementation notes of WeakHashMap[1], says: /One way to deal with this is to wrap values themselves within WeakReferences before inserting, as in: m.put(key, new WeakReference(value)), and then unwrapping upon each get./ However, it is not concise and a little misleading. Because the value in the WeakReference can be GC'd if there are no strong reference to it. This behaviour surprises some customers. How about add a statement like [2]: /However, as the use of WeakReference in this manner will not prevent value objects from being GC'd, this approach is only useful when entries in the map are not relied upon for keeping the underlying value objects live./ [1]: http://docs.oracle.com/javase/7/docs/api/java/util/WeakHashMap.html [2]: http://cr.openjdk.java.net/~littlee/7166055/webrev.00/ http://cr.openjdk.java.net/%7Elittlee/7166055/webrev.00/ -- Yours Charles
Re: RFR: 5015163 (str) String merge/join that is the inverse of String.split() into JDK 8
On May 2, 2012, at 8:39 AM, Stuart Marks wrote: It's fun to think about how joining would work in a lambda/streamy kind of world, e.g. stream.infix(,).join(new StringBuilder()).toString() Indeed :-) [Paul ducks as he makes up stuff!]: String s = stream.interpose(,).reduce(new ToStringReducer()); since join can be considered a reduce operation, and the above could be equivalent to: String s = stream.interleave(repeat(,)).drop(1).reduce(new ToStringReducer()); [*] As well as: String s = stream.join(,) // can be optimal implementation specific to strings, String.join could defer to this or some such. There are a bunch of issues to consider here though, such as special-casing of types in the input stream, e.g., append CharSequence directly instead of calling toString(), treat int value as a Unicode code point, etc. There are also issues about the result type: StringBuilder? String? Appendable? As much as I like the lambda stuff, though, I don't think having stream-based joining will supplant the need to have a good old-fashioned String.join(,, ...bunch of strings...) Yes. Paul. [*] interleave could support one or more streams
Re: RFR: 5015163 (str) String merge/join that is the inverse of String.split() into JDK 8
On May 1, 2012, at 2:40 PM, Rémi Forax wrote: Not saying join should be implemented that way (not so optimal for Strings only) but i think such functions are very useful. I am not tracking the lambda library work very closely, have such functions been considered? Yes, we discuss about zip/unzip, and what we call BiStream. unzip is the other name of interleave. Would that require the creation of an intermediate object that holds two values? or reuse Map.Entry. That are the two reasonable choices. I was questioning whether the creation of such objects are necessary, not the definition of a class of such an object. i.e. while zip/unzip could be used it does not seem particular efficient for the interleave use-case (especially when three or more streams are interleaved). Paul, I think this discussion should be moved to lambda-dev. It will be more fruitful. Given the context with core libraries i kept it on the same list for now. Paul.
Review Request for CR : 7144861 RMI activation tests are too slow
Please review this fix for making the jdk regression tests for rmi activation run faster. It brings a near to x2 speed factor on a Solaris/SPARC machine. The webrev for the fix is here: http://cr.openjdk.java.net/~olagneau/7144861/webrev.00/ This is a speedup only fix that does not attempt to cleanup the rmi/testlibrary code and minimizes the changes. The fix consists in applying what is described as suggestedFix(Entry 1) in bug page(see http://monaco.sfbay.sun.com/detail.jsf?cr=7144861). It mainly reduces long (seconds) waiting times steps by several much shorter ones (second tenthes) that have been chosen to minimize and keep usefull the waiting loops. These waiting time values are hardcoded, as were before the fix. The additional possible fixes described in suggestFix/Entry2 (grouping jtreg @build tags, and reducing waiting time in tests) are *not* applied here. Below is the detailed list of changes. Thanks, Olivier. Here are the details of the changes I did: -b. - testlibrary/JavaVM.java : rather than waiting once for an hopefully sufficient time of 2secs at the end of start() method, a way to know when the vm is really started has been added with the help of redirected buffers in StreamPipe : in StreamPipe.run(), as soon as we have something to read in the vm output buffer, it means the distant vm can be considered started, and thus a synchronized JavaVM.started() method that sets-up a javaVM started status is called. We force such an output in the default case (most used one) by prepending -showversion flag in the command line running distant vm process. At the end of JavaVM.start(), we loop and wait by steps of 100msecs to check for the started status until the started status is set or max bound time is reached (keeping the initial max of 2secs bound). If bound is reached without seeing started flag set, vm is consiedered started anyway. We keep the previously existing way of starting the vm and using streamPipe for the cases where we don't want child vm to output anything or if we don't have any control of child process (when started without using JavaVM constructor/start). In a usual jtreg env, 3 loops are most often enough (300msecs), with a max of 700msecs seen from numerous trials. - testlibrary/StreamPipe : this is all described here above. - testlibray/RMID : start() method: the existing waiting time slices have been reduced to 100msecs, before calling rmidRunning(). These were/are useless since rmidRunning() also does such waiting loops, but the intention is not to cleanup testlibrary code to avoid confusion and mixing things. So just reduced the waiting time slices. Most of the times 1 such waiting step is enough, since rmidRunning does the same kind of loops. So we most often see rmid running after 300msecs most often, with an observed max of 1.1sec. shutdown() : suppressed useless sleep(5000) which is better handled in destroy() method. Provide additional status on communication status with distant rmid. destroy() : Added a waiting loop on process.exitvalue() (by steps of 200msecs) to have more chances to see distant rmid process terminates gracefully, while being faster. The max waiting time bound here is 60secs (300 steps). Observed needed time varies between 600msecs and 3secs. - testlibrary/ActivationLibrary : deactivate(): Waiting time steps reduced from 1000msecs to 100, enlarging the number of steps to 50 (kept total waiitng time of 5secs). In almost all cases 1 waiting step is enough, sometimes up to 5, and only for CheckImplClassLoader we occasionnally never see inactive call succeeding. rmidRunning() : Reduced the waiting time slice to 100msecs and added some communication/exception status info. Kept the max waiting time bound of 7.5secs. In most cases 300msecs (3 steps) is enough. - CheckUsage test: main() : suppressed useless sleep of 7secs. - NoConsoleOutput test: main() : the only observed test to expect no output from distant vm. Thus using previously existing method for instantiating/starting distant vm, with a fixed waiting time of 2secs. ---e.
Re: Review Request for CR : 7144861 RMI activation tests are too slow
On 03/05/2012 14:09, Olivier Lagneau wrote: Please review this fix for making the jdk regression tests for rmi activation run faster. It brings a near to x2 speed factor on a Solaris/SPARC machine. The webrev for the fix is here: http://cr.openjdk.java.net/~olagneau/7144861/webrev.00/ It's great to see patches like this, thank you! The RMI tests have always been really slow, the activation tests in particular so I'm looking forward to seeing this patch go in. I'm also looking forward to trying it out in conjunction with Darryl Mocek's patch as the combined patches should mean we get much better overall through-put. I think Stuart is going to do the detailed review and help you get this over the finish line. I've just scanned the webrev (I didn't do a detailed review) and I didn't see anything obviously wrong, looks like the changes are in the right places. -Alan.
Re: RFR: 5015163 (str) String merge/join that is the inverse of String.split() into JDK 8
I'm just now reading State of the Lambda and beginning to get a handle on this discussion, which makes sense to me today (and didn't yesterday morning). (All this stuff about reduce is definitely taking me back to my APL days. s - ./list -- a concat/reduce operation (sans the delimiter of course)) Once I come up to speed more thoroughly I'll take a shot at this with join. Your comments are definitely giving me food for thought. Thanks, JIm On 05/03/2012 04:38 AM, Paul Sandoz wrote: On May 2, 2012, at 8:39 AM, Stuart Marks wrote: It's fun to think about how joining would work in a lambda/streamy kind of world, e.g. stream.infix(,).join(new StringBuilder()).toString() Indeed :-) [Paul ducks as he makes up stuff!]: String s = stream.interpose(,).reduce(new ToStringReducer()); since join can be considered a reduce operation, and the above could be equivalent to: String s = stream.interleave(repeat(,)).drop(1).reduce(new ToStringReducer()); [*] As well as: String s = stream.join(,) // can be optimal implementation specific to strings, String.join could defer to this or some such. There are a bunch of issues to consider here though, such as special-casing of types in the input stream, e.g., append CharSequence directly instead of calling toString(), treat int value as a Unicode code point, etc. There are also issues about the result type: StringBuilder? String? Appendable? As much as I like the lambda stuff, though, I don't think having stream-based joining will supplant the need to have a good old-fashioned String.join(,, ...bunch of strings...) Yes. Paul. [*] interleave could support one or more streams
Re: Code Review Request: 7165118: (prefs) AbstractPreferences.remove(null) does not throw NPE
On 02/05/2012 18:47, Kurchi Hazra wrote: Thanks all for the review. A webrev with the doc change: http://cr.openjdk.java.net/~khazra/7165118/webrev.01/ This looks fine to me. -Alan
