Link Details

Link 421455 thumbnail
User 171700 avatar

By pron
via infoq.com
Published: May 30 2010 / 09:39

Whilst detailed contention information is available through the JLM for conventional Java locks, no equivalent exists for the java.util.concurrent.locks package; no tool is supplied by Sun/Oracle with the JDK, nor other Java vendors have one. This absence of a java.util.concurrent lock profiling tool is the motivation behind the development of our lock tool, jucprofiler, as a part of Multicore SDK.
  • 9
  • 2
  • 7935
  • 5

Comments

Add your comment
User 724623 avatar

governor replied ago:

0 votes Vote down Vote up Reply

I'm confused: why go through the effort of developing an SDK to detect locks when one could simply use clojure?

User 85500 avatar

andrewm replied ago:

0 votes Vote down Vote up Reply

> I'm confused: why go through the effort of developing an SDK to detect locks when one could simply use clojure?

it's an app and sdk to profile *existing* java multithreaded apps that *already* use juc. how does clojure help with that?

User 724623 avatar

governor replied ago:

0 votes Vote down Vote up Reply

> it's an app and sdk to profile *existing* java multithreaded apps that *already* use juc. how does clojure help with that?

How does Java help in writing multi-threaded applications that share changing state? Profiling is no solution, it's band-aid. If the software in distress has a market it's always cheaper and a sign of wisdom to rewrite in clojure.

User 85500 avatar

andrewm replied ago:

0 votes Vote down Vote up Reply

> If the software in distress has a market it's always cheaper and a sign of wisdom to rewrite in clojure.

there are '000s of multi-threaded, large scale apps written in java. some products in this space and the apps they run are worth $bns, e.g. datasynapse, coherence based stuff running on thousands of grids just at the bank i work at, and they work very well. however, they need profiling occasionally. big deal.

rewriting these would not be a sign of wisdom, just to match up with a better concurrency paradigm. try this as an experiment: go to such a place with one of the apps above, and suggest rewriting the apps in clojure. if you manage to get a single gig doing this, i'll be surprised.

User 724623 avatar

governor replied ago:

0 votes Vote down Vote up Reply

I notice your wisdom is infallible, good for you. Anybody in their right mind will try to solve locking conditions by avoiding locks all together but you won't.

Heroism doesn't create added value.

User 85500 avatar

andrewm replied ago:

0 votes Vote down Vote up Reply

steven, you misrepresent my point of view. my perspective is that a cost-benefits analysis needs to be done before rewriting an underperforming multi-threaded java app into clojure. i also assert that most of the time, it will make sense to simply remediate the java application. i base the latter on experience.

by way of contrast, you have chosen to give us this absolutist fluff: "If the software in distress has a market it's *always* cheaper and a sign of *wisdom* to rewrite in clojure." (emphasis mine). tellingly, you've offered no evidence, experience or technical points of view to back this up.

for the record, lock-free stm isn't the only effective way to structure parallel applications, and can be very costly in some situations. it's a nifty paradigm to be sure, but so is dataflow dependency (Oz) and also the actor model (Scala, Akka). i've had good experience, particularly with the former, which incidentally can be done quite easily in Java using futures from j.u.c. Even better for this is the fork/join stuff from Doug, which is making its way into Java7 I believe.

User 724623 avatar

governor replied ago:

0 votes Vote down Vote up Reply

Jim, you want evidence, experience and technical points. That's telling: you believe that if your demands are sufficiently contrived other people will eventually abandon pointing out you're wrong. That thing about having the last word.

Contention in Java 5 concurrent.locks occurs for the same reason contention always occurs: when changing mutable state. Avoid mutable state and contention is not an issue. It's a binary world: either you work with mutable state and contention can become an issue or you don't and it can't. When contention can become an issue one will always have to pay attention to locking issues, hence profiling tools. When contention can't be an issue, well, you get to go home early.

Applications that have to deal with contention will be more expensive to use then applications that don't. That's easy to prove: due to the halting problem one will never be able to prove that applications that use the Java 5 concurrent.locks classes will not suffer from contention. In other terms: since the author of an application can't predict how the application will be used he cannot make reliable predications about contention issues.

Applications written in clojure can't be affected by contention hence the authors can make predications about contention issues. Due the halting problem these predications may not all be verifiable, but those that are verified will have outcomes as predicted.

User 85500 avatar

andrewm replied ago:

0 votes Vote down Vote up Reply

>you want evidence, experience and technical points.

umm, what else is there? a phone call to mum? A throwaway reference to the halting problem, hoping it will make your earlier assertions vanish?

> That's telling: you believe that if your demands are sufficiently contrived
> other people will eventually abandon pointing out you're wrong. That thing about having the last word.

remember, i'm not claiming that stm isn't sometimes the best. you, however, made the rather grand claim that converting to clojure/stm is always cheaper than fixing a java app without reference to how large the app is, or what it does. give me something to work with -- to date you've provided nothing to show your assertions stack up.

> Applications that have to deal with contention will be more expensive to use then applications that don't.

now you've moved from claiming that it's always cheaper to convert a java app into clojure, to details of STM itself. i'm not arguing that STM isn't superior for a class of synchronisation problems. on the contrary. (it's not universally true, however)

i just don't understand what you are arguing. you seemed to be earlier saying that it is always cheaper and wiser to rewrite a java app that needs profiling in clojure. are you seriously saying that this is always the case, with factoring in development costs etc?

Add your comment


Html tags not supported. Reply is editable for 5 minutes. Use [code lang="java|ruby|sql|css|xml"][/code] to post code snippets.

Node.js
Written by: Bert Belder
Featured Refcardz: Top Refcardz:
  1. Design Patterns
  2. OO JS
  3. Cont. Delivery
  4. Java EE7
  5. HTML5 Mobile
  1. Debugging JavaScript
  2. OO JS
  3. JSON
  4. Ajax
  5. REST