The Synchronized Native Problem

I haven’t done any serious tests with the synchronized method to block instrumentor, but even if everything checks out, there’s still a problem with synchronized native methods. Those have to be instrumented at the call site. I can’t think of a different way. Assume there is a method synchronized native void syncNative(). Then the call

1
2
3
...
syncNative();
...

will have to be changed into

1
2
3
4
5
...
synchronized(this) {
    syncNative();
}
...

where syncNative is not actually synchronized anymore. Then the synchronized block will have to be instrumented. This is still a different strategy than the one I used before. We’ll see how this goes.

Fortunately, the number of synchronized native methods is relatively small:

class com.sun.java.util.jar.pack.NativeUnpack:
   initIDs
   start
   getNextFile
   getUnusedInput
   finish
   setOption
   getOption

class sun.awt.DebugHelperImpl:
   printlnImpl
   printImpl
   setCTracingOn

class sun.awt.image.codec.JPEGImageDecoderImpl:
   readJPEGStream
   writeJPEGStream

class sun.awt.windows.WDefaultFontCharset:
   canConvert

class sun.awt.windows.WMenuItemPeer:
   _dispose

class sun.awt.windows.WRobotPeer:
   _dispose()

class sun.awt.windows.WScrollPanePeer:
   setScrollPosition
   setSpans

class java.net.PlainDatagramSocketImpl:
   bind0
   peek
   peekData
   receive0

class java.text.Bidi:
   nativeBidiChars

class sun.font.FileFontStrike:
   getNullScalerContext

class sun.awt.windows.WWindowPeer:
   reshapeFrame

class sun.font.Type1Font:
   getGlyphCode

class sun.font.TrueTypeFont:
   getGlyphPoint

class sun.font.FileFont:
   getNullScaler
   getFontMetrics
   getGlyphAdvance
   getGlyphMetrics
   getGlyphImage
   getGlyphOutlineBounds
   getGlyphOutline
   getGlyphVectorOutline

class sun.font.FontManager:
   getFontPath
   setNativeFontPath

class sun.awt.windows.WComponentPeer:
   pShow
   hide
   enable
   disable
   updateWindow
   reshape
   dispose
   setFont
   start

class java.io.WinNTFileSystem:
   deleteOnExit

class java.io.Win32FileSystem:
   deleteOnExit

class java.lang.Throwable:
   fillInStackTrace

Ugh. Relatively.

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