On Mon, Jun 22, 2009 at 9:40 PM, Charles Hedrick<[email protected]> wrote: > Thanks for the suggestions. I'm using u14. (Actually I think I'm using 1.7 at > this moment, but normally 1.6.0u14.) We're moving to u14 in production, in > hopes of beginning to test G1. (We're going to be *very* conservative about > that though.) On our production systems we've had a bit too many long GC > pauses. I'm hoping G1 will help us with that. Of course it may be that just > going from 1.5 to 1.6 will be enough. (We're just in the process of that now.) > > It doesn't look like a lock issue: > > plockstat: pid 2952 has exited > > Mutex block > > Count nsec Lock Caller > ------------------------------------------------------------------------------- > 10 209803 libc.so.1`libc_malloc_lock > libjava.so`JNU_GetStringPlatformChars+0x4d0 > 20 72016 libc.so.1`libc_malloc_lock > libjava.so`JNU_ReleaseStringPlatformChars+0x1e > 50 27446 libc.so.1`libc_malloc_lock libjvm.so`__1cCosEfree6Fpv_v_+0x1e > 24 27960 libc.so.1`libc_malloc_lock libzip.so`zcfree+0x1e > 12 25816 libc.so.1`libc_malloc_lock > libjvm.so`__1cCosGmalloc6FI_pv_+0x2e > 5 26522 libc.so.1`libc_malloc_lock libverify.so`verify_method+0x99a > 2 55999 libc.so.1`libc_malloc_lock > libzip.so`Java_java_util_zip_Inflater_inflateBytes+0xb4 > 6 17213 libc.so.1`libc_malloc_lock libzip.so`freeZip+0x93 > 5 18190 libc.so.1`libc_malloc_lock libzip.so`freeMetaNames+0x3b > 1 85590 libc.so.1`libc_malloc_lock > libverify.so`VerifyClassForMajorVersion+0x46c > 1 50780 libc.so.1`libc_malloc_lock > libzip.so`Java_java_util_zip_Deflater_deflateBytes+0x1b7 > 2 24013 libc.so.1`libc_malloc_lock > libverify.so`signature_to_fieldtype+0x93b > 2 20947 libc.so.1`libc_malloc_lock > libverify.so`VerifyClassForMajorVersion+0x306 > 2 20475 libc.so.1`libc_malloc_lock > libzip.so`Java_java_util_zip_Deflater_deflateBytes+0x101 > 1 39596 libc.so.1`libc_malloc_lock libverify.so`CCinit+0x22 > 1 39205 libc.so.1`libc_malloc_lock libverify.so`class_to_ID+0x74d > 1 37187 libc.so.1`libc_malloc_lock libverify.so`class_name_to_ID+0x323 > 1 37001 libc.so.1`libc_malloc_lock libc.so.1`calloc+0x4c > 4 8815 libc.so.1`libc_malloc_lock libzip.so`ZIP_FreeEntry+0x48 > 1 32371 libc.so.1`libc_malloc_lock libzip.so`ZIP_FreeEntry+0x7c > 4 4338 libc.so.1`libc_malloc_lock > libzip.so`Java_java_util_zip_Inflater_end+0x2e > 1 17218 libc.so.1`libc_malloc_lock libCrun.so.1`__1c2n6FI_pv_+0x38 > 1 10798 libc.so.1`libc_malloc_lock > libverify.so`VerifyClassForMajorVersion+0x54d > 1 10341 libc.so.1`libc_malloc_lock libjava.so`readBytes+0x17f > 1 10170 libc.so.1`libc_malloc_lock libzip.so`freeCEN+0x21 > 1 9553 libc.so.1`libc_malloc_lock libzip.so`newEntry+0x1f > 1 9060 libc.so.1`libc_malloc_lock libzip.so`freeMetaNames+0x5b > 1 8116 libc.so.1`libc_malloc_lock > libverify.so`cp_index_to_class_fullinfo+0x6c2 > 1 3288 libc.so.1`libc_malloc_lock > libverify.so`VerifyClassForMajorVersion+0xb48
How long did it run, and how many threads? The original post suggests a 5 second runtime. Unless I'm forgetting the meaning of the output values from plockstat, that's almost a whole second (900msec) of blocking on the libc malloc lock (all by various callers, but the same lock). If the code is only running for 5 seconds, that seems significant (though depends on how many threads). try doing "LD_PRELOAD=libmtmalloc.so java ....." and "LD_PRELOAD=libumem.so java ...." to run your commands and see how each fares (each has different pathological cases so if you can, doesn't hurt to see if one does better than the other). _______________________________________________ opensolaris-discuss mailing list [email protected]
