JVM Anatomy Park(shipilev.net)
shipilev.net
JVM Anatomy Park
https://shipilev.net/jvm-anatomy-park/
32 comments
Regarding the question in the 1st topic: (https://shipilev.net/jvm-anatomy-park/1-lock-coarsening-for-...)
" 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.
" 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.
> 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.
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.
>And it's unsafe? For what definition of safety?
Let me try to answer with an example. Let us say, we have original code like this:
For the for loop, an example of code where pulling the synchronized statement out of the loop is problematic:
Let me try to answer with an example. Let us say, we have original code like this:
synchronized(this) {
a();
b();
}
c();
synchronized(this) {
d();
e();
}
synchronized(this) {
a();
b();
c();
d();
e();
}
synchronized(this) {
p();
q();
}
synchronized(this) {
r();
s();
}
synchronized(this) {
p();
q();
r();
s();
}
For the for loop, an example of code where pulling the synchronized statement out of the loop is problematic:
for(a = AcquireLock(), c = 0; c < 100; c++) {
synchronized(this) {
f();
}
}
ReleaseLock(a);
a = AcquireLock();
synchronized(this) {
for(c = 0; c < 100; c++) {
f();
}
}
ReleaseLock(a);
Look at it in smaller transformations. Compiler optimizations are kinda like algebra - many small structured steps result in hard, large changes.
Interestingly enough, if you'd talk about 'f(c = 0, g(); c < 100; c++)', the optimizations above might be impossible because you don't know if the call to g modifies c. Unless you can inline g, so you can re-arrange instructions again.
for(a = AcquireLock(), c = 0; c < 100; c++) {
synchronized(this) {
f();
}
}
ReleaseLock(a);
a = AcquireLock();
c = 0;
while (c < 100) {
synchronized(this) { f(); }
c++;
}
ReleaseLock(a);
Interestingly enough, if you'd talk about 'f(c = 0, g(); c < 100; c++)', the optimizations above might be impossible because you don't know if the call to g modifies c. Unless you can inline g, so you can re-arrange instructions again.
Just looking at your final example, I can't understand how you can say that is unsafe. How would anyone be able to tell the difference between the two? I think anything you tell me I'm just going to be able to answer 'but Java never guaranteed you that in the first place'. If nobody can tell the difference then how can it be unsafe?
>Just looking at your final example, I can't understand how you can say that is unsafe
Let me change the example a bit. Say we have two locks aL and bL, that we must always acquire in the order aL first and then bL.
Following the rule, say we write code like this:
Let me change the example a bit. Say we have two locks aL and bL, that we must always acquire in the order aL first and then bL.
Following the rule, say we write code like this:
import java.util.concurrent.locks.ReentrantLock;
class X {
private static ReentrantLock aL = new ReentrantLock();
private static ReentrantLock bL = new ReentrantLock();
static int x = 0;
static int c = 0;
static public void main(String[] args) {
for(aL.lock(); c < 100; c++) {
synchronized(bL) {
x = x + 0x42;
}
}
aL.unlock();
}
}
import java.util.concurrent.locks.ReentrantLock;
class X {
private static ReentrantLock aL = new ReentrantLock();
private static ReentrantLock bL = new ReentrantLock();
static int x = 0;
static int c = 0;
static public void main(String[] args) {
synchronized(bL) {
for(aL.lock(); c < 100; c++) {
x = x + 0x42;
}
aL.unlock();
} // end synnchronized
}
}
But that's just a different example to the one you gave before. In your previous example acquiring the explicit lock always came before the start of synchronised block, both before and after the rewrite. You've changed it here so it's a different question.
Sorry, I meant to write:
To repeat the blog is a question:
synchronized(this) {
a = AcquireLock();
for(c = 0; c < 100; c++) {
f();
}
}
ReleaseLock(a);
To repeat the blog is a question:
for (...) {
synchronized (obj) {
// something
}
}
synchronized (this) {
for (...) {
// something
}
}
You mean because ... could be code that can detect whether or not the monitor is held?
Yes, but I think it's an assumption so obvious as to be not worth stating that the author means as long as ... does not do that.
Yes, but I think it's an assumption so obvious as to be not worth stating that the author means as long as ... does not do that.
> My answer to that is in general, no.
Because '...' can include arbitrary side-effect inducing statements that can't be moved around without affecting the behavior. As the poster discovered.
Because '...' can include arbitrary side-effect inducing statements that can't be moved around without affecting the behavior. As the poster discovered.
> 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. :)
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. :)
Neither of those optimizations looks safe to me. Couldn't they potentially introduce deadlocks?
I had the same reaction, but now I'm starting to suspect it actually is safe, for a reason that's not immediately obvious.
Consider the unoptimized version. It's possible that after you release the lock, another thread will take it. But I'm pretty confident there is no guarantee of this, and your own thread might immediately take the lock back. (Probably often, especially if there's just one CPU.) If taking the lock back immediately causes a deadlock, then your code is already broken as written.
So you already must account for the possibility that nothing changes between the time you release the lock and take it again. All the optimization does is take away the _other_ possibility, which was something you couldn't rely on anyway.
Consider the unoptimized version. It's possible that after you release the lock, another thread will take it. But I'm pretty confident there is no guarantee of this, and your own thread might immediately take the lock back. (Probably often, especially if there's just one CPU.) If taking the lock back immediately causes a deadlock, then your code is already broken as written.
So you already must account for the possibility that nothing changes between the time you release the lock and take it again. All the optimization does is take away the _other_ possibility, which was something you couldn't rely on anyway.
Yes, you're right. The definition of an optimization being ``safe'' is tricky in the presence of non-determinism.
The set of possible executions of a correctly optimized program should be a subset of---and specifically, need not be necessarily equal to---the possible executions of the original unoptimized version.
The set of possible executions of a correctly optimized program should be a subset of---and specifically, need not be necessarily equal to---the possible executions of the original unoptimized version.
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.
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.
Maybe it is a reference to the Rick and Morty episode "Anatomy Park". http://rickandmorty.wikia.com/wiki/Anatomy_Park_(episode)
Oh, that has to be it! So it's just a reference I didn't understand.
Could be as in wildlife park.
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.
Why PDF is so large?
7k views, 155 upvotes, 1 comment...
I peek at articles all the time without upvoting, and upvote articles without commenting all the time.
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)
To clarify, I don't think this is improper use of the upvote mechanism, I was just hoping for more engagement with the comment feature of Hacker News, given the 7k click thrus.
Half the upvotes are probably for the Rick and Morty reference.
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.
How do you know it has 7K views?
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...)