Before WAS 8.5, the "thread ID" printed in WAS logs (the hexadecimal number after the timestamp) comes from the java/util/logging/LogRecord.getThreadID method. This number was not in javacores, so there was no easy way to correlate javacores with log and trace messages. Moreover, this thread ID was different from java/lang/Thread.getID which might be printed in other components, and that thread ID also wasn't in javacores. (Note: see Mapping Underlying Java Thread Identifiers to those in Logging and Trace for a method to map these values using a system dump.)
WAS 8.5 has changed the ID printed in logs to the value from java/lang/Thread.getID. This can be changed back to the previous behavior using com.ibm.websphere.logging.useJULThreadID=true. See: http://www14.software.ibm.com/webapp/wsbroker/redirect?version=phil&product=was-nd-mp&topic=rtrb_readmsglogs. This was also backported to WAS 126.96.36.199 (PM60913); however, it must be explicitly enabled.
With IBM Java 6 SR12 (WAS 188.8.131.52), IBM Java 626 SR4 (WAS 184.108.40.206, 220.127.116.11, 18.104.22.168), and IBM Java 7 SR3 (WAS 22.214.171.124, 126.96.36.199), javacores will have the value of Thread.getID printed with each stack. Given the above change, this allows you to correlate WAS log messages with javacores (note the bold and underlined parts):
[8/22/12 10:00:05:049 PDT] 0000005b SystemOut O swat.ear: Calling com.ibm.jvm.Dump.JavaDump()... Thread.getId=0x5b 3XMTHREADINFO "WebContainer : 1" J9VMThread:0x0000000012593E00, j9thread_t:0x00007F7F542C6FF0, java/lang/Thread:0x00000000104FEE78, state:R, prio=5 3XMJAVALTHREAD (java/lang/Thread getId:0x5B, isDaemon:true) 3XMTHREADINFO1 (native thread ID:0x5859, native priority:0x5, native policy:UNKNOWN) 3XMTHREADINFO2 (native stack address range from:0x00007F8031226000, to:0x00007F8031267000, size:0x41000) 3XMHEAPALLOC Heap bytes allocated since last GC cycle=2132320 (0x208960) 3XMTHREADINFO3 Java callstack: 4XESTACKTRACE at com/ibm/jvm/Dump.JavaDumpImpl(Native Method)