Stolen: Re: [concurrency-interest] LongAdder (was: StripedAdder) and LongAdderTable
forax at univ-mlv.fr
Mon Aug 1 07:14:01 PDT 2011
An interesting post stolen from the Doug Lea's concurrency mailing list.
Having this kind of counter can be really great for those that
want to do profiling without having an interpreter
Groovy, Nashorn, ...
Basically, this kind of counter already exist in the VM,
is there a way to bubble them up in Java ?
-------- Original Message --------
Subject: Re: [concurrency-interest] LongAdder (was: StripedAdder) and
Date: Sun, 31 Jul 2011 21:22:19 +0200
From: William Louth (JINSPIRED.COM) <william.louth at jinspired.com>
To: concurrency-interest at cs.oswego.edu
I am currently writing up a proposal (will be posted on blog next week
hopefully) for having an intrinsic (long) counter data type in the Java
that would be thread local (though not access through this interface)
and optimized by the JVM whilst affording the ability to introspect the
current set of named counters in the JVM as well as their instance (and
value) on a per thread basis (preferably within the thread itself) via
an API. I think we should be encouraging developers to move away from
process level JMX like counters and instead thread specific& event
based (without state) which could be in turn be accessed at a process
level if need be but more so at the thread level and from a caller/chain
perspective forming a foundation for the ultimate feedback loop between
callers and callees.
This a part of a much bigger proposal for software activity metering to
be a core aspect of the runtime, library and possibly language (via
OpenCore Metering Runtime Actors
Activity Based Costing& Metering (ABC/M) – The Ultimate Feedback Loop
Automated Performance Management starts with Software’s Self Observation
Metering (Probes) Open API
On 31/07/2011 20:56, Doug Lea wrote:
> On 07/31/11 12:39, Christian Vest Hansen wrote:
>> Some interfaces for these things might be a good idea, as I can
>> imagine data
>> grid libraries might want to provide distributed implementations.
>> Counter and
>> CounterTable comes to mind as possible names.
> I had proposed this, but talked myself out of it.
> The APIs are tied to a particular scalar type (long),
> and might grow to include others (in particular, a
> DoubleAdder class). It may be that the only
> commonality is that they extend java.lang.Number. Which
> we declared for the AtomicX classes, but even that was not
> obviously helpful.
>> On Sun, Jul 31, 2011 at 16:55, Doug Lea<dl at cs.oswego.edu
>> <mailto:dl at cs.oswego.edu>> wrote:
>> Also, because it is likely to be among the more
>> common uses of LongAdders, we created AtomicLongTable,
> Oops. I meant LongAdderTable. (The names changed several times
> times before check-in.)
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
Concurrency-interest mailing list
Concurrency-interest at cs.oswego.edu
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the mlvm-dev