Naming of thread pools (Executors)
Hi,
I would like create a patch for
https://bugs.openjdk.java.net/browse/JDK-8016248.
MOTIVATION: Today thread pools created by the Executors method are always
prefixed with "pool". The developer can work around this by providing his own
ThreadFactory but if he wants to have the default JDK behaviour then it means
he has to replicate code in the JDK. The string "pool" is hardcoded in the JDK.
The fact that threads cannot be identified by their purpose is annoying
especially when working with JEE servers.
SUGGESTION:
The idea is to amend private classes Executors.DefaultThreadFactory and
Executors.PrivilegedThreadFactory to optionally accept a name prefix in their
constructor.Then methods Executors.defaultThreadFactory() and
Executors.privilegedThreadFactory() will be overloaded to optionally accept a
name prefix.
With this change the developer can now use a custom thread name prefix. If he
wanted to do:
Executors.newFixedThreadPool(3); // standard, results in "pool" prefix
He could instead use a developer supplied ThreadFactory yet still using JDK's
ThreadFactory:
Executors.newFixedThreadPool(3,
Executors.defaultThreadFactory("snmpworker"));
Good idea ? Bad idea? Any negative side effects ?
Thanks
Peter
Re: RFR: 8077846: improve locking strategy for readConfiguration(), reset(), and initializeGlobalHandlers()
On 05/15/2015 05:05 PM, Daniel Fuchs wrote: Looks good for me Peter :-) Hopefully Mandy will like it too! Yes it looks good to me. Thanks to both of you for imprpving the synchronization. This is the comment on the test I sent last round: TestConfigurationLock.java Copyright year should be 2015 TestConfigurationLock.properties It would be good to delete all commented lines except the lines relevant to the setting to make it obvious what the configuration is. Right. Sorry I forgot about that. Here is an updated webrev containing Peter's webrev.04 in which I have updated the test: http://cr.openjdk.java.net/~dfuchs/webrev_8077846/webrev.05 Peter, are you still willing to push that? best regards, -- daniel Right. I went over code changes once again and I was happy with the final shape. I re-ran the java/util/logging tests an all 60 passed. So I pushed this change. Thanks to David, Alan and Mandy for reviewing and of course to Daniel for cooperation and the majority of the code in this changeset. Regards, Peter Mandy
JDK 9 RFR of JDK-8078136: Incorrect figure number in reference to Hacker's Delight book in Long.bitCount() method
Hello,
Please review this typo fix for
JDK-8078136: Incorrect figure number in reference to Hacker's
Delight book in Long.bitCount() method
diff -r d40f1245a1f1 src/java.base/share/classes/java/lang/Long.java
--- a/src/java.base/share/classes/java/lang/Long.javaWed May 13
14:16:46 2015 -0700
+++ b/src/java.base/share/classes/java/lang/Long.javaSun May 17
09:51:48 2015 -0700
@@ -1708,7 +1708,7 @@
* @since 1.5
*/
public static int bitCount(long i) {
-// HD, Figure 5-14
+// HD, Figure 5-2
i = i - ((i >>> 1) & 0xL);
i = (i & 0xL) + ((i >>> 2) & 0xL);
i = (i + (i >>> 4)) & 0x0f0f0f0f0f0f0f0fL;
I verified all the other figure references between java.lang.Integer and
java.lang.Long were consistent.
Thanks,
-Joe
Re: JDK 9 RFR of JDK-8078136: Incorrect figure number in reference to Hacker's Delight book in Long.bitCount() method
Go for it joe😎
Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering
1 Network Drive
Burlington, MA 01803
lance.ander...@oracle.com
Sent from my iPad
> On May 17, 2015, at 12:53 PM, joe darcy wrote:
>
> Hello,
>
> Please review this typo fix for
>
>JDK-8078136: Incorrect figure number in reference to Hacker's Delight book
> in Long.bitCount() method
>
> diff -r d40f1245a1f1 src/java.base/share/classes/java/lang/Long.java
> --- a/src/java.base/share/classes/java/lang/Long.javaWed May 13 14:16:46
> 2015 -0700
> +++ b/src/java.base/share/classes/java/lang/Long.javaSun May 17 09:51:48
> 2015 -0700
> @@ -1708,7 +1708,7 @@
> * @since 1.5
> */
> public static int bitCount(long i) {
> -// HD, Figure 5-14
> +// HD, Figure 5-2
> i = i - ((i >>> 1) & 0xL);
> i = (i & 0xL) + ((i >>> 2) & 0xL);
> i = (i + (i >>> 4)) & 0x0f0f0f0f0f0f0f0fL;
>
> I verified all the other figure references between java.lang.Integer and
> java.lang.Long were consistent.
>
> Thanks,
>
> -Joe
Re: RFR 8029891 : Deadlock detected in java/lang/ClassLoader/deadlock/GetResource.java
On 16/05/2015 5:09 AM, Brent Christian wrote: On 5/13/15 8:53 AM, Mandy Chung wrote: On May 12, 2015, at 2:26 PM, Peter Levart wrote: On 05/12/2015 10:49 PM, Mandy Chung wrote: But I think it should be pretty safe to make the java.util.Properties object override all Hashtable methods and delegate to internal CMH so that: - all modification methods + all bulk read methods such as (keySet().toArray, values.toArray) are made synchronized again - individual entry read methods (get, containsKey, ...) are not synchronized. This way we get the benefits of non-synchronized read access but the change is hardly observable. In particular since external synchronization on the Properties object makes guarded code atomic like it is now and individual entry read accesses are almost equivalent whether they are synchronized or not and I would be surprised if any code using Properties for the purpose they were designed for worked any differently. I agree that making read-only methods not synchronized while keeping any method with write-access with synchronized is pretty safe change and low compatibility risk. On the other hand, would most of the overrridden methods be synchronized then? Yes, and that doesn't seem to be a problem. Setting properties is not very frequent operation and is usually quite localized. Reading properties is, on the other hand, a very frequent operation dispersed throughout the code (almost like logging) and therefore very prone to deadlocks like the one in this issue. I think that by having an unsynchronized get(Property), most problems with Properties will be solved - deadlock and performance (scalability) related. I’m keen on cleaning up the system properties but it is a bigger scope as it should take other related enhancement requests into account that should be something for future. I think what you propose seems a good solution to fix JDK-8029891 while it doesn’t completely get us off the deadlock due to user code locking the Properties object. Updated webrev: http://cr.openjdk.java.net/~bchristi/8029891/webrev.1/ This approach seems reasonable to me. I don't have any specific concerns. Thanks, David - I have restored synchronization to modification methods, and to my interpretation of "bulk read" operations: * forEach * replaceAll * store: (synchronized(this) in store0; also, entrySet() returns a synchronizedSet) * storeToXML: PropertiesDefaultsHandler.store() synchronizes on the Properties instance * propertyNames(): returns an Enumeration not backed by the Properies; calls (still synchronized) enumerate() * stringPropertyNames returns a Set not backed by the Properties; calls (still synchronized) enumerateStringProperties These continue to return a synchronized[Set|Collection]: * keySet * entrySet * values These methods should operate on a coherent snapshot: * clone * equals * hashCode I expect these two are only used for debugging. I wonder if we could get away with removing synchronization: * list * toString I'm still looking through the serialization code, though I suspect some synchronization should be added. The new webrev also has the updated test case from Peter. Thanks, -Brent
