[concurrency-interest] Multi consumer queue
gergg at cox.net
Wed Apr 15 12:23:38 EDT 2009
David Holmes wrote:
> For a particular application scenario a more efficient implementation is
> nearly always possible. But in general, allocation is dirt cheap (99% of the
> time from the thread-local allocation buffer) and short-lived objects are
> easily reclaimed by the GC from the young generation. And you only get
> millions of allocations if you get millions of contentions on the lock -
> which is likely to be more of a problem with regards to performance and
> latency than the allocation itself.
Just as a casual reminder, there are small devices such as the AJile processor
and the Sunspot environment, which could really make good use of efficient,
non-allocation based locking schemes in the J2ME profile. As devices get faster
and can use more memory, we start to lose sight of the basic issue of latency,
and realtime (soft and hard) requirements that many applications can have to
benefit the user experience.
I really do thing that from a performance perspective, the time is getting right
for a refocus on a totally real-time runtime environment for Java that allows
the developer to guarantee a lot more about the characteristics of the
applications performance relative to a particular class of hardware.
And we have come such a long way... I remember the example HTTP session at
JavaOne about 3 years ago where they showed how just putting forth a few simple
real-time constraints for response time, greatly smoothed the users experience
of response-time to requests.
More information about the Concurrency-interest