Hi,
wanted to add 2 points here:
1) Agree with the concern of putting .class files to repository.
This was done in order to support latest JDK 7 available collection on
JDK 6. Because if we will just put source of JDK 7 collection to
Grizzly workspace - we will not be able to compile Grizzly on JDK 1.5
If anyone has any strong concern or issue related to that - please let
us know.
Anyway I hope we will remove this code once latest JDK 7 collection
will be ported to JDK 6 (hope it will happen).
2) The entire idea of centralizing creation of collections, which
supposed to be used in multithreaded mode, IMO, is good. At least it
will help us quickly fix issues related to possible JDK bugs, like a
memory leak we were observing recently with ConcurrentLinkedQueue.
Thanks.
WBR,
Alexey.
On Dec 16, 2009, at 8:30 , gustav trede wrote:
>
>
> 2009/12/16 kedar mhaswade <kedar.mhaswade_at_gmail.com>
>
>
> On Tue, Dec 15, 2009 at 9:02 PM, gustav trede
> <gustav.trede_at_gmail.com> wrote:
>
>
> 2009/12/15 kedar mhaswade <kedar.mhaswade_at_gmail.com>
>
>
>
> On Tue, Dec 15, 2009 at 7:16 AM, gustav trede
> <gustav.trede_at_gmail.com> wrote:
>
>
> 2009/12/15 Justin Lee <Justin.Lee_at_sun.com>
>
> Right. LinkedTransferQueue, e.g., is a JDK7 class so it's not even
> in Java6 (yet?).
>
> LTQ shines for clean fixed Thread pool implementations when no extra
> fluff is needed.
> If anybody finds a more scalable way to implement a threadpool then
> the current poison based Fixed pool in grizzly it would be good to
> know, so we can ensure we got the best thing possible.
> LBQ does perform better for a few threads that consume/produces
> extremely short tasks, but it dont scale well.
>
> Hello Gustav,
>
> JCiP (the book Java Concurrency in Practice) contains a comparison
> of LBQ and ABQ (ArrayBlockingQueue) and demonstrates that LBQ
> "scales" better on multi-core machine (that they chose). Is a
> similar comparison available somewhere with regards to LTQ and LBQ?
>
>
> What is written in an old book about two datastructures A and B has
> nothing to do with A and C..
> That information is only of historical and general education interest.
> I have read that book several times,im slow at learning =). it does
> have some valuable timeless knowledge about memory models and safe
> publishing etc.
>
> I have stated multiple times on this mailing list that its only
> during the latest few months that the LTQ implementation has become
> good.
>
> Synchronized and atomics/volatile loops are both concept that dont
> scale well when failure rate is high,
> due to cpu caches are severly trashed etc.
>
> Can you explain what you mean by "failure rate"?
> When load is high enough, synchronized or lock gets contended,
> atomics incrementandget etc tends to deteriorate to approach
> synchronized level of scalability.
>
> Best is to read about these matters in general, follow openjdk
> hotspot, concurrency maling list
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest.
> There is quite often interesting discussions where the full
> complexity sometimes is probed and finally completely explained/
> analyzed if we are lucky.
> The detailed documentation available for the current LTQ,CLQ is a
> very good source for its specifics :
> In jdk7 or doug cvs http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/main/java/util/concurrent/
> .
>
>
>
> Looking at the code you can see that LTQ is designed to avoid
> sharing (and hence trashing) cachelines.
>
> Real world like or specific carefully designed technical tests on
> _modern_ hardware and JVMs, verify the findings, try to understand
> from a theoretical point of view is IMO what counts.
> I did my best efforts to do so regarding LBQ vs LTQ with one of that
> book authors Doug lea that also is the author of LTQ.
>
> Ah ok. Need to understand this better. Maybe one of these days ...
> Well, my best efforts is only that. feedback from others and whats
> best solution when all abstract aspects is considered in a community
> concensus is the real answer.
> Its a rapidly evolving combination of hardware, JVM and
> datastructures etc. It requires a personal interest inorder to even
> be somewhat up to date of the current situation.
>
>
> Also, will it be better if we created a Java 1.5 maven artifact of
> these classes rather than checking them into SCM?
>
> Your imo free to commit any change you want.
> What is the exact problem that it would fix, does OSGI have problems
> or what is it ?.
> Don't know about OSGi, but it will probably solve the problem of not
> checking in something (e.g. class files) that are generally not a
> version controlled entities. But anyway, I am not hard pressed for
> it if none else sees that as a problem.
>
> Im not skilled at maven xml stuff, if its somehow needed to use
> maven artifacts or other tricks i gladly get helped with it.
>
> --
> regards
> gustav trede
>
>