loom-dev Digest, Vol 28, Issue 3

[Douglas Surber]

I agree with Kasper. All my uses of thread local are to avoid contention and all would be addressed by a processor local with the very important caveat that the points where the processor can change are well defined and easily recognized. In practice I have a feeling that would not be practical. Stepping away from implementation, what I need is something like this:

	public final class LocalResource<T> {
		private final Supplier<T> creator;
		public LocalResource(Supplier<T> c) {
			creator = c;
		}
		private T get() { ... }
		private void release(T resource) { ... }
		public <V> V do(Function<T, V> f) {
			T t = this.get();
			try {
				return f.apply(t); // capturing t in f is an error
			}
			finally {
				this.release(t);
			}
		}
	}

An instance of LocalResource creates and retains the minimum number of instances of T necessary to satisfy all calls to do without any contention. Assume T is not thread safe and expensive to create. A LocalResource is used like this:

	Bar b = new Bar();
	Foo f = resource.do( t -> t.foo(b) );

Presently we use ThreadLocal for this purpose, but ThreadLocal implies an implementation. ProcessorLocal would also imply an implementation. I don't care how it's implemented. What I want is something that allocates a minimum number of instances of T, on the order of the number of cores, and has zero contention, ever, and is fast. If Loom provides something like LocalResource I think many of the demands on ThreadLocal are relaxed giving more freedom to specify how it works with virtual threads.

Douglas


> On Apr 3, 2020, at 1:57 AM, loom-dev-request at openjdk.java.net wrote:
> 
> Date: Fri, 3 Apr 2020 08:35:03 +0100
> From: Kasper Nielsen <kasperni at gmail.com <mailto:kasperni at gmail.com>>
> To: Thomas May <tmay at clearwateranalytics.com <mailto:tmay at clearwateranalytics.com>>,
> 	dmitry.zaslavsky at gmail.com <mailto:dmitry.zaslavsky at gmail.com>
> Cc: "loom-dev at openjdk.java.net <mailto:loom-dev at openjdk.java.net>" <loom-dev at openjdk.java.net <mailto:loom-dev at openjdk.java.net>>
> Subject: Re: carrier local
> Message-ID:
> 	<CAPs6152sBjL4u8dXskvhpR5v4cXKNoBzeN2tdKdf0xnOqUY1Mg at mail.gmail.com <mailto:CAPs6152sBjL4u8dXskvhpR5v4cXKNoBzeN2tdKdf0xnOqUY1Mg at mail.gmail.com>>
> Content-Type: text/plain; charset="UTF-8"
> 
> On Thu, 2 Apr 2020 at 21:07, Thomas May <tmay at clearwateranalytics.com <mailto:tmay at clearwateranalytics.com>> wrote:
>> 
>> LongAdder would be a good example where you'd want carrier local storage rather than thread local.  Having it ThreadLocal would allocate more memory than necessary.
> 
> I think you would be better off with processor local state in most
> cases where you
> are trying to avoid contention as mentioned in the Loom proposal [1]
> and this RFE [2].
> 
> /Kasper
> 
> [1] https://cr.openjdk.java.net/~rpressler/loom/Loom-Proposal.html <https://cr.openjdk.java.net/~rpressler/loom/Loom-Proposal.html>
> [2] https://bugs.openjdk.java.net/browse/JDK-7065539 <https://bugs.openjdk.java.net/browse/JDK-7065539>
>