The answer would be no in general, I think, since it is unsafe.
Moving the entire loop into the synchronized block would make the statement marked XXX above, i.e. "for (...)" execute inside the synchronized block, which has the potential to change the semantics (for example, the statement may include an rpc, and we don't want to make that rpc under the lock).
> Moving the entire loop into the synchronized block would make the statement marked XXX above, i.e. "for (...)" execute inside the synchronized block, which has the potential to change the semantics (for example, the statement may include an rpc, and we don't want to make that rpc under the lock).
That's not change in semantics. The JVM doesn't provide any guarantees about parallelism or scheduling semantics in the first place so how can you possibly argue about the semantics of holding a lock too long?
And it's unsafe? For what definition of safety?
But in practice - yes you obviously wouldn't do this if the code in the loop control code had any side effects.
> The answer would be no in general, I think, since it is unsafe.
> ...
> for example, the statement may include an rpc, and we don't want to make that rpc under the lock
I do agree that it's not a "safe" optimization in the extreme general case (so don't go rewriting your code assuming it's equivalent!), but in the case where the loop is a candidate for unrolling it works just fine. Imagine you had a more CPU- or memory-bound workload, and these benchmarks are a whole lot more interesting.
Put another way: if there's an RPC call in the for loop, the time spent in the RPC will dwarf the work involved in executing loop itself so ... odds are good it's not going to be a candidate for unrolling anyways. :)
This is of no real consequence except curiosity, but I'm at a loss to understand what "park" means in the title.
I don't even know what sense of the word is intended. Is it "park" like a city or amusement park that you visit, and the idea is that you enjoy a variety of different activities while you're there? Is it "park" like a ballpark, and the analogy is that sporting events take place there and each one of these topics is an event? Is it somehow "park" like a parking lot? Maybe "park" is a too-literal translation from another language where the corresponding word has a meaning that the English one doesn't?
I'm trying to guess based on context, but none of these really seems to fit.
Besides being interesting in itself, this is the best collection of examples I've seen for JMH. When I looked last the official documentation was a bit thin, and most articles on it just included an unmotivated hello world example.
I was skeptical at first as well, but your own stats show a different picture: the site gets a lot of views, which correlates with the upvotes. No comments is probably due to the fact that people use upvoting as a mechanism to save links to material (which might be of use later)
My take: not everyone has time to read this right now. I use upvote to "bookmark", and I expect not everyone here use Java. I am not, but I intend to give it a round at some point.
[+] [-] kondor6c|8 years ago|reply
This reminds me when the Java Pub House did a few podcasts on Garbage Collections and performance (http://www.javapubhouse.com/2012/04/episode-22-garbage-man-i...)
[+] [-] jonahx|8 years ago|reply
Would also love details on the author's workflow and automation behind this.
[+] [-] zanker_swe|8 years ago|reply
" for (...) { synchronized (obj) { // something } }
…could it optimize into this?
synchronized (this) { for (...) { <----XXX---- // something } } "
The answer would be no in general, I think, since it is unsafe.
Moving the entire loop into the synchronized block would make the statement marked XXX above, i.e. "for (...)" execute inside the synchronized block, which has the potential to change the semantics (for example, the statement may include an rpc, and we don't want to make that rpc under the lock).
The earlier optimization of
synchronized (this) { statement1; }
synchronized (this) { statement2; }
to
synchronized (this) { statement1; statement2; }
is safe.
[+] [-] chrisseaton|8 years ago|reply
That's not change in semantics. The JVM doesn't provide any guarantees about parallelism or scheduling semantics in the first place so how can you possibly argue about the semantics of holding a lock too long?
And it's unsafe? For what definition of safety?
But in practice - yes you obviously wouldn't do this if the code in the loop control code had any side effects.
[+] [-] thomaslee|8 years ago|reply
I do agree that it's not a "safe" optimization in the extreme general case (so don't go rewriting your code assuming it's equivalent!), but in the case where the loop is a candidate for unrolling it works just fine. Imagine you had a more CPU- or memory-bound workload, and these benchmarks are a whole lot more interesting.
Put another way: if there's an RPC call in the for loop, the time spent in the RPC will dwarf the work involved in executing loop itself so ... odds are good it's not going to be a candidate for unrolling anyways. :)
[+] [-] endoplasm|8 years ago|reply
[+] [-] adrianmonk|8 years ago|reply
I don't even know what sense of the word is intended. Is it "park" like a city or amusement park that you visit, and the idea is that you enjoy a variety of different activities while you're there? Is it "park" like a ballpark, and the analogy is that sporting events take place there and each one of these topics is an event? Is it somehow "park" like a parking lot? Maybe "park" is a too-literal translation from another language where the corresponding word has a meaning that the English one doesn't?
I'm trying to guess based on context, but none of these really seems to fit.
[+] [-] leodeid|8 years ago|reply
[+] [-] Flenser|8 years ago|reply
[+] [-] tveita|8 years ago|reply
[+] [-] zerr|8 years ago|reply
[+] [-] SamPutnam|8 years ago|reply
[+] [-] bdcravens|8 years ago|reply
[+] [-] baxtr|8 years ago|reply
[+] [-] gok|8 years ago|reply
[+] [-] yeukhon|8 years ago|reply
[+] [-] johnfn|8 years ago|reply