instructions reordering in java - practical check tools/principals/papers

classic Classic list List threaded Threaded
4 messages Options
DT
Reply | Threaded
Open this post in threaded view
|

instructions reordering in java - practical check tools/principals/papers

DT
What would be a good way or tools to check of the reordering of
instructions in java starting from java code-> compiler ->jvm reordering
->processor reordering?


Thanks,
DT
_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: instructions reordering in java - practical check tools/principals/papers

Daniel Mitterdorfer
Hi,

I am not sure what you want to do but you might want to look into JITWatch [1] written by Chris Newland. It presents Java code, along with byte code instructions and generated assembly instructions. This might be a starting point for your analysis.

Bye,

Daniel

[1] JITWatch: https://github.com/AdoptOpenJDK/jitwatch

2014-12-31 4:14 GMT+01:00 DT <[hidden email]>:
What would be a good way or tools to check of the reordering of instructions in java starting from java code-> compiler ->jvm reordering ->processor reordering?


Thanks,
DT
_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
DT
Reply | Threaded
Open this post in threaded view
|

Re: instructions reordering in java - practical check tools/principals/papers

DT
I am not sure if this is the right way to explore this question, but thought it would be interesting to see  how byte code execution (opcodes) can be checked for reordering through entire cycle up to the processor.
For instance, there are two opcodes, monitorEnter and monitorExist, but in terms of synchronization constructions we have  semaphores, reentrantlocks, synchronized stmts, etc. so we should analyze different opcode combinations based on the synchronization construct and influence on the jvm execution of those opcodes to be able to understand if there are any issues.
Then, once we see how jvm is performing, the next step would be to compare whether  there is any difference in program behavior based on the specific garbage collector and cpu architecture.


On 1/6/2015 10:54 AM, Daniel Mitterdorfer wrote:
Hi,

I am not sure what you want to do but you might want to look into JITWatch [1] written by Chris Newland. It presents Java code, along with byte code instructions and generated assembly instructions. This might be a starting point for your analysis.

Bye,

Daniel

[1] JITWatch: https://github.com/AdoptOpenJDK/jitwatch

2014-12-31 4:14 GMT+01:00 DT <[hidden email]>:
What would be a good way or tools to check of the reordering of instructions in java starting from java code-> compiler ->jvm reordering ->processor reordering?


Thanks,
DT
_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest



_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: instructions reordering in java - practical check tools/principals/papers

Daniel Mitterdorfer
Hi,

you can follow such reorderings down to assembly level with JITWatch as its assembly view is based on HotSpot's assembly log output (see also [1]). Beyond that level it can get a bit tricky. :)

Regarding your concrete example with synchronization: As far as I am aware, the high level abstractions in j.u.c are mostly built on top of methods in sun.misc.Unsafe so you need to look for calls to sun.misc.Unsafe instead of monitorenter and monitorexit. As HotSpot implements some optimizations regarding locks (see [2]) you should expect that synchronization code might be eliminated alltogether after the JIT compiler is done (see [3]).

If you are interested in implementation guidance of synchronization primitives on JVM level you can look into Doug Lea's "JSR-133 Cookbook for Compiler Writers" [4] and want to continue with some articles on specifics like "NOOP Memory Barriers on x86 are NOT FREE " by Nitsan Wakart [5]. Last but not least you can also look into the OpenJDK source code [6].

Bye,

Daniel

2015-01-07 6:21 GMT+01:00 DT <[hidden email]>:
I am not sure if this is the right way to explore this question, but thought it would be interesting to see  how byte code execution (opcodes) can be checked for reordering through entire cycle up to the processor.
For instance, there are two opcodes, monitorEnter and monitorExist, but in terms of synchronization constructions we have  semaphores, reentrantlocks, synchronized stmts, etc. so we should analyze different opcode combinations based on the synchronization construct and influence on the jvm execution of those opcodes to be able to understand if there are any issues.
Then, once we see how jvm is performing, the next step would be to compare whether  there is any difference in program behavior based on the specific garbage collector and cpu architecture.


On 1/6/2015 10:54 AM, Daniel Mitterdorfer wrote:
Hi,

I am not sure what you want to do but you might want to look into JITWatch [1] written by Chris Newland. It presents Java code, along with byte code instructions and generated assembly instructions. This might be a starting point for your analysis.

Bye,

Daniel

[1] JITWatch: https://github.com/AdoptOpenJDK/jitwatch

2014-12-31 4:14 GMT+01:00 DT <[hidden email]>:
What would be a good way or tools to check of the reordering of instructions in java starting from java code-> compiler ->jvm reordering ->processor reordering?


Thanks,
DT
_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest




_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest