Re: RFR JDK-8081452: Move sun.nio.cs.AbstractCharsetProvider into jdk.charset/sun.nio.cs.ext
Am 30.05.2015 um 03:26 schrieb Xueming Shen: On 5/29/15 4:02 PM, Ulf Zibis wrote: Am 29.05.2015 um 19:42 schrieb Xueming Shen: But if it is decided later that we may want to have a separate ext charsets provider2, for example to split most of the ibm charsets to a separate provider, it might be desired to keep it as a base class ... Hm, is it mandatory, that each charset provider must have it's own class? I also think, that we do not need a separate class for each charset. No, it's not a must to have a separate class for each charset, but it's a logical way to organize those charset with their data. Given how most of these charsets are src-generated in current jdk, it's fair easy to actually generate a charset object from a base classes (SingleByte, or DoubleByte) + a set of data ( such as the name, aliases table, mapping data, etc) during runtime, without having a real concrete charset class. But then you need to figure out a better way to organize, store and read/initialize those data in a optimized way to initialize each charset on the fly, which we are now utilizing the jvm's class initialization mechanism to achieve this. Any benefit/advantage of doing this? We might throw in some resource someday to gather some data ... Hi sherman, I did some work here: https://bugs.openjdk.java.net/show_bug.cgi?id=100090 https://bugs.openjdk.java.net/show_bug.cgi?id=100091 https://bugs.openjdk.java.net/show_bug.cgi?id=100092 https://bugs.openjdk.java.net/show_bug.cgi?id=100095 https://bugs.openjdk.java.net/show_bug.cgi?id=100098 https://bugs.openjdk.java.net/show_bug.cgi?id=1000104 https://bugs.openjdk.java.net/show_bug.cgi?id=1000105 https://bugs.openjdk.java.net/show_bug.cgi?id=1000107 https://bugs.openjdk.java.net/show_bug.cgi?id=1000132 Unfortunately the data was moved somewhere. Do you know, where the data was moved? One of the original bug reports: http://bugs.java.com/bugdatabase/view_bug.do?bug_id=6862158 Also I did some work here: https://java.net/projects/java-nio-charset-enhanced -Ulf
Re: 8058779: Faster implementation of String.replace(CharSequence, CharSequence)
Hi everyone! Here's another webrev, in which replace() is implemented with StringBuilder. On my benchmark it is almost as fast as the version backed with arrays, but this variant is much shorter. Credits to Sherman for combining the general algorithm with the case of empty target. Comments, further suggestions are welcome! BUGURL: https://bugs.openjdk.java.net/browse/JDK-8058779 WEBREV: http://cr.openjdk.java.net/~igerasim/8058779/04/webrev/ Sincerely yours, Ivan
Re: 8058779: Faster implementation of String.replace(CharSequence, CharSequence)
On 5/30/15 7:19 PM, Ivan Gerasimov wrote:
Hi everyone!
Here's another webrev, in which replace() is implemented with
StringBuilder.
On my benchmark it is almost as fast as the version backed with
arrays, but this variant is much shorter.
Credits to Sherman for combining the general algorithm with the case
of empty target.
Comments, further suggestions are welcome!
BUGURL: https://bugs.openjdk.java.net/browse/JDK-8058779
WEBREV: http://cr.openjdk.java.net/~igerasim/8058779/04/webrev/
Sincerely yours,
Ivan
This is one is much better:-) I would suggest to leave the
overflow-conscious code to the StringBuilder.
The same range check is being done inside ABS every time the repl string
is appended into the buffer,
it does not appear to be very helpful to have a redundant check here.
And it seems this check only works
for the single appearance of target string.
2260 // overflow-conscious code
2261 if (value.length - targLen Integer.MAX_VALUE - replValue.length)
{
2262 throw new OutOfMemoryError();
2263 }
Re: Why isn't Object.notify() a synchronized method?
On 30/05/2015 2:48 AM, Ulf Zibis wrote: Thanks for your hint David. That's the only reason I could imagine too. Can somebody tell something about the cost for recursive lock acquisition in comparison to the whole call, couldn't it be eliminated by Hotspot? There are a number of fast paths related to recursive locking. Not sure if inlining allows lock elision that something for the compiler folk. As I recently fell into the trap of forgetting the synchronized block around a single notifyAll(), I believe, the current situation is just errorprone. How is it errorprone? You forgot to acquire the lock and you got an IllegalMonitorStateException when you did notifyAll. That's pointing out your error. Any comments about the Javadoc issue? I did comment - I don't see any issue. David H. -Ulf Am 28.05.2015 um 18:27 schrieb David M. Lloyd: Since most of the time you have to hold the lock anyway for other reasons, I think this would generally be an unwelcome change since I expect the cost of recursive lock acquisition is nonzero. On 05/28/2015 11:08 AM, Ulf Zibis wrote: Hi all, in the Javadoc of notify(), notifyAll() and wait(...) I read, that this methods should only be used with synchronisation on it's instance. So I'm wondering, why they don't have the synchronized modifier out of the box in Object class. Also I think, the following note should be moved from wait(long,int) to wait(long): /The current thread must own this object's monitor. The thread releases ownership of this monitor and waits until either of the following two conditions has occurred:// / * /Another thread notifies threads waiting on this object's monitor to wake up either through a call to the notify method or the notifyAll method./ * /The timeout period, specified by timeout milliseconds plus nanos nanoseconds arguments, has elapsed. / Cheers, Ulf
