[PATCH] EnableTracing: output from multiple threads may be mixed together

Kirk Pepperdine kirk at kodewerk.com
Thu May 2 06:49:11 PDT 2013


Hi Yunda,

Sorry for not being clear about this. The CMS collector injects records into the middle of young gen (ParNew/DefNew) collections. Sorry for the noise but this is due to a different issue in how logging is performed.

Regards,
Kirk

On 2013-05-02, at 3:42 PM, 云达(Yunda) <yunda.mly at taobao.com> wrote:

> Kirk,
> 
> I'm not quite clear what "the other mixed up log files" means, since when using EnableTracing the output uses stdout by default.
> 
> 
> Regards,
> Yunda
> ________________________________________
> From: Kirk Pepperdine [kirk at kodewerk.com]
> Sent: Thursday, May 02, 2013 21:05
> To: Staffan Larsen
> Cc: 云达(Yunda); serviceability-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net
> Subject: Re: [PATCH] EnableTracing: output from multiple threads may be mixed together
> 
> What effect with this have on the other mixed up log files?
> 
> Regards,
> Kirk
> 
> On 2013-05-02, at 2:57 PM, Staffan Larsen <staffan.larsen at oracle.com<mailto:staffan.larsen at oracle.com>> wrote:
> 
> Looks good. (not a reviewer)
> 
> /Staffan
> 
> On 2 maj 2013, at 05:07, 云达(Yunda) <yunda.mly at taobao.com<mailto:yunda.mly at taobao.com>> wrote:
> 
> Could anyone review this for me, please?
> 
> Regards,
> Yunda
> 
> From: 云达(Yunda)
> Sent: Friday, April 19, 2013 4:26 PM
> To: hotspot-runtime-dev at openjdk.java.net<mailto:hotspot-runtime-dev at openjdk.java.net>; serviceability-dev at openjdk.java.net<mailto:serviceability-dev at openjdk.java.net>
> Subject: [PATCH] EnableTracing: output from multiple threads may be mixed together
> 
> Hi all,
> 
> I found that the output from multiple threads may be mixed together when using EnableTracing. It happens many times in my test case like this:
> 
> Allocation outside TLAB: [Allocation in new TLAB: [Allocation in new TLAB: [Allocation in new TLAB: [Class = [C, Allocation in new TLAB: [Class = [I, Allocation in new TLAB: [Java Monitor Wait: [Class = java/lang/String, Allocation Size = 24, Allocation Size = 24, Class = java/lang/String, Class = [I, Allocation in new TLAB: [Class = [C, Allocation in new TLAB: [Allocation Size = 192]
> Class = com/sun/org/apache/xerces/internal/dom/DeferredElementNSImpl, Allocation Size = 24, Allocation Size = 24, TLAB Size = 23712280]
> TLAB Size = 24607080]
> Allocation Size = 24, Monitor Class = java/lang/ref/Reference$Lock, TLAB Size = 25054480]
> TLAB Size = 25054480]
> Allocation in new TLAB: [Class = [CTLAB Size = 24607080]
> Allocation Size = 72, Class = [C, TLAB Size = 24159728]
> , Allocation Size = 32, TLAB Size = 23712288]
> 
> It's very confusing and it's even not easy to tell how many events there are. I think the reason is that the writeEvent() method of each Event* class output the fields of event one by one without using any lock. So I made a small patch which add ttyLocker to writeEvent() method and after applying this patch there's no output mixed together in my test case(against http://hg.openjdk.java.net/hsx/hsx24/hotspot/):
> diff -r edd1619a3ae4 src/share/vm/trace/traceEventClasses.xsl
> --- a/src/share/vm/trace/traceEventClasses.xsl    Thu Apr 18 13:50:58 2013 -0700
> +++ b/src/share/vm/trace/traceEventClasses.xsl Fri Apr 19 16:12:38 2013 +0800
> @@ -132,6 +132,7 @@
>   void writeEvent(void) {
>     ResourceMark rm;
>     HandleMark hm;
> +    ttyLocker ttyl;
>     TraceStream ts(*tty);
>     ts.print("<xsl:value-of select="@label"/>: [");
> <xsl:apply-templates select="value|structvalue" mode="write-data"/>
> 
> 
> I searched before sending this mail I didn't find anyone who covering this☺
> 
> Regards,
> Yunda
> 
> 
> ________________________________
> 
> This email (including any attachments) is confidential and may be legally privileged. If you received this email in error, please delete it immediately and do not copy it or use it for any purpose or disclose its contents to any other person. Thank you.
> 
> 本电邮(包括任何附件)可能含有机密资料并受法律保护。如您不是正确的收件人,请您立即删除本邮件。请不要将本电邮进行复制并用作任何其他用途、或透露本邮件之内容。谢谢。
> 
> 



More information about the serviceability-dev mailing list