Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

JVM Anatomy Park

shipilev.net

Post reply on HN
Print view View original

31–33 of 33 posts

Re: JVM Anatomy Park

#31

Post by zanker_swe »

zanker_swe wrote: post #29
chrisseaton wrote: post #28

Earlier quoted context omitted.

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: synchronized(this) { a = AcquireLock(); for(c = 0; c which is inline with what the blog post was proposing. To repeat the blog is a question: for (...) { synchronized (obj) { // something } } …​could it optimize into this? synchronized (this) { for (...) { // something } } My answer to that is in general, no.

> 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.

Re: JVM Anatomy Park

#32

Post by tveita »

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.

Re: JVM Anatomy Park

#33

Post by tetha »

zanker_swe wrote: post #25
chrisseaton wrote: post #19

Earlier quoted context omitted.

> 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…

>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: synchronized(this) { a(); b(); } c(); synchronized(this) { d(); e(); } It would be unsafe (in general) to transform the above code to synchronized(this) { a(); b(); c(); d(); e(); } Simply because Compiler does not know (again, in general) what may happen during the execution of c(). How…

Look at it in smaller transformations. Compiler optimizations are kinda like algebra - many small structured steps result in hard, large changes.

  for(a = AcquireLock(), c = 0; c
Per definition of the for-loop, that's the same as:

  a = AcquireLock();
  c = 0;
  while (c
From there, you can deduce: 'c 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.
Post reply on HN