On 7/05/2013 7:43 PM, 云达(Yunda) wrote:
Hi David,
Thanks for the review and I see your concern. Please see the updated change
below:
diff -r 627cf9e9ea31 src/share/vm/runtime/globals.hpp
--- a/src/share/vm/runtime/globals.hpp Mon May 06 10:29:49 2013 -0700
+++ b/src/share/vm/runtime/globals.hpp Tue May 07 17:38:58 2013 +0800
@@ -3634,7 +3634,10 @@
"Include GC cause in GC logging") \
\
product(bool, EnableTracing, false, \
- "Enable event-based tracing")
+ "Enable event-based tracing") \
+ \
+ product(bool, UseLockedTracing, false, \
+ "Use locked-tracing when doing event-based tracing")
/*
* Macros for factoring of globals
diff -r 627cf9e9ea31 src/share/vm/trace/traceEventClasses.xsl
--- a/src/share/vm/trace/traceEventClasses.xsl Mon May 06 10:29:49 2013 -0700
+++ b/src/share/vm/trace/traceEventClasses.xsl Tue May 07 17:38:58 2013 +0800
@@ -132,6 +132,9 @@
void writeEvent(void) {
ResourceMark rm;
HandleMark hm;
+ if (UseLockedTracing) {
+ ttyLocker ttyl;
+ }
Ah that doesn't work - the ttyLocker is block-scoped by the if statement
so it will be created, grab the lock, then immediately be destructed and
the lock released.
David
-----
TraceStream ts(*tty);
ts.print("<xsl:value-of select="@label"/>: [");
<xsl:apply-templates select="value|structvalue" mode="write-data"/>
Regards,
Yunda
-----Original Message-----
From: David Holmes [mailto:[email protected]]
Sent: Tuesday, May 07, 2013 10:39 AM
To: 云达(Yunda)
Cc: [email protected];
[email protected]
Subject: Re: [PATCH] EnableTracing: output from multiple threads may be mixed
together
Hi Yunda,
There is a potential problem with using a ttyLocker here, depending on exactly
what events are being traced and from where - you must always be in code
where it is both safe to acquire the lock, and safe to block waiting for the
lock if
it is not available.
I think I would prefer to see unlocked tracing by default with a flag to use
locked-tracing if requested.
David
On 19/04/2013 6:26 PM, 云达(Yunda) wrote:
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
thisJ
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.
本电邮(包括任何附件)可能含有机密资料并受法律保护。如您不是正确的
收件人，
请您立即删除本邮件。请不要将本电邮进行复制并用作任何其他用途、
或透露本邮
件之内容。谢谢。
________________________________
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.
本电邮(包括任何附件)可能含有机密资料并受法律保护。如您不是正确的收件人，请您立即删除本邮件。请不要将本电邮进行复制并用作任何其他用途、或透露本邮件之内容。谢谢。
