Re: An Alternative Hashing Alternative

Whoa! This is awesome. Bob On Wed, Jun 6, 2012 at 9:22 AM, Doug Lea wrote: > > I just posted the following to the concurrency-interest list. > I'll send a follow-up on tie-ins to core-lib issues next. > > ... > > > Finally acting on an old idea, I committed an update to > ConcurrentHashMap (cur

Re: Code review: 7012540 (java.util.Objects.nonNull() incorrectly named)

On Wed, Jan 26, 2011 at 3:44 PM, Joshua Bloch wrote: > I like the name *nonNull*. All other things being equal, shorter is > better. I've used the name *nonNull* for a few years, and it's feels > right. To my mind, *requireNonNull* does a worse job of suggesting that > the method returns its ar

Re: A small ClassLoader change proposal

On Thu, Sep 16, 2010 at 9:22 AM, Jevgeni Kabanov wrote: > Bob, if you check the link to the blog post, it described such an > implementation that I did a while ago. > Doh! Sorry for not reading that. > Unfortunately what I found out is that it doesn't work with some class > loaders. Mainly bec

Re: A small ClassLoader change proposal

Jevgeni, The best long term solution for the VM is ephemerons. They're not slated for Java 7 or even 8 yet though. I implemented "class loader locals" as a library years ago. Unfortunately, I don't have the code anymore because I didn't end up using them.

Re: Thread.getState() very slow

Doug, I ran into similar problems not too long ago. Dalvik uses a volatile field for the thread state. I wrote a sampling profiler for Dalvik. See SamplingProfiler.c

Re: java.util.Pair

On Tue, Mar 30, 2010 at 4:34 PM, wrote: > While I have sympathy with that conclusion, there is the > side-effect of littering many APIs with the flotsam of lots of different > classes named "Pair." My inclination would be to produce one adequate > Pair class in the JDK to prevent the proliferati

Re: hg: jdk7/tl/jdk: 3 new changesets

On Wed, Oct 21, 2009 at 1:02 PM, wrote: > 4206909: want java.util.zip to work for interactive use (Z_SYNC_FLUSH) > Summary: Add sync_flush option into Deflater/DefalterOutputStream > Reviewed-by: martin, alanb > > ! src/share/classes/java/util/zip/Deflater.java > ! src/share/classes/java/util/zip

Re: j.u.Objects follow-up: deepEquals(Object, Object)?

On Mon, Oct 12, 2009 at 10:40 AM, Joseph D. Darcy wrote: > I think Objects is a better home for deepEquals(Object, Object) than Arrays > since the arguments are not arrays and since it is a sibling method to > equals(Object, Object). > While the argument types are Object, the behavior and usage

Re: j.ul.Objects follow-up: methods for var-argification?

On Mon, Oct 12, 2009 at 12:52 PM, Rémi Forax wrote: > It's not a good idea to have a hashCode() that allocate objects, > at least until escape analysis is implemented in all VMs. Agree with Joe--these methods don't carry their weight. If the allocation is too much to bear, it's easy enough to w

Re: What methods should go into a java.util.Objects class in JDK 7?

On Fri, Oct 9, 2009 at 6:55 PM, Paul Benedict wrote: > Understood, but the keyword (pun) here is "effectively". Why let a > developer wait until runtime to find out his code will fail? At least > by marking the class as final, anybody who wishes to subclass it will > receive a compiler error. Rai

Re: [PATCH 0/2] Class- and class loader-local storage (Bug ID #6493635)

On Tue, Mar 3, 2009 at 11:43 AM, David M. Lloyd wrote: > No, actually what I've implemented *exactly* matches this definition: a > mapping where the value is held strongly until the key is known to be > garbage collected (even when the value has a reference back to the key). The > only difference

Re: [PATCH 0/2] Class- and class loader-local storage (Bug ID #6493635)

On Mon, Mar 2, 2009 at 10:37 PM, David M. Lloyd wrote: > If not, then there is no automatic solution possible, even with special VM > ephemeron support (this basically IS an ephemeron implementation, after all, > albeit a specialized one). Actually, your approach is not the same as an ephemeron

Re: [PATCH 0/2] Class- and class loader-local storage (Bug ID #6493635)

David, Here's the problem I'd like to see solved: enable a library to hold an indirect reference to a Class without preventing that Class's loader from being reclaimed. The reclamation should happen automatically when the loader is not otherwise strongly referenced. You added a further requiremen

Re: [PATCH 0/2] Class- and class loader-local storage (Bug ID #6493635)

David, I regret making my suggestion in the first place. I really think we need ephemerons, but for the sake of discussion: - Your patch adds 2 new classes. My suggestion adds one method (maybe 2 for convenience). - Your approach enables explicit clearing, but I thought the whole point of adding

Re: [PATCH 0/2] Class- and class loader-local storage (Bug ID #6493635)

There's no need for insults, David. Have some perspective. I've been nothing but civil and respectful (even after you presumed to know what I do and don't understand). On Fri, Feb 27, 2009 at 1:12 PM, David M. Lloyd wrote: > I'm not talking about a parent/child relationship at all. I'm talking

Re: [PATCH 0/2] Class- and class loader-local storage (Bug ID #6493635)

On Fri, Feb 27, 2009 at 12:48 PM, David M. Lloyd wrote: > I don't think you understood what I wrote I understood. I just think you're trying to solve a problem that no one really has. 99% of the time, the problem is with a class from a parent class loader keeping a strong reference to a class in

Re: [PATCH 0/2] Class- and class loader-local storage (Bug ID #6493635)

On Fri, Feb 27, 2009 at 11:44 AM, David M. Lloyd wrote: > WeakHashMap, Externalizer>() > > *fails* because Externalizer instances are usually customized to the class > they externalize (which, by the way, could well be a system class). This > means that Externalizer keeps a strong ref to the Clas

Re: [PATCH 0/2] Class- and class loader-local storage (Bug ID #6493635)

On Fri, Feb 27, 2009 at 11:04 AM, David M. Lloyd wrote: > A couple use cases, off the top of my head: > > 1) I've got a set of FooBars that associate with Classes; now for whatever > reason, I want to change the FooBar that is associated with the Class.  The > old FooBar is now completely unrefere

Re: [PATCH 0/2] Class- and class loader-local storage (Bug ID #6493635)

On Fri, Feb 27, 2009 at 10:40 AM, David M. Lloyd wrote: > Seems like a reasonable alternate approach, *however* I think there ought to > be a way to clear the reference as well, Do you have a use case? *If* we wanted to support removals (I don't think we should), I would do something like this:

Re: [PATCH 0/2] Class- and class loader-local storage (Bug ID #6493635)

I have a simpler and more secure solution. I just need one method on ClassLoader: public class ClassLoader { public void keepReferenceTo(Object o) { ... } ... } The ClassLoader would keep a strong reference to the passed reference indefinitely (using some sort of minimal memory footprint,