Lots of threads blocking on Waiting for a lock on java.util.WeakHashMap

[herbie.w...@gmail.com]

Hi Guys

I recently upgraded from JAN 3.4.0 to JNA 3.5.1 with GStreamer-Java and Java 7 (Java HotSpot(TM) 64-Bit Server VM (build 23.21-b01, mixed mode)).  When runninng under a light load system Im also seeing a lot of threads blocking on the same java.util.WeakHashMap.

All the Jstack show that they are blocked in different methods with the com.sun.jna.Structure class.

Se below for a couple of samples frame.

Is there any issues with these lookups under load that you maybe aware of?

I

"Thread-4565071" prio=10 tid=0x000000002f635000 nid=0x6bde waiting for monitor entry [0x00007fe44c936000]

   java.lang.Thread.State: BLOCKED (on object monitor)

    at com.sun.jna.Native.getTypeMapper(Native.java:464)

    - waiting to lock <0x000000077ae2aef0> (a java.util.WeakHashMap)

    at com.sun.jna.Structure.initializeTypeMapper(Structure.java:230)

    at com.sun.jna.Structure.<init>(Structure.java:185)

    at com.sun.jna.Structure.<init>(Structure.java:180)

    at com.sun.jna.Structure.<init>(Structure.java:167)

    at com.sun.jna.Structure.<init>(Structure.java:159)

    at org.gstreamer.lowlevel.GstBufferAPI$BufferStruct.<init>(GstBufferAPI.java:67)

    at org.gstreamer.Buffer.<init>(Buffer.java:100)

    at sun.reflect.GeneratedConstructorAccessor21.newInstance(Unknown Source)

    at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)

    at java.lang.reflect.Constructor.newInstance(Constructor.java:525)

    at org.gstreamer.lowlevel.NativeObject.objectFor(NativeObject.java:191)

    at org.gstreamer.lowlevel.GTypeMapper$3.fromNative(GTypeMapper.java:129)

    at com.sun.jna.CallbackReference$DefaultCallbackProxy.invokeCallback(CallbackReference.java:444)

    at com.sun.jna.CallbackReference$DefaultCallbackProxy.callback(CallbackReference.java:485)

"Thread-4565051" prio=10 tid=0x000000002ecdf000 nid=0x6ad8 waiting for monitor entry [0x00007fe459905000]

   java.lang.Thread.State: BLOCKED (on object monitor)

    at com.sun.jna.Native.getStructureAlignment(Native.java:498)

    - waiting to lock <0x000000077ae2aef0> (a java.util.WeakHashMap)

    at com.sun.jna.Structure.setAlignType(Structure.java:260)

    at com.sun.jna.Structure.<init>(Structure.java:184)

    at com.sun.jna.Structure.<init>(Structure.java:180)

    at com.sun.jna.Structure.<init>(Structure.java:167)

    at com.sun.jna.Structure.<init>(Structure.java:159)

    at org.gstreamer.lowlevel.GstMiniObjectAPI$MiniObjectStruct.<init>(GstMiniObjectAPI.java:54)

    at sun.reflect.GeneratedConstructorAccessor19.newInstance(Unknown Source)

    at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)

    at java.lang.reflect.Constructor.newInstance(Constructor.java:525)

    at java.lang.Class.newInstance0(Class.java:374)

    at java.lang.Class.newInstance(Class.java:327)

    at com.sun.jna.Structure.newInstance(Structure.java:1491)

    at com.sun.jna.Native.getNativeSize(Native.java:984)

    at com.sun.jna.Structure.getNativeSize(Structure.java:1769)

    at com.sun.jna.Structure.getNativeSize(Structure.java:1762)

    at com.sun.jna.Structure.validateField(Structure.java:958)

Thanks

[Timothy Wall]

I'm not aware of anything specifically, although the caching on that stuff could probably use some improvement.

You can avoid the type mapper lookup and the alignment lookup by explicitly setting those things in your structure constructor; set a no-op type mapper and ALIGN_GNUC or ALIGN_MSVC; those will avoid the WeakHashMap lookups.

I'll put in some changes to 4.0 to improve the caching to reduce contention once the values have been cached.

Are you using callback thread initializers or Native.detach(false) for these threads? If not, you may be seeing a lot of Java Thread churn as the native threads are mapped and re-mapped.

> --
> You received this message because you are subscribed to the Google Groups "Java Native Access" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to jna-users+...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

[herbie.w...@gmail.com]

Tim

Thanks for your response, I can take a look at your comments above for GStreamer-java.

I notice that these method hold the lock for a long period of time after the lookup is done.  Im referring to the method for example of public static Map getLibraryOptions(Class type) Native.java, which is static and synchronzes on the static map libraries (Map libraries = new WeakHashMap()).

Question is why we hold the lock for so long? Is this deliberate. Cant we look up and release the lock much quicker?

Thanks

[Timothy Wall]

It's not clear to me why the lock should be held, unless the instantiation of an interface (which is the longest potential operation in the mix) causes some sort of a deadlock.