On Mon, Jun 22, 2009 at 10:09 PM, Jason King<[email protected]> wrote: > 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). >
I just reread the original post (wasn't visible with all the other threads) and just noticed I confused units on the original times, my apologies :) Still might be worth trying it just to see. _______________________________________________ opensolaris-discuss mailing list [email protected]
