Trying to Find the Source

I’m still trying to find the source of the synchronization points that only appear at the beginning during recording. I have created a few more, very simple test files to gain an understanding of what sync points belong to what portion of the code.

The program

public static void main(String[] args) {
synchronized(OneSyncBlockTest.class) {
}
}

produces a whole bunch of sync points, but during the recording phase, the last sync points are “1 0; 2 0”, as expected. During replay, the only sync points generated by thread 0 are “1 0; 2 0; 1 0; 2 0”, followed by “1 9; 2 9; 1 9; 1 9; 2 9; 1 9; 2 9; 2 9”. I don’t yet know what thread 9 does or why there’s a “1 0; 2 0” preceding the expected sync points.

A more complicated program with nested synchronized blocks,

public static void main(String[] args) {
synchronized(FewSyncBlockTest.class) {
}
synchronized(FewSyncBlockTest.class) {
synchronized(args) {
}
}
synchronized(args) {
}
}

produces sync points during recording that end with “1 0; 2 0; 1 0; 1 0; 2 0; 2 0; 1 0; 2 0”, as expected. During replay, we get the same sync points, again preceded by a “1 0; 2 0” and followed by sync points by thread 9.

Interestingly, the most trivial program,

public static void main(String[] args) {
}

with an empty main method doesn’t produce any valid sync points: The main method is never entered!

Unfortunately, so far I haven’t been able to figure out where the extraneous sync points are coming from. I will now add more debug information to the compact representation. In addition to code and thread ID, I will add a long that represents the index of the class in a list of instrumented classes (0 will be the first class, 1 the next, etc.), and another long to point me to the method within the class. All of this can be inserted directly into the bytecode as constants, without having to change the constant pool. Hopefully that will provide some more information.

Update

I just noticed I was wrong; the long constants for the class and method indices have to be added to the constant pool. That shouldn’t be a problem though.

Share

About Mathias

Software development engineer. Principal developer of DrJava. Recent Ph.D. graduate from the Department of Computer Science at Rice University.
This entry was posted in Concurrent Unit Testing. Bookmark the permalink.

Leave a Reply