From yasuenag at gmail.com  Tue Mar  1 01:05:09 2016
From: yasuenag at gmail.com (Yasumasa Suenaga)
Date: Tue, 01 Mar 2016 10:05:09 +0900
Subject: PING: Check PerfCounter in core image through JSnap
In-Reply-To: <56C072B5.1090001@gmail.com>
References: <CAGFVN2AkKnzf=BT42Qdcq57FyiTAoz+Wajt56ASPv14RirnqnQ@mail.gmail.com>
	<56C072B5.1090001@gmail.com>
Message-ID: <56D4EAC5.8050702@gmail.com>

PING: Can I file this to JBS ?


On 2016/02/14 21:27, Yasumasa Suenaga wrote:
> Ping: What do you think about this issue?
>
> Yasumasa
>
> On 2016/02/08 19:17, Yasumasa Suenaga wrote:
>> Ping: Can I file it to JBS as new issue?
>>
>> Yasumasa
>>
>> 2016/01/30 23:08 "Yasumasa Suenaga" <yasuenag at gmail.com <mailto:yasuenag at gmail.com>>:
>>
>>     Hi all,
>>
>>     I want to check PerfCounter in core image to analyze state of crashed JVM.
>>     When I use JSnap tool, I encountered NPE on Fedora 23 x86_64.
>>
>>     I checked core image, and I found PerfMemory::_start, _top, etc are set to NULL,
>>     however, PerfMemory::_initialized is set to 1.
>>
>>     PerfMemory::_start is set to NULL in PerfMemory::destroy(), and this function
>>     is called at before aborting VM.
>>
>>     I fixed as below, and it works fine with JSnap:
>>     -------------------
>>     diff -r edfc9e2316e3 src/share/vm/runtime/perfMemory.cpp
>>     --- a/src/share/vm/runtime/perfMemory.cpp       Sun Jan 24 23:20:12 2016 +0900
>>     +++ b/src/share/vm/runtime/perfMemory.cpp       Sat Jan 30 22:41:05 2016 +0900
>>     @@ -196,12 +196,6 @@
>>           //
>>           delete_memory_region();
>>         }
>>     -
>>     -  _start = NULL;
>>     -  _end = NULL;
>>     -  _top = NULL;
>>     -  _prologue = NULL;
>>     -  _capacity = 0;
>>       }
>>
>>       // allocate an aligned block of memory from the PerfData memory
>>     -------------------
>>
>>     I found JDK-6224040: enhance jstat to extract counter information from core files .
>>     At least, we can control shared memory through coredump_filter in modern Linux kernel.
>>
>>     Should I work this fix in JDK-6224040 ? or another issue ?
>>     Please cooperate.
>>
>>
>>     Thanks,
>>
>>     Yasumasa
>>
>>

From yasuenag at gmail.com  Tue Mar  1 01:05:46 2016
From: yasuenag at gmail.com (Yasumasa Suenaga)
Date: Tue, 01 Mar 2016 10:05:46 +0900
Subject: PING: RFR: JDK-8148659: Add all option to JSnap
In-Reply-To: <56C072D4.9030409@gmail.com>
References: <CAGFVN2C8WGOE-SHFgZHkK0JKR7mzx-7dzhoOBMg+uoNKP=KShw@mail.gmail.com>
	<56C072D4.9030409@gmail.com>
Message-ID: <56D4EAEA.8010001@gmail.com>

PING: Could you review and sponsor?


On 2016/02/14 21:28, Yasumasa Suenaga wrote:
> Ping: Could you review?
>
> Yasumasa
>
>
> On 2016/02/08 19:19, Yasumasa Suenaga wrote:
>> Ping:  Could you review this change?
>>
>> Yasumasa
>>
>> 2016/01/31 0:48 "Yasumasa Suenaga" <yasuenag at gmail.com <mailto:yasuenag at gmail.com>>:
>>
>>     I want to add -a (all) option to JSnap because JSnap is very useful to analyze core image.
>>
>>     Currently, JSnap can show PerfDataEntry which namespace is java.* or com.sun.* .
>>     We can use jcmd with PerfCounter.print when we want to attach live process, however,
>>     as JDK-6224040 shows, we have to use JSnap.
>>
>>     In terms of core image analysis, -a option is very useful for troubleshooting.
>>
>>     I uploaded a webrev for this enhancement.
>>     Could you review it?
>>
>>     http://cr.openjdk.java.net/~ysuenaga/JDK-8148659/webrev.00/
>>
>>     I'm jdk9 committer, however I cannot access JPRT.
>>     So I need a sponsor.
>>
>>
>>     Thanks,
>>
>>     Yasumasa
>>

From david.holmes at oracle.com  Tue Mar  1 04:59:04 2016
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 1 Mar 2016 14:59:04 +1000
Subject: RFR: 8147456 Parsing of argument for -agentpath can write outside
	of allocated memory
In-Reply-To: <a80d0093-759b-4bbd-af65-8749580dae74@default>
References: <56AF85B7.9010805@oracle.com> <56B889D3.7010402@oracle.com>
	<56B8A3CE.3050107@oracle.com> <56B8A8C1.4010804@oracle.com>
	<56C32A38.3010400@oracle.com> <56CABCAD.1050006@oracle.com>
	<c0a44299-b229-4452-b84b-cc1c7cd2f707@default>
	<56CBB988.4040900@oracle.com>
	<a80d0093-759b-4bbd-af65-8749580dae74@default>
Message-ID: <56D52198.60506@oracle.com>

Hi Sharath,

On 1/03/2016 2:39 AM, Sharath Ballal wrote:
> Hi David,
> I have created a java testcase.  The webrev link is:
>
> http://cr.openjdk.java.net/~jbachorik/sponsorship/8147456/webrev.04/

Seems fine. Just fix the copyright year:

  Copyright (c) 2003, 2016,

Should only be 2016 for this new file.

Thanks,
David

>
> -Sharath Ballal
>
>
>
> -----Original Message-----
> From: David Holmes
> Sent: Tuesday, February 23, 2016 7:15 AM
> To: Sharath Ballal; serviceability-dev at openjdk.java.net
> Subject: Re: RFR: 8147456 Parsing of argument for -agentpath can write outside of allocated memory
>
> Hi Sharath,
>
> On 23/02/2016 12:59 AM, Sharath Ballal wrote:
>> Hi,
>>
>> Pls review the fix for the following bug.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8147456
>> Webrev:
>> http://cr.openjdk.java.net/~jbachorik/sponsorship/8147456/webrev.03/
>
> The functional fix seems fine.
>
> But for the test I understand we are moving away from using shell scripts, so can you please create a Java test using the Process* API's in the test library.
>
> Thanks,
> David
>
>> -Sharath Ballal
>>

From sharath.ballal at oracle.com  Tue Mar  1 05:17:24 2016
From: sharath.ballal at oracle.com (Sharath Ballal)
Date: Mon, 29 Feb 2016 21:17:24 -0800 (PST)
Subject: RFR: 8147456 Parsing of argument for -agentpath can write outside
	of allocated memory
In-Reply-To: <56D52198.60506@oracle.com>
References: <56AF85B7.9010805@oracle.com> <56B889D3.7010402@oracle.com>
	<56B8A3CE.3050107@oracle.com> <56B8A8C1.4010804@oracle.com>
	<56C32A38.3010400@oracle.com> <56CABCAD.1050006@oracle.com>
	<c0a44299-b229-4452-b84b-cc1c7cd2f707@default>
	<56CBB988.4040900@oracle.com>
	<a80d0093-759b-4bbd-af65-8749580dae74@default>
	<56D52198.60506@oracle.com>
Message-ID: <9a7fa153-c552-4902-aede-3b932f08d1cd@default>

Thanks David.  I have changed the copyright year to 2016.

-Sharath Ballal



-----Original Message-----
From: David Holmes 
Sent: Tuesday, March 01, 2016 10:29 AM
To: Sharath Ballal; serviceability-dev at openjdk.java.net
Subject: Re: RFR: 8147456 Parsing of argument for -agentpath can write outside of allocated memory

Hi Sharath,

On 1/03/2016 2:39 AM, Sharath Ballal wrote:
> Hi David,
> I have created a java testcase.  The webrev link is:
>
> http://cr.openjdk.java.net/~jbachorik/sponsorship/8147456/webrev.04/

Seems fine. Just fix the copyright year:

  Copyright (c) 2003, 2016,

Should only be 2016 for this new file.

Thanks,
David

>
> -Sharath Ballal
>
>
>
> -----Original Message-----
> From: David Holmes
> Sent: Tuesday, February 23, 2016 7:15 AM
> To: Sharath Ballal; serviceability-dev at openjdk.java.net
> Subject: Re: RFR: 8147456 Parsing of argument for -agentpath can write outside of allocated memory
>
> Hi Sharath,
>
> On 23/02/2016 12:59 AM, Sharath Ballal wrote:
>> Hi,
>>
>> Pls review the fix for the following bug.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8147456
>> Webrev:
>> http://cr.openjdk.java.net/~jbachorik/sponsorship/8147456/webrev.03/
>
> The functional fix seems fine.
>
> But for the test I understand we are moving away from using shell scripts, so can you please create a Java test using the Process* API's in the test library.
>
> Thanks,
> David
>
>> -Sharath Ballal
>>

From marcus.larsson at oracle.com  Tue Mar  1 11:11:53 2016
From: marcus.larsson at oracle.com (Marcus Larsson)
Date: Tue, 1 Mar 2016 12:11:53 +0100
Subject: RFR: 8146879: Add option for handling existing log files in UL
	(was: Truncate new UL log files)
In-Reply-To: <5697B7F2.50104@oracle.com>
References: <5697B7F2.50104@oracle.com>
Message-ID: <56D578F9.6090602@oracle.com>

Hi again,

Taking a different approach to this.

New webrev:
http://cr.openjdk.java.net/~mlarsson/8146879/webrev.01/

Existing files will now by default be renamed/archived with a .X suffix 
where X is the lowest number such that the resulting file name is 
available (jvm.log becomes jvm.log.0). A mode option for controlling 
this behavior has been added as well. It can be set to archive, append, 
or truncate (i.e. -Xlog::jvm.log::mode=truncate).

Tested with included jtreg test through JPRT.

Thanks,
Marcus

On 01/14/2016 04:00 PM, Marcus Larsson wrote:
> Hi,
>
> Please review the following patch to make sure UL truncates existing 
> log files before writing to them. Since files are opened in append 
> mode, truncation isn't done automatically, so instead the patch adds 
> an attempt to remove the log file before opening it.
>
> Webrev:
> http://cr.openjdk.java.net/~mlarsson/8146879/webrev.00/
>
> Issue:
> https://bugs.openjdk.java.net/browse/JDK-8146879
>
> Testing:
> Included test through JPRT
>
> Thanks,
> Marcus


From dmitry.samersoff at oracle.com  Tue Mar  1 13:32:21 2016
From: dmitry.samersoff at oracle.com (Dmitry Samersoff)
Date: Tue, 1 Mar 2016 16:32:21 +0300
Subject: RFR: 8146879: Add option for handling existing log files in UL
In-Reply-To: <56D578F9.6090602@oracle.com>
References: <5697B7F2.50104@oracle.com> <56D578F9.6090602@oracle.com>
Message-ID: <56D599E5.40504@oracle.com>

Marcus,

logFileOutput.cpp:

77: Please move this function to include file

149: you have to check that file is a regular one, before any attempt to
rotate.

Please, move this function to include file.

164: As soon as size_t can't represent more than 10 decimal digits,
please replace ceil(log10(static_cast<double>(SIZE_MAX))) to 10


168: It might be better to replace SIZE_MAX to some reasonable value
(e.g. 100) and give a message on overflow. Otherwise VM never starts  in
bad no-log-removal case.

169: please make sure that you produce logname.001, logname.002 etc,
not logname.1 ... logname.10

Many filesystems sorts files alphabetically and tons of user scripts
rely on it.

186: Please print a reason of fail (os error)

-Dmitry

On 2016-03-01 14:11, Marcus Larsson wrote:
> Hi again,
> 
> Taking a different approach to this.
> 
> New webrev:
> http://cr.openjdk.java.net/~mlarsson/8146879/webrev.01/
> 
> Existing files will now by default be renamed/archived with a .X suffix
> where X is the lowest number such that the resulting file name is
> available (jvm.log becomes jvm.log.0). A mode option for controlling
> this behavior has been added as well. It can be set to archive, append,
> or truncate (i.e. -Xlog::jvm.log::mode=truncate).
> 
> Tested with included jtreg test through JPRT.
> 
> Thanks,
> Marcus
> 
> On 01/14/2016 04:00 PM, Marcus Larsson wrote:
>> Hi,
>>
>> Please review the following patch to make sure UL truncates existing
>> log files before writing to them. Since files are opened in append
>> mode, truncation isn't done automatically, so instead the patch adds
>> an attempt to remove the log file before opening it.
>>
>> Webrev:
>> http://cr.openjdk.java.net/~mlarsson/8146879/webrev.00/
>>
>> Issue:
>> https://bugs.openjdk.java.net/browse/JDK-8146879
>>
>> Testing:
>> Included test through JPRT
>>
>> Thanks,
>> Marcus
> 


-- 
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the sources.

From marcus.larsson at oracle.com  Tue Mar  1 14:05:47 2016
From: marcus.larsson at oracle.com (Marcus Larsson)
Date: Tue, 1 Mar 2016 15:05:47 +0100
Subject: RFR: 8146879: Add option for handling existing log files in UL
In-Reply-To: <56D578F9.6090602@oracle.com>
References: <5697B7F2.50104@oracle.com> <56D578F9.6090602@oracle.com>
Message-ID: <56D5A1BB.6030403@oracle.com>

Hi,

After some offline discussions I'm withdrawing this patch. I will 
instead investigate if I can achieve similar behavior using log rotation 
as the default.

Thanks,
Marcus

On 03/01/2016 12:11 PM, Marcus Larsson wrote:
> Hi again,
>
> Taking a different approach to this.
>
> New webrev:
> http://cr.openjdk.java.net/~mlarsson/8146879/webrev.01/
>
> Existing files will now by default be renamed/archived with a .X 
> suffix where X is the lowest number such that the resulting file name 
> is available (jvm.log becomes jvm.log.0). A mode option for 
> controlling this behavior has been added as well. It can be set to 
> archive, append, or truncate (i.e. -Xlog::jvm.log::mode=truncate).
>
> Tested with included jtreg test through JPRT.
>
> Thanks,
> Marcus
>
> On 01/14/2016 04:00 PM, Marcus Larsson wrote:
>> Hi,
>>
>> Please review the following patch to make sure UL truncates existing 
>> log files before writing to them. Since files are opened in append 
>> mode, truncation isn't done automatically, so instead the patch adds 
>> an attempt to remove the log file before opening it.
>>
>> Webrev:
>> http://cr.openjdk.java.net/~mlarsson/8146879/webrev.00/
>>
>> Issue:
>> https://bugs.openjdk.java.net/browse/JDK-8146879
>>
>> Testing:
>> Included test through JPRT
>>
>> Thanks,
>> Marcus
>


From marcus.larsson at oracle.com  Tue Mar  1 14:10:36 2016
From: marcus.larsson at oracle.com (Marcus Larsson)
Date: Tue, 1 Mar 2016 15:10:36 +0100
Subject: RFR: 8146879: Add option for handling existing log files in UL
In-Reply-To: <56D599E5.40504@oracle.com>
References: <5697B7F2.50104@oracle.com> <56D578F9.6090602@oracle.com>
	<56D599E5.40504@oracle.com>
Message-ID: <56D5A2DC.7040407@oracle.com>

Hi Dmitry,

Thanks for reviewing, but I'm withdrawing the current patch since I 
might choose to solve it in a different way. Sorry about that.

Marcus


On 03/01/2016 02:32 PM, Dmitry Samersoff wrote:
> Marcus,
>
> logFileOutput.cpp:
>
> 77: Please move this function to include file
>
> 149: you have to check that file is a regular one, before any attempt to
> rotate.
>
> Please, move this function to include file.
>
> 164: As soon as size_t can't represent more than 10 decimal digits,
> please replace ceil(log10(static_cast<double>(SIZE_MAX))) to 10
>
>
> 168: It might be better to replace SIZE_MAX to some reasonable value
> (e.g. 100) and give a message on overflow. Otherwise VM never starts  in
> bad no-log-removal case.
>
> 169: please make sure that you produce logname.001, logname.002 etc,
> not logname.1 ... logname.10
>
> Many filesystems sorts files alphabetically and tons of user scripts
> rely on it.
>
> 186: Please print a reason of fail (os error)
>
> -Dmitry
>
> On 2016-03-01 14:11, Marcus Larsson wrote:
>> Hi again,
>>
>> Taking a different approach to this.
>>
>> New webrev:
>> http://cr.openjdk.java.net/~mlarsson/8146879/webrev.01/
>>
>> Existing files will now by default be renamed/archived with a .X suffix
>> where X is the lowest number such that the resulting file name is
>> available (jvm.log becomes jvm.log.0). A mode option for controlling
>> this behavior has been added as well. It can be set to archive, append,
>> or truncate (i.e. -Xlog::jvm.log::mode=truncate).
>>
>> Tested with included jtreg test through JPRT.
>>
>> Thanks,
>> Marcus
>>
>> On 01/14/2016 04:00 PM, Marcus Larsson wrote:
>>> Hi,
>>>
>>> Please review the following patch to make sure UL truncates existing
>>> log files before writing to them. Since files are opened in append
>>> mode, truncation isn't done automatically, so instead the patch adds
>>> an attempt to remove the log file before opening it.
>>>
>>> Webrev:
>>> http://cr.openjdk.java.net/~mlarsson/8146879/webrev.00/
>>>
>>> Issue:
>>> https://bugs.openjdk.java.net/browse/JDK-8146879
>>>
>>> Testing:
>>> Included test through JPRT
>>>
>>> Thanks,
>>> Marcus
>


From yasuenag at gmail.com  Tue Mar  1 14:56:44 2016
From: yasuenag at gmail.com (Yasumasa Suenaga)
Date: Tue, 1 Mar 2016 23:56:44 +0900
Subject: G1 STW phases and FGC column in jstat
Message-ID: <56D5ADAC.5010701@gmail.com>

Hi all,

I wonder that STW phases (Remark and Cleanup) at G1 are not counted in jstat FGC column.
For example, Initial Mark and Remark at CMS are counted as FGC.

For consistency, I think that G1 STW phases should be counted as FGC.
What do you think about it?

If it is accepted, I will file it to JBS and will upload webrev.


suggested fix:
----------------------
diff -r 8a103ba9a7b2 src/share/vm/gc/g1/g1MonitoringSupport.cpp
--- a/src/share/vm/gc/g1/g1MonitoringSupport.cpp	Mon Feb 29 22:54:24 2016 +0900
+++ b/src/share/vm/gc/g1/g1MonitoringSupport.cpp	Tue Mar 01 23:43:30 2016 +0900
@@ -103,7 +103,7 @@
   //   name "collector.1".  In a generational collector this would be the
   // old generation collection.
   _full_collection_counters =
-    new CollectorCounters("G1 stop-the-world full collections", 1);
+    new CollectorCounters("G1 stop-the-world phase", 1);
 
   // timer sampling for all counters supporting sampling only update the
   // used value.  See the take_sample() method.  G1 requires both used and
diff -r 8a103ba9a7b2 src/share/vm/gc/g1/vm_operations_g1.cpp
--- a/src/share/vm/gc/g1/vm_operations_g1.cpp	Mon Feb 29 22:54:24 2016 +0900
+++ b/src/share/vm/gc/g1/vm_operations_g1.cpp	Tue Mar 01 23:43:30 2016 +0900
@@ -230,6 +230,8 @@
   G1CollectedHeap* g1h = G1CollectedHeap::heap();
   GCTraceTime(Info, gc) t(_printGCMessage, g1h->gc_timer_cm(), GCCause::_no_gc, true);
   IsGCActiveMark x;
+  SvcGCMarker sgcm(SvcGCMarker::OTHER);
+  TraceCollectorStats tcs(g1h->g1mm()->full_collection_counters());
   _cl->do_void();
 }
 
----------------------


Thanks,

Yasumasa



From kirk at kodewerk.com  Tue Mar  1 21:35:18 2016
From: kirk at kodewerk.com (kirk at kodewerk.com)
Date: Tue, 1 Mar 2016 15:35:18 -0600
Subject: G1 STW phases and FGC column in jstat
In-Reply-To: <56D5ADAC.5010701@gmail.com>
References: <56D5ADAC.5010701@gmail.com>
Message-ID: <9430CE85-D805-495F-A2F7-314766E7492A@kodewerk.com>

Hi,

I think it is incorrect to count remark and cleanup as FGC. They are not full collections. It is also incorrect to count initial mark and remark in CMS as a FGC. It is unfortunate that this is counted this way.

Regards,
Kirk

> On Mar 1, 2016, at 8:56 AM, Yasumasa Suenaga <yasuenag at gmail.com> wrote:
> 
> Hi all,
> 
> I wonder that STW phases (Remark and Cleanup) at G1 are not counted in jstat FGC column.
> For example, Initial Mark and Remark at CMS are counted as FGC.
> 
> For consistency, I think that G1 STW phases should be counted as FGC.
> What do you think about it?
> 
> If it is accepted, I will file it to JBS and will upload webrev.
> 
> 
> suggested fix:
> ----------------------
> diff -r 8a103ba9a7b2 src/share/vm/gc/g1/g1MonitoringSupport.cpp
> --- a/src/share/vm/gc/g1/g1MonitoringSupport.cpp	Mon Feb 29 22:54:24 2016 +0900
> +++ b/src/share/vm/gc/g1/g1MonitoringSupport.cpp	Tue Mar 01 23:43:30 2016 +0900
> @@ -103,7 +103,7 @@
>   //   name "collector.1".  In a generational collector this would be the
>   // old generation collection.
>   _full_collection_counters =
> -    new CollectorCounters("G1 stop-the-world full collections", 1);
> +    new CollectorCounters("G1 stop-the-world phase", 1);
> 
>   // timer sampling for all counters supporting sampling only update the
>   // used value.  See the take_sample() method.  G1 requires both used and
> diff -r 8a103ba9a7b2 src/share/vm/gc/g1/vm_operations_g1.cpp
> --- a/src/share/vm/gc/g1/vm_operations_g1.cpp	Mon Feb 29 22:54:24 2016 +0900
> +++ b/src/share/vm/gc/g1/vm_operations_g1.cpp	Tue Mar 01 23:43:30 2016 +0900
> @@ -230,6 +230,8 @@
>   G1CollectedHeap* g1h = G1CollectedHeap::heap();
>   GCTraceTime(Info, gc) t(_printGCMessage, g1h->gc_timer_cm(), GCCause::_no_gc, true);
>   IsGCActiveMark x;
> +  SvcGCMarker sgcm(SvcGCMarker::OTHER);
> +  TraceCollectorStats tcs(g1h->g1mm()->full_collection_counters());
>   _cl->do_void();
> }
> 
> ----------------------
> 
> 
> Thanks,
> 
> Yasumasa
> 
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20160301/1c34b016/signature.asc>

From yasuenag at gmail.com  Tue Mar  1 23:03:34 2016
From: yasuenag at gmail.com (Yasumasa Suenaga)
Date: Wed, 02 Mar 2016 08:03:34 +0900
Subject: G1 STW phases and FGC column in jstat
In-Reply-To: <9430CE85-D805-495F-A2F7-314766E7492A@kodewerk.com>
References: <56D5ADAC.5010701@gmail.com>
	<9430CE85-D805-495F-A2F7-314766E7492A@kodewerk.com>
Message-ID: <56D61FC6.2070002@gmail.com>

Hi Kirk,

> It is also incorrect to count initial mark and remark in CMS as a FGC.

Though, how can we check execution of major collection without GC log?
Should we add new PerfCounter for CGC (and add CGC column to jstat output)?


Yasumasa


On 2016/03/02 6:35, kirk at kodewerk.com wrote:
> Hi,
>
> I think it is incorrect to count remark and cleanup as FGC. They are not full collections. It is also incorrect to count initial mark and remark in CMS as a FGC. It is unfortunate that this is counted this way.
>
> Regards,
> Kirk
>
>> On Mar 1, 2016, at 8:56 AM, Yasumasa Suenaga <yasuenag at gmail.com> wrote:
>>
>> Hi all,
>>
>> I wonder that STW phases (Remark and Cleanup) at G1 are not counted in jstat FGC column.
>> For example, Initial Mark and Remark at CMS are counted as FGC.
>>
>> For consistency, I think that G1 STW phases should be counted as FGC.
>> What do you think about it?
>>
>> If it is accepted, I will file it to JBS and will upload webrev.
>>
>>
>> suggested fix:
>> ----------------------
>> diff -r 8a103ba9a7b2 src/share/vm/gc/g1/g1MonitoringSupport.cpp
>> --- a/src/share/vm/gc/g1/g1MonitoringSupport.cpp	Mon Feb 29 22:54:24 2016 +0900
>> +++ b/src/share/vm/gc/g1/g1MonitoringSupport.cpp	Tue Mar 01 23:43:30 2016 +0900
>> @@ -103,7 +103,7 @@
>>    //   name "collector.1".  In a generational collector this would be the
>>    // old generation collection.
>>    _full_collection_counters =
>> -    new CollectorCounters("G1 stop-the-world full collections", 1);
>> +    new CollectorCounters("G1 stop-the-world phase", 1);
>>
>>    // timer sampling for all counters supporting sampling only update the
>>    // used value.  See the take_sample() method.  G1 requires both used and
>> diff -r 8a103ba9a7b2 src/share/vm/gc/g1/vm_operations_g1.cpp
>> --- a/src/share/vm/gc/g1/vm_operations_g1.cpp	Mon Feb 29 22:54:24 2016 +0900
>> +++ b/src/share/vm/gc/g1/vm_operations_g1.cpp	Tue Mar 01 23:43:30 2016 +0900
>> @@ -230,6 +230,8 @@
>>    G1CollectedHeap* g1h = G1CollectedHeap::heap();
>>    GCTraceTime(Info, gc) t(_printGCMessage, g1h->gc_timer_cm(), GCCause::_no_gc, true);
>>    IsGCActiveMark x;
>> +  SvcGCMarker sgcm(SvcGCMarker::OTHER);
>> +  TraceCollectorStats tcs(g1h->g1mm()->full_collection_counters());
>>    _cl->do_void();
>> }
>>
>> ----------------------
>>
>>
>> Thanks,
>>
>> Yasumasa
>>
>>
>

From yiyeguhu at gmail.com  Wed Mar  2 00:27:03 2016
From: yiyeguhu at gmail.com (Tao Mao)
Date: Tue, 1 Mar 2016 16:27:03 -0800
Subject: G1 STW phases and FGC column in jstat
In-Reply-To: <56D61FC6.2070002@gmail.com>
References: <56D5ADAC.5010701@gmail.com>
	<9430CE85-D805-495F-A2F7-314766E7492A@kodewerk.com>
	<56D61FC6.2070002@gmail.com>
Message-ID: <CANrGW1yKDNf3UkG_gP1vwq6LCP8KQ2s0SYQV7cnkbxVz7i1E6g@mail.gmail.com>

Hi,

Would adopting MiGC (minor) and MaGC (major) in jstat output make more
sense to cover all collectors' algorithms if we need a change here?

Thanks.
Tao Mao

On Tue, Mar 1, 2016 at 3:03 PM, Yasumasa Suenaga <yasuenag at gmail.com> wrote:

> Hi Kirk,
>
> It is also incorrect to count initial mark and remark in CMS as a FGC.
>>
>
> Though, how can we check execution of major collection without GC log?
> Should we add new PerfCounter for CGC (and add CGC column to jstat output)?
>
>
> Yasumasa
>
>
>
> On 2016/03/02 6:35, kirk at kodewerk.com wrote:
>
>> Hi,
>>
>> I think it is incorrect to count remark and cleanup as FGC. They are not
>> full collections. It is also incorrect to count initial mark and remark in
>> CMS as a FGC. It is unfortunate that this is counted this way.
>>
>> Regards,
>> Kirk
>>
>> On Mar 1, 2016, at 8:56 AM, Yasumasa Suenaga <yasuenag at gmail.com> wrote:
>>>
>>> Hi all,
>>>
>>> I wonder that STW phases (Remark and Cleanup) at G1 are not counted in
>>> jstat FGC column.
>>> For example, Initial Mark and Remark at CMS are counted as FGC.
>>>
>>> For consistency, I think that G1 STW phases should be counted as FGC.
>>> What do you think about it?
>>>
>>> If it is accepted, I will file it to JBS and will upload webrev.
>>>
>>>
>>> suggested fix:
>>> ----------------------
>>> diff -r 8a103ba9a7b2 src/share/vm/gc/g1/g1MonitoringSupport.cpp
>>> --- a/src/share/vm/gc/g1/g1MonitoringSupport.cpp        Mon Feb 29
>>> 22:54:24 2016 +0900
>>> +++ b/src/share/vm/gc/g1/g1MonitoringSupport.cpp        Tue Mar 01
>>> 23:43:30 2016 +0900
>>> @@ -103,7 +103,7 @@
>>>    //   name "collector.1".  In a generational collector this would be
>>> the
>>>    // old generation collection.
>>>    _full_collection_counters =
>>> -    new CollectorCounters("G1 stop-the-world full collections", 1);
>>> +    new CollectorCounters("G1 stop-the-world phase", 1);
>>>
>>>    // timer sampling for all counters supporting sampling only update the
>>>    // used value.  See the take_sample() method.  G1 requires both used
>>> and
>>> diff -r 8a103ba9a7b2 src/share/vm/gc/g1/vm_operations_g1.cpp
>>> --- a/src/share/vm/gc/g1/vm_operations_g1.cpp   Mon Feb 29 22:54:24 2016
>>> +0900
>>> +++ b/src/share/vm/gc/g1/vm_operations_g1.cpp   Tue Mar 01 23:43:30 2016
>>> +0900
>>> @@ -230,6 +230,8 @@
>>>    G1CollectedHeap* g1h = G1CollectedHeap::heap();
>>>    GCTraceTime(Info, gc) t(_printGCMessage, g1h->gc_timer_cm(),
>>> GCCause::_no_gc, true);
>>>    IsGCActiveMark x;
>>> +  SvcGCMarker sgcm(SvcGCMarker::OTHER);
>>> +  TraceCollectorStats tcs(g1h->g1mm()->full_collection_counters());
>>>    _cl->do_void();
>>> }
>>>
>>> ----------------------
>>>
>>>
>>> Thanks,
>>>
>>> Yasumasa
>>>
>>>
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20160301/a5d3ecf9/attachment.html>

From kirk at kodewerk.com  Wed Mar  2 10:02:40 2016
From: kirk at kodewerk.com (kirk at kodewerk.com)
Date: Wed, 2 Mar 2016 04:02:40 -0600
Subject: G1 STW phases and FGC column in jstat
In-Reply-To: <56D61FC6.2070002@gmail.com>
References: <56D5ADAC.5010701@gmail.com>
	<9430CE85-D805-495F-A2F7-314766E7492A@kodewerk.com>
	<56D61FC6.2070002@gmail.com>
Message-ID: <11E54471-015C-49AE-8E5E-DA681AE3CD1A@kodewerk.com>

Hi Yasumasa,

Good question. I?ve never considered CMS to be a Full GC. This implies that there should be separate performance counters for CMS pause phases as it is possible to have FGC. Of course a FGC during CMS maybe user triggered, triggered outside a CMS cycle, interrupts a CMS cycle, or interrupts a CMS phase. I?m not sure how much of a distinction one needs to make here as that could be a quick broader discussion. Certainly the purpose isn?t to recreate the GC logs in these performance counters. But at the very least not having a distinction between full and a STW-CMS phase is kind of misleading in my opinion.

Regards,
Kirk

> On Mar 1, 2016, at 5:03 PM, Yasumasa Suenaga <yasuenag at gmail.com> wrote:
> 
> Hi Kirk,
> 
>> It is also incorrect to count initial mark and remark in CMS as a FGC.
> 
> Though, how can we check execution of major collection without GC log?
> Should we add new PerfCounter for CGC (and add CGC column to jstat output)?
> 
> 
> Yasumasa
> 
> 
> On 2016/03/02 6:35, kirk at kodewerk.com wrote:
>> Hi,
>> 
>> I think it is incorrect to count remark and cleanup as FGC. They are not full collections. It is also incorrect to count initial mark and remark in CMS as a FGC. It is unfortunate that this is counted this way.
>> 
>> Regards,
>> Kirk
>> 
>>> On Mar 1, 2016, at 8:56 AM, Yasumasa Suenaga <yasuenag at gmail.com> wrote:
>>> 
>>> Hi all,
>>> 
>>> I wonder that STW phases (Remark and Cleanup) at G1 are not counted in jstat FGC column.
>>> For example, Initial Mark and Remark at CMS are counted as FGC.
>>> 
>>> For consistency, I think that G1 STW phases should be counted as FGC.
>>> What do you think about it?
>>> 
>>> If it is accepted, I will file it to JBS and will upload webrev.
>>> 
>>> 
>>> suggested fix:
>>> ----------------------
>>> diff -r 8a103ba9a7b2 src/share/vm/gc/g1/g1MonitoringSupport.cpp
>>> --- a/src/share/vm/gc/g1/g1MonitoringSupport.cpp	Mon Feb 29 22:54:24 2016 +0900
>>> +++ b/src/share/vm/gc/g1/g1MonitoringSupport.cpp	Tue Mar 01 23:43:30 2016 +0900
>>> @@ -103,7 +103,7 @@
>>>   //   name "collector.1".  In a generational collector this would be the
>>>   // old generation collection.
>>>   _full_collection_counters =
>>> -    new CollectorCounters("G1 stop-the-world full collections", 1);
>>> +    new CollectorCounters("G1 stop-the-world phase", 1);
>>> 
>>>   // timer sampling for all counters supporting sampling only update the
>>>   // used value.  See the take_sample() method.  G1 requires both used and
>>> diff -r 8a103ba9a7b2 src/share/vm/gc/g1/vm_operations_g1.cpp
>>> --- a/src/share/vm/gc/g1/vm_operations_g1.cpp	Mon Feb 29 22:54:24 2016 +0900
>>> +++ b/src/share/vm/gc/g1/vm_operations_g1.cpp	Tue Mar 01 23:43:30 2016 +0900
>>> @@ -230,6 +230,8 @@
>>>   G1CollectedHeap* g1h = G1CollectedHeap::heap();
>>>   GCTraceTime(Info, gc) t(_printGCMessage, g1h->gc_timer_cm(), GCCause::_no_gc, true);
>>>   IsGCActiveMark x;
>>> +  SvcGCMarker sgcm(SvcGCMarker::OTHER);
>>> +  TraceCollectorStats tcs(g1h->g1mm()->full_collection_counters());
>>>   _cl->do_void();
>>> }
>>> 
>>> ----------------------
>>> 
>>> 
>>> Thanks,
>>> 
>>> Yasumasa
>>> 
>>> 
>> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20160302/98d7bd26/signature.asc>

From konstantin.shefov at oracle.com  Wed Mar  2 11:37:16 2016
From: konstantin.shefov at oracle.com (Konstantin Shefov)
Date: Wed, 2 Mar 2016 14:37:16 +0300
Subject: [8u-dev] RFR 8150070: TESTBUG: com/sun/jdi tests fail on Cygwin
	but pass on MKS
In-Reply-To: <7708648b-5d58-4d98-9e2e-0e2b113453d7@default>
References: <7708648b-5d58-4d98-9e2e-0e2b113453d7@default>
Message-ID: <56D6D06C.7040800@oracle.com>

Hi Alexander,

You suggestion to fix JDK-8145552 in JDK 9 with its backport to JDK 8u 
sounds reasonable.
I think we may close JDK-8150070 and make a backport request of 
JDK-8145552 to JDK 8u when it is fixed in JDK 9.

-Konstantin

On 02/29/2016 02:18 PM, Alexander Kulyakhtin wrote:
> Hi Konstantin,
>
> (I'm not a reviewer)
>
>  From what I've understood this is not a specific JDK 8 issue. Rather, the issue has never been observed yet on JDK 9, because it does not happen every time.
>
> In JDK 9, however there is an item (JDK-8145552) to fully replace ShellScaffold.sh with an analogous Java implementation.
>
> Therefore, it could, probably, be better either to fix the ShellScaffold.sh script in the JDK 9 or leave it as it is and proceed with JDK-8145552 as planned.
>
> Adding Jaroslav who is the lead for the Serviceability component.
>
> Best regards,
> Alexander
>
> ----- Original Message -----
> From: konstantin.shefov at oracle.com
> To: serviceability-dev at openjdk.java.net
> Sent: Monday, February 29, 2016 12:06:53 PM GMT +03:00 Iraq
> Subject: Re: [8u-dev] RFR 8150070: TESTBUG: com/sun/jdi tests fail on Cygwin but pass on MKS
>
> Kindly reminder
>
> Please, review
>
> Thanks
> -Konstantin
>
> On 02/18/2016 07:07 PM, Konstantin Shefov wrote:
>> Hello
>>
>> Please review a test bug fix.
>> The test fails because Cygwin PID returned by "$!" and Windows PID
>> returned by "tasklist" are not the same.
>> Need to use cygwin "ps".
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8150070
>> Webrev: http://cr.openjdk.java.net/~kshefov/8150070/webrev
>>
>> Thanks
>> -Konstantin


From yasuenag at gmail.com  Wed Mar  2 12:58:29 2016
From: yasuenag at gmail.com (Yasumasa Suenaga)
Date: Wed, 2 Mar 2016 21:58:29 +0900
Subject: G1 STW phases and FGC column in jstat
In-Reply-To: <11E54471-015C-49AE-8E5E-DA681AE3CD1A@kodewerk.com>
References: <56D5ADAC.5010701@gmail.com>
	<9430CE85-D805-495F-A2F7-314766E7492A@kodewerk.com>
	<56D61FC6.2070002@gmail.com>
	<11E54471-015C-49AE-8E5E-DA681AE3CD1A@kodewerk.com>
Message-ID: <56D6E375.8010605@gmail.com>

Hi Kirk,

Agree to you.
However, I use occasional FGC counter at CMS as below:

  1. Check major collection occurrence
       Some production systems have large memory as Java heap,
       and they are not set GC log.
       If their CPU usage becomes high, I want to check GC execution.
       (Of course, we have to check any other points :-) )

  2. Core image analysis
       If JVM is crashed, I want to check PerfCounter to know situation.
       (In the past, I sometimes encountered crash at GC worker thread.)

I guess that I will want to check them at G1.

Thus, at least, I want to add PerfCounter for CGC (and add JVMTI event hook).
However, this proposal will affect to jstat spec.
So I want to discuss about it before filing to JBS.


Thanks,

Yasumasa


On 2016/03/02 19:02, kirk at kodewerk.com wrote:
> Hi Yasumasa,
>
> Good question. I?ve never considered CMS to be a Full GC. This implies that there should be separate performance counters for CMS pause phases as it is possible to have FGC. Of course a FGC during CMS maybe user triggered, triggered outside a CMS cycle, interrupts a CMS cycle, or interrupts a CMS phase. I?m not sure how much of a distinction one needs to make here as that could be a quick broader discussion. Certainly the purpose isn?t to recreate the GC logs in these performance counters. But at the very least not having a distinction between full and a STW-CMS phase is kind of misleading in my opinion.
>
> Regards,
> Kirk
>
>> On Mar 1, 2016, at 5:03 PM, Yasumasa Suenaga <yasuenag at gmail.com> wrote:
>>
>> Hi Kirk,
>>
>>> It is also incorrect to count initial mark and remark in CMS as a FGC.
>>
>> Though, how can we check execution of major collection without GC log?
>> Should we add new PerfCounter for CGC (and add CGC column to jstat output)?
>>
>>
>> Yasumasa
>>
>>
>> On 2016/03/02 6:35, kirk at kodewerk.com wrote:
>>> Hi,
>>>
>>> I think it is incorrect to count remark and cleanup as FGC. They are not full collections. It is also incorrect to count initial mark and remark in CMS as a FGC. It is unfortunate that this is counted this way.
>>>
>>> Regards,
>>> Kirk
>>>
>>>> On Mar 1, 2016, at 8:56 AM, Yasumasa Suenaga <yasuenag at gmail.com> wrote:
>>>>
>>>> Hi all,
>>>>
>>>> I wonder that STW phases (Remark and Cleanup) at G1 are not counted in jstat FGC column.
>>>> For example, Initial Mark and Remark at CMS are counted as FGC.
>>>>
>>>> For consistency, I think that G1 STW phases should be counted as FGC.
>>>> What do you think about it?
>>>>
>>>> If it is accepted, I will file it to JBS and will upload webrev.
>>>>
>>>>
>>>> suggested fix:
>>>> ----------------------
>>>> diff -r 8a103ba9a7b2 src/share/vm/gc/g1/g1MonitoringSupport.cpp
>>>> --- a/src/share/vm/gc/g1/g1MonitoringSupport.cpp	Mon Feb 29 22:54:24 2016 +0900
>>>> +++ b/src/share/vm/gc/g1/g1MonitoringSupport.cpp	Tue Mar 01 23:43:30 2016 +0900
>>>> @@ -103,7 +103,7 @@
>>>>    //   name "collector.1".  In a generational collector this would be the
>>>>    // old generation collection.
>>>>    _full_collection_counters =
>>>> -    new CollectorCounters("G1 stop-the-world full collections", 1);
>>>> +    new CollectorCounters("G1 stop-the-world phase", 1);
>>>>
>>>>    // timer sampling for all counters supporting sampling only update the
>>>>    // used value.  See the take_sample() method.  G1 requires both used and
>>>> diff -r 8a103ba9a7b2 src/share/vm/gc/g1/vm_operations_g1.cpp
>>>> --- a/src/share/vm/gc/g1/vm_operations_g1.cpp	Mon Feb 29 22:54:24 2016 +0900
>>>> +++ b/src/share/vm/gc/g1/vm_operations_g1.cpp	Tue Mar 01 23:43:30 2016 +0900
>>>> @@ -230,6 +230,8 @@
>>>>    G1CollectedHeap* g1h = G1CollectedHeap::heap();
>>>>    GCTraceTime(Info, gc) t(_printGCMessage, g1h->gc_timer_cm(), GCCause::_no_gc, true);
>>>>    IsGCActiveMark x;
>>>> +  SvcGCMarker sgcm(SvcGCMarker::OTHER);
>>>> +  TraceCollectorStats tcs(g1h->g1mm()->full_collection_counters());
>>>>    _cl->do_void();
>>>> }
>>>>
>>>> ----------------------
>>>>
>>>>
>>>> Thanks,
>>>>
>>>> Yasumasa
>>>>
>>>>
>>>
>

From kirk at kodewerk.com  Wed Mar  2 13:29:18 2016
From: kirk at kodewerk.com (kirk at kodewerk.com)
Date: Wed, 2 Mar 2016 07:29:18 -0600
Subject: G1 STW phases and FGC column in jstat
In-Reply-To: <56D6E375.8010605@gmail.com>
References: <56D5ADAC.5010701@gmail.com>
	<9430CE85-D805-495F-A2F7-314766E7492A@kodewerk.com>
	<56D61FC6.2070002@gmail.com>
	<11E54471-015C-49AE-8E5E-DA681AE3CD1A@kodewerk.com>
	<56D6E375.8010605@gmail.com>
Message-ID: <46C36433-8BC0-454D-9C91-142D5C2AF552@kodewerk.com>

Hi Yasumasa,

It all sounds reasonable and of course the impact on downstream tooling vs the value of the change must be evaluated. In this case I think adding a CGC counter makes sense especially in prep for G1 becoming default in 9.

Regards,
Kirk

> On Mar 2, 2016, at 6:58 AM, Yasumasa Suenaga <yasuenag at gmail.com> wrote:
> 
> Hi Kirk,
> 
> Agree to you.
> However, I use occasional FGC counter at CMS as below:
> 
> 1. Check major collection occurrence
>      Some production systems have large memory as Java heap,
>      and they are not set GC log.
>      If their CPU usage becomes high, I want to check GC execution.
>      (Of course, we have to check any other points :-) )
> 
> 2. Core image analysis
>      If JVM is crashed, I want to check PerfCounter to know situation.
>      (In the past, I sometimes encountered crash at GC worker thread.)
> 
> I guess that I will want to check them at G1.
> 
> Thus, at least, I want to add PerfCounter for CGC (and add JVMTI event hook).
> However, this proposal will affect to jstat spec.
> So I want to discuss about it before filing to JBS.
> 
> 
> Thanks,
> 
> Yasumasa
> 
> 
> On 2016/03/02 19:02, kirk at kodewerk.com wrote:
>> Hi Yasumasa,
>> 
>> Good question. I?ve never considered CMS to be a Full GC. This implies that there should be separate performance counters for CMS pause phases as it is possible to have FGC. Of course a FGC during CMS maybe user triggered, triggered outside a CMS cycle, interrupts a CMS cycle, or interrupts a CMS phase. I?m not sure how much of a distinction one needs to make here as that could be a quick broader discussion. Certainly the purpose isn?t to recreate the GC logs in these performance counters. But at the very least not having a distinction between full and a STW-CMS phase is kind of misleading in my opinion.
>> 
>> Regards,
>> Kirk
>> 
>>> On Mar 1, 2016, at 5:03 PM, Yasumasa Suenaga <yasuenag at gmail.com> wrote:
>>> 
>>> Hi Kirk,
>>> 
>>>> It is also incorrect to count initial mark and remark in CMS as a FGC.
>>> 
>>> Though, how can we check execution of major collection without GC log?
>>> Should we add new PerfCounter for CGC (and add CGC column to jstat output)?
>>> 
>>> 
>>> Yasumasa
>>> 
>>> 
>>> On 2016/03/02 6:35, kirk at kodewerk.com wrote:
>>>> Hi,
>>>> 
>>>> I think it is incorrect to count remark and cleanup as FGC. They are not full collections. It is also incorrect to count initial mark and remark in CMS as a FGC. It is unfortunate that this is counted this way.
>>>> 
>>>> Regards,
>>>> Kirk
>>>> 
>>>>> On Mar 1, 2016, at 8:56 AM, Yasumasa Suenaga <yasuenag at gmail.com> wrote:
>>>>> 
>>>>> Hi all,
>>>>> 
>>>>> I wonder that STW phases (Remark and Cleanup) at G1 are not counted in jstat FGC column.
>>>>> For example, Initial Mark and Remark at CMS are counted as FGC.
>>>>> 
>>>>> For consistency, I think that G1 STW phases should be counted as FGC.
>>>>> What do you think about it?
>>>>> 
>>>>> If it is accepted, I will file it to JBS and will upload webrev.
>>>>> 
>>>>> 
>>>>> suggested fix:
>>>>> ----------------------
>>>>> diff -r 8a103ba9a7b2 src/share/vm/gc/g1/g1MonitoringSupport.cpp
>>>>> --- a/src/share/vm/gc/g1/g1MonitoringSupport.cpp	Mon Feb 29 22:54:24 2016 +0900
>>>>> +++ b/src/share/vm/gc/g1/g1MonitoringSupport.cpp	Tue Mar 01 23:43:30 2016 +0900
>>>>> @@ -103,7 +103,7 @@
>>>>>   //   name "collector.1".  In a generational collector this would be the
>>>>>   // old generation collection.
>>>>>   _full_collection_counters =
>>>>> -    new CollectorCounters("G1 stop-the-world full collections", 1);
>>>>> +    new CollectorCounters("G1 stop-the-world phase", 1);
>>>>> 
>>>>>   // timer sampling for all counters supporting sampling only update the
>>>>>   // used value.  See the take_sample() method.  G1 requires both used and
>>>>> diff -r 8a103ba9a7b2 src/share/vm/gc/g1/vm_operations_g1.cpp
>>>>> --- a/src/share/vm/gc/g1/vm_operations_g1.cpp	Mon Feb 29 22:54:24 2016 +0900
>>>>> +++ b/src/share/vm/gc/g1/vm_operations_g1.cpp	Tue Mar 01 23:43:30 2016 +0900
>>>>> @@ -230,6 +230,8 @@
>>>>>   G1CollectedHeap* g1h = G1CollectedHeap::heap();
>>>>>   GCTraceTime(Info, gc) t(_printGCMessage, g1h->gc_timer_cm(), GCCause::_no_gc, true);
>>>>>   IsGCActiveMark x;
>>>>> +  SvcGCMarker sgcm(SvcGCMarker::OTHER);
>>>>> +  TraceCollectorStats tcs(g1h->g1mm()->full_collection_counters());
>>>>>   _cl->do_void();
>>>>> }
>>>>> 
>>>>> ----------------------
>>>>> 
>>>>> 
>>>>> Thanks,
>>>>> 
>>>>> Yasumasa
>>>>> 
>>>>> 
>>>> 
>> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20160302/11daca41/signature.asc>

From yasuenag at gmail.com  Wed Mar  2 14:19:55 2016
From: yasuenag at gmail.com (Yasumasa Suenaga)
Date: Wed, 2 Mar 2016 23:19:55 +0900
Subject: G1 STW phases and FGC column in jstat
In-Reply-To: <46C36433-8BC0-454D-9C91-142D5C2AF552@kodewerk.com>
References: <56D5ADAC.5010701@gmail.com>
	<9430CE85-D805-495F-A2F7-314766E7492A@kodewerk.com>
	<56D61FC6.2070002@gmail.com>
	<11E54471-015C-49AE-8E5E-DA681AE3CD1A@kodewerk.com>
	<56D6E375.8010605@gmail.com>
	<46C36433-8BC0-454D-9C91-142D5C2AF552@kodewerk.com>
Message-ID: <56D6F68B.3010409@gmail.com>

It is not difficult to create webrev for this proposal.
However, this proposal affects to jstat output, and
I cannot access JPRT.
So I want to find sponsor for it at first.

Could somebody be a sponsor?


Yasumasa


On 2016/03/02 22:29, kirk at kodewerk.com wrote:
> Hi Yasumasa,
>
> It all sounds reasonable and of course the impact on downstream tooling vs the value of the change must be evaluated. In this case I think adding a CGC counter makes sense especially in prep for G1 becoming default in 9.
>
> Regards,
> Kirk
>
>> On Mar 2, 2016, at 6:58 AM, Yasumasa Suenaga <yasuenag at gmail.com> wrote:
>>
>> Hi Kirk,
>>
>> Agree to you.
>> However, I use occasional FGC counter at CMS as below:
>>
>> 1. Check major collection occurrence
>>       Some production systems have large memory as Java heap,
>>       and they are not set GC log.
>>       If their CPU usage becomes high, I want to check GC execution.
>>       (Of course, we have to check any other points :-) )
>>
>> 2. Core image analysis
>>       If JVM is crashed, I want to check PerfCounter to know situation.
>>       (In the past, I sometimes encountered crash at GC worker thread.)
>>
>> I guess that I will want to check them at G1.
>>
>> Thus, at least, I want to add PerfCounter for CGC (and add JVMTI event hook).
>> However, this proposal will affect to jstat spec.
>> So I want to discuss about it before filing to JBS.
>>
>>
>> Thanks,
>>
>> Yasumasa
>>
>>
>> On 2016/03/02 19:02, kirk at kodewerk.com wrote:
>>> Hi Yasumasa,
>>>
>>> Good question. I?ve never considered CMS to be a Full GC. This implies that there should be separate performance counters for CMS pause phases as it is possible to have FGC. Of course a FGC during CMS maybe user triggered, triggered outside a CMS cycle, interrupts a CMS cycle, or interrupts a CMS phase. I?m not sure how much of a distinction one needs to make here as that could be a quick broader discussion. Certainly the purpose isn?t to recreate the GC logs in these performance counters. But at the very least not having a distinction between full and a STW-CMS phase is kind of misleading in my opinion.
>>>
>>> Regards,
>>> Kirk
>>>
>>>> On Mar 1, 2016, at 5:03 PM, Yasumasa Suenaga <yasuenag at gmail.com> wrote:
>>>>
>>>> Hi Kirk,
>>>>
>>>>> It is also incorrect to count initial mark and remark in CMS as a FGC.
>>>>
>>>> Though, how can we check execution of major collection without GC log?
>>>> Should we add new PerfCounter for CGC (and add CGC column to jstat output)?
>>>>
>>>>
>>>> Yasumasa
>>>>
>>>>
>>>> On 2016/03/02 6:35, kirk at kodewerk.com wrote:
>>>>> Hi,
>>>>>
>>>>> I think it is incorrect to count remark and cleanup as FGC. They are not full collections. It is also incorrect to count initial mark and remark in CMS as a FGC. It is unfortunate that this is counted this way.
>>>>>
>>>>> Regards,
>>>>> Kirk
>>>>>
>>>>>> On Mar 1, 2016, at 8:56 AM, Yasumasa Suenaga <yasuenag at gmail.com> wrote:
>>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> I wonder that STW phases (Remark and Cleanup) at G1 are not counted in jstat FGC column.
>>>>>> For example, Initial Mark and Remark at CMS are counted as FGC.
>>>>>>
>>>>>> For consistency, I think that G1 STW phases should be counted as FGC.
>>>>>> What do you think about it?
>>>>>>
>>>>>> If it is accepted, I will file it to JBS and will upload webrev.
>>>>>>
>>>>>>
>>>>>> suggested fix:
>>>>>> ----------------------
>>>>>> diff -r 8a103ba9a7b2 src/share/vm/gc/g1/g1MonitoringSupport.cpp
>>>>>> --- a/src/share/vm/gc/g1/g1MonitoringSupport.cpp	Mon Feb 29 22:54:24 2016 +0900
>>>>>> +++ b/src/share/vm/gc/g1/g1MonitoringSupport.cpp	Tue Mar 01 23:43:30 2016 +0900
>>>>>> @@ -103,7 +103,7 @@
>>>>>>    //   name "collector.1".  In a generational collector this would be the
>>>>>>    // old generation collection.
>>>>>>    _full_collection_counters =
>>>>>> -    new CollectorCounters("G1 stop-the-world full collections", 1);
>>>>>> +    new CollectorCounters("G1 stop-the-world phase", 1);
>>>>>>
>>>>>>    // timer sampling for all counters supporting sampling only update the
>>>>>>    // used value.  See the take_sample() method.  G1 requires both used and
>>>>>> diff -r 8a103ba9a7b2 src/share/vm/gc/g1/vm_operations_g1.cpp
>>>>>> --- a/src/share/vm/gc/g1/vm_operations_g1.cpp	Mon Feb 29 22:54:24 2016 +0900
>>>>>> +++ b/src/share/vm/gc/g1/vm_operations_g1.cpp	Tue Mar 01 23:43:30 2016 +0900
>>>>>> @@ -230,6 +230,8 @@
>>>>>>    G1CollectedHeap* g1h = G1CollectedHeap::heap();
>>>>>>    GCTraceTime(Info, gc) t(_printGCMessage, g1h->gc_timer_cm(), GCCause::_no_gc, true);
>>>>>>    IsGCActiveMark x;
>>>>>> +  SvcGCMarker sgcm(SvcGCMarker::OTHER);
>>>>>> +  TraceCollectorStats tcs(g1h->g1mm()->full_collection_counters());
>>>>>>    _cl->do_void();
>>>>>> }
>>>>>>
>>>>>> ----------------------
>>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Yasumasa
>>>>>>
>>>>>>
>>>>>
>>>
>

From andreas.eriksson at oracle.com  Wed Mar  2 16:56:11 2016
From: andreas.eriksson at oracle.com (Andreas Eriksson)
Date: Wed, 2 Mar 2016 17:56:11 +0100
Subject: RFR (XS): 8150986:
	serviceability/sa/jmap-hprof/JMapHProfLargeHeapTest.java failing
	because expects HPROF JAVA PROFILE 1.0.1 file format
Message-ID: <56D71B2B.8070902@oracle.com>

Hi,

Can I please have a review for this small test fix.

Bug: 8150986: serviceability/sa/jmap-hprof/JMapHProfLargeHeapTest.java 
failing because expects HPROF JAVA PROFILE 1.0.1 file format
https://bugs.openjdk.java.net/browse/JDK-8150986
Webrev: http://cr.openjdk.java.net/~aeriksso/8150986/webrev/

As part of JDK-8144732 
<https://bugs.openjdk.java.net/browse/JDK-8144732> support for dumping 
hprof with format 1.0.1 was removed, and we use format 1.0.2 always.
I missed updating this test, which checks the header string in a heap dump.

Thanks,
Andreas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20160302/be1f0069/attachment.html>

From daniel.daugherty at oracle.com  Wed Mar  2 18:10:11 2016
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Wed, 2 Mar 2016 11:10:11 -0700
Subject: RFR (XS): 8150986:
	serviceability/sa/jmap-hprof/JMapHProfLargeHeapTest.java failing
	because expects HPROF JAVA PROFILE 1.0.1 file format
In-Reply-To: <56D71B2B.8070902@oracle.com>
References: <56D71B2B.8070902@oracle.com>
Message-ID: <56D72C83.90908@oracle.com>

On 3/2/16 9:56 AM, Andreas Eriksson wrote:
> Hi,
>
> Can I please have a review for this small test fix.
>
> Bug: 8150986: serviceability/sa/jmap-hprof/JMapHProfLargeHeapTest.java 
> failing because expects HPROF JAVA PROFILE 1.0.1 file format
> https://bugs.openjdk.java.net/browse/JDK-8150986
> Webrev: http://cr.openjdk.java.net/~aeriksso/8150986/webrev/

test/serviceability/sa/jmap-hprof/JMapHProfLargeHeapTest.java
     L57: private static final String HPROF_HEADER_1_0_1 = "JAVA PROFILE 
1.0.1";

     This variable isn't used anymore. Do you want to delete it?
     Or do you want to leave it for documentation/historical purposes?

Thumbs up!

It would also be a good idea to search the various test suites for the
"JAVA PROFILE 1.0.1" pattern to see if there are any other tests that
might need to be updated.

Since this bug (8150986) is an integration_blocker, please feel free
to proceed with just this fix and do any follow-up work with a new bug.

Dan


>
> As part of JDK-8144732 
> <https://bugs.openjdk.java.net/browse/JDK-8144732> support for dumping 
> hprof with format 1.0.1 was removed, and we use format 1.0.2 always.
> I missed updating this test, which checks the header string in a heap 
> dump.
>
> Thanks,
> Andreas

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20160302/b2db9474/attachment-0001.html>

From dmitry.samersoff at oracle.com  Wed Mar  2 18:26:00 2016
From: dmitry.samersoff at oracle.com (Dmitry Samersoff)
Date: Wed, 2 Mar 2016 21:26:00 +0300
Subject: RFR (XS): 8150986:
	serviceability/sa/jmap-hprof/JMapHProfLargeHeapTest.java failing
	because expects HPROF JAVA PROFILE 1.0.1 file format
In-Reply-To: <56D71B2B.8070902@oracle.com>
References: <56D71B2B.8070902@oracle.com>
Message-ID: <56D73038.7080908@oracle.com>

Looks good for me!

On 2016-03-02 19:56, Andreas Eriksson wrote:
> Hi,
> 
> Can I please have a review for this small test fix.
> 
> Bug: 8150986: serviceability/sa/jmap-hprof/JMapHProfLargeHeapTest.java
> failing because expects HPROF JAVA PROFILE 1.0.1 file format
> https://bugs.openjdk.java.net/browse/JDK-8150986
> Webrev: http://cr.openjdk.java.net/~aeriksso/8150986/webrev/
> 
> As part of JDK-8144732
> <https://bugs.openjdk.java.net/browse/JDK-8144732> support for dumping
> hprof with format 1.0.1 was removed, and we use format 1.0.2 always.
> I missed updating this test, which checks the header string in a heap dump.
> 
> Thanks,
> Andreas


-- 
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the sources.

From andreas.eriksson at oracle.com  Wed Mar  2 19:49:33 2016
From: andreas.eriksson at oracle.com (Andreas Eriksson)
Date: Wed, 2 Mar 2016 20:49:33 +0100
Subject: RFR (XS): 8150986:
	serviceability/sa/jmap-hprof/JMapHProfLargeHeapTest.java failing
	because expects HPROF JAVA PROFILE 1.0.1 file format
In-Reply-To: <56D72C83.90908@oracle.com>
References: <56D71B2B.8070902@oracle.com> <56D72C83.90908@oracle.com>
Message-ID: <56D743CD.7010804@oracle.com>

Hi,

On 2016-03-02 19:10, Daniel D. Daugherty wrote:
> On 3/2/16 9:56 AM, Andreas Eriksson wrote:
>> Hi,
>>
>> Can I please have a review for this small test fix.
>>
>> Bug: 8150986: 
>> serviceability/sa/jmap-hprof/JMapHProfLargeHeapTest.java failing 
>> because expects HPROF JAVA PROFILE 1.0.1 file format
>> https://bugs.openjdk.java.net/browse/JDK-8150986
>> Webrev: http://cr.openjdk.java.net/~aeriksso/8150986/webrev/
>
> test/serviceability/sa/jmap-hprof/JMapHProfLargeHeapTest.java
>     L57: private static final String HPROF_HEADER_1_0_1 = "JAVA 
> PROFILE 1.0.1";
>
>     This variable isn't used anymore. Do you want to delete it?
>     Or do you want to leave it for documentation/historical purposes?

Yes, I'll delete it.
Uploaded a new webrev:
http://cr.openjdk.java.net/~aeriksso/8150986/webrev.02/

Also updated copyright year.

>
> Thumbs up!
>
> It would also be a good idea to search the various test suites for the
> "JAVA PROFILE 1.0.1" pattern to see if there are any other tests that
> might need to be updated.
>

I found no more tests with a quick search.

Thanks,
Andreas


> Since this bug (8150986) is an integration_blocker, please feel free
> to proceed with just this fix and do any follow-up work with a new bug.
>
> Dan
>
>
>>
>> As part of JDK-8144732 
>> <https://bugs.openjdk.java.net/browse/JDK-8144732> support for 
>> dumping hprof with format 1.0.1 was removed, and we use format 1.0.2 
>> always.
>> I missed updating this test, which checks the header string in a heap 
>> dump.
>>
>> Thanks,
>> Andreas
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20160302/d0e170a5/attachment.html>

From andreas.eriksson at oracle.com  Wed Mar  2 19:49:54 2016
From: andreas.eriksson at oracle.com (Andreas Eriksson)
Date: Wed, 2 Mar 2016 20:49:54 +0100
Subject: RFR (XS): 8150986:
	serviceability/sa/jmap-hprof/JMapHProfLargeHeapTest.java failing
	because expects HPROF JAVA PROFILE 1.0.1 file format
In-Reply-To: <56D73038.7080908@oracle.com>
References: <56D71B2B.8070902@oracle.com> <56D73038.7080908@oracle.com>
Message-ID: <56D743E2.2090609@oracle.com>

Thanks Dmitry.

- Andreas

On 2016-03-02 19:26, Dmitry Samersoff wrote:
> Looks good for me!
>
> On 2016-03-02 19:56, Andreas Eriksson wrote:
>> Hi,
>>
>> Can I please have a review for this small test fix.
>>
>> Bug: 8150986: serviceability/sa/jmap-hprof/JMapHProfLargeHeapTest.java
>> failing because expects HPROF JAVA PROFILE 1.0.1 file format
>> https://bugs.openjdk.java.net/browse/JDK-8150986
>> Webrev: http://cr.openjdk.java.net/~aeriksso/8150986/webrev/
>>
>> As part of JDK-8144732
>> <https://bugs.openjdk.java.net/browse/JDK-8144732> support for dumping
>> hprof with format 1.0.1 was removed, and we use format 1.0.2 always.
>> I missed updating this test, which checks the header string in a heap dump.
>>
>> Thanks,
>> Andreas
>


From markus.gronlund at oracle.com  Wed Mar  2 19:49:59 2016
From: markus.gronlund at oracle.com (Markus Gronlund)
Date: Wed, 2 Mar 2016 11:49:59 -0800 (PST)
Subject: RFR(XXS): 8151053: com/sun/jdi/StepTest.java fails in 2016-03-01
	JDK9-hs-rt nightly
Message-ID: <ad5af650-b83e-4326-a474-ce6ae0fc2673@default>

Greetings,

 

Could a please ask for reviews for the following simple fix to resolve a test issue associated with com/sun/jdi/StepTest.java

 

Bug: https://bugs.openjdk.java.net/browse/JDK-8151053

 

Comment:

Need to filter out some classes that has moved to another package

 

Patch is attached.

 

Thanks in advance

Markus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20160302/401218af/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 8151053.patch
Type: application/octet-stream
Size: 739 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20160302/401218af/8151053.patch>

From daniel.daugherty at oracle.com  Wed Mar  2 20:24:45 2016
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Wed, 2 Mar 2016 13:24:45 -0700
Subject: RFR(XXS): 8151053: com/sun/jdi/StepTest.java fails in 2016-03-01
	JDK9-hs-rt nightly
In-Reply-To: <ad5af650-b83e-4326-a474-ce6ae0fc2673@default>
References: <ad5af650-b83e-4326-a474-ce6ae0fc2673@default>
Message-ID: <56D74C0D.1020503@oracle.com>

On 3/2/16 12:49 PM, Markus Gronlund wrote:
>
> Greetings,
>
> Could a please ask for reviews for the following simple fix to resolve 
> a test issue associated with com/sun/jdi/StepTest.java
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8151053
>
> Comment:
>
> Need to filter out some classes that has moved to another package
>
> Patch is attached.
>

Thumbs up on the one liner addition to test/com/sun/jdi/TestScaffold.java

@@ -752,6 +752,7 @@
          sr.addClassExclusionFilter("com.oracle.*");
          sr.addClassExclusionFilter("oracle.*");
          sr.addClassExclusionFilter("jdk.internal.*");
+        sr.addClassExclusionFilter("jdk.jfr.*");
          sr.addCountFilter(1);
          sr.enable();
          StepEvent retEvent = (StepEvent)waitForRequestedEvent(sr);


Dan


> Thanks in advance
>
> Markus
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20160302/1a50a113/attachment-0001.html>

From markus.gronlund at oracle.com  Wed Mar  2 20:24:34 2016
From: markus.gronlund at oracle.com (Markus Gronlund)
Date: Wed, 2 Mar 2016 12:24:34 -0800 (PST)
Subject: RFR(XXS): 8151053: com/sun/jdi/StepTest.java fails in 2016-03-01
	JDK9-hs-rt nightly
In-Reply-To: <56D74C0D.1020503@oracle.com>
References: <ad5af650-b83e-4326-a474-ce6ae0fc2673@default>
	<56D74C0D.1020503@oracle.com>
Message-ID: <920d76f6-c3fb-4e73-86aa-1f57a0b34f52@default>

Thank you Dan!

 

/Markus

 

From: Daniel D. Daugherty 
Sent: den 2 mars 2016 21:25
To: Markus Gronlund; serviceability-dev
Subject: Re: RFR(XXS): 8151053: com/sun/jdi/StepTest.java fails in 2016-03-01 JDK9-hs-rt nightly

 

On 3/2/16 12:49 PM, Markus Gronlund wrote:



Greetings,

 

Could a please ask for reviews for the following simple fix to resolve a test issue associated with com/sun/jdi/StepTest.java

 

Bug: https://bugs.openjdk.java.net/browse/JDK-8151053

 

Comment:

Need to filter out some classes that has moved to another package

 

Patch is attached.

 
Thumbs up on the one liner addition to test/com/sun/jdi/TestScaffold.java

@@ -752,6 +752,7 @@
         sr.addClassExclusionFilter("com.oracle.*");
         sr.addClassExclusionFilter("oracle.*");
         sr.addClassExclusionFilter("jdk.internal.*");
+        sr.addClassExclusionFilter("jdk.jfr.*");
         sr.addCountFilter(1);
         sr.enable();
         StepEvent retEvent = (StepEvent)waitForRequestedEvent(sr);


Dan





 

Thanks in advance

Markus

 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20160302/60eb7b7b/attachment.html>

From erik.gahlin at oracle.com  Wed Mar  2 20:30:25 2016
From: erik.gahlin at oracle.com (Erik Gahlin)
Date: Wed, 2 Mar 2016 21:30:25 +0100
Subject: RFR(XXS): 8151053: com/sun/jdi/StepTest.java fails in 2016-03-01
	JDK9-hs-rt nightly
In-Reply-To: <ad5af650-b83e-4326-a474-ce6ae0fc2673@default>
References: <ad5af650-b83e-4326-a474-ce6ae0fc2673@default>
Message-ID: <56D74D61.4040709@oracle.com>

Looks good. Not a reviewer.

Erik

On 2016-03-02 20:49, Markus Gronlund wrote:
>
> Greetings,
>
> Could a please ask for reviews for the following simple fix to resolve 
> a test issue associated with com/sun/jdi/StepTest.java
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8151053
>
> Comment:
>
> Need to filter out some classes that has moved to another package
>
> Patch is attached.
>
> Thanks in advance
>
> Markus
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20160302/4599ed5b/attachment.html>

From markus.gronlund at oracle.com  Wed Mar  2 20:36:05 2016
From: markus.gronlund at oracle.com (Markus Gronlund)
Date: Wed, 2 Mar 2016 12:36:05 -0800 (PST)
Subject: RFR(XXS): 8151053: com/sun/jdi/StepTest.java fails in 2016-03-01
	JDK9-hs-rt nightly
In-Reply-To: <56D74D61.4040709@oracle.com>
References: <ad5af650-b83e-4326-a474-ce6ae0fc2673@default>
	<56D74D61.4040709@oracle.com>
Message-ID: <9b529547-e83b-439a-8dd1-e911e86583e6@default>

Thanks you Erik!

 

Markus

 

From: Erik Gahlin 
Sent: den 2 mars 2016 21:30
To: serviceability-dev at openjdk.java.net
Subject: Re: RFR(XXS): 8151053: com/sun/jdi/StepTest.java fails in 2016-03-01 JDK9-hs-rt nightly

 

Looks good. Not a reviewer.

Erik

On 2016-03-02 20:49, Markus Gronlund wrote:

Greetings,

 

Could a please ask for reviews for the following simple fix to resolve a test issue associated with com/sun/jdi/StepTest.java

 

Bug: https://bugs.openjdk.java.net/browse/JDK-8151053

 

Comment:

Need to filter out some classes that has moved to another package

 

Patch is attached.

 

Thanks in advance

Markus

 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20160302/3a31775a/attachment.html>

From erik.gahlin at oracle.com  Wed Mar  2 22:08:17 2016
From: erik.gahlin at oracle.com (Erik Gahlin)
Date: Wed, 2 Mar 2016 23:08:17 +0100
Subject: RFR(XS) serviceability/sa/jmap-hprof/JMapHProfLargeHeapTest.java
	failing because expects HPROF JAVA PROFILE 1.0.1 file format
Message-ID: <56D76451.9030606@oracle.com>

Hi,

Could I have a review of a fix for

"8150986: serviceability/sa/jmap-hprof/JMapHProfLargeHeapTest.java 
failing because expects HPROF JAVA PROFILE 1.0.1 file format"
https://bugs.openjdk.java.net/browse/JDK-8150986

It's a test update to accommodate the removal of 1.0.1 HPROF file format 
support that happened with
https://bugs.openjdk.java.net/browse/JDK-8144732

Thanks
Erik

diff --git 
a/test/serviceability/sa/jmap-hprof/JMapHProfLargeHeapTest.java 
b/test/serviceability/sa/jmap-hprof/JMapHProfLargeHeapTest.java
--- a/test/serviceability/sa/jmap-hprof/JMapHProfLargeHeapTest.java
+++ b/test/serviceability/sa/jmap-hprof/JMapHProfLargeHeapTest.java
@@ -54,7 +54,6 @@

  public class JMapHProfLargeHeapTest {
      private static final String HEAP_DUMP_FILE_NAME = "heap.hprof";
-    private static final String HPROF_HEADER_1_0_1 = "JAVA PROFILE 1.0.1";
      private static final String HPROF_HEADER_1_0_2 = "JAVA PROFILE 1.0.2";
      private static final long M = 1024L;
      private static final long G = 1024L * M;
@@ -79,17 +78,7 @@
              }
          }

-        // Small heap 22 megabytes, should create 1.0.1 file format
-        testHProfFileFormat("-Xmx1g", 22 * M, HPROF_HEADER_1_0_1);
-
-        /**
-         * This test was deliberately commented out since the test 
system lacks
-         * support to handle the requirements for this kind of heap 
size in a
-         * good way. If or when it becomes possible to run this kind of 
tests in
-         * the test environment the test should be enabled again.
-         * */
-        // Large heap 2,2 gigabytes, should create 1.0.2 file format
-        // testHProfFileFormat("-Xmx4g", 2 * G + 2 * M, 
HPROF_HEADER_1_0_2);
+        testHProfFileFormat("-Xmx1g", 22 * M, HPROF_HEADER_1_0_2);
      }

      private static void testHProfFileFormat(String vmArgs, long heapSize,

From markus.gronlund at oracle.com  Wed Mar  2 22:18:13 2016
From: markus.gronlund at oracle.com (Markus Gronlund)
Date: Wed, 2 Mar 2016 14:18:13 -0800 (PST)
Subject: RFR(XS) serviceability/sa/jmap-hprof/JMapHProfLargeHeapTest.java
	failing because expects HPROF JAVA PROFILE 1.0.1 file format
In-Reply-To: <56D76451.9030606@oracle.com>
References: <56D76451.9030606@oracle.com>
Message-ID: <60240211-5051-402e-8b93-98752da1b959@default>

Hi Erik,

I think this looks good.

Thanks for fixing.

Markus

-----Original Message-----
From: Erik Gahlin 
Sent: den 2 mars 2016 23:08
To: serviceability-dev at openjdk.java.net
Subject: RFR(XS) serviceability/sa/jmap-hprof/JMapHProfLargeHeapTest.java failing because expects HPROF JAVA PROFILE 1.0.1 file format

Hi,

Could I have a review of a fix for

"8150986: serviceability/sa/jmap-hprof/JMapHProfLargeHeapTest.java
failing because expects HPROF JAVA PROFILE 1.0.1 file format"
https://bugs.openjdk.java.net/browse/JDK-8150986

It's a test update to accommodate the removal of 1.0.1 HPROF file format support that happened with
https://bugs.openjdk.java.net/browse/JDK-8144732

Thanks
Erik

diff --git
a/test/serviceability/sa/jmap-hprof/JMapHProfLargeHeapTest.java
b/test/serviceability/sa/jmap-hprof/JMapHProfLargeHeapTest.java
--- a/test/serviceability/sa/jmap-hprof/JMapHProfLargeHeapTest.java
+++ b/test/serviceability/sa/jmap-hprof/JMapHProfLargeHeapTest.java
@@ -54,7 +54,6 @@

  public class JMapHProfLargeHeapTest {
      private static final String HEAP_DUMP_FILE_NAME = "heap.hprof";
-    private static final String HPROF_HEADER_1_0_1 = "JAVA PROFILE 1.0.1";
      private static final String HPROF_HEADER_1_0_2 = "JAVA PROFILE 1.0.2";
      private static final long M = 1024L;
      private static final long G = 1024L * M; @@ -79,17 +78,7 @@
              }
          }

-        // Small heap 22 megabytes, should create 1.0.1 file format
-        testHProfFileFormat("-Xmx1g", 22 * M, HPROF_HEADER_1_0_1);
-
-        /**
-         * This test was deliberately commented out since the test 
system lacks
-         * support to handle the requirements for this kind of heap 
size in a
-         * good way. If or when it becomes possible to run this kind of 
tests in
-         * the test environment the test should be enabled again.
-         * */
-        // Large heap 2,2 gigabytes, should create 1.0.2 file format
-        // testHProfFileFormat("-Xmx4g", 2 * G + 2 * M, 
HPROF_HEADER_1_0_2);
+        testHProfFileFormat("-Xmx1g", 22 * M, HPROF_HEADER_1_0_2);
      }

      private static void testHProfFileFormat(String vmArgs, long heapSize,

From daniel.daugherty at oracle.com  Wed Mar  2 23:08:48 2016
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Wed, 2 Mar 2016 16:08:48 -0700
Subject: RFR(XS) serviceability/sa/jmap-hprof/JMapHProfLargeHeapTest.java
	failing because expects HPROF JAVA PROFILE 1.0.1 file format
In-Reply-To: <60240211-5051-402e-8b93-98752da1b959@default>
References: <56D76451.9030606@oracle.com>
	<60240211-5051-402e-8b93-98752da1b959@default>
Message-ID: <56D77280.9080802@oracle.com>

Hi Erik,

I reviewed a different fix for the same bug from Andreas E.
earlier today.

Dan

On 3/2/16 3:18 PM, Markus Gronlund wrote:
> Hi Erik,
>
> I think this looks good.
>
> Thanks for fixing.
>
> Markus
>
> -----Original Message-----
> From: Erik Gahlin
> Sent: den 2 mars 2016 23:08
> To: serviceability-dev at openjdk.java.net
> Subject: RFR(XS) serviceability/sa/jmap-hprof/JMapHProfLargeHeapTest.java failing because expects HPROF JAVA PROFILE 1.0.1 file format
>
> Hi,
>
> Could I have a review of a fix for
>
> "8150986: serviceability/sa/jmap-hprof/JMapHProfLargeHeapTest.java
> failing because expects HPROF JAVA PROFILE 1.0.1 file format"
> https://bugs.openjdk.java.net/browse/JDK-8150986
>
> It's a test update to accommodate the removal of 1.0.1 HPROF file format support that happened with
> https://bugs.openjdk.java.net/browse/JDK-8144732
>
> Thanks
> Erik
>
> diff --git
> a/test/serviceability/sa/jmap-hprof/JMapHProfLargeHeapTest.java
> b/test/serviceability/sa/jmap-hprof/JMapHProfLargeHeapTest.java
> --- a/test/serviceability/sa/jmap-hprof/JMapHProfLargeHeapTest.java
> +++ b/test/serviceability/sa/jmap-hprof/JMapHProfLargeHeapTest.java
> @@ -54,7 +54,6 @@
>
>    public class JMapHProfLargeHeapTest {
>        private static final String HEAP_DUMP_FILE_NAME = "heap.hprof";
> -    private static final String HPROF_HEADER_1_0_1 = "JAVA PROFILE 1.0.1";
>        private static final String HPROF_HEADER_1_0_2 = "JAVA PROFILE 1.0.2";
>        private static final long M = 1024L;
>        private static final long G = 1024L * M; @@ -79,17 +78,7 @@
>                }
>            }
>
> -        // Small heap 22 megabytes, should create 1.0.1 file format
> -        testHProfFileFormat("-Xmx1g", 22 * M, HPROF_HEADER_1_0_1);
> -
> -        /**
> -         * This test was deliberately commented out since the test
> system lacks
> -         * support to handle the requirements for this kind of heap
> size in a
> -         * good way. If or when it becomes possible to run this kind of
> tests in
> -         * the test environment the test should be enabled again.
> -         * */
> -        // Large heap 2,2 gigabytes, should create 1.0.2 file format
> -        // testHProfFileFormat("-Xmx4g", 2 * G + 2 * M,
> HPROF_HEADER_1_0_2);
> +        testHProfFileFormat("-Xmx1g", 22 * M, HPROF_HEADER_1_0_2);
>        }
>
>        private static void testHProfFileFormat(String vmArgs, long heapSize,


From daniel.daugherty at oracle.com  Wed Mar  2 23:14:24 2016
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Wed, 2 Mar 2016 16:14:24 -0700
Subject: RFR(XS) serviceability/sa/jmap-hprof/JMapHProfLargeHeapTest.java
	failing because expects HPROF JAVA PROFILE 1.0.1 file format
In-Reply-To: <56D77280.9080802@oracle.com>
References: <56D76451.9030606@oracle.com>
	<60240211-5051-402e-8b93-98752da1b959@default>
	<56D77280.9080802@oracle.com>
Message-ID: <56D773D0.7070703@oracle.com>

Just caught up on the bug updates so now I see that you (Erik G)
have taken over the bug...

I'm good with this fix also...

Dan


On 3/2/16 4:08 PM, Daniel D. Daugherty wrote:
> Hi Erik,
>
> I reviewed a different fix for the same bug from Andreas E.
> earlier today.
>
> Dan
>
> On 3/2/16 3:18 PM, Markus Gronlund wrote:
>> Hi Erik,
>>
>> I think this looks good.
>>
>> Thanks for fixing.
>>
>> Markus
>>
>> -----Original Message-----
>> From: Erik Gahlin
>> Sent: den 2 mars 2016 23:08
>> To: serviceability-dev at openjdk.java.net
>> Subject: RFR(XS) 
>> serviceability/sa/jmap-hprof/JMapHProfLargeHeapTest.java failing 
>> because expects HPROF JAVA PROFILE 1.0.1 file format
>>
>> Hi,
>>
>> Could I have a review of a fix for
>>
>> "8150986: serviceability/sa/jmap-hprof/JMapHProfLargeHeapTest.java
>> failing because expects HPROF JAVA PROFILE 1.0.1 file format"
>> https://bugs.openjdk.java.net/browse/JDK-8150986
>>
>> It's a test update to accommodate the removal of 1.0.1 HPROF file 
>> format support that happened with
>> https://bugs.openjdk.java.net/browse/JDK-8144732
>>
>> Thanks
>> Erik
>>
>> diff --git
>> a/test/serviceability/sa/jmap-hprof/JMapHProfLargeHeapTest.java
>> b/test/serviceability/sa/jmap-hprof/JMapHProfLargeHeapTest.java
>> --- a/test/serviceability/sa/jmap-hprof/JMapHProfLargeHeapTest.java
>> +++ b/test/serviceability/sa/jmap-hprof/JMapHProfLargeHeapTest.java
>> @@ -54,7 +54,6 @@
>>
>>    public class JMapHProfLargeHeapTest {
>>        private static final String HEAP_DUMP_FILE_NAME = "heap.hprof";
>> -    private static final String HPROF_HEADER_1_0_1 = "JAVA PROFILE 
>> 1.0.1";
>>        private static final String HPROF_HEADER_1_0_2 = "JAVA PROFILE 
>> 1.0.2";
>>        private static final long M = 1024L;
>>        private static final long G = 1024L * M; @@ -79,17 +78,7 @@
>>                }
>>            }
>>
>> -        // Small heap 22 megabytes, should create 1.0.1 file format
>> -        testHProfFileFormat("-Xmx1g", 22 * M, HPROF_HEADER_1_0_1);
>> -
>> -        /**
>> -         * This test was deliberately commented out since the test
>> system lacks
>> -         * support to handle the requirements for this kind of heap
>> size in a
>> -         * good way. If or when it becomes possible to run this kind of
>> tests in
>> -         * the test environment the test should be enabled again.
>> -         * */
>> -        // Large heap 2,2 gigabytes, should create 1.0.2 file format
>> -        // testHProfFileFormat("-Xmx4g", 2 * G + 2 * M,
>> HPROF_HEADER_1_0_2);
>> +        testHProfFileFormat("-Xmx1g", 22 * M, HPROF_HEADER_1_0_2);
>>        }
>>
>>        private static void testHProfFileFormat(String vmArgs, long 
>> heapSize,
>
>


From erik.gahlin at oracle.com  Wed Mar  2 23:24:55 2016
From: erik.gahlin at oracle.com (Erik Gahlin)
Date: Thu, 3 Mar 2016 00:24:55 +0100
Subject: RFR(XS) serviceability/sa/jmap-hprof/JMapHProfLargeHeapTest.java
	failing because expects HPROF JAVA PROFILE 1.0.1 file format
In-Reply-To: <56D773D0.7070703@oracle.com>
References: <56D76451.9030606@oracle.com>
	<60240211-5051-402e-8b93-98752da1b959@default>
	<56D77280.9080802@oracle.com> <56D773D0.7070703@oracle.com>
Message-ID: <56D77647.5070005@oracle.com>

Thanks Dan,

I missed that Andreas has started working on the bug and sent out a review.

Sorry about that. I will reassign back to Andreas.

Erik

On 2016-03-03 00:14, Daniel D. Daugherty wrote:
> Just caught up on the bug updates so now I see that you (Erik G)
> have taken over the bug...
>
> I'm good with this fix also...
>
> Dan
>
>
> On 3/2/16 4:08 PM, Daniel D. Daugherty wrote:
>> Hi Erik,
>>
>> I reviewed a different fix for the same bug from Andreas E.
>> earlier today.
>>
>> Dan
>>
>> On 3/2/16 3:18 PM, Markus Gronlund wrote:
>>> Hi Erik,
>>>
>>> I think this looks good.
>>>
>>> Thanks for fixing.
>>>
>>> Markus
>>>
>>> -----Original Message-----
>>> From: Erik Gahlin
>>> Sent: den 2 mars 2016 23:08
>>> To: serviceability-dev at openjdk.java.net
>>> Subject: RFR(XS) 
>>> serviceability/sa/jmap-hprof/JMapHProfLargeHeapTest.java failing 
>>> because expects HPROF JAVA PROFILE 1.0.1 file format
>>>
>>> Hi,
>>>
>>> Could I have a review of a fix for
>>>
>>> "8150986: serviceability/sa/jmap-hprof/JMapHProfLargeHeapTest.java
>>> failing because expects HPROF JAVA PROFILE 1.0.1 file format"
>>> https://bugs.openjdk.java.net/browse/JDK-8150986
>>>
>>> It's a test update to accommodate the removal of 1.0.1 HPROF file 
>>> format support that happened with
>>> https://bugs.openjdk.java.net/browse/JDK-8144732
>>>
>>> Thanks
>>> Erik
>>>
>>> diff --git
>>> a/test/serviceability/sa/jmap-hprof/JMapHProfLargeHeapTest.java
>>> b/test/serviceability/sa/jmap-hprof/JMapHProfLargeHeapTest.java
>>> --- a/test/serviceability/sa/jmap-hprof/JMapHProfLargeHeapTest.java
>>> +++ b/test/serviceability/sa/jmap-hprof/JMapHProfLargeHeapTest.java
>>> @@ -54,7 +54,6 @@
>>>
>>>    public class JMapHProfLargeHeapTest {
>>>        private static final String HEAP_DUMP_FILE_NAME = "heap.hprof";
>>> -    private static final String HPROF_HEADER_1_0_1 = "JAVA PROFILE 
>>> 1.0.1";
>>>        private static final String HPROF_HEADER_1_0_2 = "JAVA 
>>> PROFILE 1.0.2";
>>>        private static final long M = 1024L;
>>>        private static final long G = 1024L * M; @@ -79,17 +78,7 @@
>>>                }
>>>            }
>>>
>>> -        // Small heap 22 megabytes, should create 1.0.1 file format
>>> -        testHProfFileFormat("-Xmx1g", 22 * M, HPROF_HEADER_1_0_1);
>>> -
>>> -        /**
>>> -         * This test was deliberately commented out since the test
>>> system lacks
>>> -         * support to handle the requirements for this kind of heap
>>> size in a
>>> -         * good way. If or when it becomes possible to run this 
>>> kind of
>>> tests in
>>> -         * the test environment the test should be enabled again.
>>> -         * */
>>> -        // Large heap 2,2 gigabytes, should create 1.0.2 file format
>>> -        // testHProfFileFormat("-Xmx4g", 2 * G + 2 * M,
>>> HPROF_HEADER_1_0_2);
>>> +        testHProfFileFormat("-Xmx1g", 22 * M, HPROF_HEADER_1_0_2);
>>>        }
>>>
>>>        private static void testHProfFileFormat(String vmArgs, long 
>>> heapSize,
>>
>>
>


From markus.gronlund at oracle.com  Thu Mar  3 00:15:51 2016
From: markus.gronlund at oracle.com (Markus Gronlund)
Date: Wed, 2 Mar 2016 16:15:51 -0800 (PST)
Subject: RFR(XXS): 8151100: Test
	java/lang/instrument/NativeMethodPrefixAgent.java can't attempt to do
	CheckIntrinsics
Message-ID: <fec6026d-892c-4494-8e19-9602e12a9900@default>

Greetings,

 

Could a please ask for reviews for the following simple fix to resolve a test issue associated with test/java/lang/instrument/NativeMethodPrefixAgent.java

 

Bug: https://bugs.openjdk.java.net/browse/JDK-8151100 

 

Webrev/diff:

 

diff --git a/test/java/lang/instrument/NativeMethodPrefixAgent.java b/test/java/lang/instrument/NativeMethodPrefixAgent.java

--- a/test/java/lang/instrument/NativeMethodPrefixAgent.java

+++ b/test/java/lang/instrument/NativeMethodPrefixAgent.java

@@ -31,7 +31,7 @@

  *          java.management

  *          java.instrument

  * @run shell/timeout=240 MakeJAR2.sh NativeMethodPrefixAgent NativeMethodPrefixApp 'Can-Retransform-Classes: true' 'Can-Set-Native-Method-Prefix: true'

- * @run main/othervm -javaagent:NativeMethodPrefixAgent.jar NativeMethodPrefixApp

+ * @run main/othervm -XX:-CheckIntrinsics -javaagent:NativeMethodPrefixAgent.jar NativeMethodPrefixApp

  */

 import java.lang.instrument.*;

 

Description:

 

The java/lang/instrument/NativeMethodPrefixAgent.java modifies (wraps) the names of native methods.

If a class is loaded that contain the @HotSpotIntrinsicCandidate annotation on a native method, one step of the class file parser is an attempt to validate the method name against a registered intrinsic in the VM.

 

By default, the flag CheckIntrinsics is true, which will yield:

 

"Method [<class>.wrapped_tr0_wrapped_tr1_wrapped_tr2_<original_method_name>()<return>] is annotated with @HotSpotIntrinsicCandidate, but no compiler intrinsic is defined for the method. Exiting."

This "wrapped" prepending to the method name invalidates the intrinsic check. 

 

In order for the test to pass even when loading a class with a native method containing the @HotSpotIntrinsicCandidate annotation, the test should explicitly disable the CheckIntrinsics flag: 

 

-XX:-CheckIntrinsics

 

Thanks in advance

Markus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20160302/5cff8ae9/attachment.html>

From erik.gahlin at oracle.com  Thu Mar  3 00:39:35 2016
From: erik.gahlin at oracle.com (Erik Gahlin)
Date: Thu, 3 Mar 2016 01:39:35 +0100
Subject: RFR(XXS): 8151100: Test
	java/lang/instrument/NativeMethodPrefixAgent.java can't attempt to do
	CheckIntrinsics
In-Reply-To: <fec6026d-892c-4494-8e19-9602e12a9900@default>
References: <fec6026d-892c-4494-8e19-9602e12a9900@default>
Message-ID: <56D787C7.8030908@oracle.com>

Looks good!

Erik

Den 03/03/16 kl. 01:15, skrev Markus Gronlund:
>
> Greetings,
>
> Could a please ask for reviews for the following simple fix to resolve 
> a test issue associated with 
> test/java/lang/instrument/NativeMethodPrefixAgent.java
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8151100
>
> Webrev/diff:
>
> diff --git a/test/java/lang/instrument/NativeMethodPrefixAgent.java 
> b/test/java/lang/instrument/NativeMethodPrefixAgent.java
>
> --- a/test/java/lang/instrument/NativeMethodPrefixAgent.java
>
> +++ b/test/java/lang/instrument/NativeMethodPrefixAgent.java
>
> @@ -31,7 +31,7 @@
>
>   * java.management
>
>   * java.instrument
>
>   * @run shell/timeout=240 MakeJAR2.sh NativeMethodPrefixAgent 
> NativeMethodPrefixApp 'Can-Retransform-Classes: true' 
> 'Can-Set-Native-Method-Prefix: true'
>
> - * @run main/othervm -javaagent:NativeMethodPrefixAgent.jar 
> NativeMethodPrefixApp
>
> + * @run main/othervm -XX:-CheckIntrinsics 
> -javaagent:NativeMethodPrefixAgent.jar NativeMethodPrefixApp
>
> */
>
>  import java.lang.instrument.*;
>
> Description:
>
> The java/lang/instrument/NativeMethodPrefixAgent.java modifies (wraps) 
> the names of native methods.
>
> If a class is loaded that contain the @HotSpotIntrinsicCandidate 
> annotation on a native method, one step of the class file parser is an 
> attempt to validate the method name against a registered intrinsic in 
> the VM.
>
> By default, the flag CheckIntrinsics is true, which will yield:
>
> ?Method 
> [<class>.wrapped_tr0_wrapped_tr1_wrapped_tr2_<original_method_name>()<return>] 
> is annotated with @HotSpotIntrinsicCandidate, but no compiler 
> intrinsic is defined for the method. Exiting.?
>
> This "wrapped" prepending to the method name invalidates the intrinsic 
> check.
>
> In order for the test to pass even when loading a class with a native 
> method containing the @HotSpotIntrinsicCandidate annotation, the test 
> should explicitly disable the CheckIntrinsics flag:
>
> -XX:-CheckIntrinsics
>
> Thanks in advance
>
> Markus
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20160303/e549b4f7/attachment-0001.html>

From robbin.ehn at oracle.com  Thu Mar  3 06:41:37 2016
From: robbin.ehn at oracle.com (Robbin Ehn)
Date: Thu, 3 Mar 2016 07:41:37 +0100
Subject: PING Re: RFR(s): 8150026: Add the ability to log with variable log
	level
In-Reply-To: <56D41BFD.5080909@oracle.com>
References: <56C61D86.4010409@oracle.com> <56D41BFD.5080909@oracle.com>
Message-ID: <56D7DCA1.9080704@oracle.com>

Hi,

Could someone else also please review this?

On 02/29/2016 11:22 AM, Marcus Larsson wrote:
> Hi Robbin,
>
> On 02/18/2016 08:37 PM, Robbin Ehn wrote:
>> Hi, please review.
>>
>> This adds a write method to the UL log which takes the level as
>> parameter.
>>
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8150026
>> Webrev: http://cr.openjdk.java.net/~mlarsson/rehn/8150026/
>
> Looks good, thanks for fixing this.
>
> Marcus

Thanks Marcus!

/R

>
>>
>> Tested ok with rbt hotspot_all.
>>
>> Thanks!
>>
>> /Robbin
>

From bengt.rutisson at oracle.com  Thu Mar  3 08:35:11 2016
From: bengt.rutisson at oracle.com (Bengt Rutisson)
Date: Thu, 3 Mar 2016 09:35:11 +0100
Subject: PING Re: RFR(s): 8150026: Add the ability to log with variable
	log level
In-Reply-To: <56D7DCA1.9080704@oracle.com>
References: <56C61D86.4010409@oracle.com> <56D41BFD.5080909@oracle.com>
	<56D7DCA1.9080704@oracle.com>
Message-ID: <56D7F73F.4000502@oracle.com>


Hi Robbin,

On 2016-03-03 07:41, Robbin Ehn wrote:
> Hi,
>
> Could someone else also please review this?
>
> On 02/29/2016 11:22 AM, Marcus Larsson wrote:
>> Hi Robbin,
>>
>> On 02/18/2016 08:37 PM, Robbin Ehn wrote:
>>> Hi, please review.
>>>
>>> This adds a write method to the UL log which takes the level as
>>> parameter.
>>>
>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8150026
>>> Webrev: http://cr.openjdk.java.net/~mlarsson/rehn/8150026/
>>
>> Looks good, thanks for fixing this.

Looks good to me too.

Bengt

>>
>> Marcus
>
> Thanks Marcus!
>
> /R
>
>>
>>>
>>> Tested ok with rbt hotspot_all.
>>>
>>> Thanks!
>>>
>>> /Robbin
>>


From robbin.ehn at oracle.com  Thu Mar  3 08:44:54 2016
From: robbin.ehn at oracle.com (Robbin Ehn)
Date: Thu, 3 Mar 2016 09:44:54 +0100
Subject: PING Re: RFR(s): 8150026: Add the ability to log with variable
	log level
In-Reply-To: <56D7F73F.4000502@oracle.com>
References: <56C61D86.4010409@oracle.com> <56D41BFD.5080909@oracle.com>
	<56D7DCA1.9080704@oracle.com> <56D7F73F.4000502@oracle.com>
Message-ID: <56D7F986.6060601@oracle.com>

Thanks Bengt!

/Robbin

On 03/03/2016 09:35 AM, Bengt Rutisson wrote:
>
> Hi Robbin,
>
> On 2016-03-03 07:41, Robbin Ehn wrote:
>> Hi,
>>
>> Could someone else also please review this?
>>
>> On 02/29/2016 11:22 AM, Marcus Larsson wrote:
>>> Hi Robbin,
>>>
>>> On 02/18/2016 08:37 PM, Robbin Ehn wrote:
>>>> Hi, please review.
>>>>
>>>> This adds a write method to the UL log which takes the level as
>>>> parameter.
>>>>
>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8150026
>>>> Webrev: http://cr.openjdk.java.net/~mlarsson/rehn/8150026/
>>>
>>> Looks good, thanks for fixing this.
>
> Looks good to me too.
>
> Bengt
>
>>>
>>> Marcus
>>
>> Thanks Marcus!
>>
>> /R
>>
>>>
>>>>
>>>> Tested ok with rbt hotspot_all.
>>>>
>>>> Thanks!
>>>>
>>>> /Robbin
>>>
>

From serguei.spitsyn at oracle.com  Thu Mar  3 09:18:04 2016
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Thu, 3 Mar 2016 01:18:04 -0800
Subject: RFR(XXS): 8151100: Test
	java/lang/instrument/NativeMethodPrefixAgent.java can't attempt to do
	CheckIntrinsics
In-Reply-To: <fec6026d-892c-4494-8e19-9602e12a9900@default>
References: <fec6026d-892c-4494-8e19-9602e12a9900@default>
Message-ID: <56D8014C.3030607@oracle.com>

Hi Markus,

The fix looks good.

Thanks,
Serguei


On 3/2/16 16:15, Markus Gronlund wrote:
>
> Greetings,
>
> Could a please ask for reviews for the following simple fix to resolve 
> a test issue associated with 
> test/java/lang/instrument/NativeMethodPrefixAgent.java
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8151100
>
> Webrev/diff:
>
> diff --git a/test/java/lang/instrument/NativeMethodPrefixAgent.java 
> b/test/java/lang/instrument/NativeMethodPrefixAgent.java
>
> --- a/test/java/lang/instrument/NativeMethodPrefixAgent.java
>
> +++ b/test/java/lang/instrument/NativeMethodPrefixAgent.java
>
> @@ -31,7 +31,7 @@
>
>   * java.management
>
>   * java.instrument
>
>   * @run shell/timeout=240 MakeJAR2.sh NativeMethodPrefixAgent 
> NativeMethodPrefixApp 'Can-Retransform-Classes: true' 
> 'Can-Set-Native-Method-Prefix: true'
>
> - * @run main/othervm -javaagent:NativeMethodPrefixAgent.jar 
> NativeMethodPrefixApp
>
> + * @run main/othervm -XX:-CheckIntrinsics 
> -javaagent:NativeMethodPrefixAgent.jar NativeMethodPrefixApp
>
> */
>
>  import java.lang.instrument.*;
>
> Description:
>
> The java/lang/instrument/NativeMethodPrefixAgent.java modifies (wraps) 
> the names of native methods.
>
> If a class is loaded that contain the @HotSpotIntrinsicCandidate 
> annotation on a native method, one step of the class file parser is an 
> attempt to validate the method name against a registered intrinsic in 
> the VM.
>
> By default, the flag CheckIntrinsics is true, which will yield:
>
> ?Method 
> [<class>.wrapped_tr0_wrapped_tr1_wrapped_tr2_<original_method_name>()<return>] 
> is annotated with @HotSpotIntrinsicCandidate, but no compiler 
> intrinsic is defined for the method. Exiting.?
>
> This "wrapped" prepending to the method name invalidates the intrinsic 
> check.
>
> In order for the test to pass even when loading a class with a native 
> method containing the @HotSpotIntrinsicCandidate annotation, the test 
> should explicitly disable the CheckIntrinsics flag:
>
> -XX:-CheckIntrinsics
>
> Thanks in advance
>
> Markus
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20160303/fbaff1c9/attachment.html>

From markus.gronlund at oracle.com  Thu Mar  3 10:48:36 2016
From: markus.gronlund at oracle.com (Markus Gronlund)
Date: Thu, 3 Mar 2016 02:48:36 -0800 (PST)
Subject: RFR(XXS): 8151100: Test
	java/lang/instrument/NativeMethodPrefixAgent.java can't attempt to do
	CheckIntrinsics
In-Reply-To: <56D8014C.3030607@oracle.com>
References: <fec6026d-892c-4494-8e19-9602e12a9900@default>
	<56D8014C.3030607@oracle.com>
Message-ID: <b8d9feed-7ae3-4d81-b0ed-8ab2437cb95a@default>

Thank you Serguei!

 

Markus

 

From: Serguei Spitsyn 
Sent: den 3 mars 2016 10:18
To: Markus Gronlund; serviceability-dev at openjdk.java.net
Subject: Re: RFR(XXS): 8151100: Test java/lang/instrument/NativeMethodPrefixAgent.java can't attempt to do CheckIntrinsics

 

Hi Markus,

The fix looks good.

Thanks,
Serguei


On 3/2/16 16:15, Markus Gronlund wrote:

Greetings,

 

Could a please ask for reviews for the following simple fix to resolve a test issue associated with test/java/lang/instrument/NativeMethodPrefixAgent.java

 

Bug: https://bugs.openjdk.java.net/browse/JDK-8151100 

 

Webrev/diff:

 

diff --git a/test/java/lang/instrument/NativeMethodPrefixAgent.java b/test/java/lang/instrument/NativeMethodPrefixAgent.java

--- a/test/java/lang/instrument/NativeMethodPrefixAgent.java

+++ b/test/java/lang/instrument/NativeMethodPrefixAgent.java

@@ -31,7 +31,7 @@

  *          java.management

  *          java.instrument

  * @run shell/timeout=240 MakeJAR2.sh NativeMethodPrefixAgent NativeMethodPrefixApp 'Can-Retransform-Classes: true' 'Can-Set-Native-Method-Prefix: true'

- * @run main/othervm -javaagent:NativeMethodPrefixAgent.jar NativeMethodPrefixApp

+ * @run main/othervm -XX:-CheckIntrinsics -javaagent:NativeMethodPrefixAgent.jar NativeMethodPrefixApp

  */

 import java.lang.instrument.*;

 

Description:

 

The java/lang/instrument/NativeMethodPrefixAgent.java modifies (wraps) the names of native methods.

If a class is loaded that contain the @HotSpotIntrinsicCandidate annotation on a native method, one step of the class file parser is an attempt to validate the method name against a registered intrinsic in the VM.

 

By default, the flag CheckIntrinsics is true, which will yield:

 

"Method [<class>.wrapped_tr0_wrapped_tr1_wrapped_tr2_<original_method_name>()<return>] is annotated with @HotSpotIntrinsicCandidate, but no compiler intrinsic is defined for the method. Exiting."

This "wrapped" prepending to the method name invalidates the intrinsic check. 

 

In order for the test to pass even when loading a class with a native method containing the @HotSpotIntrinsicCandidate annotation, the test should explicitly disable the CheckIntrinsics flag: 

 

-XX:-CheckIntrinsics

 

Thanks in advance

Markus

 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20160303/eb0d9f78/attachment-0001.html>

From dmitry.dmitriev at oracle.com  Thu Mar  3 11:23:28 2016
From: dmitry.dmitriev at oracle.com (Dmitry Dmitriev)
Date: Thu, 3 Mar 2016 14:23:28 +0300
Subject: RFR(XXS): 8151100: Test
	java/lang/instrument/NativeMethodPrefixAgent.java can't attempt to do
	CheckIntrinsics
In-Reply-To: <fec6026d-892c-4494-8e19-9602e12a9900@default>
References: <fec6026d-892c-4494-8e19-9602e12a9900@default>
Message-ID: <56D81EB0.2060706@oracle.com>

Hello Markus,

CheckIntrinsics is a diagnostic flag. I think you need to add 
-XX:+UnlockDiagnosticVMOptions before it because otherwise test will 
fail on product build.

Thanks,
Dmitry

On 03.03.2016 3:15, Markus Gronlund wrote:
>
> Greetings,
>
> Could a please ask for reviews for the following simple fix to resolve 
> a test issue associated with 
> test/java/lang/instrument/NativeMethodPrefixAgent.java
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8151100
>
> Webrev/diff:
>
> diff --git a/test/java/lang/instrument/NativeMethodPrefixAgent.java 
> b/test/java/lang/instrument/NativeMethodPrefixAgent.java
>
> --- a/test/java/lang/instrument/NativeMethodPrefixAgent.java
>
> +++ b/test/java/lang/instrument/NativeMethodPrefixAgent.java
>
> @@ -31,7 +31,7 @@
>
>   * java.management
>
>   * java.instrument
>
>   * @run shell/timeout=240 MakeJAR2.sh NativeMethodPrefixAgent 
> NativeMethodPrefixApp 'Can-Retransform-Classes: true' 
> 'Can-Set-Native-Method-Prefix: true'
>
> - * @run main/othervm -javaagent:NativeMethodPrefixAgent.jar 
> NativeMethodPrefixApp
>
> + * @run main/othervm -XX:-CheckIntrinsics 
> -javaagent:NativeMethodPrefixAgent.jar NativeMethodPrefixApp
>
> */
>
>  import java.lang.instrument.*;
>
> Description:
>
> The java/lang/instrument/NativeMethodPrefixAgent.java modifies (wraps) 
> the names of native methods.
>
> If a class is loaded that contain the @HotSpotIntrinsicCandidate 
> annotation on a native method, one step of the class file parser is an 
> attempt to validate the method name against a registered intrinsic in 
> the VM.
>
> By default, the flag CheckIntrinsics is true, which will yield:
>
> ?Method 
> [<class>.wrapped_tr0_wrapped_tr1_wrapped_tr2_<original_method_name>()<return>] 
> is annotated with @HotSpotIntrinsicCandidate, but no compiler 
> intrinsic is defined for the method. Exiting.?
>
> This "wrapped" prepending to the method name invalidates the intrinsic 
> check.
>
> In order for the test to pass even when loading a class with a native 
> method containing the @HotSpotIntrinsicCandidate annotation, the test 
> should explicitly disable the CheckIntrinsics flag:
>
> -XX:-CheckIntrinsics
>
> Thanks in advance
>
> Markus
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20160303/f0c93509/attachment.html>

From markus.gronlund at oracle.com  Thu Mar  3 11:25:56 2016
From: markus.gronlund at oracle.com (Markus Gronlund)
Date: Thu, 3 Mar 2016 03:25:56 -0800 (PST)
Subject: RFR(XXS): 8151100: Test
	java/lang/instrument/NativeMethodPrefixAgent.java can't attempt to do
	CheckIntrinsics
In-Reply-To: <56D81EB0.2060706@oracle.com>
References: <fec6026d-892c-4494-8e19-9602e12a9900@default>
	<56D81EB0.2060706@oracle.com>
Message-ID: <8bfa40af-f284-4f01-adf2-8f6d8da8d591@default>

Thanks Dmitry  for noticing this - I am running slowdebug so I didn't see that.

 

Thanks again.

Markus

 

 

From: Dmitry Dmitriev 
Sent: den 3 mars 2016 12:23
To: Markus Gronlund; serviceability-dev at openjdk.java.net
Subject: Re: RFR(XXS): 8151100: Test java/lang/instrument/NativeMethodPrefixAgent.java can't attempt to do CheckIntrinsics

 

Hello Markus,

CheckIntrinsics is a diagnostic flag. I think you need to add -XX:+UnlockDiagnosticVMOptions before it because otherwise test will fail on product build.

Thanks,
Dmitry 

On 03.03.2016 3:15, Markus Gronlund wrote:

Greetings,

 

Could a please ask for reviews for the following simple fix to resolve a test issue associated with test/java/lang/instrument/NativeMethodPrefixAgent.java

 

Bug: https://bugs.openjdk.java.net/browse/JDK-8151100 

 

Webrev/diff:

 

diff --git a/test/java/lang/instrument/NativeMethodPrefixAgent.java b/test/java/lang/instrument/NativeMethodPrefixAgent.java

--- a/test/java/lang/instrument/NativeMethodPrefixAgent.java

+++ b/test/java/lang/instrument/NativeMethodPrefixAgent.java

@@ -31,7 +31,7 @@

  *          java.management

  *          java.instrument

  * @run shell/timeout=240 MakeJAR2.sh NativeMethodPrefixAgent NativeMethodPrefixApp 'Can-Retransform-Classes: true' 'Can-Set-Native-Method-Prefix: true'

- * @run main/othervm -javaagent:NativeMethodPrefixAgent.jar NativeMethodPrefixApp

+ * @run main/othervm -XX:-CheckIntrinsics -javaagent:NativeMethodPrefixAgent.jar NativeMethodPrefixApp

  */

 import java.lang.instrument.*;

 

Description:

 

The java/lang/instrument/NativeMethodPrefixAgent.java modifies (wraps) the names of native methods.

If a class is loaded that contain the @HotSpotIntrinsicCandidate annotation on a native method, one step of the class file parser is an attempt to validate the method name against a registered intrinsic in the VM.

 

By default, the flag CheckIntrinsics is true, which will yield:

 

"Method [<class>.wrapped_tr0_wrapped_tr1_wrapped_tr2_<original_method_name>()<return>] is annotated with @HotSpotIntrinsicCandidate, but no compiler intrinsic is defined for the method. Exiting."

This "wrapped" prepending to the method name invalidates the intrinsic check. 

 

In order for the test to pass even when loading a class with a native method containing the @HotSpotIntrinsicCandidate annotation, the test should explicitly disable the CheckIntrinsics flag: 

 

-XX:-CheckIntrinsics

 

Thanks in advance

Markus

 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20160303/788bdfed/attachment.html>

From yasuenag at gmail.com  Thu Mar  3 13:23:54 2016
From: yasuenag at gmail.com (Yasumasa Suenaga)
Date: Thu, 3 Mar 2016 22:23:54 +0900
Subject: G1 STW phases and FGC column in jstat
In-Reply-To: <56D6F68B.3010409@gmail.com>
References: <56D5ADAC.5010701@gmail.com>
	<9430CE85-D805-495F-A2F7-314766E7492A@kodewerk.com>
	<56D61FC6.2070002@gmail.com>
	<11E54471-015C-49AE-8E5E-DA681AE3CD1A@kodewerk.com>
	<56D6E375.8010605@gmail.com>
	<46C36433-8BC0-454D-9C91-142D5C2AF552@kodewerk.com>
	<56D6F68B.3010409@gmail.com>
Message-ID: <56D83AEA.6010100@gmail.com>

Hi all,

I've uploaded PoC of PerfCounter for STW phase in concurrent GC:

   hotspot: http://cr.openjdk.java.net/~ysuenaga/perfcounter-for-cgc/hotspot/
       jdk: http://cr.openjdk.java.net/~ysuenaga/perfcounter-for-cgc/jdk/

These patches makes new jstat column CGC and CGCT as below:
-------------
$ jstat -gc 53494 3000
  S0C    S1C    S0U    S1U      EC       EU        OC         OU       MC     MU    CCSC   CCSU   YGC     YGCT    FGC    FGCT    CGC    CGCT     GCT
  0.0    0.0    0.0    0.0    4096.0    0.0     28672.0      0.0     4480.0 948.9  384.0   77.6       0    0.000   0      0.000   0      0.000    0.000
  0.0   1024.0  0.0   1024.0  3072.0    0.0     28672.0      0.0     4864.0 2969.0 512.0  276.0       1    0.063   0      0.000   2      0.016    0.080
-------------

They are shows STW phase in concurrent GC.

   CMS: Initial Mark and Remark
    G1: Remark and Cleanup

GCT is sum of YGCT, FGCT, and CGCT.


Can be this change accepted?
If so, I will file it to JBS and will send RFR.

I cannot access JPRT.
So I need a sponsor.


Thanks,

Yasumasa


On 2016/03/02 23:19, Yasumasa Suenaga wrote:
> It is not difficult to create webrev for this proposal.
> However, this proposal affects to jstat output, and
> I cannot access JPRT.
> So I want to find sponsor for it at first.
>
> Could somebody be a sponsor?
>
>
> Yasumasa
>
>
> On 2016/03/02 22:29, kirk at kodewerk.com wrote:
>> Hi Yasumasa,
>>
>> It all sounds reasonable and of course the impact on downstream tooling vs the value of the change must be evaluated. In this case I think adding a CGC counter makes sense especially in prep for G1 becoming default in 9.
>>
>> Regards,
>> Kirk
>>
>>> On Mar 2, 2016, at 6:58 AM, Yasumasa Suenaga <yasuenag at gmail.com> wrote:
>>>
>>> Hi Kirk,
>>>
>>> Agree to you.
>>> However, I use occasional FGC counter at CMS as below:
>>>
>>> 1. Check major collection occurrence
>>>       Some production systems have large memory as Java heap,
>>>       and they are not set GC log.
>>>       If their CPU usage becomes high, I want to check GC execution.
>>>       (Of course, we have to check any other points :-) )
>>>
>>> 2. Core image analysis
>>>       If JVM is crashed, I want to check PerfCounter to know situation.
>>>       (In the past, I sometimes encountered crash at GC worker thread.)
>>>
>>> I guess that I will want to check them at G1.
>>>
>>> Thus, at least, I want to add PerfCounter for CGC (and add JVMTI event hook).
>>> However, this proposal will affect to jstat spec.
>>> So I want to discuss about it before filing to JBS.
>>>
>>>
>>> Thanks,
>>>
>>> Yasumasa
>>>
>>>
>>> On 2016/03/02 19:02, kirk at kodewerk.com wrote:
>>>> Hi Yasumasa,
>>>>
>>>> Good question. I?ve never considered CMS to be a Full GC. This implies that there should be separate performance counters for CMS pause phases as it is possible to have FGC. Of course a FGC during CMS maybe user triggered, triggered outside a CMS cycle, interrupts a CMS cycle, or interrupts a CMS phase. I?m not sure how much of a distinction one needs to make here as that could be a quick broader discussion. Certainly the purpose isn?t to recreate the GC logs in these performance counters. But at the very least not having a distinction between full and a STW-CMS phase is kind of misleading in my opinion.
>>>>
>>>> Regards,
>>>> Kirk
>>>>
>>>>> On Mar 1, 2016, at 5:03 PM, Yasumasa Suenaga <yasuenag at gmail.com> wrote:
>>>>>
>>>>> Hi Kirk,
>>>>>
>>>>>> It is also incorrect to count initial mark and remark in CMS as a FGC.
>>>>>
>>>>> Though, how can we check execution of major collection without GC log?
>>>>> Should we add new PerfCounter for CGC (and add CGC column to jstat output)?
>>>>>
>>>>>
>>>>> Yasumasa
>>>>>
>>>>>
>>>>> On 2016/03/02 6:35, kirk at kodewerk.com wrote:
>>>>>> Hi,
>>>>>>
>>>>>> I think it is incorrect to count remark and cleanup as FGC. They are not full collections. It is also incorrect to count initial mark and remark in CMS as a FGC. It is unfortunate that this is counted this way.
>>>>>>
>>>>>> Regards,
>>>>>> Kirk
>>>>>>
>>>>>>> On Mar 1, 2016, at 8:56 AM, Yasumasa Suenaga <yasuenag at gmail.com> wrote:
>>>>>>>
>>>>>>> Hi all,
>>>>>>>
>>>>>>> I wonder that STW phases (Remark and Cleanup) at G1 are not counted in jstat FGC column.
>>>>>>> For example, Initial Mark and Remark at CMS are counted as FGC.
>>>>>>>
>>>>>>> For consistency, I think that G1 STW phases should be counted as FGC.
>>>>>>> What do you think about it?
>>>>>>>
>>>>>>> If it is accepted, I will file it to JBS and will upload webrev.
>>>>>>>
>>>>>>>
>>>>>>> suggested fix:
>>>>>>> ----------------------
>>>>>>> diff -r 8a103ba9a7b2 src/share/vm/gc/g1/g1MonitoringSupport.cpp
>>>>>>> --- a/src/share/vm/gc/g1/g1MonitoringSupport.cpp    Mon Feb 29 22:54:24 2016 +0900
>>>>>>> +++ b/src/share/vm/gc/g1/g1MonitoringSupport.cpp    Tue Mar 01 23:43:30 2016 +0900
>>>>>>> @@ -103,7 +103,7 @@
>>>>>>>    //   name "collector.1".  In a generational collector this would be the
>>>>>>>    // old generation collection.
>>>>>>>    _full_collection_counters =
>>>>>>> -    new CollectorCounters("G1 stop-the-world full collections", 1);
>>>>>>> +    new CollectorCounters("G1 stop-the-world phase", 1);
>>>>>>>
>>>>>>>    // timer sampling for all counters supporting sampling only update the
>>>>>>>    // used value.  See the take_sample() method.  G1 requires both used and
>>>>>>> diff -r 8a103ba9a7b2 src/share/vm/gc/g1/vm_operations_g1.cpp
>>>>>>> --- a/src/share/vm/gc/g1/vm_operations_g1.cpp    Mon Feb 29 22:54:24 2016 +0900
>>>>>>> +++ b/src/share/vm/gc/g1/vm_operations_g1.cpp    Tue Mar 01 23:43:30 2016 +0900
>>>>>>> @@ -230,6 +230,8 @@
>>>>>>>    G1CollectedHeap* g1h = G1CollectedHeap::heap();
>>>>>>>    GCTraceTime(Info, gc) t(_printGCMessage, g1h->gc_timer_cm(), GCCause::_no_gc, true);
>>>>>>>    IsGCActiveMark x;
>>>>>>> +  SvcGCMarker sgcm(SvcGCMarker::OTHER);
>>>>>>> +  TraceCollectorStats tcs(g1h->g1mm()->full_collection_counters());
>>>>>>>    _cl->do_void();
>>>>>>> }
>>>>>>>
>>>>>>> ----------------------
>>>>>>>
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> Yasumasa
>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>

From dmitry.samersoff at oracle.com  Thu Mar  3 13:55:07 2016
From: dmitry.samersoff at oracle.com (Dmitry Samersoff)
Date: Thu, 3 Mar 2016 16:55:07 +0300
Subject: JDK-8148659: Add all option to JSnap
In-Reply-To: <56ACDB68.9080505@gmail.com>
References: <56ACDB68.9080505@gmail.com>
Message-ID: <56D8423B.2020509@oracle.com>

Yasumasa,

Overall direction is to support jhsdb as the only entry point for SA and
all coredump related staff.

Could you move JSnap "into jhsdb".

And this change requires CCC approval (I'll file it for you)

-Dmitry

On 2016-01-30 18:48, Yasumasa Suenaga wrote:
> I want to add -a (all) option to JSnap because JSnap is very useful to analyze core image.
> 
> Currently, JSnap can show PerfDataEntry which namespace is java.* or com.sun.* .
> We can use jcmd with PerfCounter.print when we want to attach live process, however,
> as JDK-6224040 shows, we have to use JSnap.
> 
> In terms of core image analysis, -a option is very useful for troubleshooting.
> 
> I uploaded a webrev for this enhancement.
> Could you review it?
> 
>   http://cr.openjdk.java.net/~ysuenaga/JDK-8148659/webrev.00/
> 
> I'm jdk9 committer, however I cannot access JPRT.
> So I need a sponsor.
> 
> 
> Thanks,
> 
> Yasumasa
> 


-- 
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the sources.

From andreas.eriksson at oracle.com  Thu Mar  3 14:05:57 2016
From: andreas.eriksson at oracle.com (Andreas Eriksson)
Date: Thu, 3 Mar 2016 15:05:57 +0100
Subject: RFR (XS): 8151064: com/sun/jdi/RedefineAddPrivateMethod.sh fails
	intermittently
Message-ID: <56D844C5.2040408@oracle.com>

Hi,

Can I please have a review of this fix for
8151064: com/sun/jdi/RedefineAddPrivateMethod.sh fails intermittently
https://bugs.openjdk.java.net/browse/JDK-8151064

Webrev: http://cr.openjdk.java.net/~aeriksso/8151064/webrev/

Still not sure why it only fails sometimes, but after this change the 
test has not failed once after a couple of hours of testing. Before the 
change it would fail after ~5 minutes of running it in a loop.

Thanks,
Andreas

From dmitry.samersoff at oracle.com  Thu Mar  3 14:35:35 2016
From: dmitry.samersoff at oracle.com (Dmitry Samersoff)
Date: Thu, 3 Mar 2016 17:35:35 +0300
Subject: RFR (XS): 8151064: com/sun/jdi/RedefineAddPrivateMethod.sh fails
	intermittently
In-Reply-To: <56D844C5.2040408@oracle.com>
References: <56D844C5.2040408@oracle.com>
Message-ID: <56D84BB7.10606@oracle.com>

Andreas,

Looks good for me.

-Dmitry

On 2016-03-03 17:05, Andreas Eriksson wrote:
> Hi,
> 
> Can I please have a review of this fix for
> 8151064: com/sun/jdi/RedefineAddPrivateMethod.sh fails intermittently
> https://bugs.openjdk.java.net/browse/JDK-8151064
> 
> Webrev: http://cr.openjdk.java.net/~aeriksso/8151064/webrev/
> 
> Still not sure why it only fails sometimes, but after this change the
> test has not failed once after a couple of hours of testing. Before the
> change it would fail after ~5 minutes of running it in a loop.
> 
> Thanks,
> Andreas


-- 
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the sources.

From yasuenag at gmail.com  Thu Mar  3 14:43:19 2016
From: yasuenag at gmail.com (Yasumasa Suenaga)
Date: Thu, 3 Mar 2016 23:43:19 +0900
Subject: RFR: 8151181: Add JSnap to jhsdb
Message-ID: <56D84D87.9050308@gmail.com>

Hi all,

JSnap is useful SA tool to check PerfCounter. 
So I want to add it to jhsdb.

  http://cr.openjdk.java.net/~ysuenaga/JDK-8151181/webrev.00/

Could you review it?


Thanks,

Yasumasa

From yasuenag at gmail.com  Thu Mar  3 14:46:08 2016
From: yasuenag at gmail.com (Yasumasa Suenaga)
Date: Thu, 3 Mar 2016 23:46:08 +0900
Subject: JDK-8148659: Add all option to JSnap
In-Reply-To: <56D8423B.2020509@oracle.com>
References: <56ACDB68.9080505@gmail.com> <56D8423B.2020509@oracle.com>
Message-ID: <56D84E30.4090902@gmail.com>

Hi Dmitry,

> Overall direction is to support jhsdb as the only entry point for SA and
> all coredump related staff.

I'm working on another issue (JDK-8151181) for it.
  http://mail.openjdk.java.net/pipermail/serviceability-dev/2016-March/019007.html

After that, I will work for this issue (JDK-8148659) and adding all option
to JSnap.
  http://mail.openjdk.java.net/pipermail/serviceability-dev/2016-March/018962.html


Thanks,

Yasumasa


On 2016/03/03 22:55, Dmitry Samersoff wrote:
> Yasumasa,
> 
> Overall direction is to support jhsdb as the only entry point for SA and
> all coredump related staff.
> 
> Could you move JSnap "into jhsdb".
> 
> And this change requires CCC approval (I'll file it for you)
> 
> -Dmitry
> 
> On 2016-01-30 18:48, Yasumasa Suenaga wrote:
>> I want to add -a (all) option to JSnap because JSnap is very useful to analyze core image.
>>
>> Currently, JSnap can show PerfDataEntry which namespace is java.* or com.sun.* .
>> We can use jcmd with PerfCounter.print when we want to attach live process, however,
>> as JDK-6224040 shows, we have to use JSnap.
>>
>> In terms of core image analysis, -a option is very useful for troubleshooting.
>>
>> I uploaded a webrev for this enhancement.
>> Could you review it?
>>
>>    http://cr.openjdk.java.net/~ysuenaga/JDK-8148659/webrev.00/
>>
>> I'm jdk9 committer, however I cannot access JPRT.
>> So I need a sponsor.
>>
>>
>> Thanks,
>>
>> Yasumasa
>>
> 
> 

From dmitry.samersoff at oracle.com  Thu Mar  3 15:15:20 2016
From: dmitry.samersoff at oracle.com (Dmitry Samersoff)
Date: Thu, 3 Mar 2016 18:15:20 +0300
Subject: RFR: 8151181: Add JSnap to jhsdb
In-Reply-To: <56D84D87.9050308@gmail.com>
References: <56D84D87.9050308@gmail.com>
Message-ID: <56D85508.4060408@oracle.com>

Yasumasa,

It's better (with upcoming changes for JDK-8148659 in mind) to create a
separate

private static boolean jsnapHelp() {
   System.out.println(" <no option>\tdump perfromance counters");
   return commonHelp();
}

and write:

System.out.println(" jsnap --help\tto get more information");

Please also update:

   jdk/test/sun/tools/jhsdb/BasicLauncherTest.java

-Dmitry


On 2016-03-03 17:43, Yasumasa Suenaga wrote:
> Hi all,
> 
> JSnap is useful SA tool to check PerfCounter. 
> So I want to add it to jhsdb.
> 
>   http://cr.openjdk.java.net/~ysuenaga/JDK-8151181/webrev.00/
> 
> Could you review it?
> 
> 
> Thanks,
> 
> Yasumasa
> 


-- 
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the sources.

From andreas.eriksson at oracle.com  Thu Mar  3 15:21:21 2016
From: andreas.eriksson at oracle.com (Andreas Eriksson)
Date: Thu, 3 Mar 2016 16:21:21 +0100
Subject: RFR (XS): 8151064: com/sun/jdi/RedefineAddPrivateMethod.sh fails
	intermittently
In-Reply-To: <56D84BB7.10606@oracle.com>
References: <56D844C5.2040408@oracle.com> <56D84BB7.10606@oracle.com>
Message-ID: <56D85671.70203@oracle.com>

Thanks.

- Andreas

On 2016-03-03 15:35, Dmitry Samersoff wrote:
> Andreas,
>
> Looks good for me.
>
> -Dmitry
>
> On 2016-03-03 17:05, Andreas Eriksson wrote:
>> Hi,
>>
>> Can I please have a review of this fix for
>> 8151064: com/sun/jdi/RedefineAddPrivateMethod.sh fails intermittently
>> https://bugs.openjdk.java.net/browse/JDK-8151064
>>
>> Webrev: http://cr.openjdk.java.net/~aeriksso/8151064/webrev/
>>
>> Still not sure why it only fails sometimes, but after this change the
>> test has not failed once after a couple of hours of testing. Before the
>> change it would fail after ~5 minutes of running it in a loop.
>>
>> Thanks,
>> Andreas
>


From yasuenag at gmail.com  Thu Mar  3 15:45:57 2016
From: yasuenag at gmail.com (Yasumasa Suenaga)
Date: Fri, 4 Mar 2016 00:45:57 +0900
Subject: RFR: 8151181: Add JSnap to jhsdb
In-Reply-To: <56D85508.4060408@oracle.com>
References: <56D84D87.9050308@gmail.com> <56D85508.4060408@oracle.com>
Message-ID: <56D85C35.9020703@gmail.com>

Hi Dmitry,

Thank you for your comment.
I uploaded new webrev:

  hotspot: http://cr.openjdk.java.net/~ysuenaga/JDK-8151181/webrev.01/hotspot/
      jdk: http://cr.openjdk.java.net/~ysuenaga/JDK-8151181/webrev.01/jdk/


Could you review again?


Thanks,

Yasumasa


On 2016/03/04 0:15, Dmitry Samersoff wrote:
> Yasumasa,
> 
> It's better (with upcoming changes for JDK-8148659 in mind) to create a
> separate
> 
> private static boolean jsnapHelp() {
>     System.out.println(" <no option>\tdump perfromance counters");
>     return commonHelp();
> }
> 
> and write:
> 
> System.out.println(" jsnap --help\tto get more information");
> 
> Please also update:
> 
>     jdk/test/sun/tools/jhsdb/BasicLauncherTest.java
> 
> -Dmitry
> 
> 
> On 2016-03-03 17:43, Yasumasa Suenaga wrote:
>> Hi all,
>>
>> JSnap is useful SA tool to check PerfCounter.
>> So I want to add it to jhsdb.
>>
>>    http://cr.openjdk.java.net/~ysuenaga/JDK-8151181/webrev.00/
>>
>> Could you review it?
>>
>>
>> Thanks,
>>
>> Yasumasa
>>
> 
> 

From cheleswer.sahu at oracle.com  Thu Mar  3 16:28:58 2016
From: cheleswer.sahu at oracle.com (Cheleswer Sahu)
Date: Thu, 3 Mar 2016 08:28:58 -0800 (PST)
Subject: RFR[9u-dev]: 8146683: check_addr0 should be more efficient
In-Reply-To: <56CD11F5.9060002@oracle.com>
References: <38bc418b-c510-4ae8-8d8e-161b5ea42920@default>
	<CAA-vtUxV_93cfiFpR-PaMjbShAYqjCNtWwPAMGZ8-XPwG2t2ig@mail.gmail.com>
	<56CC9FF2.4040406@oracle.com> <56CD11F5.9060002@oracle.com>
Message-ID: <2fecd625-4723-4fbe-b148-36f7bb654df6@default>

Hi,

Please review the new code changes for this bug. I have removed  " fstat()"  call which seems not safe to read the "/proc/map/self" file and have made some other changes too. Please find the latest code in below link
Webrev link: http://cr.openjdk.java.net/~csahu/8146683/webrev.01/


Regards,
Cheleswer

-----Original Message-----
From: Dean Long 
Sent: Wednesday, February 24, 2016 7:44 AM
To: Daniel Daugherty; Thomas St?fe; Cheleswer Sahu
Cc: serviceability-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net
Subject: Re: RFR[9u-dev]: 8146683: check_addr0 should be more efficient

On 2/23/2016 10:07 AM, Daniel D. Daugherty wrote:
> On 2/23/16 5:56 AM, Thomas St?fe wrote:
>> Hi Cheleswer,
>>
>>
>> On Tue, Feb 23, 2016 at 9:38 AM, Cheleswer Sahu 
>> <cheleswer.sahu at oracle.com>
>>   wrote:
>>
>>> Hi,
>>>
>>>
>>>
>>> Please review the code changes for
>>> https://bugs.openjdk.java.net/browse/JDK-8146683 .
>>>
>>>
>>>
>>> Webrev link: http://cr.openjdk.java.net/~csahu/8146683/
>>>
>>> JBS Link: https://bugs.openjdk.java.net/browse/JDK-8146683
>>>
>>>
>>>
>>> Bug Brief:
>>>
>>> While investigating  bug
>>> https://bugs.openjdk.java.net/browse/JDK-8144483
>>> it has been observed that "check_addr0() " function  is not written 
>>> efficiently.
>>>
>>> This function is trying to read each "prmap_t" entry in 
>>> "/proc/self/map"
>>> file one by one which is time taking and can cause in long pauses.
>>>
>>>
>>>
>>> Solution proposed:
>>>
>>> Instead of reading each "prmap_t" entry in "/proc/self/map" file one 
>>> by one, read the entries in chunks. There can be many entries in "map"
>>> file,
>>> so I have decided to read these
>>>
>>> in chunks of 100  "prmap_t" entries. Reading entries in chunks saves 
>>> a lot of read calls and results in smaller pause times.
>>>
>>>
>>>
>>>
>>>
>>> Regards,
>>>
>>> Cheleswer
>>>
>>
>> We saw cases, especially on Solaris, where the content of a file in the
>> proc file system changed under us while we were reading it. So this 
>> should
>> be kept in mind. The original code seems also broken in that regard,
>> because it assumes the ::read() call to read the full size of a prmap_t
>> entry, but it may theoretically read an incomplete entry.
>>
>> As for your coding, you first estimate the size of the mapping file and
>> then use this to determine how many entries to read; but when 
>> reading, this
>> information may already be stale. I think it would be more robust and 
>> also
>> simpler to just try to read as many entries as possible - in chunks, to
>> make reading faster - until you get EOF.
>>
>> Kind Regards, Thomas
>
> I'm really sure that we've been down this road before. In particular,
> Dmitry Samersoff has worked on this issue (or one very much like it)
> before, but he is on vacation until the end of the month.
>

There was a similar issue with Linux /proc/self/maps, and whether it was 
safe to read the file with buffered stdio or not.  See 8009062 and 7017193.

dl

> Dan
>
>
>>
>> On Tue, Feb 23, 2016 at 9:38 AM, Cheleswer Sahu 
>> <cheleswer.sahu at oracle.com>
>> wrote:
>>
>>> Hi,
>>>
>>>
>>>
>>> Please review the code changes for
>>> https://bugs.openjdk.java.net/browse/JDK-8146683 .
>>>
>>>
>>>
>>> Webrev link: http://cr.openjdk.java.net/~csahu/8146683/
>>>
>>> JBS Link: https://bugs.openjdk.java.net/browse/JDK-8146683
>>>
>>>
>>>
>>> Bug Brief:
>>>
>>> While investigating  bug 
>>> https://bugs.openjdk.java.net/browse/JDK-8144483
>>> it has been observed that "check_addr0() " function  is not written
>>> efficiently.
>>>
>>> This function is trying to read each "prmap_t" entry in 
>>> "/proc/self/map"
>>> file one by one which is time taking and can cause in long pauses.
>>>
>>>
>>>
>>> Solution proposed:
>>>
>>> Instead of reading each "prmap_t" entry in "/proc/self/map" file one by
>>> one, read the entries in chunks. There can be many entries in "map" 
>>> file,
>>> so I have decided to read these
>>>
>>> in chunks of 100  "prmap_t" entries. Reading entries in chunks saves 
>>> a lot
>>> of read calls and results in smaller pause times.
>>>
>>>
>>>
>>>
>>>
>>> Regards,
>>>
>>> Cheleswer
>>>
>


From serguei.spitsyn at oracle.com  Thu Mar  3 16:54:53 2016
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Thu, 3 Mar 2016 08:54:53 -0800
Subject: RFR (XS): 8151064: com/sun/jdi/RedefineAddPrivateMethod.sh fails
	intermittently
In-Reply-To: <56D84BB7.10606@oracle.com>
References: <56D844C5.2040408@oracle.com> <56D84BB7.10606@oracle.com>
Message-ID: <56D86C5D.5010004@oracle.com>

Hi Andreas,

Good++

Thanks,
Serguei


On 3/3/16 06:35, Dmitry Samersoff wrote:
> Andreas,
>
> Looks good for me.
>
> -Dmitry
>
> On 2016-03-03 17:05, Andreas Eriksson wrote:
>> Hi,
>>
>> Can I please have a review of this fix for
>> 8151064: com/sun/jdi/RedefineAddPrivateMethod.sh fails intermittently
>> https://bugs.openjdk.java.net/browse/JDK-8151064
>>
>> Webrev: http://cr.openjdk.java.net/~aeriksso/8151064/webrev/
>>
>> Still not sure why it only fails sometimes, but after this change the
>> test has not failed once after a couple of hours of testing. Before the
>> change it would fail after ~5 minutes of running it in a loop.
>>
>> Thanks,
>> Andreas
>


From andreas.eriksson at oracle.com  Thu Mar  3 17:05:33 2016
From: andreas.eriksson at oracle.com (Andreas Eriksson)
Date: Thu, 3 Mar 2016 18:05:33 +0100
Subject: RFR (XS): 8151064: com/sun/jdi/RedefineAddPrivateMethod.sh fails
	intermittently
In-Reply-To: <56D86C5D.5010004@oracle.com>
References: <56D844C5.2040408@oracle.com> <56D84BB7.10606@oracle.com>
	<56D86C5D.5010004@oracle.com>
Message-ID: <56D86EDD.7060308@oracle.com>

Thanks Serguei.
I'll go ahead and push this now, since I believe this change is small 
enough.

- Andreas

On 2016-03-03 17:54, serguei.spitsyn at oracle.com wrote:
> Hi Andreas,
>
> Good++
>
> Thanks,
> Serguei
>
>
> On 3/3/16 06:35, Dmitry Samersoff wrote:
>> Andreas,
>>
>> Looks good for me.
>>
>> -Dmitry
>>
>> On 2016-03-03 17:05, Andreas Eriksson wrote:
>>> Hi,
>>>
>>> Can I please have a review of this fix for
>>> 8151064: com/sun/jdi/RedefineAddPrivateMethod.sh fails intermittently
>>> https://bugs.openjdk.java.net/browse/JDK-8151064
>>>
>>> Webrev: http://cr.openjdk.java.net/~aeriksso/8151064/webrev/
>>>
>>> Still not sure why it only fails sometimes, but after this change the
>>> test has not failed once after a couple of hours of testing. Before the
>>> change it would fail after ~5 minutes of running it in a loop.
>>>
>>> Thanks,
>>> Andreas
>>
>


From dmitry.samersoff at oracle.com  Thu Mar  3 17:06:33 2016
From: dmitry.samersoff at oracle.com (Dmitry Samersoff)
Date: Thu, 3 Mar 2016 20:06:33 +0300
Subject: RFR: 8151181: Add JSnap to jhsdb
In-Reply-To: <56D85C35.9020703@gmail.com>
References: <56D84D87.9050308@gmail.com> <56D85508.4060408@oracle.com>
	<56D85C35.9020703@gmail.com>
Message-ID: <56D86F19.5070500@oracle.com>

Yasumasa,

91 s/perfromance/performance/

Test:

146         launch("compiler detected.", "jsnap");


Please, choose expectedMessage carefully, I'm not sure "compiler
detected." is an appropriate one.

-Dmitry


On 2016-03-03 18:45, Yasumasa Suenaga wrote:
> Hi Dmitry,
> 
> Thank you for your comment.
> I uploaded new webrev:
> 
>   hotspot: http://cr.openjdk.java.net/~ysuenaga/JDK-8151181/webrev.01/hotspot/
>       jdk: http://cr.openjdk.java.net/~ysuenaga/JDK-8151181/webrev.01/jdk/
> 
> 
> Could you review again?
> 
> 
> Thanks,
> 
> Yasumasa
> 
> 
> On 2016/03/04 0:15, Dmitry Samersoff wrote:
>> Yasumasa,
>>
>> It's better (with upcoming changes for JDK-8148659 in mind) to create a
>> separate
>>
>> private static boolean jsnapHelp() {
>>     System.out.println(" <no option>\tdump perfromance counters");
>>     return commonHelp();
>> }
>>
>> and write:
>>
>> System.out.println(" jsnap --help\tto get more information");
>>
>> Please also update:
>>
>>     jdk/test/sun/tools/jhsdb/BasicLauncherTest.java
>>
>> -Dmitry
>>
>>
>> On 2016-03-03 17:43, Yasumasa Suenaga wrote:
>>> Hi all,
>>>
>>> JSnap is useful SA tool to check PerfCounter.
>>> So I want to add it to jhsdb.
>>>
>>>    http://cr.openjdk.java.net/~ysuenaga/JDK-8151181/webrev.00/
>>>
>>> Could you review it?
>>>
>>>
>>> Thanks,
>>>
>>> Yasumasa
>>>
>>
>>


-- 
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the sources.

From daniel.daugherty at oracle.com  Thu Mar  3 17:29:14 2016
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Thu, 3 Mar 2016 10:29:14 -0700
Subject: RFR (XS): 8151064: com/sun/jdi/RedefineAddPrivateMethod.sh fails
	intermittently
In-Reply-To: <56D86EDD.7060308@oracle.com>
References: <56D844C5.2040408@oracle.com> <56D84BB7.10606@oracle.com>
	<56D86C5D.5010004@oracle.com> <56D86EDD.7060308@oracle.com>
Message-ID: <56D8746A.2040301@oracle.com>

 > Webrev: http://cr.openjdk.java.net/~aeriksso/8151064/webrev/

test/com/sun/jdi/RedefineAddPrivateMethod.sh
     L38:         System.out.println("@1 breakpoint");
     L39:         System.out.println("@2 breakpoint");

         With these tests, this is usually done like this:

         System.out.println("stop here for breakpoint 1");  // @1 breakpoint
         System.out.println("stop here for breakpoint 2");  // @2 breakpoint

     I _think_ the scaffold stuff can handle the way you did
     it on all platforms, but I'm not sure. Sorry, my memory
     is a bit rusty on this stuff.

     Thumbs up on the original version or you can change it to
     the above. Your choice.

Dan

P.S.

It occurs to me that in the original code the main() method
is empty, i.e., just comment lines. I have a vague memory
about empty methods being treated differently in HotSpot,
but I don't remember the exact details...



On 3/3/16 10:05 AM, Andreas Eriksson wrote:
> Thanks Serguei.
> I'll go ahead and push this now, since I believe this change is small 
> enough.
>
> - Andreas
>
> On 2016-03-03 17:54, serguei.spitsyn at oracle.com wrote:
>> Hi Andreas,
>>
>> Good++
>>
>> Thanks,
>> Serguei
>>
>>
>> On 3/3/16 06:35, Dmitry Samersoff wrote:
>>> Andreas,
>>>
>>> Looks good for me.
>>>
>>> -Dmitry
>>>
>>> On 2016-03-03 17:05, Andreas Eriksson wrote:
>>>> Hi,
>>>>
>>>> Can I please have a review of this fix for
>>>> 8151064: com/sun/jdi/RedefineAddPrivateMethod.sh fails intermittently
>>>> https://bugs.openjdk.java.net/browse/JDK-8151064
>>>>
>>>> Webrev: http://cr.openjdk.java.net/~aeriksso/8151064/webrev/
>>>>
>>>> Still not sure why it only fails sometimes, but after this change the
>>>> test has not failed once after a couple of hours of testing. Before 
>>>> the
>>>> change it would fail after ~5 minutes of running it in a loop.
>>>>
>>>> Thanks,
>>>> Andreas
>>>
>>
>


From andreas.eriksson at oracle.com  Thu Mar  3 19:56:38 2016
From: andreas.eriksson at oracle.com (Andreas Eriksson)
Date: Thu, 3 Mar 2016 20:56:38 +0100
Subject: RFR (XS): 8151064: com/sun/jdi/RedefineAddPrivateMethod.sh fails
	intermittently
In-Reply-To: <56D8746A.2040301@oracle.com>
References: <56D844C5.2040408@oracle.com> <56D84BB7.10606@oracle.com>
	<56D86C5D.5010004@oracle.com> <56D86EDD.7060308@oracle.com>
	<56D8746A.2040301@oracle.com>
Message-ID: <56D896F6.1050404@oracle.com>



On 2016-03-03 18:29, Daniel D. Daugherty wrote:
> > Webrev: http://cr.openjdk.java.net/~aeriksso/8151064/webrev/
>
> test/com/sun/jdi/RedefineAddPrivateMethod.sh
>     L38:         System.out.println("@1 breakpoint");
>     L39:         System.out.println("@2 breakpoint");
>
>         With these tests, this is usually done like this:
>
>         System.out.println("stop here for breakpoint 1");  // @1 
> breakpoint
>         System.out.println("stop here for breakpoint 2");  // @2 
> breakpoint
>
>     I _think_ the scaffold stuff can handle the way you did
>     it on all platforms, but I'm not sure. Sorry, my memory
>     is a bit rusty on this stuff.
>
>     Thumbs up on the original version or you can change it to
>     the above. Your choice.

Sorry, saw this after I had already pushed with the original version.
But other tests did similar things:
RedefineException.sh - line 83: System.out.println("a3: @1 breakpoint 
here a3");
And it ran fine through RBT, so hopefully it should be no problem.

>
> Dan
>
> P.S.
>
> It occurs to me that in the original code the main() method
> is empty, i.e., just comment lines. I have a vague memory
> about empty methods being treated differently in HotSpot,
> but I don't remember the exact details...
>

What was weird is that it only failed sometimes. I'll take a look 
tomorrow to see if I can find out why, but I probably wont spend too 
much time on it.

Thanks,
Andreas

>
>
> On 3/3/16 10:05 AM, Andreas Eriksson wrote:
>> Thanks Serguei.
>> I'll go ahead and push this now, since I believe this change is small 
>> enough.
>>
>> - Andreas
>>
>> On 2016-03-03 17:54, serguei.spitsyn at oracle.com wrote:
>>> Hi Andreas,
>>>
>>> Good++
>>>
>>> Thanks,
>>> Serguei
>>>
>>>
>>> On 3/3/16 06:35, Dmitry Samersoff wrote:
>>>> Andreas,
>>>>
>>>> Looks good for me.
>>>>
>>>> -Dmitry
>>>>
>>>> On 2016-03-03 17:05, Andreas Eriksson wrote:
>>>>> Hi,
>>>>>
>>>>> Can I please have a review of this fix for
>>>>> 8151064: com/sun/jdi/RedefineAddPrivateMethod.sh fails intermittently
>>>>> https://bugs.openjdk.java.net/browse/JDK-8151064
>>>>>
>>>>> Webrev: http://cr.openjdk.java.net/~aeriksso/8151064/webrev/
>>>>>
>>>>> Still not sure why it only fails sometimes, but after this change the
>>>>> test has not failed once after a couple of hours of testing. 
>>>>> Before the
>>>>> change it would fail after ~5 minutes of running it in a loop.
>>>>>
>>>>> Thanks,
>>>>> Andreas
>>>>
>>>
>>
>


From daniel.daugherty at oracle.com  Thu Mar  3 20:43:36 2016
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Thu, 3 Mar 2016 13:43:36 -0700
Subject: RFR (XS): 8151064: com/sun/jdi/RedefineAddPrivateMethod.sh fails
	intermittently
In-Reply-To: <56D896F6.1050404@oracle.com>
References: <56D844C5.2040408@oracle.com> <56D84BB7.10606@oracle.com>
	<56D86C5D.5010004@oracle.com> <56D86EDD.7060308@oracle.com>
	<56D8746A.2040301@oracle.com> <56D896F6.1050404@oracle.com>
Message-ID: <56D8A1F8.70806@oracle.com>

On 3/3/16 12:56 PM, Andreas Eriksson wrote:
>
>
> On 2016-03-03 18:29, Daniel D. Daugherty wrote:
>> > Webrev: http://cr.openjdk.java.net/~aeriksso/8151064/webrev/
>>
>> test/com/sun/jdi/RedefineAddPrivateMethod.sh
>>     L38:         System.out.println("@1 breakpoint");
>>     L39:         System.out.println("@2 breakpoint");
>>
>>         With these tests, this is usually done like this:
>>
>>         System.out.println("stop here for breakpoint 1");  // @1 
>> breakpoint
>>         System.out.println("stop here for breakpoint 2");  // @2 
>> breakpoint
>>
>>     I _think_ the scaffold stuff can handle the way you did
>>     it on all platforms, but I'm not sure. Sorry, my memory
>>     is a bit rusty on this stuff.
>>
>>     Thumbs up on the original version or you can change it to
>>     the above. Your choice.
>
> Sorry, saw this after I had already pushed with the original version.
> But other tests did similar things:
> RedefineException.sh - line 83: System.out.println("a3: @1 breakpoint 
> here a3");
> And it ran fine through RBT, so hopefully it should be no problem.

Sounds good to me...


>
>>
>> Dan
>>
>> P.S.
>>
>> It occurs to me that in the original code the main() method
>> is empty, i.e., just comment lines. I have a vague memory
>> about empty methods being treated differently in HotSpot,
>> but I don't remember the exact details...
>>
>
> What was weird is that it only failed sometimes. I'll take a look 
> tomorrow to see if I can find out why, but I probably wont spend too 
> much time on it.

In the original .jtr file:

Java HotSpot(TM) 64-Bit Server VM (fastdebug build 
9-internal+0-2016-03-02-004742.mgronlun.upstream, mixed mode)

Since we're in -Xmixed mode, the compiler could kick in, but
on such a short-lived test? I'm dubious...

Good hunting tomorrow!

Dan


>
> Thanks,
> Andreas
>
>>
>>
>> On 3/3/16 10:05 AM, Andreas Eriksson wrote:
>>> Thanks Serguei.
>>> I'll go ahead and push this now, since I believe this change is 
>>> small enough.
>>>
>>> - Andreas
>>>
>>> On 2016-03-03 17:54, serguei.spitsyn at oracle.com wrote:
>>>> Hi Andreas,
>>>>
>>>> Good++
>>>>
>>>> Thanks,
>>>> Serguei
>>>>
>>>>
>>>> On 3/3/16 06:35, Dmitry Samersoff wrote:
>>>>> Andreas,
>>>>>
>>>>> Looks good for me.
>>>>>
>>>>> -Dmitry
>>>>>
>>>>> On 2016-03-03 17:05, Andreas Eriksson wrote:
>>>>>> Hi,
>>>>>>
>>>>>> Can I please have a review of this fix for
>>>>>> 8151064: com/sun/jdi/RedefineAddPrivateMethod.sh fails 
>>>>>> intermittently
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8151064
>>>>>>
>>>>>> Webrev: http://cr.openjdk.java.net/~aeriksso/8151064/webrev/
>>>>>>
>>>>>> Still not sure why it only fails sometimes, but after this change 
>>>>>> the
>>>>>> test has not failed once after a couple of hours of testing. 
>>>>>> Before the
>>>>>> change it would fail after ~5 minutes of running it in a loop.
>>>>>>
>>>>>> Thanks,
>>>>>> Andreas
>>>>>
>>>>
>>>
>>
>


From yasuenag at gmail.com  Fri Mar  4 03:33:16 2016
From: yasuenag at gmail.com (Yasumasa Suenaga)
Date: Fri, 4 Mar 2016 12:33:16 +0900
Subject: RFR: 8151181: Add JSnap to jhsdb
In-Reply-To: <56D86F19.5070500@oracle.com>
References: <56D84D87.9050308@gmail.com> <56D85508.4060408@oracle.com>
	<56D85C35.9020703@gmail.com> <56D86F19.5070500@oracle.com>
Message-ID: <56D901FC.4020507@gmail.com>

Hi Dmitry,

I uploaded new webrev:

  hotspot (not changed): http://cr.openjdk.java.net/~ysuenaga/JDK-8151181/webrev.02/hotspot/
                    jdk: http://cr.openjdk.java.net/~ysuenaga/JDK-8151181/webrev.02/jdk/

Could you review it again?


BTW, jmap test uses "compiler detected" as expected message.
Should I fix it? (Should I file it as another test bug?)


Thanks,

Yasumasa


On 2016/03/04 2:06, Dmitry Samersoff wrote:
> Yasumasa,
> 
> 91 s/perfromance/performance/
> 
> Test:
> 
> 146         launch("compiler detected.", "jsnap");
> 
> 
> Please, choose expectedMessage carefully, I'm not sure "compiler
> detected." is an appropriate one.
> 
> -Dmitry
> 
> 
> On 2016-03-03 18:45, Yasumasa Suenaga wrote:
>> Hi Dmitry,
>>
>> Thank you for your comment.
>> I uploaded new webrev:
>>
>>    hotspot: http://cr.openjdk.java.net/~ysuenaga/JDK-8151181/webrev.01/hotspot/
>>        jdk: http://cr.openjdk.java.net/~ysuenaga/JDK-8151181/webrev.01/jdk/
>>
>>
>> Could you review again?
>>
>>
>> Thanks,
>>
>> Yasumasa
>>
>>
>> On 2016/03/04 0:15, Dmitry Samersoff wrote:
>>> Yasumasa,
>>>
>>> It's better (with upcoming changes for JDK-8148659 in mind) to create a
>>> separate
>>>
>>> private static boolean jsnapHelp() {
>>>      System.out.println(" <no option>\tdump perfromance counters");
>>>      return commonHelp();
>>> }
>>>
>>> and write:
>>>
>>> System.out.println(" jsnap --help\tto get more information");
>>>
>>> Please also update:
>>>
>>>      jdk/test/sun/tools/jhsdb/BasicLauncherTest.java
>>>
>>> -Dmitry
>>>
>>>
>>> On 2016-03-03 17:43, Yasumasa Suenaga wrote:
>>>> Hi all,
>>>>
>>>> JSnap is useful SA tool to check PerfCounter.
>>>> So I want to add it to jhsdb.
>>>>
>>>>     http://cr.openjdk.java.net/~ysuenaga/JDK-8151181/webrev.00/
>>>>
>>>> Could you review it?
>>>>
>>>>
>>>> Thanks,
>>>>
>>>> Yasumasa
>>>>
>>>
>>>
> 
> 

From dmitry.samersoff at oracle.com  Fri Mar  4 07:59:25 2016
From: dmitry.samersoff at oracle.com (Dmitry Samersoff)
Date: Fri, 4 Mar 2016 10:59:25 +0300
Subject: RFR: 8151181: Add JSnap to jhsdb
In-Reply-To: <56D901FC.4020507@gmail.com>
References: <56D84D87.9050308@gmail.com> <56D85508.4060408@oracle.com>
	<56D85C35.9020703@gmail.com> <56D86F19.5070500@oracle.com>
	<56D901FC.4020507@gmail.com>
Message-ID: <56D9405D.8000902@oracle.com>

Yasumasa,

1. Changes looks good for me, but please fix a typeo in
hotspot/SALauncher.java (no need to re-review)

91 s/perfromance/performance/

2. Simple jmap output looks like

dooku:test#/opt/jdk9/bin/jmap 6379
Attaching to process ID 6379, please wait...
Debugger attached successfully.
Server compiler detected.
JVM version is 9-internal+0-2016-02-29-173800.dms.hs-rt
0x0000000000400000      8K      /opt/jdk9/bin/java
....

So "compiler detected" is acceptable message to test that jmap is
launched and attached successfully. Not the best one but it works on all
platfroms.

-Dmitry

On 2016-03-04 06:33, Yasumasa Suenaga wrote:
> Hi Dmitry,
> 
> I uploaded new webrev:
> 
>   hotspot (not changed): http://cr.openjdk.java.net/~ysuenaga/JDK-8151181/webrev.02/hotspot/
>                     jdk: http://cr.openjdk.java.net/~ysuenaga/JDK-8151181/webrev.02/jdk/
> 
> Could you review it again?
> 
> 
> BTW, jmap test uses "compiler detected" as expected message.
> Should I fix it? (Should I file it as another test bug?)
> 
> 
> Thanks,
> 
> Yasumasa
> 
> 
> On 2016/03/04 2:06, Dmitry Samersoff wrote:
>> Yasumasa,
>>
>> 91 s/perfromance/performance/
>>
>> Test:
>>
>> 146         launch("compiler detected.", "jsnap");
>>
>>
>> Please, choose expectedMessage carefully, I'm not sure "compiler
>> detected." is an appropriate one.
>>
>> -Dmitry
>>
>>
>> On 2016-03-03 18:45, Yasumasa Suenaga wrote:
>>> Hi Dmitry,
>>>
>>> Thank you for your comment.
>>> I uploaded new webrev:
>>>
>>>    hotspot: http://cr.openjdk.java.net/~ysuenaga/JDK-8151181/webrev.01/hotspot/
>>>        jdk: http://cr.openjdk.java.net/~ysuenaga/JDK-8151181/webrev.01/jdk/
>>>
>>>
>>> Could you review again?
>>>
>>>
>>> Thanks,
>>>
>>> Yasumasa
>>>
>>>
>>> On 2016/03/04 0:15, Dmitry Samersoff wrote:
>>>> Yasumasa,
>>>>
>>>> It's better (with upcoming changes for JDK-8148659 in mind) to create a
>>>> separate
>>>>
>>>> private static boolean jsnapHelp() {
>>>>      System.out.println(" <no option>\tdump perfromance counters");
>>>>      return commonHelp();
>>>> }
>>>>
>>>> and write:
>>>>
>>>> System.out.println(" jsnap --help\tto get more information");
>>>>
>>>> Please also update:
>>>>
>>>>      jdk/test/sun/tools/jhsdb/BasicLauncherTest.java
>>>>
>>>> -Dmitry
>>>>
>>>>
>>>> On 2016-03-03 17:43, Yasumasa Suenaga wrote:
>>>>> Hi all,
>>>>>
>>>>> JSnap is useful SA tool to check PerfCounter.
>>>>> So I want to add it to jhsdb.
>>>>>
>>>>>     http://cr.openjdk.java.net/~ysuenaga/JDK-8151181/webrev.00/
>>>>>
>>>>> Could you review it?
>>>>>
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Yasumasa
>>>>>
>>>>
>>>>
>>
>>


-- 
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the sources.

From yasuenag at gmail.com  Fri Mar  4 09:15:12 2016
From: yasuenag at gmail.com (Yasumasa Suenaga)
Date: Fri, 4 Mar 2016 18:15:12 +0900
Subject: RFR: 8151181: Add JSnap to jhsdb
In-Reply-To: <56D9405D.8000902@oracle.com>
References: <56D84D87.9050308@gmail.com> <56D85508.4060408@oracle.com>
	<56D85C35.9020703@gmail.com> <56D86F19.5070500@oracle.com>
	<56D901FC.4020507@gmail.com> <56D9405D.8000902@oracle.com>
Message-ID: <56D95220.7090402@gmail.com>

Hi Dmitry,

Thanks, I understood.
I will send changesets to you.


Yasumasa


On 2016/03/04 16:59, Dmitry Samersoff wrote:
> Yasumasa,
> 
> 1. Changes looks good for me, but please fix a typeo in
> hotspot/SALauncher.java (no need to re-review)
> 
> 91 s/perfromance/performance/
> 
> 2. Simple jmap output looks like
> 
> dooku:test#/opt/jdk9/bin/jmap 6379
> Attaching to process ID 6379, please wait...
> Debugger attached successfully.
> Server compiler detected.
> JVM version is 9-internal+0-2016-02-29-173800.dms.hs-rt
> 0x0000000000400000      8K      /opt/jdk9/bin/java
> ....
> 
> So "compiler detected" is acceptable message to test that jmap is
> launched and attached successfully. Not the best one but it works on all
> platfroms.
> 
> -Dmitry
> 
> On 2016-03-04 06:33, Yasumasa Suenaga wrote:
>> Hi Dmitry,
>>
>> I uploaded new webrev:
>>
>>    hotspot (not changed): http://cr.openjdk.java.net/~ysuenaga/JDK-8151181/webrev.02/hotspot/
>>                      jdk: http://cr.openjdk.java.net/~ysuenaga/JDK-8151181/webrev.02/jdk/
>>
>> Could you review it again?
>>
>>
>> BTW, jmap test uses "compiler detected" as expected message.
>> Should I fix it? (Should I file it as another test bug?)
>>
>>
>> Thanks,
>>
>> Yasumasa
>>
>>
>> On 2016/03/04 2:06, Dmitry Samersoff wrote:
>>> Yasumasa,
>>>
>>> 91 s/perfromance/performance/
>>>
>>> Test:
>>>
>>> 146         launch("compiler detected.", "jsnap");
>>>
>>>
>>> Please, choose expectedMessage carefully, I'm not sure "compiler
>>> detected." is an appropriate one.
>>>
>>> -Dmitry
>>>
>>>
>>> On 2016-03-03 18:45, Yasumasa Suenaga wrote:
>>>> Hi Dmitry,
>>>>
>>>> Thank you for your comment.
>>>> I uploaded new webrev:
>>>>
>>>>     hotspot: http://cr.openjdk.java.net/~ysuenaga/JDK-8151181/webrev.01/hotspot/
>>>>         jdk: http://cr.openjdk.java.net/~ysuenaga/JDK-8151181/webrev.01/jdk/
>>>>
>>>>
>>>> Could you review again?
>>>>
>>>>
>>>> Thanks,
>>>>
>>>> Yasumasa
>>>>
>>>>
>>>> On 2016/03/04 0:15, Dmitry Samersoff wrote:
>>>>> Yasumasa,
>>>>>
>>>>> It's better (with upcoming changes for JDK-8148659 in mind) to create a
>>>>> separate
>>>>>
>>>>> private static boolean jsnapHelp() {
>>>>>       System.out.println(" <no option>\tdump perfromance counters");
>>>>>       return commonHelp();
>>>>> }
>>>>>
>>>>> and write:
>>>>>
>>>>> System.out.println(" jsnap --help\tto get more information");
>>>>>
>>>>> Please also update:
>>>>>
>>>>>       jdk/test/sun/tools/jhsdb/BasicLauncherTest.java
>>>>>
>>>>> -Dmitry
>>>>>
>>>>>
>>>>> On 2016-03-03 17:43, Yasumasa Suenaga wrote:
>>>>>> Hi all,
>>>>>>
>>>>>> JSnap is useful SA tool to check PerfCounter.
>>>>>> So I want to add it to jhsdb.
>>>>>>
>>>>>>      http://cr.openjdk.java.net/~ysuenaga/JDK-8151181/webrev.00/
>>>>>>
>>>>>> Could you review it?
>>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Yasumasa
>>>>>>
>>>>>
>>>>>
>>>
>>>
> 
> 

From kirk.pepperdine at gmail.com  Sun Mar  6 16:03:46 2016
From: kirk.pepperdine at gmail.com (kirk.pepperdine at gmail.com)
Date: Sun, 6 Mar 2016 17:03:46 +0100
Subject: G1 STW phases and FGC column in jstat
In-Reply-To: <56D83AEA.6010100@gmail.com>
References: <56D5ADAC.5010701@gmail.com>
	<9430CE85-D805-495F-A2F7-314766E7492A@kodewerk.com>
	<56D61FC6.2070002@gmail.com>
	<11E54471-015C-49AE-8E5E-DA681AE3CD1A@kodewerk.com>
	<56D6E375.8010605@gmail.com>
	<46C36433-8BC0-454D-9C91-142D5C2AF552@kodewerk.com>
	<56D6F68B.3010409@gmail.com> <56D83AEA.6010100@gmail.com>
Message-ID: <B65BC547-0B4F-4D07-A439-844A6DE79A0D@gmail.com>

Hi Yasumasa,

Looks good.

Regards,
Kirk

> On Mar 3, 2016, at 2:23 PM, Yasumasa Suenaga <yasuenag at gmail.com> wrote:
> 
> Hi all,
> 
> I've uploaded PoC of PerfCounter for STW phase in concurrent GC:
> 
>  hotspot: http://cr.openjdk.java.net/~ysuenaga/perfcounter-for-cgc/hotspot/
>      jdk: http://cr.openjdk.java.net/~ysuenaga/perfcounter-for-cgc/jdk/
> 
> These patches makes new jstat column CGC and CGCT as below:
> -------------
> $ jstat -gc 53494 3000
> S0C    S1C    S0U    S1U      EC       EU        OC         OU       MC     MU    CCSC   CCSU   YGC     YGCT    FGC    FGCT    CGC    CGCT     GCT
> 0.0    0.0    0.0    0.0    4096.0    0.0     28672.0      0.0     4480.0 948.9  384.0   77.6       0    0.000   0      0.000   0      0.000    0.000
> 0.0   1024.0  0.0   1024.0  3072.0    0.0     28672.0      0.0     4864.0 2969.0 512.0  276.0       1    0.063   0      0.000   2      0.016    0.080
> -------------
> 
> They are shows STW phase in concurrent GC.
> 
>  CMS: Initial Mark and Remark
>   G1: Remark and Cleanup
> 
> GCT is sum of YGCT, FGCT, and CGCT.
> 
> 
> Can be this change accepted?
> If so, I will file it to JBS and will send RFR.
> 
> I cannot access JPRT.
> So I need a sponsor.
> 
> 
> Thanks,
> 
> Yasumasa
> 
> 
> On 2016/03/02 23:19, Yasumasa Suenaga wrote:
>> It is not difficult to create webrev for this proposal.
>> However, this proposal affects to jstat output, and
>> I cannot access JPRT.
>> So I want to find sponsor for it at first.
>> 
>> Could somebody be a sponsor?
>> 
>> 
>> Yasumasa
>> 
>> 
>> On 2016/03/02 22:29, kirk at kodewerk.com wrote:
>>> Hi Yasumasa,
>>> 
>>> It all sounds reasonable and of course the impact on downstream tooling vs the value of the change must be evaluated. In this case I think adding a CGC counter makes sense especially in prep for G1 becoming default in 9.
>>> 
>>> Regards,
>>> Kirk
>>> 
>>>> On Mar 2, 2016, at 6:58 AM, Yasumasa Suenaga <yasuenag at gmail.com> wrote:
>>>> 
>>>> Hi Kirk,
>>>> 
>>>> Agree to you.
>>>> However, I use occasional FGC counter at CMS as below:
>>>> 
>>>> 1. Check major collection occurrence
>>>>      Some production systems have large memory as Java heap,
>>>>      and they are not set GC log.
>>>>      If their CPU usage becomes high, I want to check GC execution.
>>>>      (Of course, we have to check any other points :-) )
>>>> 
>>>> 2. Core image analysis
>>>>      If JVM is crashed, I want to check PerfCounter to know situation.
>>>>      (In the past, I sometimes encountered crash at GC worker thread.)
>>>> 
>>>> I guess that I will want to check them at G1.
>>>> 
>>>> Thus, at least, I want to add PerfCounter for CGC (and add JVMTI event hook).
>>>> However, this proposal will affect to jstat spec.
>>>> So I want to discuss about it before filing to JBS.
>>>> 
>>>> 
>>>> Thanks,
>>>> 
>>>> Yasumasa
>>>> 
>>>> 
>>>> On 2016/03/02 19:02, kirk at kodewerk.com wrote:
>>>>> Hi Yasumasa,
>>>>> 
>>>>> Good question. I?ve never considered CMS to be a Full GC. This implies that there should be separate performance counters for CMS pause phases as it is possible to have FGC. Of course a FGC during CMS maybe user triggered, triggered outside a CMS cycle, interrupts a CMS cycle, or interrupts a CMS phase. I?m not sure how much of a distinction one needs to make here as that could be a quick broader discussion. Certainly the purpose isn?t to recreate the GC logs in these performance counters. But at the very least not having a distinction between full and a STW-CMS phase is kind of misleading in my opinion.
>>>>> 
>>>>> Regards,
>>>>> Kirk
>>>>> 
>>>>>> On Mar 1, 2016, at 5:03 PM, Yasumasa Suenaga <yasuenag at gmail.com> wrote:
>>>>>> 
>>>>>> Hi Kirk,
>>>>>> 
>>>>>>> It is also incorrect to count initial mark and remark in CMS as a FGC.
>>>>>> 
>>>>>> Though, how can we check execution of major collection without GC log?
>>>>>> Should we add new PerfCounter for CGC (and add CGC column to jstat output)?
>>>>>> 
>>>>>> 
>>>>>> Yasumasa
>>>>>> 
>>>>>> 
>>>>>> On 2016/03/02 6:35, kirk at kodewerk.com wrote:
>>>>>>> Hi,
>>>>>>> 
>>>>>>> I think it is incorrect to count remark and cleanup as FGC. They are not full collections. It is also incorrect to count initial mark and remark in CMS as a FGC. It is unfortunate that this is counted this way.
>>>>>>> 
>>>>>>> Regards,
>>>>>>> Kirk
>>>>>>> 
>>>>>>>> On Mar 1, 2016, at 8:56 AM, Yasumasa Suenaga <yasuenag at gmail.com> wrote:
>>>>>>>> 
>>>>>>>> Hi all,
>>>>>>>> 
>>>>>>>> I wonder that STW phases (Remark and Cleanup) at G1 are not counted in jstat FGC column.
>>>>>>>> For example, Initial Mark and Remark at CMS are counted as FGC.
>>>>>>>> 
>>>>>>>> For consistency, I think that G1 STW phases should be counted as FGC.
>>>>>>>> What do you think about it?
>>>>>>>> 
>>>>>>>> If it is accepted, I will file it to JBS and will upload webrev.
>>>>>>>> 
>>>>>>>> 
>>>>>>>> suggested fix:
>>>>>>>> ----------------------
>>>>>>>> diff -r 8a103ba9a7b2 src/share/vm/gc/g1/g1MonitoringSupport.cpp
>>>>>>>> --- a/src/share/vm/gc/g1/g1MonitoringSupport.cpp    Mon Feb 29 22:54:24 2016 +0900
>>>>>>>> +++ b/src/share/vm/gc/g1/g1MonitoringSupport.cpp    Tue Mar 01 23:43:30 2016 +0900
>>>>>>>> @@ -103,7 +103,7 @@
>>>>>>>>   //   name "collector.1".  In a generational collector this would be the
>>>>>>>>   // old generation collection.
>>>>>>>>   _full_collection_counters =
>>>>>>>> -    new CollectorCounters("G1 stop-the-world full collections", 1);
>>>>>>>> +    new CollectorCounters("G1 stop-the-world phase", 1);
>>>>>>>> 
>>>>>>>>   // timer sampling for all counters supporting sampling only update the
>>>>>>>>   // used value.  See the take_sample() method.  G1 requires both used and
>>>>>>>> diff -r 8a103ba9a7b2 src/share/vm/gc/g1/vm_operations_g1.cpp
>>>>>>>> --- a/src/share/vm/gc/g1/vm_operations_g1.cpp    Mon Feb 29 22:54:24 2016 +0900
>>>>>>>> +++ b/src/share/vm/gc/g1/vm_operations_g1.cpp    Tue Mar 01 23:43:30 2016 +0900
>>>>>>>> @@ -230,6 +230,8 @@
>>>>>>>>   G1CollectedHeap* g1h = G1CollectedHeap::heap();
>>>>>>>>   GCTraceTime(Info, gc) t(_printGCMessage, g1h->gc_timer_cm(), GCCause::_no_gc, true);
>>>>>>>>   IsGCActiveMark x;
>>>>>>>> +  SvcGCMarker sgcm(SvcGCMarker::OTHER);
>>>>>>>> +  TraceCollectorStats tcs(g1h->g1mm()->full_collection_counters());
>>>>>>>>   _cl->do_void();
>>>>>>>> }
>>>>>>>> 
>>>>>>>> ----------------------
>>>>>>>> 
>>>>>>>> 
>>>>>>>> Thanks,
>>>>>>>> 
>>>>>>>> Yasumasa
>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>> 
>>> 


From dmitry.samersoff at oracle.com  Mon Mar  7 10:07:52 2016
From: dmitry.samersoff at oracle.com (Dmitry Samersoff)
Date: Mon, 7 Mar 2016 13:07:52 +0300
Subject: RFR[9u-dev]: 8146683: check_addr0 should be more efficient
In-Reply-To: <2fecd625-4723-4fbe-b148-36f7bb654df6@default>
References: <38bc418b-c510-4ae8-8d8e-161b5ea42920@default>
	<CAA-vtUxV_93cfiFpR-PaMjbShAYqjCNtWwPAMGZ8-XPwG2t2ig@mail.gmail.com>
	<56CC9FF2.4040406@oracle.com> <56CD11F5.9060002@oracle.com>
	<2fecd625-4723-4fbe-b148-36f7bb654df6@default>
Message-ID: <56DD52F8.8070208@oracle.com>

Cheleswer,

Looks good for me.

-Dmitry


On 2016-03-03 19:28, Cheleswer Sahu wrote:
> Hi,
> 
> Please review the new code changes for this bug. I have removed  " fstat()"  call which seems not safe to read the "/proc/map/self" file and have made some other changes too. Please find the latest code in below link
> Webrev link: http://cr.openjdk.java.net/~csahu/8146683/webrev.01/
> 
> 
> Regards,
> Cheleswer
> 
> -----Original Message-----
> From: Dean Long 
> Sent: Wednesday, February 24, 2016 7:44 AM
> To: Daniel Daugherty; Thomas St?fe; Cheleswer Sahu
> Cc: serviceability-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net
> Subject: Re: RFR[9u-dev]: 8146683: check_addr0 should be more efficient
> 
> On 2/23/2016 10:07 AM, Daniel D. Daugherty wrote:
>> On 2/23/16 5:56 AM, Thomas St?fe wrote:
>>> Hi Cheleswer,
>>>
>>>
>>> On Tue, Feb 23, 2016 at 9:38 AM, Cheleswer Sahu 
>>> <cheleswer.sahu at oracle.com>
>>>   wrote:
>>>
>>>> Hi,
>>>>
>>>>
>>>>
>>>> Please review the code changes for
>>>> https://bugs.openjdk.java.net/browse/JDK-8146683 .
>>>>
>>>>
>>>>
>>>> Webrev link: http://cr.openjdk.java.net/~csahu/8146683/
>>>>
>>>> JBS Link: https://bugs.openjdk.java.net/browse/JDK-8146683
>>>>
>>>>
>>>>
>>>> Bug Brief:
>>>>
>>>> While investigating  bug
>>>> https://bugs.openjdk.java.net/browse/JDK-8144483
>>>> it has been observed that "check_addr0() " function  is not written 
>>>> efficiently.
>>>>
>>>> This function is trying to read each "prmap_t" entry in 
>>>> "/proc/self/map"
>>>> file one by one which is time taking and can cause in long pauses.
>>>>
>>>>
>>>>
>>>> Solution proposed:
>>>>
>>>> Instead of reading each "prmap_t" entry in "/proc/self/map" file one 
>>>> by one, read the entries in chunks. There can be many entries in "map"
>>>> file,
>>>> so I have decided to read these
>>>>
>>>> in chunks of 100  "prmap_t" entries. Reading entries in chunks saves 
>>>> a lot of read calls and results in smaller pause times.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Regards,
>>>>
>>>> Cheleswer
>>>>
>>>
>>> We saw cases, especially on Solaris, where the content of a file in the
>>> proc file system changed under us while we were reading it. So this 
>>> should
>>> be kept in mind. The original code seems also broken in that regard,
>>> because it assumes the ::read() call to read the full size of a prmap_t
>>> entry, but it may theoretically read an incomplete entry.
>>>
>>> As for your coding, you first estimate the size of the mapping file and
>>> then use this to determine how many entries to read; but when 
>>> reading, this
>>> information may already be stale. I think it would be more robust and 
>>> also
>>> simpler to just try to read as many entries as possible - in chunks, to
>>> make reading faster - until you get EOF.
>>>
>>> Kind Regards, Thomas
>>
>> I'm really sure that we've been down this road before. In particular,
>> Dmitry Samersoff has worked on this issue (or one very much like it)
>> before, but he is on vacation until the end of the month.
>>
> 
> There was a similar issue with Linux /proc/self/maps, and whether it was 
> safe to read the file with buffered stdio or not.  See 8009062 and 7017193.
> 
> dl
> 
>> Dan
>>
>>
>>>
>>> On Tue, Feb 23, 2016 at 9:38 AM, Cheleswer Sahu 
>>> <cheleswer.sahu at oracle.com>
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>>
>>>>
>>>> Please review the code changes for
>>>> https://bugs.openjdk.java.net/browse/JDK-8146683 .
>>>>
>>>>
>>>>
>>>> Webrev link: http://cr.openjdk.java.net/~csahu/8146683/
>>>>
>>>> JBS Link: https://bugs.openjdk.java.net/browse/JDK-8146683
>>>>
>>>>
>>>>
>>>> Bug Brief:
>>>>
>>>> While investigating  bug 
>>>> https://bugs.openjdk.java.net/browse/JDK-8144483
>>>> it has been observed that "check_addr0() " function  is not written
>>>> efficiently.
>>>>
>>>> This function is trying to read each "prmap_t" entry in 
>>>> "/proc/self/map"
>>>> file one by one which is time taking and can cause in long pauses.
>>>>
>>>>
>>>>
>>>> Solution proposed:
>>>>
>>>> Instead of reading each "prmap_t" entry in "/proc/self/map" file one by
>>>> one, read the entries in chunks. There can be many entries in "map" 
>>>> file,
>>>> so I have decided to read these
>>>>
>>>> in chunks of 100  "prmap_t" entries. Reading entries in chunks saves 
>>>> a lot
>>>> of read calls and results in smaller pause times.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Regards,
>>>>
>>>> Cheleswer
>>>>
>>
> 


-- 
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the sources.

From kevin.walls at oracle.com  Mon Mar  7 10:36:18 2016
From: kevin.walls at oracle.com (Kevin Walls)
Date: Mon, 7 Mar 2016 10:36:18 +0000
Subject: RFR[9u-dev]: 8146683: check_addr0 should be more efficient
In-Reply-To: <56DD52F8.8070208@oracle.com>
References: <38bc418b-c510-4ae8-8d8e-161b5ea42920@default>
	<CAA-vtUxV_93cfiFpR-PaMjbShAYqjCNtWwPAMGZ8-XPwG2t2ig@mail.gmail.com>
	<56CC9FF2.4040406@oracle.com> <56CD11F5.9060002@oracle.com>
	<2fecd625-4723-4fbe-b148-36f7bb654df6@default>
	<56DD52F8.8070208@oracle.com>
Message-ID: <56DD59A2.1030804@oracle.com>


Hi Cheleswer,

Looks good.  (While we've discussed it offline I haven't actually 
offered a public review).

Just one more thing, and this concerns the original code not the change:

1880           st->print("Warning: Address: 0x%x, Size: %dK, 
",p->pr_vaddr, p->pr_size/1024, p->pr_mapname);

We pass 3 params when we only print two items?  The "p->pr_mapname", we 
pass again on the next line where we do have the the "%s" in the format 
string, so this one is unnecessary. 8-)

Thanks
Kevin



On 07/03/2016 10:07, Dmitry Samersoff wrote:
> Cheleswer,
>
> Looks good for me.
>
> -Dmitry
>
>
> On 2016-03-03 19:28, Cheleswer Sahu wrote:
>> Hi,
>>
>> Please review the new code changes for this bug. I have removed  " fstat()"  call which seems not safe to read the "/proc/map/self" file and have made some other changes too. Please find the latest code in below link
>> Webrev link: http://cr.openjdk.java.net/~csahu/8146683/webrev.01/
>>
>>
>> Regards,
>> Cheleswer
>>
>> -----Original Message-----
>> From: Dean Long
>> Sent: Wednesday, February 24, 2016 7:44 AM
>> To: Daniel Daugherty; Thomas St?fe; Cheleswer Sahu
>> Cc: serviceability-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net
>> Subject: Re: RFR[9u-dev]: 8146683: check_addr0 should be more efficient
>>
>> On 2/23/2016 10:07 AM, Daniel D. Daugherty wrote:
>>> On 2/23/16 5:56 AM, Thomas St?fe wrote:
>>>> Hi Cheleswer,
>>>>
>>>>
>>>> On Tue, Feb 23, 2016 at 9:38 AM, Cheleswer Sahu
>>>> <cheleswer.sahu at oracle.com>
>>>>    wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>>
>>>>>
>>>>> Please review the code changes for
>>>>> https://bugs.openjdk.java.net/browse/JDK-8146683 .
>>>>>
>>>>>
>>>>>
>>>>> Webrev link: http://cr.openjdk.java.net/~csahu/8146683/
>>>>>
>>>>> JBS Link: https://bugs.openjdk.java.net/browse/JDK-8146683
>>>>>
>>>>>
>>>>>
>>>>> Bug Brief:
>>>>>
>>>>> While investigating  bug
>>>>> https://bugs.openjdk.java.net/browse/JDK-8144483
>>>>> it has been observed that "check_addr0() " function  is not written
>>>>> efficiently.
>>>>>
>>>>> This function is trying to read each "prmap_t" entry in
>>>>> "/proc/self/map"
>>>>> file one by one which is time taking and can cause in long pauses.
>>>>>
>>>>>
>>>>>
>>>>> Solution proposed:
>>>>>
>>>>> Instead of reading each "prmap_t" entry in "/proc/self/map" file one
>>>>> by one, read the entries in chunks. There can be many entries in "map"
>>>>> file,
>>>>> so I have decided to read these
>>>>>
>>>>> in chunks of 100  "prmap_t" entries. Reading entries in chunks saves
>>>>> a lot of read calls and results in smaller pause times.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Regards,
>>>>>
>>>>> Cheleswer
>>>>>
>>>> We saw cases, especially on Solaris, where the content of a file in the
>>>> proc file system changed under us while we were reading it. So this
>>>> should
>>>> be kept in mind. The original code seems also broken in that regard,
>>>> because it assumes the ::read() call to read the full size of a prmap_t
>>>> entry, but it may theoretically read an incomplete entry.
>>>>
>>>> As for your coding, you first estimate the size of the mapping file and
>>>> then use this to determine how many entries to read; but when
>>>> reading, this
>>>> information may already be stale. I think it would be more robust and
>>>> also
>>>> simpler to just try to read as many entries as possible - in chunks, to
>>>> make reading faster - until you get EOF.
>>>>
>>>> Kind Regards, Thomas
>>> I'm really sure that we've been down this road before. In particular,
>>> Dmitry Samersoff has worked on this issue (or one very much like it)
>>> before, but he is on vacation until the end of the month.
>>>
>> There was a similar issue with Linux /proc/self/maps, and whether it was
>> safe to read the file with buffered stdio or not.  See 8009062 and 7017193.
>>
>> dl
>>
>>> Dan
>>>
>>>
>>>> On Tue, Feb 23, 2016 at 9:38 AM, Cheleswer Sahu
>>>> <cheleswer.sahu at oracle.com>
>>>> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>>
>>>>>
>>>>> Please review the code changes for
>>>>> https://bugs.openjdk.java.net/browse/JDK-8146683 .
>>>>>
>>>>>
>>>>>
>>>>> Webrev link: http://cr.openjdk.java.net/~csahu/8146683/
>>>>>
>>>>> JBS Link: https://bugs.openjdk.java.net/browse/JDK-8146683
>>>>>
>>>>>
>>>>>
>>>>> Bug Brief:
>>>>>
>>>>> While investigating  bug
>>>>> https://bugs.openjdk.java.net/browse/JDK-8144483
>>>>> it has been observed that "check_addr0() " function  is not written
>>>>> efficiently.
>>>>>
>>>>> This function is trying to read each "prmap_t" entry in
>>>>> "/proc/self/map"
>>>>> file one by one which is time taking and can cause in long pauses.
>>>>>
>>>>>
>>>>>
>>>>> Solution proposed:
>>>>>
>>>>> Instead of reading each "prmap_t" entry in "/proc/self/map" file one by
>>>>> one, read the entries in chunks. There can be many entries in "map"
>>>>> file,
>>>>> so I have decided to read these
>>>>>
>>>>> in chunks of 100  "prmap_t" entries. Reading entries in chunks saves
>>>>> a lot
>>>>> of read calls and results in smaller pause times.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Regards,
>>>>>
>>>>> Cheleswer
>>>>>
>


From david.holmes at oracle.com  Mon Mar  7 11:23:30 2016
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 7 Mar 2016 21:23:30 +1000
Subject: RFR[9u-dev]: 8146683: check_addr0 should be more efficient
In-Reply-To: <56DD59A2.1030804@oracle.com>
References: <38bc418b-c510-4ae8-8d8e-161b5ea42920@default>
	<CAA-vtUxV_93cfiFpR-PaMjbShAYqjCNtWwPAMGZ8-XPwG2t2ig@mail.gmail.com>
	<56CC9FF2.4040406@oracle.com> <56CD11F5.9060002@oracle.com>
	<2fecd625-4723-4fbe-b148-36f7bb654df6@default>
	<56DD52F8.8070208@oracle.com> <56DD59A2.1030804@oracle.com>
Message-ID: <56DD64B2.4010901@oracle.com>

On 7/03/2016 8:36 PM, Kevin Walls wrote:
>
> Hi Cheleswer,
>
> Looks good.  (While we've discussed it offline I haven't actually
> offered a public review).
>
> Just one more thing, and this concerns the original code not the change:
>
> 1880           st->print("Warning: Address: 0x%x, Size: %dK,
> ",p->pr_vaddr, p->pr_size/1024, p->pr_mapname);

Also %x is the wrong format specifier:

typedef struct prmap {
	uintptr_t pr_vaddr;	/* virtual address of mapping */

David
-----

> We pass 3 params when we only print two items?  The "p->pr_mapname", we
> pass again on the next line where we do have the the "%s" in the format
> string, so this one is unnecessary. 8-)
>
> Thanks
> Kevin
>
>
>
> On 07/03/2016 10:07, Dmitry Samersoff wrote:
>> Cheleswer,
>>
>> Looks good for me.
>>
>> -Dmitry
>>
>>
>> On 2016-03-03 19:28, Cheleswer Sahu wrote:
>>> Hi,
>>>
>>> Please review the new code changes for this bug. I have removed  "
>>> fstat()"  call which seems not safe to read the "/proc/map/self" file
>>> and have made some other changes too. Please find the latest code in
>>> below link
>>> Webrev link: http://cr.openjdk.java.net/~csahu/8146683/webrev.01/
>>>
>>>
>>> Regards,
>>> Cheleswer
>>>
>>> -----Original Message-----
>>> From: Dean Long
>>> Sent: Wednesday, February 24, 2016 7:44 AM
>>> To: Daniel Daugherty; Thomas St?fe; Cheleswer Sahu
>>> Cc: serviceability-dev at openjdk.java.net;
>>> hotspot-runtime-dev at openjdk.java.net
>>> Subject: Re: RFR[9u-dev]: 8146683: check_addr0 should be more efficient
>>>
>>> On 2/23/2016 10:07 AM, Daniel D. Daugherty wrote:
>>>> On 2/23/16 5:56 AM, Thomas St?fe wrote:
>>>>> Hi Cheleswer,
>>>>>
>>>>>
>>>>> On Tue, Feb 23, 2016 at 9:38 AM, Cheleswer Sahu
>>>>> <cheleswer.sahu at oracle.com>
>>>>>    wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>>
>>>>>>
>>>>>> Please review the code changes for
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8146683 .
>>>>>>
>>>>>>
>>>>>>
>>>>>> Webrev link: http://cr.openjdk.java.net/~csahu/8146683/
>>>>>>
>>>>>> JBS Link: https://bugs.openjdk.java.net/browse/JDK-8146683
>>>>>>
>>>>>>
>>>>>>
>>>>>> Bug Brief:
>>>>>>
>>>>>> While investigating  bug
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8144483
>>>>>> it has been observed that "check_addr0() " function  is not written
>>>>>> efficiently.
>>>>>>
>>>>>> This function is trying to read each "prmap_t" entry in
>>>>>> "/proc/self/map"
>>>>>> file one by one which is time taking and can cause in long pauses.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Solution proposed:
>>>>>>
>>>>>> Instead of reading each "prmap_t" entry in "/proc/self/map" file one
>>>>>> by one, read the entries in chunks. There can be many entries in
>>>>>> "map"
>>>>>> file,
>>>>>> so I have decided to read these
>>>>>>
>>>>>> in chunks of 100  "prmap_t" entries. Reading entries in chunks saves
>>>>>> a lot of read calls and results in smaller pause times.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> Cheleswer
>>>>>>
>>>>> We saw cases, especially on Solaris, where the content of a file in
>>>>> the
>>>>> proc file system changed under us while we were reading it. So this
>>>>> should
>>>>> be kept in mind. The original code seems also broken in that regard,
>>>>> because it assumes the ::read() call to read the full size of a
>>>>> prmap_t
>>>>> entry, but it may theoretically read an incomplete entry.
>>>>>
>>>>> As for your coding, you first estimate the size of the mapping file
>>>>> and
>>>>> then use this to determine how many entries to read; but when
>>>>> reading, this
>>>>> information may already be stale. I think it would be more robust and
>>>>> also
>>>>> simpler to just try to read as many entries as possible - in
>>>>> chunks, to
>>>>> make reading faster - until you get EOF.
>>>>>
>>>>> Kind Regards, Thomas
>>>> I'm really sure that we've been down this road before. In particular,
>>>> Dmitry Samersoff has worked on this issue (or one very much like it)
>>>> before, but he is on vacation until the end of the month.
>>>>
>>> There was a similar issue with Linux /proc/self/maps, and whether it was
>>> safe to read the file with buffered stdio or not.  See 8009062 and
>>> 7017193.
>>>
>>> dl
>>>
>>>> Dan
>>>>
>>>>
>>>>> On Tue, Feb 23, 2016 at 9:38 AM, Cheleswer Sahu
>>>>> <cheleswer.sahu at oracle.com>
>>>>> wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>>
>>>>>>
>>>>>> Please review the code changes for
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8146683 .
>>>>>>
>>>>>>
>>>>>>
>>>>>> Webrev link: http://cr.openjdk.java.net/~csahu/8146683/
>>>>>>
>>>>>> JBS Link: https://bugs.openjdk.java.net/browse/JDK-8146683
>>>>>>
>>>>>>
>>>>>>
>>>>>> Bug Brief:
>>>>>>
>>>>>> While investigating  bug
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8144483
>>>>>> it has been observed that "check_addr0() " function  is not written
>>>>>> efficiently.
>>>>>>
>>>>>> This function is trying to read each "prmap_t" entry in
>>>>>> "/proc/self/map"
>>>>>> file one by one which is time taking and can cause in long pauses.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Solution proposed:
>>>>>>
>>>>>> Instead of reading each "prmap_t" entry in "/proc/self/map" file
>>>>>> one by
>>>>>> one, read the entries in chunks. There can be many entries in "map"
>>>>>> file,
>>>>>> so I have decided to read these
>>>>>>
>>>>>> in chunks of 100  "prmap_t" entries. Reading entries in chunks saves
>>>>>> a lot
>>>>>> of read calls and results in smaller pause times.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> Cheleswer
>>>>>>
>>
>

From dmitry.samersoff at oracle.com  Mon Mar  7 11:48:38 2016
From: dmitry.samersoff at oracle.com (Dmitry Samersoff)
Date: Mon, 7 Mar 2016 14:48:38 +0300
Subject: PING: Unexpected ArithmeticException at
	sun.jvm.hotspot.utilities.CompactHashTable
In-Reply-To: <CABU-27OngawMU1gSUZGx84U=qkGo_HYfFsa8z6edHgKM6jr0qQ@mail.gmail.com>
References: <CABU-27OngawMU1gSUZGx84U=qkGo_HYfFsa8z6edHgKM6jr0qQ@mail.gmail.com>
Message-ID: <56DD6A96.8090209@oracle.com>

Yuji,

CR number is JDK-8151368

-Dmitry

On 2016-02-22 15:31, KUBOTA Yuji wrote:
> Hi all,
> 
> Could you please review this patch?
> I do not have any account at openjdk now, so I need a sponsor.
> 
> Thanks,
> Yuji
> 
> 2015-12-18 15:27 GMT+09:00 KUBOTA Yuji <kubota.yuji at gmail.com>:
>> Hi all,
>>
>> I caught an unexpected java.lang.ArithmeticException by CLHSDB through
>> jhsdb as below.
>>
>> -----
>> ./jhsdb clhsdb --pid 16809
>> Attaching to process 16809, please wait...
>> hsdb> class java/lang/ArithmeticException
>> java/lang/ArithmeticException @0x0000000100011958
>> hsdb> class java
>> class not found: java
>> hsdb> class java/lang
>> Error: java.lang.ArithmeticException: / by zero
>> -----
>>
>> I think that CLHSDB returns "class not found: java/lang". But
>> ArithmetricException is returned instead.
>> CLHSDB tries to search the given class name from the regular symbol
>> table and the shared symbol table.
>> And called the probe function of the shared symbol table does not
>> support a case of the empty bucket such as below expression
>>
>>> long index = hash % bucketCount();
>>
>> then, throws ArithmetricException.
>>
>> The stack trace of this java.lang.ArithmeticException is here.
>> ------
>> java.lang.ArithmeticException: / by zero
>>         at sun.jvm.hotspot.utilities.CompactHashTable.probe(CompactHashTable.java:89)
>>         at sun.jvm.hotspot.memory.SymbolTable.probe(SymbolTable.java:97)
>>         at sun.jvm.hotspot.memory.SymbolTable.probe(SymbolTable.java:75)
>>         at sun.jvm.hotspot.memory.SystemDictionary.find(SystemDictionary.java:149)
>>         at sun.jvm.hotspot.utilities.SystemDictionaryHelper.findInstanceKlass(SystemDictionaryHelper.java:107)
>>         at jdk.nashorn.internal.scripts.Script$Recompilation$2402$7541A$sa.main$jclass(sa.js:247)
>>         at jdk.nashorn.internal.runtime.ScriptFunctionData.invoke(ScriptFunctionData.java:625)
>>         at jdk.nashorn.internal.runtime.ScriptFunction.invoke(ScriptFunction.java:511)
>>         at jdk.nashorn.internal.runtime.ScriptRuntime.apply(ScriptRuntime.java:393)
>>         at jdk.nashorn.api.scripting.ScriptObjectMirror.callMember(ScriptObjectMirror.java:199)
>>         at jdk.nashorn.api.scripting.NashornScriptEngine.invokeImpl(NashornScriptEngine.java:383)
>>         at jdk.nashorn.api.scripting.NashornScriptEngine.invokeFunction(NashornScriptEngine.java:190)
>>         at sun.jvm.hotspot.utilities.soql.JSJavaScriptEngine.call(JSJavaScriptEngine.java:78)
>>         at sun.jvm.hotspot.CommandProcessor$52.doit(CommandProcessor.java:1755)
>>         at sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:1951)
>>         at sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:1921)
>>         at sun.jvm.hotspot.CommandProcessor.run(CommandProcessor.java:1801)
>>         at sun.jvm.hotspot.CLHSDB.run(CLHSDB.java:99)
>>         at sun.jvm.hotspot.CLHSDB.main(CLHSDB.java:40)
>>         at sun.jvm.hotspot.SALauncher.runCLHSDB(SALauncher.java:134)
>>         at sun.jvm.hotspot.SALauncher.main(SALauncher.java:334)
>> ------
>>
>> I have created a patch from jdk9/dev/hotspot (changeset:
>> 9625:de592ea5f7ba) as below, and checked to return "class not found
>> java/lang" correctly. Please review it.
>>
>> diff --git a/agent/src/share/classes/sun/jvm/hotspot/utilities/CompactHashTable.java
>> b/agent/src/share/classes/sun/jvm/hotspot/utilities/CompactHashTable.java
>> --- a/agent/src/share/classes/sun/jvm/hotspot/utilities/CompactHashTable.java
>> +++ b/agent/src/share/classes/sun/jvm/hotspot/utilities/CompactHashTable.java
>> @@ -86,6 +86,10 @@
>>      Address baseAddress = baseAddressField.getValue(addr);
>>      Address bucket = bucketsField.getValue(addr);
>>      Address bucketEnd = bucket;
>> +
>> +    if (bucketCount() == 0) {
>> +      return null;
>> +    }
>>      long index = hash % bucketCount();
>>      int bucketInfo = (int)bucket.getCIntegerAt(index * uintSize,
>> uintSize, true);
>>      int bucketOffset = bucketOffset(bucketInfo);
>>
>>
>> Thanks,
>> Yuji


-- 
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the sources.

From kubota.yuji at gmail.com  Mon Mar  7 12:03:44 2016
From: kubota.yuji at gmail.com (KUBOTA Yuji)
Date: Mon, 7 Mar 2016 21:03:44 +0900
Subject: PING: Unexpected ArithmeticException at
	sun.jvm.hotspot.utilities.CompactHashTable
In-Reply-To: <56DD6A96.8090209@oracle.com>
References: <CABU-27OngawMU1gSUZGx84U=qkGo_HYfFsa8z6edHgKM6jr0qQ@mail.gmail.com>
	<56DD6A96.8090209@oracle.com>
Message-ID: <CABU-27Nn-mfJvJ2yB-Oji-MYW3HSYhF3P61v4HTHy4AnYUZbXA@mail.gmail.com>

Dmitry,

Thank you for your kindly sponsorship!

- Yuji


2016-03-07 20:48 GMT+09:00 Dmitry Samersoff <dmitry.samersoff at oracle.com>:
> Yuji,
>
> CR number is JDK-8151368
>
> -Dmitry
>
> On 2016-02-22 15:31, KUBOTA Yuji wrote:
>> Hi all,
>>
>> Could you please review this patch?
>> I do not have any account at openjdk now, so I need a sponsor.
>>
>> Thanks,
>> Yuji
>>
>> 2015-12-18 15:27 GMT+09:00 KUBOTA Yuji <kubota.yuji at gmail.com>:
>>> Hi all,
>>>
>>> I caught an unexpected java.lang.ArithmeticException by CLHSDB through
>>> jhsdb as below.
>>>
>>> -----
>>> ./jhsdb clhsdb --pid 16809
>>> Attaching to process 16809, please wait...
>>> hsdb> class java/lang/ArithmeticException
>>> java/lang/ArithmeticException @0x0000000100011958
>>> hsdb> class java
>>> class not found: java
>>> hsdb> class java/lang
>>> Error: java.lang.ArithmeticException: / by zero
>>> -----
>>>
>>> I think that CLHSDB returns "class not found: java/lang". But
>>> ArithmetricException is returned instead.
>>> CLHSDB tries to search the given class name from the regular symbol
>>> table and the shared symbol table.
>>> And called the probe function of the shared symbol table does not
>>> support a case of the empty bucket such as below expression
>>>
>>>> long index = hash % bucketCount();
>>>
>>> then, throws ArithmetricException.
>>>
>>> The stack trace of this java.lang.ArithmeticException is here.
>>> ------
>>> java.lang.ArithmeticException: / by zero
>>>         at sun.jvm.hotspot.utilities.CompactHashTable.probe(CompactHashTable.java:89)
>>>         at sun.jvm.hotspot.memory.SymbolTable.probe(SymbolTable.java:97)
>>>         at sun.jvm.hotspot.memory.SymbolTable.probe(SymbolTable.java:75)
>>>         at sun.jvm.hotspot.memory.SystemDictionary.find(SystemDictionary.java:149)
>>>         at sun.jvm.hotspot.utilities.SystemDictionaryHelper.findInstanceKlass(SystemDictionaryHelper.java:107)
>>>         at jdk.nashorn.internal.scripts.Script$Recompilation$2402$7541A$sa.main$jclass(sa.js:247)
>>>         at jdk.nashorn.internal.runtime.ScriptFunctionData.invoke(ScriptFunctionData.java:625)
>>>         at jdk.nashorn.internal.runtime.ScriptFunction.invoke(ScriptFunction.java:511)
>>>         at jdk.nashorn.internal.runtime.ScriptRuntime.apply(ScriptRuntime.java:393)
>>>         at jdk.nashorn.api.scripting.ScriptObjectMirror.callMember(ScriptObjectMirror.java:199)
>>>         at jdk.nashorn.api.scripting.NashornScriptEngine.invokeImpl(NashornScriptEngine.java:383)
>>>         at jdk.nashorn.api.scripting.NashornScriptEngine.invokeFunction(NashornScriptEngine.java:190)
>>>         at sun.jvm.hotspot.utilities.soql.JSJavaScriptEngine.call(JSJavaScriptEngine.java:78)
>>>         at sun.jvm.hotspot.CommandProcessor$52.doit(CommandProcessor.java:1755)
>>>         at sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:1951)
>>>         at sun.jvm.hotspot.CommandProcessor.executeCommand(CommandProcessor.java:1921)
>>>         at sun.jvm.hotspot.CommandProcessor.run(CommandProcessor.java:1801)
>>>         at sun.jvm.hotspot.CLHSDB.run(CLHSDB.java:99)
>>>         at sun.jvm.hotspot.CLHSDB.main(CLHSDB.java:40)
>>>         at sun.jvm.hotspot.SALauncher.runCLHSDB(SALauncher.java:134)
>>>         at sun.jvm.hotspot.SALauncher.main(SALauncher.java:334)
>>> ------
>>>
>>> I have created a patch from jdk9/dev/hotspot (changeset:
>>> 9625:de592ea5f7ba) as below, and checked to return "class not found
>>> java/lang" correctly. Please review it.
>>>
>>> diff --git a/agent/src/share/classes/sun/jvm/hotspot/utilities/CompactHashTable.java
>>> b/agent/src/share/classes/sun/jvm/hotspot/utilities/CompactHashTable.java
>>> --- a/agent/src/share/classes/sun/jvm/hotspot/utilities/CompactHashTable.java
>>> +++ b/agent/src/share/classes/sun/jvm/hotspot/utilities/CompactHashTable.java
>>> @@ -86,6 +86,10 @@
>>>      Address baseAddress = baseAddressField.getValue(addr);
>>>      Address bucket = bucketsField.getValue(addr);
>>>      Address bucketEnd = bucket;
>>> +
>>> +    if (bucketCount() == 0) {
>>> +      return null;
>>> +    }
>>>      long index = hash % bucketCount();
>>>      int bucketInfo = (int)bucket.getCIntegerAt(index * uintSize,
>>> uintSize, true);
>>>      int bucketOffset = bucketOffset(bucketInfo);
>>>
>>>
>>> Thanks,
>>> Yuji
>
>
> --
> Dmitry Samersoff
> Oracle Java development team, Saint Petersburg, Russia
> * I would love to change the world, but they won't give me the sources.

From dmitry.samersoff at oracle.com  Mon Mar  7 14:29:04 2016
From: dmitry.samersoff at oracle.com (Dmitry Samersoff)
Date: Mon, 7 Mar 2016 17:29:04 +0300
Subject: RFR(S): JDK-8151368 SA: Unexpected ArithmeticException in
	CompactHashTable
In-Reply-To: <CABU-27Nn-mfJvJ2yB-Oji-MYW3HSYhF3P61v4HTHy4AnYUZbXA@mail.gmail.com>
References: <CABU-27OngawMU1gSUZGx84U=qkGo_HYfFsa8z6edHgKM6jr0qQ@mail.gmail.com>
	<56DD6A96.8090209@oracle.com>
	<CABU-27Nn-mfJvJ2yB-Oji-MYW3HSYhF3P61v4HTHy4AnYUZbXA@mail.gmail.com>
Message-ID: <56DD9030.70607@oracle.com>

Everybody,

Please review the changes:

http://cr.openjdk.java.net/~dsamersoff/sponsorship/kubota.yuji/JDK-8151368/webrev.01/

(on behalf of KUBOTA Yuji)

 If bucket_count read from coredump/test image is 0 code throws
ArithmeticException. Change it to silently bailout.

 No testcase provided as it's hard to reproduce the problem reliable.

-Dmitry

-- 
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the sources.

From mandy.chung at oracle.com  Tue Mar  8 00:15:45 2016
From: mandy.chung at oracle.com (Mandy Chung)
Date: Mon, 7 Mar 2016 16:15:45 -0800
Subject: Initial webrev with changes for JDK 9
In-Reply-To: <56D84C7D.9020006@oracle.com>
References: <56D84C7D.9020006@oracle.com>
Message-ID: <CDCE36A3-780D-407C-AEE9-1459742DA2BC@oracle.com>


> On Mar 3, 2016, at 6:38 AM, Alan Bateman <alan.bateman at oracle.com> wrote:
> 
> I've pushed webrevs with the initial changes for JDK 9 here:
>    http://cr.openjdk.java.net/~alanb/8142968/0/

I have reviewed changes for java.management and java.logging module.

src/java.management/share/classes/sun/management/ThreadInfoCompositeData.java
 197     private static final String[] threadInfoV9Attributes = {
 198         DAEMON,
 199         PRIORITY,
 200         MODULE_NAME,
 201         MODULE_VERSION,

Are line 200-201 left over from some earlier prototype?  I think they should be removed.

src/java.management/share/classes/sun/management/TypeVersionMapper.java
  Formatting nit: throws in several method signature better to be indented.

I also reviewed the removal of the service config files in the following modules:
jdk.attach
jdk.jvmstat
jdk.jvmstat.rmi

Mandy

From yasuenag at gmail.com  Tue Mar  8 14:38:23 2016
From: yasuenag at gmail.com (Yasumasa Suenaga)
Date: Tue, 8 Mar 2016 23:38:23 +0900
Subject: JDK-6291341: jstat: FGC counter confusing when CMS GC is used
Message-ID: <56DEE3DF.6070709@gmail.com>

Hi all,

I discussed about FullGC counter for Concurrent GC:
    http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2016-March/016774.html

I found same issue on JBS:
    JDK-6291341: jstat: FGC counter confusing when CMS GC is used

JDK-6291341 was closed with Cannot Reproduce.
However, I showed cause of this issue in above thread.

I uploaded patches for this issue:

    hotspot: http://cr.openjdk.java.net/~ysuenaga/JDK-6291341/poc/hotspot/
        jdk: http://cr.openjdk.java.net/~ysuenaga/JDK-6291341/poc/jdk/

JDK webrev includes testcase update.
All tests for jstat work fine.


Should I work for it as new issue? Or should I reopen JDK-6291341?

I cannot access JPRT.
So I need a sponsor.


Thanks,

Yasumasa



From Alan.Bateman at oracle.com  Tue Mar  8 17:26:39 2016
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 8 Mar 2016 17:26:39 +0000
Subject: Initial webrev with changes for JDK 9
In-Reply-To: <CDCE36A3-780D-407C-AEE9-1459742DA2BC@oracle.com>
References: <56D84C7D.9020006@oracle.com>
	<CDCE36A3-780D-407C-AEE9-1459742DA2BC@oracle.com>
Message-ID: <56DF0B4F.9070409@oracle.com>


On 08/03/2016 00:15, Mandy Chung wrote:
> :
>
> src/java.management/share/classes/sun/management/ThreadInfoCompositeData.java
>   197     private static final String[] threadInfoV9Attributes = {
>   198         DAEMON,
>   199         PRIORITY,
>   200         MODULE_NAME,
>   201         MODULE_VERSION,
>
> Are line 200-201 left over from some earlier prototype?  I think they should be removed.
>
>
I think you are right, these should not be needed. There is a 
compatibility test for this and I assume it will continue to pass if 
these are removed.

-Alan

From jon.masamitsu at oracle.com  Tue Mar  8 22:08:27 2016
From: jon.masamitsu at oracle.com (Jon Masamitsu)
Date: Tue, 8 Mar 2016 14:08:27 -0800
Subject: JDK-6291341: jstat: FGC counter confusing when CMS GC is used
In-Reply-To: <56DEE3DF.6070709@gmail.com>
References: <56DEE3DF.6070709@gmail.com>
Message-ID: <56DF4D5B.8070409@oracle.com>

Yasumasa,

We're discussing this.

What would the result be if the GC team made the
JVM changes that you want to contribute.  Meaning,
without the jdk changes, will jstat continue to work
as it currently does?  Would the changes in the JVM
be useful to you without the jstat changes?  By the
JVM changes, I mean the changes for the counters.

The reason I ask is that the GC team does not
own jstat.   If I can integrate the JVM changes
without the jstat changes, it makes it a little
simpler.

Jon


On 3/8/2016 6:38 AM, Yasumasa Suenaga wrote:
> Hi all,
>
> I discussed about FullGC counter for Concurrent GC:
>      http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2016-March/016774.html
>
> I found same issue on JBS:
>      JDK-6291341: jstat: FGC counter confusing when CMS GC is used
>
> JDK-6291341 was closed with Cannot Reproduce.
> However, I showed cause of this issue in above thread.
>
> I uploaded patches for this issue:
>
>      hotspot:http://cr.openjdk.java.net/~ysuenaga/JDK-6291341/poc/hotspot/
>          jdk:http://cr.openjdk.java.net/~ysuenaga/JDK-6291341/poc/jdk/
>
> JDK webrev includes testcase update.
> All tests for jstat work fine.
>
>
> Should I work for it as new issue? Or should I reopen JDK-6291341?
>
> I cannot access JPRT.
> So I need a sponsor.
>
>
> Thanks,
>
> Yasumasa
>
>


From staffan.larsen at oracle.com  Wed Mar  9 07:13:13 2016
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Wed, 9 Mar 2016 08:13:13 +0100
Subject: JDK-6291341: jstat: FGC counter confusing when CMS GC is used
In-Reply-To: <56DF4D5B.8070409@oracle.com>
References: <56DEE3DF.6070709@gmail.com> <56DF4D5B.8070409@oracle.com>
Message-ID: <BEC8AE2A-BABB-45D8-B569-1BCD2F507305@oracle.com>

The jdk changes look good to me. Jon, if you integrate the JVM changes you can do the jdk changes at the same time in the hs-rt repo.

Thanks,
/Staffan


> On 8 mars 2016, at 23:08, Jon Masamitsu <jon.masamitsu at oracle.com> wrote:
> 
> Yasumasa,
> 
> We're discussing this.
> 
> What would the result be if the GC team made the
> JVM changes that you want to contribute.  Meaning,
> without the jdk changes, will jstat continue to work
> as it currently does?  Would the changes in the JVM
> be useful to you without the jstat changes?  By the
> JVM changes, I mean the changes for the counters.
> 
> The reason I ask is that the GC team does not
> own jstat.   If I can integrate the JVM changes
> without the jstat changes, it makes it a little
> simpler.
> 
> Jon
> 
> 
> On 3/8/2016 6:38 AM, Yasumasa Suenaga wrote:
>> Hi all,
>> 
>> I discussed about FullGC counter for Concurrent GC:
>>     http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2016-March/016774.html
>> 
>> I found same issue on JBS:
>>     JDK-6291341: jstat: FGC counter confusing when CMS GC is used
>> 
>> JDK-6291341 was closed with Cannot Reproduce.
>> However, I showed cause of this issue in above thread.
>> 
>> I uploaded patches for this issue:
>> 
>>     hotspot:http://cr.openjdk.java.net/~ysuenaga/JDK-6291341/poc/hotspot/
>>         jdk:http://cr.openjdk.java.net/~ysuenaga/JDK-6291341/poc/jdk/
>> 
>> JDK webrev includes testcase update.
>> All tests for jstat work fine.
>> 
>> 
>> Should I work for it as new issue? Or should I reopen JDK-6291341?
>> 
>> I cannot access JPRT.
>> So I need a sponsor.
>> 
>> 
>> Thanks,
>> 
>> Yasumasa
>> 
>> 
> 


From staffan.larsen at oracle.com  Wed Mar  9 09:47:54 2016
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Wed, 9 Mar 2016 10:47:54 +0100
Subject: RFR: JDK-8151196 Several tests fail due to test library not found
Message-ID: <916B8270-CFF4-4BC7-89AF-A909D494AA1D@oracle.com>

Please review this small fix to some tests with the wrong paths in them. Tested locally with jtreg 4.1 b12 and b13.

Thanks,
/Staffan


$ hg diff
diff --git a/test/gc/g1/plab/TestPLABPromotion.java b/test/gc/g1/plab/TestPLABPromotion.java
--- a/test/gc/g1/plab/TestPLABPromotion.java
+++ b/test/gc/g1/plab/TestPLABPromotion.java
@@ -27,7 +27,7 @@
  * @summary Test PLAB promotion
  * @requires vm.gc=="G1" | vm.gc=="null"
  * @requires vm.opt.FlightRecorder != true
- * @library /testlibrary /../../test/lib /
+ * @library /testlibrary /test/lib /
  * @modules java.management
  * @build ClassFileInstaller
  *        sun.hotspot.WhiteBox
diff --git a/test/serviceability/dcmd/gc/HeapDumpAllTest.java b/test/serviceability/dcmd/gc/HeapDumpAllTest.java
--- a/test/serviceability/dcmd/gc/HeapDumpAllTest.java
+++ b/test/serviceability/dcmd/gc/HeapDumpAllTest.java
@@ -35,7 +35,7 @@
  * @build jdk.test.lib.hprof.*
  * @build jdk.test.lib.hprof.model.*
  * @build jdk.test.lib.hprof.parser.*
- * @build jdk.test.lib.hprof.utils.*
+ * @build jdk.test.lib.hprof.util.*
  * @build HeapDumpTest
  * @run testng HeapDumpAllTest
  */
diff --git a/test/serviceability/dcmd/gc/HeapDumpTest.java b/test/serviceability/dcmd/gc/HeapDumpTest.java
--- a/test/serviceability/dcmd/gc/HeapDumpTest.java
+++ b/test/serviceability/dcmd/gc/HeapDumpTest.java
@@ -51,7 +51,7 @@
  * @build jdk.test.lib.hprof.*
  * @build jdk.test.lib.hprof.model.*
  * @build jdk.test.lib.hprof.parser.*
- * @build jdk.test.lib.hprof.utils.*
+ * @build jdk.test.lib.hprof.util.*
  * @run testng HeapDumpTest
  */
 public class HeapDumpTest {

From bengt.rutisson at oracle.com  Wed Mar  9 09:54:12 2016
From: bengt.rutisson at oracle.com (Bengt Rutisson)
Date: Wed, 9 Mar 2016 10:54:12 +0100
Subject: RFR: JDK-8151196 Several tests fail due to test library not found
In-Reply-To: <916B8270-CFF4-4BC7-89AF-A909D494AA1D@oracle.com>
References: <916B8270-CFF4-4BC7-89AF-A909D494AA1D@oracle.com>
Message-ID: <56DFF2C4.9050105@oracle.com>


Hi Staffan,

Changes look good.

However it looks like this test has the same issue, right?
http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/file/59d3a69564dc/test/gc/g1/plab/TestPLABResize.java

It is currently ignored, but we should probably fix it too...

Thanks,
Bengt

On 2016-03-09 10:47, Staffan Larsen wrote:
> Please review this small fix to some tests with the wrong paths in them. Tested locally with jtreg 4.1 b12 and b13.
>
> Thanks,
> /Staffan
>
>
> $ hg diff
> diff --git a/test/gc/g1/plab/TestPLABPromotion.java b/test/gc/g1/plab/TestPLABPromotion.java
> --- a/test/gc/g1/plab/TestPLABPromotion.java
> +++ b/test/gc/g1/plab/TestPLABPromotion.java
> @@ -27,7 +27,7 @@
>    * @summary Test PLAB promotion
>    * @requires vm.gc=="G1" | vm.gc=="null"
>    * @requires vm.opt.FlightRecorder != true
> - * @library /testlibrary /../../test/lib /
> + * @library /testlibrary /test/lib /
>    * @modules java.management
>    * @build ClassFileInstaller
>    *        sun.hotspot.WhiteBox
> diff --git a/test/serviceability/dcmd/gc/HeapDumpAllTest.java b/test/serviceability/dcmd/gc/HeapDumpAllTest.java
> --- a/test/serviceability/dcmd/gc/HeapDumpAllTest.java
> +++ b/test/serviceability/dcmd/gc/HeapDumpAllTest.java
> @@ -35,7 +35,7 @@
>    * @build jdk.test.lib.hprof.*
>    * @build jdk.test.lib.hprof.model.*
>    * @build jdk.test.lib.hprof.parser.*
> - * @build jdk.test.lib.hprof.utils.*
> + * @build jdk.test.lib.hprof.util.*
>    * @build HeapDumpTest
>    * @run testng HeapDumpAllTest
>    */
> diff --git a/test/serviceability/dcmd/gc/HeapDumpTest.java b/test/serviceability/dcmd/gc/HeapDumpTest.java
> --- a/test/serviceability/dcmd/gc/HeapDumpTest.java
> +++ b/test/serviceability/dcmd/gc/HeapDumpTest.java
> @@ -51,7 +51,7 @@
>    * @build jdk.test.lib.hprof.*
>    * @build jdk.test.lib.hprof.model.*
>    * @build jdk.test.lib.hprof.parser.*
> - * @build jdk.test.lib.hprof.utils.*
> + * @build jdk.test.lib.hprof.util.*
>    * @run testng HeapDumpTest
>    */
>   public class HeapDumpTest {


From staffan.larsen at oracle.com  Wed Mar  9 10:02:31 2016
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Wed, 9 Mar 2016 11:02:31 +0100
Subject: RFR: JDK-8151196 Several tests fail due to test library not found
In-Reply-To: <56DFF2C4.9050105@oracle.com>
References: <916B8270-CFF4-4BC7-89AF-A909D494AA1D@oracle.com>
	<56DFF2C4.9050105@oracle.com>
Message-ID: <17547FF0-000C-408A-8D54-45FA738D1255@oracle.com>

Good catch. Incremental change:

diff --git a/test/gc/g1/plab/TestPLABResize.java b/test/gc/g1/plab/TestPLABResize.java
--- a/test/gc/g1/plab/TestPLABResize.java
+++ b/test/gc/g1/plab/TestPLABResize.java
@@ -27,7 +27,7 @@
  * @summary Test for PLAB resizing
  * @requires vm.gc=="G1" | vm.gc=="null"
  * @requires vm.opt.FlightRecorder != true
- * @library /testlibrary /../../test/lib /
+ * @library /testlibrary /test/lib /
  * @modules java.management
  * @build ClassFileInstaller
  *        sun.hotspot.WhiteBox

> On 9 mars 2016, at 10:54, Bengt Rutisson <bengt.rutisson at oracle.com> wrote:
> 
> 
> Hi Staffan,
> 
> Changes look good.
> 
> However it looks like this test has the same issue, right?
> http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/file/59d3a69564dc/test/gc/g1/plab/TestPLABResize.java
> 
> It is currently ignored, but we should probably fix it too...
> 
> Thanks,
> Bengt
> 
> On 2016-03-09 10:47, Staffan Larsen wrote:
>> Please review this small fix to some tests with the wrong paths in them. Tested locally with jtreg 4.1 b12 and b13.
>> 
>> Thanks,
>> /Staffan
>> 
>> 
>> $ hg diff
>> diff --git a/test/gc/g1/plab/TestPLABPromotion.java b/test/gc/g1/plab/TestPLABPromotion.java
>> --- a/test/gc/g1/plab/TestPLABPromotion.java
>> +++ b/test/gc/g1/plab/TestPLABPromotion.java
>> @@ -27,7 +27,7 @@
>>   * @summary Test PLAB promotion
>>   * @requires vm.gc=="G1" | vm.gc=="null"
>>   * @requires vm.opt.FlightRecorder != true
>> - * @library /testlibrary /../../test/lib /
>> + * @library /testlibrary /test/lib /
>>   * @modules java.management
>>   * @build ClassFileInstaller
>>   *        sun.hotspot.WhiteBox
>> diff --git a/test/serviceability/dcmd/gc/HeapDumpAllTest.java b/test/serviceability/dcmd/gc/HeapDumpAllTest.java
>> --- a/test/serviceability/dcmd/gc/HeapDumpAllTest.java
>> +++ b/test/serviceability/dcmd/gc/HeapDumpAllTest.java
>> @@ -35,7 +35,7 @@
>>   * @build jdk.test.lib.hprof.*
>>   * @build jdk.test.lib.hprof.model.*
>>   * @build jdk.test.lib.hprof.parser.*
>> - * @build jdk.test.lib.hprof.utils.*
>> + * @build jdk.test.lib.hprof.util.*
>>   * @build HeapDumpTest
>>   * @run testng HeapDumpAllTest
>>   */
>> diff --git a/test/serviceability/dcmd/gc/HeapDumpTest.java b/test/serviceability/dcmd/gc/HeapDumpTest.java
>> --- a/test/serviceability/dcmd/gc/HeapDumpTest.java
>> +++ b/test/serviceability/dcmd/gc/HeapDumpTest.java
>> @@ -51,7 +51,7 @@
>>   * @build jdk.test.lib.hprof.*
>>   * @build jdk.test.lib.hprof.model.*
>>   * @build jdk.test.lib.hprof.parser.*
>> - * @build jdk.test.lib.hprof.utils.*
>> + * @build jdk.test.lib.hprof.util.*
>>   * @run testng HeapDumpTest
>>   */
>>  public class HeapDumpTest {
> 


From bengt.rutisson at oracle.com  Wed Mar  9 10:00:22 2016
From: bengt.rutisson at oracle.com (Bengt Rutisson)
Date: Wed, 9 Mar 2016 11:00:22 +0100
Subject: RFR: JDK-8151196 Several tests fail due to test library not found
In-Reply-To: <17547FF0-000C-408A-8D54-45FA738D1255@oracle.com>
References: <916B8270-CFF4-4BC7-89AF-A909D494AA1D@oracle.com>
	<56DFF2C4.9050105@oracle.com>
	<17547FF0-000C-408A-8D54-45FA738D1255@oracle.com>
Message-ID: <56DFF436.1090606@oracle.com>


Great! Looks good now!

Bengt

On 2016-03-09 11:02, Staffan Larsen wrote:
> Good catch. Incremental change:
>
> diff --git a/test/gc/g1/plab/TestPLABResize.java b/test/gc/g1/plab/TestPLABResize.java
> --- a/test/gc/g1/plab/TestPLABResize.java
> +++ b/test/gc/g1/plab/TestPLABResize.java
> @@ -27,7 +27,7 @@
>    * @summary Test for PLAB resizing
>    * @requires vm.gc=="G1" | vm.gc=="null"
>    * @requires vm.opt.FlightRecorder != true
> - * @library /testlibrary /../../test/lib /
> + * @library /testlibrary /test/lib /
>    * @modules java.management
>    * @build ClassFileInstaller
>    *        sun.hotspot.WhiteBox
>
>> On 9 mars 2016, at 10:54, Bengt Rutisson <bengt.rutisson at oracle.com> wrote:
>>
>>
>> Hi Staffan,
>>
>> Changes look good.
>>
>> However it looks like this test has the same issue, right?
>> http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/file/59d3a69564dc/test/gc/g1/plab/TestPLABResize.java
>>
>> It is currently ignored, but we should probably fix it too...
>>
>> Thanks,
>> Bengt
>>
>> On 2016-03-09 10:47, Staffan Larsen wrote:
>>> Please review this small fix to some tests with the wrong paths in them. Tested locally with jtreg 4.1 b12 and b13.
>>>
>>> Thanks,
>>> /Staffan
>>>
>>>
>>> $ hg diff
>>> diff --git a/test/gc/g1/plab/TestPLABPromotion.java b/test/gc/g1/plab/TestPLABPromotion.java
>>> --- a/test/gc/g1/plab/TestPLABPromotion.java
>>> +++ b/test/gc/g1/plab/TestPLABPromotion.java
>>> @@ -27,7 +27,7 @@
>>>    * @summary Test PLAB promotion
>>>    * @requires vm.gc=="G1" | vm.gc=="null"
>>>    * @requires vm.opt.FlightRecorder != true
>>> - * @library /testlibrary /../../test/lib /
>>> + * @library /testlibrary /test/lib /
>>>    * @modules java.management
>>>    * @build ClassFileInstaller
>>>    *        sun.hotspot.WhiteBox
>>> diff --git a/test/serviceability/dcmd/gc/HeapDumpAllTest.java b/test/serviceability/dcmd/gc/HeapDumpAllTest.java
>>> --- a/test/serviceability/dcmd/gc/HeapDumpAllTest.java
>>> +++ b/test/serviceability/dcmd/gc/HeapDumpAllTest.java
>>> @@ -35,7 +35,7 @@
>>>    * @build jdk.test.lib.hprof.*
>>>    * @build jdk.test.lib.hprof.model.*
>>>    * @build jdk.test.lib.hprof.parser.*
>>> - * @build jdk.test.lib.hprof.utils.*
>>> + * @build jdk.test.lib.hprof.util.*
>>>    * @build HeapDumpTest
>>>    * @run testng HeapDumpAllTest
>>>    */
>>> diff --git a/test/serviceability/dcmd/gc/HeapDumpTest.java b/test/serviceability/dcmd/gc/HeapDumpTest.java
>>> --- a/test/serviceability/dcmd/gc/HeapDumpTest.java
>>> +++ b/test/serviceability/dcmd/gc/HeapDumpTest.java
>>> @@ -51,7 +51,7 @@
>>>    * @build jdk.test.lib.hprof.*
>>>    * @build jdk.test.lib.hprof.model.*
>>>    * @build jdk.test.lib.hprof.parser.*
>>> - * @build jdk.test.lib.hprof.utils.*
>>> + * @build jdk.test.lib.hprof.util.*
>>>    * @run testng HeapDumpTest
>>>    */
>>>   public class HeapDumpTest {


From christian.tornqvist at oracle.com  Wed Mar  9 10:29:50 2016
From: christian.tornqvist at oracle.com (Christian Tornqvist)
Date: Wed, 9 Mar 2016 05:29:50 -0500
Subject: RFR: JDK-8151196 Several tests fail due to test library not found
In-Reply-To: <17547FF0-000C-408A-8D54-45FA738D1255@oracle.com>
References: <916B8270-CFF4-4BC7-89AF-A909D494AA1D@oracle.com>	<56DFF2C4.9050105@oracle.com>
	<17547FF0-000C-408A-8D54-45FA738D1255@oracle.com>
Message-ID: <133d01d179ee$9d06f030$d714d090$@oracle.com>

Hi Staffan,

Looks good, thanks for fixing this.

Thanks,
Christian

-----Original Message-----
From: serviceability-dev
[mailto:serviceability-dev-bounces at openjdk.java.net] On Behalf Of Staffan
Larsen
Sent: Wednesday, March 9, 2016 5:03 AM
To: Bengt Rutisson <bengt.rutisson at oracle.com>
Cc: serviceability-dev at openjdk.java.net; hotspot-gc-dev at openjdk.java.net
Subject: Re: RFR: JDK-8151196 Several tests fail due to test library not
found

Good catch. Incremental change:

diff --git a/test/gc/g1/plab/TestPLABResize.java
b/test/gc/g1/plab/TestPLABResize.java
--- a/test/gc/g1/plab/TestPLABResize.java
+++ b/test/gc/g1/plab/TestPLABResize.java
@@ -27,7 +27,7 @@
  * @summary Test for PLAB resizing
  * @requires vm.gc=="G1" | vm.gc=="null"
  * @requires vm.opt.FlightRecorder != true
- * @library /testlibrary /../../test/lib /
+ * @library /testlibrary /test/lib /
  * @modules java.management
  * @build ClassFileInstaller
  *        sun.hotspot.WhiteBox

> On 9 mars 2016, at 10:54, Bengt Rutisson <bengt.rutisson at oracle.com>
wrote:
> 
> 
> Hi Staffan,
> 
> Changes look good.
> 
> However it looks like this test has the same issue, right?
>
http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/file/59d3a69564dc/test/gc/g1
/plab/TestPLABResize.java
> 
> It is currently ignored, but we should probably fix it too...
> 
> Thanks,
> Bengt
> 
> On 2016-03-09 10:47, Staffan Larsen wrote:
>> Please review this small fix to some tests with the wrong paths in
them. Tested locally with jtreg 4.1 b12 and b13.
>> 
>> Thanks,
>> /Staffan
>> 
>> 
>> $ hg diff
>> diff --git a/test/gc/g1/plab/TestPLABPromotion.java
b/test/gc/g1/plab/TestPLABPromotion.java
>> --- a/test/gc/g1/plab/TestPLABPromotion.java
>> +++ b/test/gc/g1/plab/TestPLABPromotion.java
>> @@ -27,7 +27,7 @@
>>   * @summary Test PLAB promotion
>>   * @requires vm.gc=="G1" | vm.gc=="null"
>>   * @requires vm.opt.FlightRecorder != true
>> - * @library /testlibrary /../../test/lib /
>> + * @library /testlibrary /test/lib /
>>   * @modules java.management
>>   * @build ClassFileInstaller
>>   *        sun.hotspot.WhiteBox
>> diff --git a/test/serviceability/dcmd/gc/HeapDumpAllTest.java
b/test/serviceability/dcmd/gc/HeapDumpAllTest.java
>> --- a/test/serviceability/dcmd/gc/HeapDumpAllTest.java
>> +++ b/test/serviceability/dcmd/gc/HeapDumpAllTest.java
>> @@ -35,7 +35,7 @@
>>   * @build jdk.test.lib.hprof.*
>>   * @build jdk.test.lib.hprof.model.*
>>   * @build jdk.test.lib.hprof.parser.*
>> - * @build jdk.test.lib.hprof.utils.*
>> + * @build jdk.test.lib.hprof.util.*
>>   * @build HeapDumpTest
>>   * @run testng HeapDumpAllTest
>>   */
>> diff --git a/test/serviceability/dcmd/gc/HeapDumpTest.java
b/test/serviceability/dcmd/gc/HeapDumpTest.java
>> --- a/test/serviceability/dcmd/gc/HeapDumpTest.java
>> +++ b/test/serviceability/dcmd/gc/HeapDumpTest.java
>> @@ -51,7 +51,7 @@
>>   * @build jdk.test.lib.hprof.*
>>   * @build jdk.test.lib.hprof.model.*
>>   * @build jdk.test.lib.hprof.parser.*
>> - * @build jdk.test.lib.hprof.utils.*
>> + * @build jdk.test.lib.hprof.util.*
>>   * @run testng HeapDumpTest
>>   */
>>  public class HeapDumpTest {
> 



From thomas.stuefe at gmail.com  Wed Mar  9 11:13:35 2016
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Wed, 9 Mar 2016 12:13:35 +0100
Subject: RFR[9u-dev]: 8146683: check_addr0 should be more efficient
In-Reply-To: <56DD64B2.4010901@oracle.com>
References: <38bc418b-c510-4ae8-8d8e-161b5ea42920@default>
	<CAA-vtUxV_93cfiFpR-PaMjbShAYqjCNtWwPAMGZ8-XPwG2t2ig@mail.gmail.com>
	<56CC9FF2.4040406@oracle.com> <56CD11F5.9060002@oracle.com>
	<2fecd625-4723-4fbe-b148-36f7bb654df6@default>
	<56DD52F8.8070208@oracle.com> <56DD59A2.1030804@oracle.com>
	<56DD64B2.4010901@oracle.com>
Message-ID: <CAA-vtUwzb0Ew7d6eYdipoFYErPes0tGDd5287Ee6NcOfb0x-yw@mail.gmail.com>

Hi all,

I see the change is already pushed, but I am not sure this works as
intended:

We iterate now over all fully read items:

+      p = (prmap_t *)mbuff;
+      for(int i = 0; i < nmap; i++){
+        if (p->pr_vaddr == 0x0) {
+   ....
+        }
+        p = (prmap_t *)(mbuff + sizeof(prmap_t));
+      }

Where do we move the pointer forward? The way I see it, we only ever
examine the first and the second item, then repeat examining the second
item over and over again.

Instead of

+        p = (prmap_t *)(mbuff + sizeof(prmap_t));

Should this not be

p = ((prmap_t *)mbuff) + i;

or just

p++;

?

Kind Regards, Thomas






On Mon, Mar 7, 2016 at 12:23 PM, David Holmes <david.holmes at oracle.com>
wrote:

> On 7/03/2016 8:36 PM, Kevin Walls wrote:
>
>>
>> Hi Cheleswer,
>>
>> Looks good.  (While we've discussed it offline I haven't actually
>> offered a public review).
>>
>> Just one more thing, and this concerns the original code not the change:
>>
>> 1880           st->print("Warning: Address: 0x%x, Size: %dK,
>> ",p->pr_vaddr, p->pr_size/1024, p->pr_mapname);
>>
>
> Also %x is the wrong format specifier:
>
> typedef struct prmap {
>         uintptr_t pr_vaddr;     /* virtual address of mapping */
>
> David
> -----
>
>
> We pass 3 params when we only print two items?  The "p->pr_mapname", we
>> pass again on the next line where we do have the the "%s" in the format
>> string, so this one is unnecessary. 8-)
>>
>> Thanks
>> Kevin
>>
>>
>>
>> On 07/03/2016 10:07, Dmitry Samersoff wrote:
>>
>>> Cheleswer,
>>>
>>> Looks good for me.
>>>
>>> -Dmitry
>>>
>>>
>>> On 2016-03-03 19:28, Cheleswer Sahu wrote:
>>>
>>>> Hi,
>>>>
>>>> Please review the new code changes for this bug. I have removed  "
>>>> fstat()"  call which seems not safe to read the "/proc/map/self" file
>>>> and have made some other changes too. Please find the latest code in
>>>> below link
>>>> Webrev link: http://cr.openjdk.java.net/~csahu/8146683/webrev.01/
>>>>
>>>>
>>>> Regards,
>>>> Cheleswer
>>>>
>>>> -----Original Message-----
>>>> From: Dean Long
>>>> Sent: Wednesday, February 24, 2016 7:44 AM
>>>> To: Daniel Daugherty; Thomas St?fe; Cheleswer Sahu
>>>> Cc: serviceability-dev at openjdk.java.net;
>>>> hotspot-runtime-dev at openjdk.java.net
>>>> Subject: Re: RFR[9u-dev]: 8146683: check_addr0 should be more efficient
>>>>
>>>> On 2/23/2016 10:07 AM, Daniel D. Daugherty wrote:
>>>>
>>>>> On 2/23/16 5:56 AM, Thomas St?fe wrote:
>>>>>
>>>>>> Hi Cheleswer,
>>>>>>
>>>>>>
>>>>>> On Tue, Feb 23, 2016 at 9:38 AM, Cheleswer Sahu
>>>>>> <cheleswer.sahu at oracle.com>
>>>>>>    wrote:
>>>>>>
>>>>>> Hi,
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Please review the code changes for
>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8146683 .
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Webrev link: http://cr.openjdk.java.net/~csahu/8146683/
>>>>>>>
>>>>>>> JBS Link: https://bugs.openjdk.java.net/browse/JDK-8146683
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Bug Brief:
>>>>>>>
>>>>>>> While investigating  bug
>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8144483
>>>>>>> it has been observed that "check_addr0() " function  is not written
>>>>>>> efficiently.
>>>>>>>
>>>>>>> This function is trying to read each "prmap_t" entry in
>>>>>>> "/proc/self/map"
>>>>>>> file one by one which is time taking and can cause in long pauses.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Solution proposed:
>>>>>>>
>>>>>>> Instead of reading each "prmap_t" entry in "/proc/self/map" file one
>>>>>>> by one, read the entries in chunks. There can be many entries in
>>>>>>> "map"
>>>>>>> file,
>>>>>>> so I have decided to read these
>>>>>>>
>>>>>>> in chunks of 100  "prmap_t" entries. Reading entries in chunks saves
>>>>>>> a lot of read calls and results in smaller pause times.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Regards,
>>>>>>>
>>>>>>> Cheleswer
>>>>>>>
>>>>>>> We saw cases, especially on Solaris, where the content of a file in
>>>>>> the
>>>>>> proc file system changed under us while we were reading it. So this
>>>>>> should
>>>>>> be kept in mind. The original code seems also broken in that regard,
>>>>>> because it assumes the ::read() call to read the full size of a
>>>>>> prmap_t
>>>>>> entry, but it may theoretically read an incomplete entry.
>>>>>>
>>>>>> As for your coding, you first estimate the size of the mapping file
>>>>>> and
>>>>>> then use this to determine how many entries to read; but when
>>>>>> reading, this
>>>>>> information may already be stale. I think it would be more robust and
>>>>>> also
>>>>>> simpler to just try to read as many entries as possible - in
>>>>>> chunks, to
>>>>>> make reading faster - until you get EOF.
>>>>>>
>>>>>> Kind Regards, Thomas
>>>>>>
>>>>> I'm really sure that we've been down this road before. In particular,
>>>>> Dmitry Samersoff has worked on this issue (or one very much like it)
>>>>> before, but he is on vacation until the end of the month.
>>>>>
>>>>> There was a similar issue with Linux /proc/self/maps, and whether it
>>>> was
>>>> safe to read the file with buffered stdio or not.  See 8009062 and
>>>> 7017193.
>>>>
>>>> dl
>>>>
>>>> Dan
>>>>>
>>>>>
>>>>> On Tue, Feb 23, 2016 at 9:38 AM, Cheleswer Sahu
>>>>>> <cheleswer.sahu at oracle.com>
>>>>>> wrote:
>>>>>>
>>>>>> Hi,
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Please review the code changes for
>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8146683 .
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Webrev link: http://cr.openjdk.java.net/~csahu/8146683/
>>>>>>>
>>>>>>> JBS Link: https://bugs.openjdk.java.net/browse/JDK-8146683
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Bug Brief:
>>>>>>>
>>>>>>> While investigating  bug
>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8144483
>>>>>>> it has been observed that "check_addr0() " function  is not written
>>>>>>> efficiently.
>>>>>>>
>>>>>>> This function is trying to read each "prmap_t" entry in
>>>>>>> "/proc/self/map"
>>>>>>> file one by one which is time taking and can cause in long pauses.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Solution proposed:
>>>>>>>
>>>>>>> Instead of reading each "prmap_t" entry in "/proc/self/map" file
>>>>>>> one by
>>>>>>> one, read the entries in chunks. There can be many entries in "map"
>>>>>>> file,
>>>>>>> so I have decided to read these
>>>>>>>
>>>>>>> in chunks of 100  "prmap_t" entries. Reading entries in chunks saves
>>>>>>> a lot
>>>>>>> of read calls and results in smaller pause times.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Regards,
>>>>>>>
>>>>>>> Cheleswer
>>>>>>>
>>>>>>>
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20160309/00103ed4/attachment-0001.html>

From staffan.larsen at oracle.com  Wed Mar  9 11:31:56 2016
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Wed, 9 Mar 2016 12:31:56 +0100
Subject: RFR: JDK-8151196 Several tests fail due to test library not found
In-Reply-To: <133d01d179ee$9d06f030$d714d090$@oracle.com>
References: <916B8270-CFF4-4BC7-89AF-A909D494AA1D@oracle.com>
	<56DFF2C4.9050105@oracle.com>
	<17547FF0-000C-408A-8D54-45FA738D1255@oracle.com>
	<133d01d179ee$9d06f030$d714d090$@oracle.com>
Message-ID: <114E1943-5F0F-4B28-A77F-15A127F16779@oracle.com>

Christian, Bengt: Thanks for the reviews. Pushing now.

> On 9 mars 2016, at 11:29, Christian Tornqvist <christian.tornqvist at oracle.com> wrote:
> 
> Hi Staffan,
> 
> Looks good, thanks for fixing this.
> 
> Thanks,
> Christian
> 
> -----Original Message-----
> From: serviceability-dev
> [mailto:serviceability-dev-bounces at openjdk.java.net] On Behalf Of Staffan
> Larsen
> Sent: Wednesday, March 9, 2016 5:03 AM
> To: Bengt Rutisson <bengt.rutisson at oracle.com>
> Cc: serviceability-dev at openjdk.java.net; hotspot-gc-dev at openjdk.java.net
> Subject: Re: RFR: JDK-8151196 Several tests fail due to test library not
> found
> 
> Good catch. Incremental change:
> 
> diff --git a/test/gc/g1/plab/TestPLABResize.java
> b/test/gc/g1/plab/TestPLABResize.java
> --- a/test/gc/g1/plab/TestPLABResize.java
> +++ b/test/gc/g1/plab/TestPLABResize.java
> @@ -27,7 +27,7 @@
>  * @summary Test for PLAB resizing
>  * @requires vm.gc=="G1" | vm.gc=="null"
>  * @requires vm.opt.FlightRecorder != true
> - * @library /testlibrary /../../test/lib /
> + * @library /testlibrary /test/lib /
>  * @modules java.management
>  * @build ClassFileInstaller
>  *        sun.hotspot.WhiteBox
> 
>> On 9 mars 2016, at 10:54, Bengt Rutisson <bengt.rutisson at oracle.com>
> wrote:
>> 
>> 
>> Hi Staffan,
>> 
>> Changes look good.
>> 
>> However it looks like this test has the same issue, right?
>> 
> http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/file/59d3a69564dc/test/gc/g1
> /plab/TestPLABResize.java
>> 
>> It is currently ignored, but we should probably fix it too...
>> 
>> Thanks,
>> Bengt
>> 
>> On 2016-03-09 10:47, Staffan Larsen wrote:
>>> Please review this small fix to some tests with the wrong paths in
> them. Tested locally with jtreg 4.1 b12 and b13.
>>> 
>>> Thanks,
>>> /Staffan
>>> 
>>> 
>>> $ hg diff
>>> diff --git a/test/gc/g1/plab/TestPLABPromotion.java
> b/test/gc/g1/plab/TestPLABPromotion.java
>>> --- a/test/gc/g1/plab/TestPLABPromotion.java
>>> +++ b/test/gc/g1/plab/TestPLABPromotion.java
>>> @@ -27,7 +27,7 @@
>>>  * @summary Test PLAB promotion
>>>  * @requires vm.gc=="G1" | vm.gc=="null"
>>>  * @requires vm.opt.FlightRecorder != true
>>> - * @library /testlibrary /../../test/lib /
>>> + * @library /testlibrary /test/lib /
>>>  * @modules java.management
>>>  * @build ClassFileInstaller
>>>  *        sun.hotspot.WhiteBox
>>> diff --git a/test/serviceability/dcmd/gc/HeapDumpAllTest.java
> b/test/serviceability/dcmd/gc/HeapDumpAllTest.java
>>> --- a/test/serviceability/dcmd/gc/HeapDumpAllTest.java
>>> +++ b/test/serviceability/dcmd/gc/HeapDumpAllTest.java
>>> @@ -35,7 +35,7 @@
>>>  * @build jdk.test.lib.hprof.*
>>>  * @build jdk.test.lib.hprof.model.*
>>>  * @build jdk.test.lib.hprof.parser.*
>>> - * @build jdk.test.lib.hprof.utils.*
>>> + * @build jdk.test.lib.hprof.util.*
>>>  * @build HeapDumpTest
>>>  * @run testng HeapDumpAllTest
>>>  */
>>> diff --git a/test/serviceability/dcmd/gc/HeapDumpTest.java
> b/test/serviceability/dcmd/gc/HeapDumpTest.java
>>> --- a/test/serviceability/dcmd/gc/HeapDumpTest.java
>>> +++ b/test/serviceability/dcmd/gc/HeapDumpTest.java
>>> @@ -51,7 +51,7 @@
>>>  * @build jdk.test.lib.hprof.*
>>>  * @build jdk.test.lib.hprof.model.*
>>>  * @build jdk.test.lib.hprof.parser.*
>>> - * @build jdk.test.lib.hprof.utils.*
>>> + * @build jdk.test.lib.hprof.util.*
>>>  * @run testng HeapDumpTest
>>>  */
>>> public class HeapDumpTest {
>> 
> 
> 


From cheleswer.sahu at oracle.com  Wed Mar  9 12:19:31 2016
From: cheleswer.sahu at oracle.com (Cheleswer Sahu)
Date: Wed, 9 Mar 2016 04:19:31 -0800 (PST)
Subject: RFR[9u-dev]: 8146683: check_addr0 should be more efficient
In-Reply-To: <CAA-vtUwzb0Ew7d6eYdipoFYErPes0tGDd5287Ee6NcOfb0x-yw@mail.gmail.com>
References: <38bc418b-c510-4ae8-8d8e-161b5ea42920@default>
	<CAA-vtUxV_93cfiFpR-PaMjbShAYqjCNtWwPAMGZ8-XPwG2t2ig@mail.gmail.com>
	<56CC9FF2.4040406@oracle.com> <56CD11F5.9060002@oracle.com>
	<2fecd625-4723-4fbe-b148-36f7bb654df6@default>
	<56DD52F8.8070208@oracle.com>
	<56DD59A2.1030804@oracle.com> <56DD64B2.4010901@oracle.com>
	<CAA-vtUwzb0Ew7d6eYdipoFYErPes0tGDd5287Ee6NcOfb0x-yw@mail.gmail.com>
Message-ID: <7f870af4-0d4a-4645-981b-97bae67abfaf@default>

Hi Thomas,

?

Thanks for identifying the issue. I will file a new bug for this and correct the issue.

?

?

Regards,

Cheleswer

?

?

From: Thomas St?fe [mailto:thomas.stuefe at gmail.com] 
Sent: Wednesday, March 09, 2016 4:44 PM
To: David Holmes
Cc: Kevin Walls; Cheleswer Sahu; Daniel Daugherty; serviceability-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net
Subject: Re: RFR[9u-dev]: 8146683: check_addr0 should be more efficient

?

Hi all,

?

I see the change is already pushed, but I am not sure this works as intended:

?

We iterate now over all fully read items:


+ ? ? ?p = (prmap_t *)mbuff;
+ ? ? ?for(int i = 0; i < nmap; i++){
+ ? ? ? ?if (p->pr_vaddr == 0x0) {
+ ? ....
+ ? ? ? ?}
+ ? ? ? ?p = (prmap_t *)(mbuff + sizeof(prmap_t));
+ ? ? ?}

?

Where do we move the pointer forward? The way I see it, we only ever examine the first and the second item, then repeat examining the second item over and over again.

?

Instead of?

?

+ ? ? ? ?p = (prmap_t *)(mbuff + sizeof(prmap_t));

?

Should this not be

?

p = ((prmap_t *)mbuff) + i;

?

or just

?

p++;

?

?

?

Kind Regards, Thomas

?

?

?

?

?

?

On Mon, Mar 7, 2016 at 12:23 PM, David Holmes <HYPERLINK "mailto:david.holmes at oracle.com"david.holmes at oracle.com> wrote:

On 7/03/2016 8:36 PM, Kevin Walls wrote:


Hi Cheleswer,

Looks good.? (While we've discussed it offline I haven't actually
offered a public review).

Just one more thing, and this concerns the original code not the change:

1880? ? ? ? ? ?st->print("Warning: Address: 0x%x, Size: %dK,
",p->pr_vaddr, p->pr_size/1024, p->pr_mapname);


Also %x is the wrong format specifier:

typedef struct prmap {
? ? ? ? uintptr_t pr_vaddr;? ? ?/* virtual address of mapping */

David
-----

?

We pass 3 params when we only print two items?? The "p->pr_mapname", we
pass again on the next line where we do have the the "%s" in the format
string, so this one is unnecessary. 8-)

Thanks
Kevin



On 07/03/2016 10:07, Dmitry Samersoff wrote:

Cheleswer,

Looks good for me.

-Dmitry


On 2016-03-03 19:28, Cheleswer Sahu wrote:

Hi,

Please review the new code changes for this bug. I have removed? "
fstat()"? call which seems not safe to read the "/proc/map/self" file
and have made some other changes too. Please find the latest code in
below link
Webrev link: http://cr.openjdk.java.net/~csahu/8146683/webrev.01/


Regards,
Cheleswer

-----Original Message-----
From: Dean Long
Sent: Wednesday, February 24, 2016 7:44 AM
To: Daniel Daugherty; Thomas St?fe; Cheleswer Sahu
Cc: HYPERLINK "mailto:serviceability-dev at openjdk.java.net"serviceability-dev at openjdk.java.net;
HYPERLINK "mailto:hotspot-runtime-dev at openjdk.java.net"hotspot-runtime-dev at openjdk.java.net
Subject: Re: RFR[9u-dev]: 8146683: check_addr0 should be more efficient

On 2/23/2016 10:07 AM, Daniel D. Daugherty wrote:

On 2/23/16 5:56 AM, Thomas St?fe wrote:

Hi Cheleswer,


On Tue, Feb 23, 2016 at 9:38 AM, Cheleswer Sahu
<HYPERLINK "mailto:cheleswer.sahu at oracle.com"cheleswer.sahu at oracle.com>
? ?wrote:

Hi,



Please review the code changes for
https://bugs.openjdk.java.net/browse/JDK-8146683 .



Webrev link: http://cr.openjdk.java.net/~csahu/8146683/

JBS Link: https://bugs.openjdk.java.net/browse/JDK-8146683



Bug Brief:

While investigating? bug
https://bugs.openjdk.java.net/browse/JDK-8144483
it has been observed that "check_addr0() " function? is not written
efficiently.

This function is trying to read each "prmap_t" entry in
"/proc/self/map"
file one by one which is time taking and can cause in long pauses.



Solution proposed:

Instead of reading each "prmap_t" entry in "/proc/self/map" file one
by one, read the entries in chunks. There can be many entries in
"map"
file,
so I have decided to read these

in chunks of 100? "prmap_t" entries. Reading entries in chunks saves
a lot of read calls and results in smaller pause times.





Regards,

Cheleswer

We saw cases, especially on Solaris, where the content of a file in
the
proc file system changed under us while we were reading it. So this
should
be kept in mind. The original code seems also broken in that regard,
because it assumes the ::read() call to read the full size of a
prmap_t
entry, but it may theoretically read an incomplete entry.

As for your coding, you first estimate the size of the mapping file
and
then use this to determine how many entries to read; but when
reading, this
information may already be stale. I think it would be more robust and
also
simpler to just try to read as many entries as possible - in
chunks, to
make reading faster - until you get EOF.

Kind Regards, Thomas

I'm really sure that we've been down this road before. In particular,
Dmitry Samersoff has worked on this issue (or one very much like it)
before, but he is on vacation until the end of the month.

There was a similar issue with Linux /proc/self/maps, and whether it was
safe to read the file with buffered stdio or not.? See 8009062 and
7017193.

dl

Dan



On Tue, Feb 23, 2016 at 9:38 AM, Cheleswer Sahu
<HYPERLINK "mailto:cheleswer.sahu at oracle.com"cheleswer.sahu at oracle.com>
wrote:

Hi,



Please review the code changes for
https://bugs.openjdk.java.net/browse/JDK-8146683 .



Webrev link: http://cr.openjdk.java.net/~csahu/8146683/

JBS Link: https://bugs.openjdk.java.net/browse/JDK-8146683



Bug Brief:

While investigating? bug
https://bugs.openjdk.java.net/browse/JDK-8144483
it has been observed that "check_addr0() " function? is not written
efficiently.

This function is trying to read each "prmap_t" entry in
"/proc/self/map"
file one by one which is time taking and can cause in long pauses.



Solution proposed:

Instead of reading each "prmap_t" entry in "/proc/self/map" file
one by
one, read the entries in chunks. There can be many entries in "map"
file,
so I have decided to read these

in chunks of 100? "prmap_t" entries. Reading entries in chunks saves
a lot
of read calls and results in smaller pause times.





Regards,

Cheleswer

?

?

?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20160309/3b742959/attachment-0001.html>

From yasuenag at gmail.com  Wed Mar  9 12:41:55 2016
From: yasuenag at gmail.com (Yasumasa Suenaga)
Date: Wed, 9 Mar 2016 21:41:55 +0900
Subject: JDK-6291341: jstat: FGC counter confusing when CMS GC is used
In-Reply-To: <BEC8AE2A-BABB-45D8-B569-1BCD2F507305@oracle.com>
References: <56DEE3DF.6070709@gmail.com> <56DF4D5B.8070409@oracle.com>
	<BEC8AE2A-BABB-45D8-B569-1BCD2F507305@oracle.com>
Message-ID: <56E01A13.9050201@gmail.com>

Hi,

> The jdk changes look good to me.

Thanks! Staffan


Jon,

>> Meaning, without the jdk changes, will jstat continue to work
>> as it currently does?

I uploaded new webrev. I updated webrev for hotspot only:
    http://cr.openjdk.java.net/~ysuenaga/JDK-6291341/poc-2/hotspot/

This patch works the same as the current by default.
If you set -XX:+EnableConcGCPerfCounter, CGC counter will work fine.
(I want to set +EnableConcGCPerfCounter by default :-) )


>> Would the changes in the JVM be useful to you without the jstat changes?

We can override jstat_options if we want to watch CGC counters.
Also we can check it through PerfCounter.print jcmd.

I'm developing JVMTI agent [1] which uses sun.gc.collector PerfCounters.
Our agent watches major collection through PerfCounter and JVMTI events.

Thus I'm sure that this change is very useful for us.


Thanks,

Yasumasa


[1] http://icedtea.classpath.org/wiki/HeapStats


On 2016/03/09 16:13, Staffan Larsen wrote:
> The jdk changes look good to me. Jon, if you integrate the JVM changes you can do the jdk changes at the same time in the hs-rt repo.
> 
> Thanks,
> /Staffan
> 
> 
>> On 8 mars 2016, at 23:08, Jon Masamitsu <jon.masamitsu at oracle.com> wrote:
>>
>> Yasumasa,
>>
>> We're discussing this.
>>
>> What would the result be if the GC team made the
>> JVM changes that you want to contribute.  Meaning,
>> without the jdk changes, will jstat continue to work
>> as it currently does?  Would the changes in the JVM
>> be useful to you without the jstat changes?  By the
>> JVM changes, I mean the changes for the counters.
>>
>> The reason I ask is that the GC team does not
>> own jstat.   If I can integrate the JVM changes
>> without the jstat changes, it makes it a little
>> simpler.
>>
>> Jon
>>
>>
>> On 3/8/2016 6:38 AM, Yasumasa Suenaga wrote:
>>> Hi all,
>>>
>>> I discussed about FullGC counter for Concurrent GC:
>>>      http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2016-March/016774.html
>>>
>>> I found same issue on JBS:
>>>      JDK-6291341: jstat: FGC counter confusing when CMS GC is used
>>>
>>> JDK-6291341 was closed with Cannot Reproduce.
>>> However, I showed cause of this issue in above thread.
>>>
>>> I uploaded patches for this issue:
>>>
>>>      hotspot:http://cr.openjdk.java.net/~ysuenaga/JDK-6291341/poc/hotspot/
>>>          jdk:http://cr.openjdk.java.net/~ysuenaga/JDK-6291341/poc/jdk/
>>>
>>> JDK webrev includes testcase update.
>>> All tests for jstat work fine.
>>>
>>>
>>> Should I work for it as new issue? Or should I reopen JDK-6291341?
>>>
>>> I cannot access JPRT.
>>> So I need a sponsor.
>>>
>>>
>>> Thanks,
>>>
>>> Yasumasa
>>>
>>>
>>
> 
> 

From cheleswer.sahu at oracle.com  Thu Mar 10 10:43:57 2016
From: cheleswer.sahu at oracle.com (Cheleswer Sahu)
Date: Thu, 10 Mar 2016 02:43:57 -0800 (PST)
Subject: RFR[9u-dev]: 8151509: In check_addr0() function pointer is not
	updated correctly
Message-ID: <c136e4ba-60f8-493b-8179-1b8178083a8c@default>

Hi,

 

Please review the code changes for https://bugs.openjdk.java.net/browse/JDK-8151509.

 

Webrev link: http://cr.openjdk.java.net/~csahu/8151509/

 

Bug Brief: 

In check_addr0(),  pointer "p" is not updated correctly, because of this it was reading only first two entries from buffer.

 

 

Regards,

Cheleswer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20160310/b97cba4e/attachment.html>

From dmitry.dmitriev at oracle.com  Thu Mar 10 12:45:57 2016
From: dmitry.dmitriev at oracle.com (Dmitry Dmitriev)
Date: Thu, 10 Mar 2016 15:45:57 +0300
Subject: RFR[9u-dev]: 8151509: In check_addr0() function pointer is not
	updated correctly
In-Reply-To: <c136e4ba-60f8-493b-8179-1b8178083a8c@default>
References: <c136e4ba-60f8-493b-8179-1b8178083a8c@default>
Message-ID: <56E16C85.30102@oracle.com>

Hi Cheleswer,

Looks good, but I have questions/comments about other code in this function:
1) I think that "::close(fd);" should be inside "if (fd >= 0) {".
2) Just interesting, do you really need to set memory to 0 by memset?

Thanks,
Dmitry


On 10.03.2016 13:43, Cheleswer Sahu wrote:
>
> Hi,
>
> Please review the code changes for 
> https://bugs.openjdk.java.net/browse/JDK-8151509.
>
> Webrev link: http://cr.openjdk.java.net/~csahu/8151509/ 
> <http://cr.openjdk.java.net/%7Ecsahu/8151509/>
>
> Bug Brief:
>
> In check_addr0(),  pointer ?p? is not updated correctly, because of 
> this it was reading only first two entries from buffer.
>
> Regards,
>
> Cheleswer
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20160310/1d181fad/attachment.html>

From thomas.stuefe at gmail.com  Thu Mar 10 14:07:18 2016
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Thu, 10 Mar 2016 15:07:18 +0100
Subject: RFR[9u-dev]: 8151509: In check_addr0() function pointer is not
	updated correctly
In-Reply-To: <56E16C85.30102@oracle.com>
References: <c136e4ba-60f8-493b-8179-1b8178083a8c@default>
	<56E16C85.30102@oracle.com>
Message-ID: <CAA-vtUyfV1BiJBXNiO5Qk_=z_ZKGOVx7bvBDOpGuxPXxZ7zhXA@mail.gmail.com>

Hi Cheleswer,

thanks for fixing this.

Some more issues:

- 1866 char *mbuff = (char *) calloc(read_chunk, sizeof(prmap_t) + 1);

Why the "+1"? It is unnecessary and causes the allocation to be 200 bytes
larger than necessary.

- 1880 st->print("Warning: Address: " PTR_FORMAT ", Size: %dK,
",p->pr_vaddr, p->pr_size/1024);

Format specifier for Size is wrong.%d is int, but p->pr_size is size_t.
Theoretical truncation for mappings larger than 4g*1024.
(But I know this coding was there before)

Beside those points, I think both points of Dmitry are valid.

Also, I find


Kind Regards, Thomas

On Thu, Mar 10, 2016 at 1:45 PM, Dmitry Dmitriev <dmitry.dmitriev at oracle.com
> wrote:

> Hi Cheleswer,
>
> Looks good, but I have questions/comments about other code in this
> function:
> 1) I think that "::close(fd);" should be inside "if (fd >= 0) {".
> 2) Just interesting, do you really need to set memory to 0 by memset?
>
> Thanks,
> Dmitry
>
>
> On 10.03.2016 13:43, Cheleswer Sahu wrote:
>
>>
>> Hi,
>>
>> Please review the code changes for
>> https://bugs.openjdk.java.net/browse/JDK-8151509.
>>
>> Webrev link: http://cr.openjdk.java.net/~csahu/8151509/ <
>> http://cr.openjdk.java.net/%7Ecsahu/8151509/>
>>
>> Bug Brief:
>>
>> In check_addr0(),  pointer ?p? is not updated correctly, because of this
>> it was reading only first two entries from buffer.
>>
>> Regards,
>>
>> Cheleswer
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20160310/bed7a503/attachment.html>

From thomas.stuefe at gmail.com  Thu Mar 10 14:09:04 2016
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Thu, 10 Mar 2016 15:09:04 +0100
Subject: RFR[9u-dev]: 8151509: In check_addr0() function pointer is not
	updated correctly
In-Reply-To: <CAA-vtUyfV1BiJBXNiO5Qk_=z_ZKGOVx7bvBDOpGuxPXxZ7zhXA@mail.gmail.com>
References: <c136e4ba-60f8-493b-8179-1b8178083a8c@default>
	<56E16C85.30102@oracle.com>
	<CAA-vtUyfV1BiJBXNiO5Qk_=z_ZKGOVx7bvBDOpGuxPXxZ7zhXA@mail.gmail.com>
Message-ID: <CAA-vtUxJA7FzDaXAvebPdfcCGqCtwrCjt-Hqz_4_snhvGqWB6w@mail.gmail.com>

(Sorry, pressed Send button too early)

Just wanted to add that

1873       if( 0 != ret % sizeof(prmap_t)){
1874         break;
1875       }

may be a bit harsh, as it skips the entire mapping in case read() stopped
reading in a middle of a record. You could just continue to read until you
read the rest of the record.

Kind Regards, Thomas


On Thu, Mar 10, 2016 at 3:07 PM, Thomas St?fe <thomas.stuefe at gmail.com>
wrote:

> Hi Cheleswer,
>
> thanks for fixing this.
>
> Some more issues:
>
> - 1866 char *mbuff = (char *) calloc(read_chunk, sizeof(prmap_t) + 1);
>
> Why the "+1"? It is unnecessary and causes the allocation to be 200 bytes
> larger than necessary.
>
> - 1880 st->print("Warning: Address: " PTR_FORMAT ", Size: %dK,
> ",p->pr_vaddr, p->pr_size/1024);
>
> Format specifier for Size is wrong.%d is int, but p->pr_size is size_t.
> Theoretical truncation for mappings larger than 4g*1024.
> (But I know this coding was there before)
>
> Beside those points, I think both points of Dmitry are valid.
>
> Also, I find
>
>
> Kind Regards, Thomas
>
> On Thu, Mar 10, 2016 at 1:45 PM, Dmitry Dmitriev <
> dmitry.dmitriev at oracle.com> wrote:
>
>> Hi Cheleswer,
>>
>> Looks good, but I have questions/comments about other code in this
>> function:
>> 1) I think that "::close(fd);" should be inside "if (fd >= 0) {".
>> 2) Just interesting, do you really need to set memory to 0 by memset?
>>
>> Thanks,
>> Dmitry
>>
>>
>> On 10.03.2016 13:43, Cheleswer Sahu wrote:
>>
>>>
>>> Hi,
>>>
>>> Please review the code changes for
>>> https://bugs.openjdk.java.net/browse/JDK-8151509.
>>>
>>> Webrev link: http://cr.openjdk.java.net/~csahu/8151509/ <
>>> http://cr.openjdk.java.net/%7Ecsahu/8151509/>
>>>
>>> Bug Brief:
>>>
>>> In check_addr0(),  pointer ?p? is not updated correctly, because of this
>>> it was reading only first two entries from buffer.
>>>
>>> Regards,
>>>
>>> Cheleswer
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20160310/1a195f9c/attachment-0001.html>

From yasuenag at gmail.com  Fri Mar 11 03:59:49 2016
From: yasuenag at gmail.com (Yasumasa Suenaga)
Date: Fri, 11 Mar 2016 12:59:49 +0900
Subject: RFR: JDK-8151674: STW phases at Concurrent GC should count in
	PerfCounter
Message-ID: <56E242B5.1070206@gmail.com>

Hi all,

This review request continues from:
  http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2016-March/016774.html
  http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2016-March/016896.html

I wonder that STW phases (Remark and Cleanup) at G1 are not counted in jstat FGC column. 
For example, Initial Mark and Remark at CMS are counted as FGC. 
We discussed on hotspot-gc-dev for this issue, and I proposed to add new PerfCounter
for CGC STW phases. 

I uploaded webrev. Could you review it?
    hotspot: http://cr.openjdk.java.net/~ysuenaga/JDK-8151674/webrev.00/hotspot/
        jdk: http://cr.openjdk.java.net/~ysuenaga/JDK-8151674/webrev.00/jdk/

For compatibility, this patch works the same as the current by default.
If you set -XX:+EnableConcGCPerfCounter, CGC counter will work fine.
(I want to set +EnableConcGCPerfCounter by default)


I cannot access JPRT.
So I need a sponsor.


Thanks,

Yasumasa

From cheleswer.sahu at oracle.com  Fri Mar 11 09:31:55 2016
From: cheleswer.sahu at oracle.com (Cheleswer Sahu)
Date: Fri, 11 Mar 2016 01:31:55 -0800 (PST)
Subject: RFR[9u-dev]: 8151509: In check_addr0() function pointer is not
	updated correctly
In-Reply-To: <CAA-vtUxJA7FzDaXAvebPdfcCGqCtwrCjt-Hqz_4_snhvGqWB6w@mail.gmail.com>
References: <c136e4ba-60f8-493b-8179-1b8178083a8c@default>
	<56E16C85.30102@oracle.com>
	<CAA-vtUyfV1BiJBXNiO5Qk_=z_ZKGOVx7bvBDOpGuxPXxZ7zhXA@mail.gmail.com>
	<CAA-vtUxJA7FzDaXAvebPdfcCGqCtwrCjt-Hqz_4_snhvGqWB6w@mail.gmail.com>
Message-ID: <6472a6fc-3197-4f42-927a-2b0ab0663a60@default>

Hi Thomas, Dmitry,

?

Thanks for your review comments. ?My answers are below for your review comments 

?

1873 ? ? ? if( 0 != ret % sizeof(prmap_t)){
1874 ? ? ? ? break;
1875 ? ? ? }



>> For this it has been thought that mostly read() will return the desired number of bytes, but only in case if something goes wrong and read() will? not able to read the data, it will return lesser number of bytes, which contains the partial data of ??prmap_t? structure. The reason could be like file is corrupted, in such cases we don?t want to read anymore and feel it?s safe to skip the rest of file. 

?

2) Just interesting, do you really need to set memory to 0 by memset?

>> ?I thought this it is good to have a clean buffer every time we read something into it, but it?s really not that much required as we are reading a binary data. So I am removing this line from the code.

?

For rest of the comments I have made correction in the code. The new webrev is available in the below location

http://cr.openjdk.java.net/~csahu/8151509/webrev.01/

?

?

Regards,

Cheleswer

?

From: Thomas St?fe [mailto:thomas.stuefe at gmail.com] 
Sent: Thursday, March 10, 2016 7:39 PM
To: Dmitry Dmitriev
Cc: Cheleswer Sahu; serviceability-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net
Subject: Re: RFR[9u-dev]: 8151509: In check_addr0() function pointer is not updated correctly

?

(Sorry, pressed Send button too early)

Just wanted to add that 

1873 ? ? ? if( 0 != ret % sizeof(prmap_t)){
1874 ? ? ? ? break;
1875 ? ? ? }

may be a bit harsh, as it skips the entire mapping in case read() stopped reading in a middle of a record. You could just continue to read until you read the rest of the record.

Kind Regards, Thomas

?

On Thu, Mar 10, 2016 at 3:07 PM, Thomas St?fe <HYPERLINK "mailto:thomas.stuefe at gmail.com"thomas.stuefe at gmail.com> wrote:

Hi?Cheleswer,

?

thanks for fixing this.

?

Some more issues:

?

-?1866 char *mbuff = (char *) calloc(read_chunk, sizeof(prmap_t) + 1);

?

Why the "+1"? It is unnecessary and causes the allocation to be 200 bytes larger than necessary.

?

-?1880 st->print("Warning: Address: " PTR_FORMAT ", Size: %dK, ",p->pr_vaddr, p->pr_size/1024);

?

Format specifier for Size is wrong.%d is int, but?p->pr_size is size_t. Theoretical truncation for mappings larger than 4g*1024.

(But I know this coding was there before)

?

Beside those points, I think both points of Dmitry are valid.

?

Also, I find?

?

?

Kind Regards, Thomas

?

On Thu, Mar 10, 2016 at 1:45 PM, Dmitry Dmitriev <HYPERLINK "mailto:dmitry.dmitriev at oracle.com"dmitry.dmitriev at oracle.com> wrote:

Hi Cheleswer,

Looks good, but I have questions/comments about other code in this function:
1) I think that "::close(fd);" should be inside "if (fd >= 0) {".
2) Just interesting, do you really need to set memory to 0 by memset?

Thanks,
Dmitry


On 10.03.2016 13:43, Cheleswer Sahu wrote:


Hi,

Please review the code changes for https://bugs.openjdk.java.net/browse/JDK-8151509.

Webrev link: http://cr.openjdk.java.net/~csahu/8151509/ <http://cr.openjdk.java.net/%7Ecsahu/8151509/>

Bug Brief:

In check_addr0(),? pointer ?p? is not updated correctly, because of this it was reading only first two entries from buffer.

Regards,

Cheleswer

?

?

?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20160311/181550cf/attachment.html>

From dmitry.dmitriev at oracle.com  Fri Mar 11 11:29:44 2016
From: dmitry.dmitriev at oracle.com (Dmitry Dmitriev)
Date: Fri, 11 Mar 2016 14:29:44 +0300
Subject: RFR[9u-dev]: 8151509: In check_addr0() function pointer is not
	updated correctly
In-Reply-To: <6472a6fc-3197-4f42-927a-2b0ab0663a60@default>
References: <c136e4ba-60f8-493b-8179-1b8178083a8c@default>
	<56E16C85.30102@oracle.com>
	<CAA-vtUyfV1BiJBXNiO5Qk_=z_ZKGOVx7bvBDOpGuxPXxZ7zhXA@mail.gmail.com>
	<CAA-vtUxJA7FzDaXAvebPdfcCGqCtwrCjt-Hqz_4_snhvGqWB6w@mail.gmail.com>
	<6472a6fc-3197-4f42-927a-2b0ab0663a60@default>
Message-ID: <56E2AC28.4040306@oracle.com>

Hi Cheleswer,

Please, add space between SIZE_FORMAT and " because C++11 requires a 
space between literal and identifier. Not need a new webrev for that.

Thanks,
Dmitry

On 11.03.2016 12:31, Cheleswer Sahu wrote:
>
> Hi Thomas, Dmitry,
>
> Thanks for your review comments.  My answers are below for your review 
> comments
>
> 1873       if( 0 != ret % sizeof(prmap_t)){
> 1874         break;
> 1875       }
>
> >> For this it has been thought that mostly read() will return the 
> desired number of bytes, but only in case if something goes wrong and 
> read() will  not able to read the data, it will return lesser number 
> of bytes, which contains the partial data of  ?prmap_t? structure. The 
> reason could be like file is corrupted, in such cases we don?t want to 
> read anymore and feel it?s safe to skip the rest of file.
>
> 2) Just interesting, do you really need to set memory to 0 by memset?
>
> >>  I thought this it is good to have a clean buffer every time we 
> read something into it, but it?s really not that much required as we 
> are reading a binary data. So I am removing this line from the code.
>
> For rest of the comments I have made correction in the code. The new 
> webrev is available in the below location
>
> http://cr.openjdk.java.net/~csahu/8151509/webrev.01/ 
> <http://cr.openjdk.java.net/%7Ecsahu/8151509/webrev.01/>
>
> Regards,
>
> Cheleswer
>
> *From:*Thomas St?fe [mailto:thomas.stuefe at gmail.com]
> *Sent:* Thursday, March 10, 2016 7:39 PM
> *To:* Dmitry Dmitriev
> *Cc:* Cheleswer Sahu; serviceability-dev at openjdk.java.net; 
> hotspot-runtime-dev at openjdk.java.net
> *Subject:* Re: RFR[9u-dev]: 8151509: In check_addr0() function pointer 
> is not updated correctly
>
> (Sorry, pressed Send button too early)
>
> Just wanted to add that
>
> 1873       if( 0 != ret % sizeof(prmap_t)){
> 1874         break;
> 1875       }
>
> may be a bit harsh, as it skips the entire mapping in case read() 
> stopped reading in a middle of a record. You could just continue to 
> read until you read the rest of the record.
>
> Kind Regards, Thomas
>
> On Thu, Mar 10, 2016 at 3:07 PM, Thomas St?fe <thomas.stuefe at gmail.com 
> <mailto:thomas.stuefe at gmail.com>> wrote:
>
>     Hi Cheleswer,
>
>     thanks for fixing this.
>
>     Some more issues:
>
>     - 1866 char *mbuff = (char *) calloc(read_chunk, sizeof(prmap_t) + 1);
>
>     Why the "+1"? It is unnecessary and causes the allocation to be
>     200 bytes larger than necessary.
>
>     - 1880 st->print("Warning: Address: " PTR_FORMAT ", Size: %dK,
>     ",p->pr_vaddr, p->pr_size/1024);
>
>     Format specifier for Size is wrong.%d is int, but p->pr_size is
>     size_t. Theoretical truncation for mappings larger than 4g*1024.
>
>     (But I know this coding was there before)
>
>     Beside those points, I think both points of Dmitry are valid.
>
>     Also, I find
>
>     Kind Regards, Thomas
>
>     On Thu, Mar 10, 2016 at 1:45 PM, Dmitry Dmitriev
>     <dmitry.dmitriev at oracle.com <mailto:dmitry.dmitriev at oracle.com>>
>     wrote:
>
>         Hi Cheleswer,
>
>         Looks good, but I have questions/comments about other code in
>         this function:
>         1) I think that "::close(fd);" should be inside "if (fd >= 0) {".
>         2) Just interesting, do you really need to set memory to 0 by
>         memset?
>
>         Thanks,
>         Dmitry
>
>
>         On 10.03.2016 13:43, Cheleswer Sahu wrote:
>
>
>             Hi,
>
>             Please review the code changes for
>             https://bugs.openjdk.java.net/browse/JDK-8151509.
>
>             Webrev link: http://cr.openjdk.java.net/~csahu/8151509/
>             <http://cr.openjdk.java.net/%7Ecsahu/8151509/>
>             <http://cr.openjdk.java.net/%7Ecsahu/8151509/>
>
>             Bug Brief:
>
>             In check_addr0(),  pointer ?p? is not updated correctly,
>             because of this it was reading only first two entries from
>             buffer.
>
>             Regards,
>
>             Cheleswer
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20160311/355afd1f/attachment-0001.html>

From thomas.stuefe at gmail.com  Fri Mar 11 11:32:42 2016
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Fri, 11 Mar 2016 12:32:42 +0100
Subject: RFR[9u-dev]: 8151509: In check_addr0() function pointer is not
	updated correctly
In-Reply-To: <6472a6fc-3197-4f42-927a-2b0ab0663a60@default>
References: <c136e4ba-60f8-493b-8179-1b8178083a8c@default>
	<56E16C85.30102@oracle.com>
	<CAA-vtUyfV1BiJBXNiO5Qk_=z_ZKGOVx7bvBDOpGuxPXxZ7zhXA@mail.gmail.com>
	<CAA-vtUxJA7FzDaXAvebPdfcCGqCtwrCjt-Hqz_4_snhvGqWB6w@mail.gmail.com>
	<6472a6fc-3197-4f42-927a-2b0ab0663a60@default>
Message-ID: <CAA-vtUzgkwpFYYeg8z+Pcvd1me6Q30vPcj0AUijPkUS4emNu6Q@mail.gmail.com>

Hi Cheleswer,

this version looks fine too me. Thank you for doing this.

Kind Regards, Thomas

On Fri, Mar 11, 2016 at 10:31 AM, Cheleswer Sahu <cheleswer.sahu at oracle.com>
wrote:

> Hi Thomas, Dmitry,
>
>
>
> Thanks for your review comments.  My answers are below for your review
> comments
>
>
>
> 1873       if( 0 != ret % sizeof(prmap_t)){
> 1874         break;
> 1875       }
>
> >> For this it has been thought that mostly read() will return the desired
> number of bytes, but only in case if something goes wrong and read() will
> not able to read the data, it will return lesser number of bytes, which
> contains the partial data of  ?prmap_t? structure. The reason could be like
> file is corrupted, in such cases we don?t want to read anymore and feel
> it?s safe to skip the rest of file.
>
>
>
> 2) Just interesting, do you really need to set memory to 0 by memset?
>
> >>  I thought this it is good to have a clean buffer every time we read
> something into it, but it?s really not that much required as we are reading
> a binary data. So I am removing this line from the code.
>
>
>
> For rest of the comments I have made correction in the code. The new
> webrev is available in the below location
>
> http://cr.openjdk.java.net/~csahu/8151509/webrev.01/
>
>
>
>
>
> Regards,
>
> Cheleswer
>
>
>
> *From:* Thomas St?fe [mailto:thomas.stuefe at gmail.com]
> *Sent:* Thursday, March 10, 2016 7:39 PM
> *To:* Dmitry Dmitriev
> *Cc:* Cheleswer Sahu; serviceability-dev at openjdk.java.net;
> hotspot-runtime-dev at openjdk.java.net
> *Subject:* Re: RFR[9u-dev]: 8151509: In check_addr0() function pointer is
> not updated correctly
>
>
>
> (Sorry, pressed Send button too early)
>
> Just wanted to add that
>
> 1873       if( 0 != ret % sizeof(prmap_t)){
> 1874         break;
> 1875       }
>
> may be a bit harsh, as it skips the entire mapping in case read() stopped
> reading in a middle of a record. You could just continue to read until you
> read the rest of the record.
>
> Kind Regards, Thomas
>
>
>
> On Thu, Mar 10, 2016 at 3:07 PM, Thomas St?fe <thomas.stuefe at gmail.com>
> wrote:
>
> Hi Cheleswer,
>
>
>
> thanks for fixing this.
>
>
>
> Some more issues:
>
>
>
> - 1866 char *mbuff = (char *) calloc(read_chunk, sizeof(prmap_t) + 1);
>
>
>
> Why the "+1"? It is unnecessary and causes the allocation to be 200 bytes
> larger than necessary.
>
>
>
> - 1880 st->print("Warning: Address: " PTR_FORMAT ", Size: %dK,
> ",p->pr_vaddr, p->pr_size/1024);
>
>
>
> Format specifier for Size is wrong.%d is int, but p->pr_size is size_t.
> Theoretical truncation for mappings larger than 4g*1024.
>
> (But I know this coding was there before)
>
>
>
> Beside those points, I think both points of Dmitry are valid.
>
>
>
> Also, I find
>
>
>
>
>
> Kind Regards, Thomas
>
>
>
> On Thu, Mar 10, 2016 at 1:45 PM, Dmitry Dmitriev <
> dmitry.dmitriev at oracle.com> wrote:
>
> Hi Cheleswer,
>
> Looks good, but I have questions/comments about other code in this
> function:
> 1) I think that "::close(fd);" should be inside "if (fd >= 0) {".
> 2) Just interesting, do you really need to set memory to 0 by memset?
>
> Thanks,
> Dmitry
>
>
> On 10.03.2016 13:43, Cheleswer Sahu wrote:
>
>
> Hi,
>
> Please review the code changes for
> https://bugs.openjdk.java.net/browse/JDK-8151509.
>
> Webrev link: http://cr.openjdk.java.net/~csahu/8151509/ <
> http://cr.openjdk.java.net/%7Ecsahu/8151509/>
>
> Bug Brief:
>
> In check_addr0(),  pointer ?p? is not updated correctly, because of this
> it was reading only first two entries from buffer.
>
> Regards,
>
> Cheleswer
>
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20160311/673bf24c/attachment.html>

From cheleswer.sahu at oracle.com  Fri Mar 11 11:38:15 2016
From: cheleswer.sahu at oracle.com (Cheleswer Sahu)
Date: Fri, 11 Mar 2016 03:38:15 -0800 (PST)
Subject: RFR[9u-dev]: 8151509: In check_addr0() function pointer is not
	updated correctly
In-Reply-To: <56E2AC28.4040306@oracle.com>
References: <c136e4ba-60f8-493b-8179-1b8178083a8c@default>
	<56E16C85.30102@oracle.com>
	<CAA-vtUyfV1BiJBXNiO5Qk_=z_ZKGOVx7bvBDOpGuxPXxZ7zhXA@mail.gmail.com>
	<CAA-vtUxJA7FzDaXAvebPdfcCGqCtwrCjt-Hqz_4_snhvGqWB6w@mail.gmail.com>
	<6472a6fc-3197-4f42-927a-2b0ab0663a60@default>
	<56E2AC28.4040306@oracle.com>
Message-ID: <bb6749b1-6e3e-45e2-b96d-111d9a82b799@default>

Thanks Dmitry and Thomas for reviews. After adding space I will ?request for the push.

?

Regards,

Cheleswer

?

From: Dmitry Dmitriev 
Sent: Friday, March 11, 2016 5:00 PM
To: Cheleswer Sahu; Thomas St?fe
Cc: serviceability-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net
Subject: Re: RFR[9u-dev]: 8151509: In check_addr0() function pointer is not updated correctly

?

Hi Cheleswer,

Please, add space between SIZE_FORMAT and " because C++11 requires a space between literal and identifier. Not need a new webrev for that.

Thanks,
Dmitry



On 11.03.2016 12:31, Cheleswer Sahu wrote:

Hi Thomas, Dmitry,

?

Thanks for your review comments. ?My answers are below for your review comments 

?

1873 ? ? ? if( 0 != ret % sizeof(prmap_t)){
1874 ? ? ? ? break;
1875 ? ? ? }




>> For this it has been thought that mostly read() will return the desired number of bytes, but only in case if something goes wrong and read() will? not able to read the data, it will return lesser number of bytes, which contains the partial data of ??prmap_t? structure. The reason could be like file is corrupted, in such cases we don?t want to read anymore and feel it?s safe to skip the rest of file. 

?

2) Just interesting, do you really need to set memory to 0 by memset?

>> ?I thought this it is good to have a clean buffer every time we read something into it, but it?s really not that much required as we are reading a binary data. So I am removing this line from the code.

?

For rest of the comments I have made correction in the code. The new webrev is available in the below location

HYPERLINK "http://cr.openjdk.java.net/%7Ecsahu/8151509/webrev.01/"http://cr.openjdk.java.net/~csahu/8151509/webrev.01/

?

?

Regards,

Cheleswer

?

From: Thomas St?fe [mailto:thomas.stuefe at gmail.com] 
Sent: Thursday, March 10, 2016 7:39 PM
To: Dmitry Dmitriev
Cc: Cheleswer Sahu; HYPERLINK "mailto:serviceability-dev at openjdk.java.net"serviceability-dev at openjdk.java.net; HYPERLINK "mailto:hotspot-runtime-dev at openjdk.java.net"hotspot-runtime-dev at openjdk.java.net
Subject: Re: RFR[9u-dev]: 8151509: In check_addr0() function pointer is not updated correctly

?

(Sorry, pressed Send button too early)

Just wanted to add that 

1873 ? ? ? if( 0 != ret % sizeof(prmap_t)){
1874 ? ? ? ? break;
1875 ? ? ? }

may be a bit harsh, as it skips the entire mapping in case read() stopped reading in a middle of a record. You could just continue to read until you read the rest of the record.

Kind Regards, Thomas

?

On Thu, Mar 10, 2016 at 3:07 PM, Thomas St?fe <HYPERLINK "mailto:thomas.stuefe at gmail.com"thomas.stuefe at gmail.com> wrote:

Hi?Cheleswer,

?

thanks for fixing this.

?

Some more issues:

?

-?1866 char *mbuff = (char *) calloc(read_chunk, sizeof(prmap_t) + 1);

?

Why the "+1"? It is unnecessary and causes the allocation to be 200 bytes larger than necessary.

?

-?1880 st->print("Warning: Address: " PTR_FORMAT ", Size: %dK, ",p->pr_vaddr, p->pr_size/1024);

?

Format specifier for Size is wrong.%d is int, but?p->pr_size is size_t. Theoretical truncation for mappings larger than 4g*1024.

(But I know this coding was there before)

?

Beside those points, I think both points of Dmitry are valid.

?

Also, I find?

?

?

Kind Regards, Thomas

?

On Thu, Mar 10, 2016 at 1:45 PM, Dmitry Dmitriev <HYPERLINK "mailto:dmitry.dmitriev at oracle.com"dmitry.dmitriev at oracle.com> wrote:

Hi Cheleswer,

Looks good, but I have questions/comments about other code in this function:
1) I think that "::close(fd);" should be inside "if (fd >= 0) {".
2) Just interesting, do you really need to set memory to 0 by memset?

Thanks,
Dmitry


On 10.03.2016 13:43, Cheleswer Sahu wrote:


Hi,

Please review the code changes for https://bugs.openjdk.java.net/browse/JDK-8151509.

Webrev link: HYPERLINK "http://cr.openjdk.java.net/%7Ecsahu/8151509/"http://cr.openjdk.java.net/~csahu/8151509/ <http://cr.openjdk.java.net/%7Ecsahu/8151509/>

Bug Brief:

In check_addr0(),? pointer ?p? is not updated correctly, because of this it was reading only first two entries from buffer.

Regards,

Cheleswer

?

?

?

?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20160311/4821462a/attachment-0001.html>

From dmitry.dmitriev at oracle.com  Fri Mar 11 11:40:31 2016
From: dmitry.dmitriev at oracle.com (Dmitry Dmitriev)
Date: Fri, 11 Mar 2016 14:40:31 +0300
Subject: RFR[9u-dev]: 8151509: In check_addr0() function pointer is not
	updated correctly
In-Reply-To: <bb6749b1-6e3e-45e2-b96d-111d9a82b799@default>
References: <c136e4ba-60f8-493b-8179-1b8178083a8c@default>
	<56E16C85.30102@oracle.com>
	<CAA-vtUyfV1BiJBXNiO5Qk_=z_ZKGOVx7bvBDOpGuxPXxZ7zhXA@mail.gmail.com>
	<CAA-vtUxJA7FzDaXAvebPdfcCGqCtwrCjt-Hqz_4_snhvGqWB6w@mail.gmail.com>
	<6472a6fc-3197-4f42-927a-2b0ab0663a60@default>
	<56E2AC28.4040306@oracle.com>
	<bb6749b1-6e3e-45e2-b96d-111d9a82b799@default>
Message-ID: <56E2AEAF.3030101@oracle.com>

Cheleswer, thank you! But I think you need a "R"eviewer for that change 
before push.

Dmitry

On 11.03.2016 14:38, Cheleswer Sahu wrote:
>
> Thanks Dmitry and Thomas for reviews. After adding space I will 
>  request for the push.
>
> Regards,
>
> Cheleswer
>
> *From:*Dmitry Dmitriev
> *Sent:* Friday, March 11, 2016 5:00 PM
> *To:* Cheleswer Sahu; Thomas St?fe
> *Cc:* serviceability-dev at openjdk.java.net; 
> hotspot-runtime-dev at openjdk.java.net
> *Subject:* Re: RFR[9u-dev]: 8151509: In check_addr0() function pointer 
> is not updated correctly
>
> Hi Cheleswer,
>
> Please, add space between SIZE_FORMAT and " because C++11 requires a 
> space between literal and identifier. Not need a new webrev for that.
>
> Thanks,
> Dmitry
>
> On 11.03.2016 12:31, Cheleswer Sahu wrote:
>
>     Hi Thomas, Dmitry,
>
>     Thanks for your review comments.  My answers are below for your
>     review comments
>
>     1873       if( 0 != ret % sizeof(prmap_t)){
>     1874         break;
>     1875       }
>
>
>     >> For this it has been thought that mostly read() will return the
>     desired number of bytes, but only in case if something goes wrong
>     and read() will  not able to read the data, it will return lesser
>     number of bytes, which contains the partial data of  ?prmap_t?
>     structure. The reason could be like file is corrupted, in such
>     cases we don?t want to read anymore and feel it?s safe to skip the
>     rest of file.
>
>     2) Just interesting, do you really need to set memory to 0 by memset?
>
>     >>  I thought this it is good to have a clean buffer every time we
>     read something into it, but it?s really not that much required as
>     we are reading a binary data. So I am removing this line from the
>     code.
>
>     For rest of the comments I have made correction in the code. The
>     new webrev is available in the below location
>
>     http://cr.openjdk.java.net/~csahu/8151509/webrev.01/
>     <http://cr.openjdk.java.net/%7Ecsahu/8151509/webrev.01/>
>
>     Regards,
>
>     Cheleswer
>
>     *From:*Thomas St?fe [mailto:thomas.stuefe at gmail.com]
>     *Sent:* Thursday, March 10, 2016 7:39 PM
>     *To:* Dmitry Dmitriev
>     *Cc:* Cheleswer Sahu; serviceability-dev at openjdk.java.net
>     <mailto:serviceability-dev at openjdk.java.net>;
>     hotspot-runtime-dev at openjdk.java.net
>     <mailto:hotspot-runtime-dev at openjdk.java.net>
>     *Subject:* Re: RFR[9u-dev]: 8151509: In check_addr0() function
>     pointer is not updated correctly
>
>     (Sorry, pressed Send button too early)
>
>     Just wanted to add that
>
>     1873       if( 0 != ret % sizeof(prmap_t)){
>     1874         break;
>     1875       }
>
>     may be a bit harsh, as it skips the entire mapping in case read()
>     stopped reading in a middle of a record. You could just continue
>     to read until you read the rest of the record.
>
>     Kind Regards, Thomas
>
>     On Thu, Mar 10, 2016 at 3:07 PM, Thomas St?fe
>     <thomas.stuefe at gmail.com <mailto:thomas.stuefe at gmail.com>> wrote:
>
>         Hi Cheleswer,
>
>         thanks for fixing this.
>
>         Some more issues:
>
>         - 1866 char *mbuff = (char *) calloc(read_chunk,
>         sizeof(prmap_t) + 1);
>
>         Why the "+1"? It is unnecessary and causes the allocation to
>         be 200 bytes larger than necessary.
>
>         - 1880 st->print("Warning: Address: " PTR_FORMAT ", Size: %dK,
>         ",p->pr_vaddr, p->pr_size/1024);
>
>         Format specifier for Size is wrong.%d is int, but p->pr_size
>         is size_t. Theoretical truncation for mappings larger than
>         4g*1024.
>
>         (But I know this coding was there before)
>
>         Beside those points, I think both points of Dmitry are valid.
>
>         Also, I find
>
>         Kind Regards, Thomas
>
>         On Thu, Mar 10, 2016 at 1:45 PM, Dmitry Dmitriev
>         <dmitry.dmitriev at oracle.com
>         <mailto:dmitry.dmitriev at oracle.com>> wrote:
>
>             Hi Cheleswer,
>
>             Looks good, but I have questions/comments about other code
>             in this function:
>             1) I think that "::close(fd);" should be inside "if (fd >=
>             0) {".
>             2) Just interesting, do you really need to set memory to 0
>             by memset?
>
>             Thanks,
>             Dmitry
>
>
>             On 10.03.2016 13:43, Cheleswer Sahu wrote:
>
>
>                 Hi,
>
>                 Please review the code changes for
>                 https://bugs.openjdk.java.net/browse/JDK-8151509.
>
>                 Webrev link:
>                 http://cr.openjdk.java.net/~csahu/8151509/
>                 <http://cr.openjdk.java.net/%7Ecsahu/8151509/>
>                 <http://cr.openjdk.java.net/%7Ecsahu/8151509/>
>
>                 Bug Brief:
>
>                 In check_addr0(),  pointer ?p? is not updated
>                 correctly, because of this it was reading only first
>                 two entries from buffer.
>
>                 Regards,
>
>                 Cheleswer
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20160311/2929b571/attachment.html>

From yasuenag at gmail.com  Fri Mar 11 13:26:40 2016
From: yasuenag at gmail.com (Yasumasa Suenaga)
Date: Fri, 11 Mar 2016 22:26:40 +0900
Subject: RFR: JDK-8151709: jhsdb should show help message in SALauncher.
Message-ID: <56E2C790.4020802@gmail.com>

Hi all,

jhsdb shows error message in each tool implemantation as below:
--------------
$ jhsdb jstack -aaa
Usage: jstack [option] <pid>
                (to connect to a live java process)
   or jstack [option] <executable> <core>
                (to connect to a core file)
   or jstack [option] [server_id@]<remote server IP or hostname>
                (to connect to a remote debug server)

where option must be one of:
    -l  to print java.util.concurrent locks
    -m  to print both java and native frames (mixed mode)
    -h | -help  to print this help message
--------------

If we run SA tool via jhsdb, we should get help message of SALauncher as below:
--------------
$ jhsdb jstack -aaa
    --locks     to print java.util.concurrent locks
    --mixed     to print both java and native frames (mixed mode)
    --exe       executable image name
    --core      path to coredump
    --pid       pid of process to attach
--------------

I uploaded webrev. Could you review it?
    http://cr.openjdk.java.net/~ysuenaga/JDK-8151709/webrev.00/

I cannot access JPRT.
So I need a Sponsor.


Thanks,

Yasumasa


From thomas.stuefe at gmail.com  Fri Mar 11 13:31:37 2016
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Fri, 11 Mar 2016 14:31:37 +0100
Subject: RFR[9u-dev]: 8151509: In check_addr0() function pointer is not
	updated correctly
In-Reply-To: <56E2AEAF.3030101@oracle.com>
References: <c136e4ba-60f8-493b-8179-1b8178083a8c@default>
	<56E16C85.30102@oracle.com>
	<CAA-vtUyfV1BiJBXNiO5Qk_=z_ZKGOVx7bvBDOpGuxPXxZ7zhXA@mail.gmail.com>
	<CAA-vtUxJA7FzDaXAvebPdfcCGqCtwrCjt-Hqz_4_snhvGqWB6w@mail.gmail.com>
	<6472a6fc-3197-4f42-927a-2b0ab0663a60@default>
	<56E2AC28.4040306@oracle.com>
	<bb6749b1-6e3e-45e2-b96d-111d9a82b799@default>
	<56E2AEAF.3030101@oracle.com>
Message-ID: <CAA-vtUxN2F2aiYSya_uOusJKbfQhnKg8Ez+GSNYRX_83PvX2xw@mail.gmail.com>

Dmitry is right, at least I am only a committer, not a "R"eviewer.

On Fri, Mar 11, 2016 at 12:40 PM, Dmitry Dmitriev <
dmitry.dmitriev at oracle.com> wrote:

> Cheleswer, thank you! But I think you need a "R"eviewer for that change
> before push.
>
> Dmitry
>
>
> On 11.03.2016 14:38, Cheleswer Sahu wrote:
>
> Thanks Dmitry and Thomas for reviews. After adding space I will  request
> for the push.
>
>
>
> Regards,
>
> Cheleswer
>
>
>
> *From:* Dmitry Dmitriev
> *Sent:* Friday, March 11, 2016 5:00 PM
> *To:* Cheleswer Sahu; Thomas St?fe
> *Cc:* serviceability-dev at openjdk.java.net;
> hotspot-runtime-dev at openjdk.java.net
> *Subject:* Re: RFR[9u-dev]: 8151509: In check_addr0() function pointer is
> not updated correctly
>
>
>
> Hi Cheleswer,
>
> Please, add space between SIZE_FORMAT and " because C++11 requires a space
> between literal and identifier. Not need a new webrev for that.
>
> Thanks,
> Dmitry
>
> On 11.03.2016 12:31, Cheleswer Sahu wrote:
>
> Hi Thomas, Dmitry,
>
>
>
> Thanks for your review comments.  My answers are below for your review
> comments
>
>
>
> 1873       if( 0 != ret % sizeof(prmap_t)){
> 1874         break;
> 1875       }
>
>
> >> For this it has been thought that mostly read() will return the desired
> number of bytes, but only in case if something goes wrong and read() will
> not able to read the data, it will return lesser number of bytes, which
> contains the partial data of  ?prmap_t? structure. The reason could be like
> file is corrupted, in such cases we don?t want to read anymore and feel
> it?s safe to skip the rest of file.
>
>
>
> 2) Just interesting, do you really need to set memory to 0 by memset?
>
> >>  I thought this it is good to have a clean buffer every time we read
> something into it, but it?s really not that much required as we are reading
> a binary data. So I am removing this line from the code.
>
>
>
> For rest of the comments I have made correction in the code. The new
> webrev is available in the below location
>
> http://cr.openjdk.java.net/~csahu/8151509/webrev.01/
>
>
>
>
>
> Regards,
>
> Cheleswer
>
>
>
> *From:* Thomas St?fe [mailto:thomas.stuefe at gmail.com
> <thomas.stuefe at gmail.com>]
> *Sent:* Thursday, March 10, 2016 7:39 PM
> *To:* Dmitry Dmitriev
> *Cc:* Cheleswer Sahu; serviceability-dev at openjdk.java.net;
> hotspot-runtime-dev at openjdk.java.net
> *Subject:* Re: RFR[9u-dev]: 8151509: In check_addr0() function pointer is
> not updated correctly
>
>
>
> (Sorry, pressed Send button too early)
>
> Just wanted to add that
>
> 1873       if( 0 != ret % sizeof(prmap_t)){
> 1874         break;
> 1875       }
>
> may be a bit harsh, as it skips the entire mapping in case read() stopped
> reading in a middle of a record. You could just continue to read until you
> read the rest of the record.
>
> Kind Regards, Thomas
>
>
>
> On Thu, Mar 10, 2016 at 3:07 PM, Thomas St?fe <thomas.stuefe at gmail.com>
> wrote:
>
> Hi Cheleswer,
>
>
>
> thanks for fixing this.
>
>
>
> Some more issues:
>
>
>
> - 1866 char *mbuff = (char *) calloc(read_chunk, sizeof(prmap_t) + 1);
>
>
>
> Why the "+1"? It is unnecessary and causes the allocation to be 200 bytes
> larger than necessary.
>
>
>
> - 1880 st->print("Warning: Address: " PTR_FORMAT ", Size: %dK,
> ",p->pr_vaddr, p->pr_size/1024);
>
>
>
> Format specifier for Size is wrong.%d is int, but p->pr_size is size_t.
> Theoretical truncation for mappings larger than 4g*1024.
>
> (But I know this coding was there before)
>
>
>
> Beside those points, I think both points of Dmitry are valid.
>
>
>
> Also, I find
>
>
>
>
>
> Kind Regards, Thomas
>
>
>
> On Thu, Mar 10, 2016 at 1:45 PM, Dmitry Dmitriev <
> <dmitry.dmitriev at oracle.com>dmitry.dmitriev at oracle.com> wrote:
>
> Hi Cheleswer,
>
> Looks good, but I have questions/comments about other code in this
> function:
> 1) I think that "::close(fd);" should be inside "if (fd >= 0) {".
> 2) Just interesting, do you really need to set memory to 0 by memset?
>
> Thanks,
> Dmitry
>
>
> On 10.03.2016 13:43, Cheleswer Sahu wrote:
>
>
> Hi,
>
> Please review the code changes for
> <https://bugs.openjdk.java.net/browse/JDK-8151509>
> https://bugs.openjdk.java.net/browse/JDK-8151509.
>
> Webrev link: http://cr.openjdk.java.net/~csahu/8151509/ <
> http://cr.openjdk.java.net/%7Ecsahu/8151509/>
>
> Bug Brief:
>
> In check_addr0(),  pointer ?p? is not updated correctly, because of this
> it was reading only first two entries from buffer.
>
> Regards,
>
> Cheleswer
>
>
>
>
>
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20160311/8de5468e/attachment.html>

From marcus.larsson at oracle.com  Fri Mar 11 14:21:44 2016
From: marcus.larsson at oracle.com (Marcus Larsson)
Date: Fri, 11 Mar 2016 15:21:44 +0100
Subject: RFR: 8146879: Add option for handling existing log files in UL
In-Reply-To: <56D5A1BB.6030403@oracle.com>
References: <5697B7F2.50104@oracle.com> <56D578F9.6090602@oracle.com>
	<56D5A1BB.6030403@oracle.com>
Message-ID: <56E2D478.3090202@oracle.com>

Third time's the charm.

Webrev:
http://cr.openjdk.java.net/~mlarsson/8146879/webrev.03/

This patch makes log file rotation the default. Default thresholds are 5 
rotated files with a target size of 20MiB. Truncating behavior can be 
achieved by setting filecount to 0 (-Xlog::myfile.log::filecount=0).

If a log file already exists during log file initialization it will be 
rotated. If any of the target file names (file.0 to file.4 in the 
default case) are available, that filename will be used for the existing 
log. If all names are taken the VM will attempt to overwrite the oldest 
file.

This should prevent unlimited log file creations and avoid accidental 
loss of log files from previous runs. The default thresholds (5 files, 
20MiB each) is just a suggestion. If you think it should be higher/lower 
let me know.

Tested with included internal VM tests through RBT.

Thanks,
Marcus

On 2016-03-01 15:05, Marcus Larsson wrote:
> Hi,
>
> After some offline discussions I'm withdrawing this patch. I will 
> instead investigate if I can achieve similar behavior using log 
> rotation as the default.
>
> Thanks,
> Marcus
>
> On 03/01/2016 12:11 PM, Marcus Larsson wrote:
>> Hi again,
>>
>> Taking a different approach to this.
>>
>> New webrev:
>> http://cr.openjdk.java.net/~mlarsson/8146879/webrev.01/
>>
>> Existing files will now by default be renamed/archived with a .X 
>> suffix where X is the lowest number such that the resulting file name 
>> is available (jvm.log becomes jvm.log.0). A mode option for 
>> controlling this behavior has been added as well. It can be set to 
>> archive, append, or truncate (i.e. -Xlog::jvm.log::mode=truncate).
>>
>> Tested with included jtreg test through JPRT.
>>
>> Thanks,
>> Marcus
>>
>> On 01/14/2016 04:00 PM, Marcus Larsson wrote:
>>> Hi,
>>>
>>> Please review the following patch to make sure UL truncates existing 
>>> log files before writing to them. Since files are opened in append 
>>> mode, truncation isn't done automatically, so instead the patch adds 
>>> an attempt to remove the log file before opening it.
>>>
>>> Webrev:
>>> http://cr.openjdk.java.net/~mlarsson/8146879/webrev.00/
>>>
>>> Issue:
>>> https://bugs.openjdk.java.net/browse/JDK-8146879
>>>
>>> Testing:
>>> Included test through JPRT
>>>
>>> Thanks,
>>> Marcus
>>
>


From bengt.rutisson at oracle.com  Fri Mar 11 14:35:22 2016
From: bengt.rutisson at oracle.com (Bengt Rutisson)
Date: Fri, 11 Mar 2016 15:35:22 +0100
Subject: RFR: 8146879: Add option for handling existing log files in UL
In-Reply-To: <56E2D478.3090202@oracle.com>
References: <5697B7F2.50104@oracle.com> <56D578F9.6090602@oracle.com>
	<56D5A1BB.6030403@oracle.com> <56E2D478.3090202@oracle.com>
Message-ID: <56E2D7AA.1060803@oracle.com>


Hi Marcus,

On 2016-03-11 15:21, Marcus Larsson wrote:
> Third time's the charm.
>
> Webrev:
> http://cr.openjdk.java.net/~mlarsson/8146879/webrev.03/

I had a quick look at the code changes. It is not really my area of the 
code, so I'll leave to someone else to formally review it.

However, I downloaded the patch a played a bit with the logging. This is 
much more like the way I would like it! Thanks!

So, from a functional perspective this looks good to me.

Thanks,
Bengt

>
> This patch makes log file rotation the default. Default thresholds are 
> 5 rotated files with a target size of 20MiB. Truncating behavior can 
> be achieved by setting filecount to 0 (-Xlog::myfile.log::filecount=0).
>
> If a log file already exists during log file initialization it will be 
> rotated. If any of the target file names (file.0 to file.4 in the 
> default case) are available, that filename will be used for the 
> existing log. If all names are taken the VM will attempt to overwrite 
> the oldest file.
>
> This should prevent unlimited log file creations and avoid accidental 
> loss of log files from previous runs. The default thresholds (5 files, 
> 20MiB each) is just a suggestion. If you think it should be 
> higher/lower let me know.
>
> Tested with included internal VM tests through RBT.
>
> Thanks,
> Marcus
>
> On 2016-03-01 15:05, Marcus Larsson wrote:
>> Hi,
>>
>> After some offline discussions I'm withdrawing this patch. I will 
>> instead investigate if I can achieve similar behavior using log 
>> rotation as the default.
>>
>> Thanks,
>> Marcus
>>
>> On 03/01/2016 12:11 PM, Marcus Larsson wrote:
>>> Hi again,
>>>
>>> Taking a different approach to this.
>>>
>>> New webrev:
>>> http://cr.openjdk.java.net/~mlarsson/8146879/webrev.01/
>>>
>>> Existing files will now by default be renamed/archived with a .X 
>>> suffix where X is the lowest number such that the resulting file 
>>> name is available (jvm.log becomes jvm.log.0). A mode option for 
>>> controlling this behavior has been added as well. It can be set to 
>>> archive, append, or truncate (i.e. -Xlog::jvm.log::mode=truncate).
>>>
>>> Tested with included jtreg test through JPRT.
>>>
>>> Thanks,
>>> Marcus
>>>
>>> On 01/14/2016 04:00 PM, Marcus Larsson wrote:
>>>> Hi,
>>>>
>>>> Please review the following patch to make sure UL truncates 
>>>> existing log files before writing to them. Since files are opened 
>>>> in append mode, truncation isn't done automatically, so instead the 
>>>> patch adds an attempt to remove the log file before opening it.
>>>>
>>>> Webrev:
>>>> http://cr.openjdk.java.net/~mlarsson/8146879/webrev.00/
>>>>
>>>> Issue:
>>>> https://bugs.openjdk.java.net/browse/JDK-8146879
>>>>
>>>> Testing:
>>>> Included test through JPRT
>>>>
>>>> Thanks,
>>>> Marcus
>>>
>>
>


From marcus.larsson at oracle.com  Fri Mar 11 14:39:41 2016
From: marcus.larsson at oracle.com (Marcus Larsson)
Date: Fri, 11 Mar 2016 15:39:41 +0100
Subject: RFR: 8146879: Add option for handling existing log files in UL
In-Reply-To: <56E2D7AA.1060803@oracle.com>
References: <5697B7F2.50104@oracle.com> <56D578F9.6090602@oracle.com>
	<56D5A1BB.6030403@oracle.com> <56E2D478.3090202@oracle.com>
	<56E2D7AA.1060803@oracle.com>
Message-ID: <56E2D8AD.8040902@oracle.com>

Hi,

On 2016-03-11 15:35, Bengt Rutisson wrote:
>
> Hi Marcus,
>
> On 2016-03-11 15:21, Marcus Larsson wrote:
>> Third time's the charm.
>>
>> Webrev:
>> http://cr.openjdk.java.net/~mlarsson/8146879/webrev.03/
>
> I had a quick look at the code changes. It is not really my area of 
> the code, so I'll leave to someone else to formally review it.
>
> However, I downloaded the patch a played a bit with the logging. This 
> is much more like the way I would like it! Thanks!
>
> So, from a functional perspective this looks good to me.
>

Thanks for the feedback!

Marcus

> Thanks,
> Bengt
>
>>
>> This patch makes log file rotation the default. Default thresholds 
>> are 5 rotated files with a target size of 20MiB. Truncating behavior 
>> can be achieved by setting filecount to 0 
>> (-Xlog::myfile.log::filecount=0).
>>
>> If a log file already exists during log file initialization it will 
>> be rotated. If any of the target file names (file.0 to file.4 in the 
>> default case) are available, that filename will be used for the 
>> existing log. If all names are taken the VM will attempt to overwrite 
>> the oldest file.
>>
>> This should prevent unlimited log file creations and avoid accidental 
>> loss of log files from previous runs. The default thresholds (5 
>> files, 20MiB each) is just a suggestion. If you think it should be 
>> higher/lower let me know.
>>
>> Tested with included internal VM tests through RBT.
>>
>> Thanks,
>> Marcus
>>
>> On 2016-03-01 15:05, Marcus Larsson wrote:
>>> Hi,
>>>
>>> After some offline discussions I'm withdrawing this patch. I will 
>>> instead investigate if I can achieve similar behavior using log 
>>> rotation as the default.
>>>
>>> Thanks,
>>> Marcus
>>>
>>> On 03/01/2016 12:11 PM, Marcus Larsson wrote:
>>>> Hi again,
>>>>
>>>> Taking a different approach to this.
>>>>
>>>> New webrev:
>>>> http://cr.openjdk.java.net/~mlarsson/8146879/webrev.01/
>>>>
>>>> Existing files will now by default be renamed/archived with a .X 
>>>> suffix where X is the lowest number such that the resulting file 
>>>> name is available (jvm.log becomes jvm.log.0). A mode option for 
>>>> controlling this behavior has been added as well. It can be set to 
>>>> archive, append, or truncate (i.e. -Xlog::jvm.log::mode=truncate).
>>>>
>>>> Tested with included jtreg test through JPRT.
>>>>
>>>> Thanks,
>>>> Marcus
>>>>
>>>> On 01/14/2016 04:00 PM, Marcus Larsson wrote:
>>>>> Hi,
>>>>>
>>>>> Please review the following patch to make sure UL truncates 
>>>>> existing log files before writing to them. Since files are opened 
>>>>> in append mode, truncation isn't done automatically, so instead 
>>>>> the patch adds an attempt to remove the log file before opening it.
>>>>>
>>>>> Webrev:
>>>>> http://cr.openjdk.java.net/~mlarsson/8146879/webrev.00/
>>>>>
>>>>> Issue:
>>>>> https://bugs.openjdk.java.net/browse/JDK-8146879
>>>>>
>>>>> Testing:
>>>>> Included test through JPRT
>>>>>
>>>>> Thanks,
>>>>> Marcus
>>>>
>>>
>>
>


From marcus.larsson at oracle.com  Fri Mar 11 14:40:45 2016
From: marcus.larsson at oracle.com (Marcus Larsson)
Date: Fri, 11 Mar 2016 15:40:45 +0100
Subject: RFR: 8150823: UL handles disabling logs incorrectly
Message-ID: <56E2D8ED.3040204@oracle.com>

Hi,

Please review the following patch to fix a problem with disabling log 
outputs using -Xlog:disable or disable_logging() when there are multiple 
file outputs configured. The patch also resolves an issue with log file 
lookups that could cause multiple outputs to be created for the same log 
file.

Log output removal now iterates backwards to not invalidate the loop 
index, and file outputs are always prepended with "file=" during lookups 
and listings.

Webrev:
http://cr.openjdk.java.net/~mlarsson/8150823/webrev.00/

Issue:
https://bugs.openjdk.java.net/browse/JDK-8150823

Testing:
Included tests through RBT

Thanks,
Marcus

From robbin.ehn at oracle.com  Fri Mar 11 15:50:51 2016
From: robbin.ehn at oracle.com (Robbin Ehn)
Date: Fri, 11 Mar 2016 16:50:51 +0100
Subject: RFR: 8146879: Add option for handling existing log files in UL
In-Reply-To: <56E2D478.3090202@oracle.com>
References: <5697B7F2.50104@oracle.com> <56D578F9.6090602@oracle.com>
	<56D5A1BB.6030403@oracle.com> <56E2D478.3090202@oracle.com>
Message-ID: <56E2E95B.8050500@oracle.com>

Hi Marcus,

Two small things.

src/share/vm/runtime/os.hpp:
+  static int compare_file_modified_times(const char* file1, const char* 
file2);
Is this so generic that we should have it os.[h,c]pp?
E.g. if we want to compare ctime, etc.. ?

On 03/11/2016 03:21 PM, Marcus Larsson wrote:
> Third time's the charm.
>
> Webrev:
> http://cr.openjdk.java.net/~mlarsson/8146879/webrev.03/
>
> This patch makes log file rotation the default. Default thresholds are 5
> rotated files with a target size of 20MiB. Truncating behavior can be
> achieved by setting filecount to 0 (-Xlog::myfile.log::filecount=0).

src/share/vm/logging/logFileOutput.hpp:
+ static const size_t DefaultRotationFileSize = 2097152; // 20MiB
Missing a 0 here, I prefer to write this as 20*1024*1024

>
> If a log file already exists during log file initialization it will be
> rotated. If any of the target file names (file.0 to file.4 in the
> default case) are available, that filename will be used for the existing
> log. If all names are taken the VM will attempt to overwrite the oldest
> file.
>
> This should prevent unlimited log file creations and avoid accidental
> loss of log files from previous runs. The default thresholds (5 files,
> 20MiB each) is just a suggestion. If you think it should be higher/lower
> let me know.
>
> Tested with included internal VM tests through RBT.

I also functional tested this and it works as intended.
There is an issue regarding removing the current log file.
Discussed in side-channel it will be handled outside this CS since it 
not directly related.

Otherwise looks good!

/Robbin

>
> Thanks,
> Marcus
>
> On 2016-03-01 15:05, Marcus Larsson wrote:
>> Hi,
>>
>> After some offline discussions I'm withdrawing this patch. I will
>> instead investigate if I can achieve similar behavior using log
>> rotation as the default.
>>
>> Thanks,
>> Marcus
>>
>> On 03/01/2016 12:11 PM, Marcus Larsson wrote:
>>> Hi again,
>>>
>>> Taking a different approach to this.
>>>
>>> New webrev:
>>> http://cr.openjdk.java.net/~mlarsson/8146879/webrev.01/
>>>
>>> Existing files will now by default be renamed/archived with a .X
>>> suffix where X is the lowest number such that the resulting file name
>>> is available (jvm.log becomes jvm.log.0). A mode option for
>>> controlling this behavior has been added as well. It can be set to
>>> archive, append, or truncate (i.e. -Xlog::jvm.log::mode=truncate).
>>>
>>> Tested with included jtreg test through JPRT.
>>>
>>> Thanks,
>>> Marcus
>>>
>>> On 01/14/2016 04:00 PM, Marcus Larsson wrote:
>>>> Hi,
>>>>
>>>> Please review the following patch to make sure UL truncates existing
>>>> log files before writing to them. Since files are opened in append
>>>> mode, truncation isn't done automatically, so instead the patch adds
>>>> an attempt to remove the log file before opening it.
>>>>
>>>> Webrev:
>>>> http://cr.openjdk.java.net/~mlarsson/8146879/webrev.00/
>>>>
>>>> Issue:
>>>> https://bugs.openjdk.java.net/browse/JDK-8146879
>>>>
>>>> Testing:
>>>> Included test through JPRT
>>>>
>>>> Thanks,
>>>> Marcus
>>>
>>
>

From erik.joelsson at oracle.com  Fri Mar 11 16:31:03 2016
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Fri, 11 Mar 2016 17:31:03 +0100
Subject: RFR: JDK-8151653: Hotspot build does not respect --enable-openjdk-only
Message-ID: <56E2F2C7.9090301@oracle.com>

Hello,

When building hotspot with closed sources present and configuring with 
--enable-openjdk-only, various closed parts are included in the build 
anyway, at least on Windows. This needs to be fixed in preparation for 
the new hotspot build for build output comparisons to be meaningful 
between the old and new.

The major culprit here, which applies to all platforms, is the trace 
source generation. The base trace.xml uses XInclude to explicitly and 
unconditionally include closed xml files if present. I'm fixing this by 
introducing a closed version of trace.xml which includes the open and 
closed parts, while the open trace.xml only includes the open parts.

The rest of the changes are just for Windows, making sure the OPENJDK 
variable is propagated into the nmake build and making all conditionals 
on including closed source also check that variable.

Bug: https://bugs.openjdk.java.net/browse/JDK-8151653
Webrev: 
http://cr.openjdk.java.net/~erikj/8151653/webrev.hotspot.01/index.html

/Erik
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20160311/a87431bb/attachment.html>

From gerard.ziemski at oracle.com  Fri Mar 11 16:40:47 2016
From: gerard.ziemski at oracle.com (Gerard Ziemski)
Date: Fri, 11 Mar 2016 10:40:47 -0600
Subject: RFR: 8146879: Add option for handling existing log files in UL
In-Reply-To: <56E2D478.3090202@oracle.com>
References: <5697B7F2.50104@oracle.com> <56D578F9.6090602@oracle.com>
	<56D5A1BB.6030403@oracle.com> <56E2D478.3090202@oracle.com>
Message-ID: <D794E59F-5B0F-463E-A855-1F185330BD27@oracle.com>

hi Marcus,

I?m still going through the webrev, but I thought I would report my feedback so far.

------------------------------------------------
#1 File src/os/posix/vm/os_posix.cpp

How about instead of:

+int os::compare_file_modified_times(const char* file1, const char* file2) {
+  struct stat st[2];
+  struct timespec filetime[2];
+
+  for (int i = 0; i < 2; i++) {
+    const char* file = (i == 0 ? file1 : file2);
+    int ret = os::stat(file, &st[i]);
+    assert(ret == 0, "failed to stat() file '%s': %s", file, strerror(errno));
+#ifdef __APPLE__
+    filetime[i] = st[i].st_mtimespec;
+#else
+    filetime[i] = st[i].st_mtim;
+#endif
+  }
+
+  int diff = filetime[0].tv_sec - filetime[1].tv_sec;
+  if (diff == 0) {
+    return filetime[0].tv_nsec - filetime[1].tv_nsec;
+  }
+  return diff;
+}

we have something like this, which doesn?t use arrays or a loop mimicking inline function:

static inline struct timespec get_timespec(const char* file) {
  struct stat st;
  int ret = stat(file, &st);
  assert(ret == 0, "failed to stat() file '%s': %s", file, strerror(errno));
  #ifdef __APPLE__
    return st.st_mtimespec;
  #else
    return st.st_mtim;
  #endif
}

int compare_file_modified_times(const char* file1, const char* file2) {
  struct timespec filetime1 = get_timespec(file1);
  struct timespec filetime2 = get_timespec(file2);
  int diff = filetime1.tv_sec - filetime2.tv_sec;
  if (diff == 0) {
     return filetime1.tv_nsec - filetime2.tv_nsec;
  }
  return diff;
}

Similarly we should use static inline function instead of a loop in src/os/windows/vm/os_windows.cpp

-----------------------------------------------
#2 File src/share/vm/logging/log.cpp

Doesn?t this function produce an error or at least a warning on a product build without asserts?

+static void delete_file(const char* filename) {
+  if (!file_exists(filename)) {
+    return;
+  }
+  int ret = remove(filename);
+  assert(ret == 0, "failed to remove file '%s': %s", filename, strerror(errno));
+}


-----------------------------------------------
#3 File src/share/vm/logging/log.cpp

The number_of_lines_with_substring_in_file() function will not count the substrings that happen to lay across the boundary at sizeof(buf). For example with:

 char buf[16];

and file consisting of ?12345678901234gerard1234567890? it will return 0 for number_of_lines_with_substring_in_file(file, ?gerard")


-----------------------------------------------
#4 File src/share/vm/logging/log.cpp

Should we clarify that we are rounding the results of log10 down by explicitly using floor and explicitly casting it to uint?

static uint number_of_digits_new(uint number) {
  double d = static_cast<double>(number);
  uint res = 1 + static_cast<uint>(floor(log10(d)));
  return res;
}

cheers


> On Mar 11, 2016, at 8:21 AM, Marcus Larsson <marcus.larsson at oracle.com> wrote:
> 
> Third time's the charm.
> 
> Webrev:
> http://cr.openjdk.java.net/~mlarsson/8146879/webrev.03/
> 
> This patch makes log file rotation the default. Default thresholds are 5 rotated files with a target size of 20MiB. Truncating behavior can be achieved by setting filecount to 0 (-Xlog::myfile.log::filecount=0).
> 
> If a log file already exists during log file initialization it will be rotated. If any of the target file names (file.0 to file.4 in the default case) are available, that filename will be used for the existing log. If all names are taken the VM will attempt to overwrite the oldest file.
> 
> This should prevent unlimited log file creations and avoid accidental loss of log files from previous runs. The default thresholds (5 files, 20MiB each) is just a suggestion. If you think it should be higher/lower let me know.
> 
> Tested with included internal VM tests through RBT.
> 
> Thanks,
> Marcus
> 
> On 2016-03-01 15:05, Marcus Larsson wrote:
>> Hi,
>> 
>> After some offline discussions I'm withdrawing this patch. I will instead investigate if I can achieve similar behavior using log rotation as the default.
>> 
>> Thanks,
>> Marcus
>> 
>> On 03/01/2016 12:11 PM, Marcus Larsson wrote:
>>> Hi again,
>>> 
>>> Taking a different approach to this.
>>> 
>>> New webrev:
>>> http://cr.openjdk.java.net/~mlarsson/8146879/webrev.01/
>>> 
>>> Existing files will now by default be renamed/archived with a .X suffix where X is the lowest number such that the resulting file name is available (jvm.log becomes jvm.log.0). A mode option for controlling this behavior has been added as well. It can be set to archive, append, or truncate (i.e. -Xlog::jvm.log::mode=truncate).
>>> 
>>> Tested with included jtreg test through JPRT.
>>> 
>>> Thanks,
>>> Marcus
>>> 
>>> On 01/14/2016 04:00 PM, Marcus Larsson wrote:
>>>> Hi,
>>>> 
>>>> Please review the following patch to make sure UL truncates existing log files before writing to them. Since files are opened in append mode, truncation isn't done automatically, so instead the patch adds an attempt to remove the log file before opening it.
>>>> 
>>>> Webrev:
>>>> http://cr.openjdk.java.net/~mlarsson/8146879/webrev.00/
>>>> 
>>>> Issue:
>>>> https://bugs.openjdk.java.net/browse/JDK-8146879
>>>> 
>>>> Testing:
>>>> Included test through JPRT
>>>> 
>>>> Thanks,
>>>> Marcus
>>> 
>> 
> 


From yasuenag at gmail.com  Sat Mar 12 14:33:32 2016
From: yasuenag at gmail.com (Yasumasa Suenaga)
Date: Sat, 12 Mar 2016 23:33:32 +0900
Subject: RFR: JDK-8151709: jhsdb should show help message in SALauncher.
In-Reply-To: <56E2C790.4020802@gmail.com>
References: <56E2C790.4020802@gmail.com>
Message-ID: <56E428BC.8050108@gmail.com>

I updated webrev:
    http://cr.openjdk.java.net/~ysuenaga/JDK-8151709/webrev.01/

I added changes for JInfo.java because help message is shown in twice.

Please review.


Thanks,

Yasumasa


On 2016/03/11 22:26, Yasumasa Suenaga wrote:
> Hi all,
> 
> jhsdb shows error message in each tool implemantation as below:
> --------------
> $ jhsdb jstack -aaa
> Usage: jstack [option] <pid>
>                  (to connect to a live java process)
>     or jstack [option] <executable> <core>
>                  (to connect to a core file)
>     or jstack [option] [server_id@]<remote server IP or hostname>
>                  (to connect to a remote debug server)
> 
> where option must be one of:
>      -l  to print java.util.concurrent locks
>      -m  to print both java and native frames (mixed mode)
>      -h | -help  to print this help message
> --------------
> 
> If we run SA tool via jhsdb, we should get help message of SALauncher as below:
> --------------
> $ jhsdb jstack -aaa
>      --locks     to print java.util.concurrent locks
>      --mixed     to print both java and native frames (mixed mode)
>      --exe       executable image name
>      --core      path to coredump
>      --pid       pid of process to attach
> --------------
> 
> I uploaded webrev. Could you review it?
>      http://cr.openjdk.java.net/~ysuenaga/JDK-8151709/webrev.00/
> 
> I cannot access JPRT.
> So I need a Sponsor.
> 
> 
> Thanks,
> 
> Yasumasa
> 

From kubota.yuji at gmail.com  Sat Mar 12 14:46:32 2016
From: kubota.yuji at gmail.com (KUBOTA Yuji)
Date: Sat, 12 Mar 2016 23:46:32 +0900
Subject: Check core dumping is enabled when set CrashOnOutOfMemoryError
Message-ID: <CABU-27P4ZvQZio761Q2W8_w0=SXA9p=a3c4HRW9KEq+rVXrEsA@mail.gmail.com>

Hi everyone.

When set -XX:+CrashOnOutOfMemoryError, I think we should know
whether core dumping has been enabled or not before launching
process to prevent lack of information for after-the-fact analysis.

So I create a patch to check the core dumping, please review it.
I do not have an account of openjdk, so I need sponsor.

I send to serviceability-dev because JDK-8138745 [1] has been
reviewed here. If unfit, please let me know.

[1]:Implement ExitOnOutOfMemory and CrashOnOutOfMemory in HotSpot
     https://bugs.openjdk.java.net/browse/JDK-8138745

diff --git a/src/share/vm/runtime/commandLineFlagConstraintsRuntime.cpp
b/src/share/vm/runtime/commandLineFlagConstraintsRuntime.cpp
--- a/src/share/vm/runtime/commandLineFlagConstraintsRuntime.cpp
+++ b/src/share/vm/runtime/commandLineFlagConstraintsRuntime.cpp
@@ -119,6 +119,17 @@
   }
 }

+Flag::Error CrashOnOutOfMemoryErrorFunc(bool value, bool verbose) {
+  char buffer[O_BUFLEN];
+  os::check_dump_limit(buffer, sizeof(buffer));
+  if (!VMError::coredump_status) {
+    CommandLineError::print(verbose,
+                            "%s\n", VMError::coredump_message);
+    return Flag::VIOLATES_CONSTRAINT;
+  }
+  return Flag::SUCCESS;
+}
+
 Flag::Error PerfDataSamplingIntervalFunc(intx value, bool verbose) {
   if ((value % PeriodicTask::interval_gran != 0)) {
     CommandLineError::print(verbose,
diff --git a/src/share/vm/runtime/commandLineFlagConstraintsRuntime.hpp
b/src/share/vm/runtime/commandLineFlagConstraintsRuntime.hpp
--- a/src/share/vm/runtime/commandLineFlagConstraintsRuntime.hpp
+++ b/src/share/vm/runtime/commandLineFlagConstraintsRuntime.hpp
@@ -43,6 +43,8 @@
 Flag::Error BiasedLockingBulkRevokeThresholdFunc(intx value, bool verbose);
 Flag::Error BiasedLockingDecayTimeFunc(intx value, bool verbose);

+Flag::Error CrashOnOutOfMemoryErrorFunc(bool value, bool verbose);
+
 Flag::Error PerfDataSamplingIntervalFunc(intx value, bool verbose);

 #endif /* SHARE_VM_RUNTIME_COMMANDLINEFLAGCONSTRAINTSRUNTIME_HPP */
diff --git a/src/share/vm/runtime/globals.hpp b/src/share/vm/runtime/globals.hpp
--- a/src/share/vm/runtime/globals.hpp
+++ b/src/share/vm/runtime/globals.hpp
@@ -1401,6 +1401,7 @@
   product(bool, CrashOnOutOfMemoryError, false,                             \
           "JVM aborts, producing an error log and core/mini dump, on the "  \
           "first occurrence of an out-of-memory error")                     \
+          constraint(CrashOnOutOfMemoryErrorFunc,AfterErgo)                 \
                                                                             \
   /* tracing */                                                             \
                                                                             \
diff --git a/src/share/vm/utilities/vmError.hpp
b/src/share/vm/utilities/vmError.hpp
--- a/src/share/vm/utilities/vmError.hpp
+++ b/src/share/vm/utilities/vmError.hpp
@@ -65,14 +65,6 @@
   // so use thread id instead of Thread* to identify thread.
   static volatile intptr_t first_error_tid;

-  // Core dump status, false if we have been unable to write a
core/minidump for some reason
-  static bool coredump_status;
-
-  // When coredump_status is set to true this will contain the
name/path to the core/minidump,
-  // if coredump_status if false, this will (hopefully) contain a
useful error explaining why
-  // no core/minidump has been written to disk
-  static char coredump_message[O_BUFLEN];
-

   // set signal handlers on Solaris/Linux or the default exception filter
   // on Windows, to handle recursive crashes.
@@ -111,6 +103,14 @@
   // Record status of core/minidump
   static void record_coredump_status(const char* message, bool status);

+  // Core dump status, false if we have been unable to write a
core/minidump for some reason
+  static bool coredump_status;
+
+  // When coredump_status is set to true this will contain the
name/path to the core/minidump,
+  // if coredump_status if false, this will (hopefully) contain a
useful error explaining why
+  // no core/minidump has been written to disk
+  static char coredump_message[O_BUFLEN];
+
   // support for VM.info diagnostic command
   static void print_vm_info(outputStream* st);


Thanks,
Yuji

From tim.bell at oracle.com  Sat Mar 12 21:11:38 2016
From: tim.bell at oracle.com (Tim Bell)
Date: Sat, 12 Mar 2016 13:11:38 -0800
Subject: RFR: JDK-8151653: Hotspot build does not respect
	--enable-openjdk-only
In-Reply-To: <56E2F2C7.9090301@oracle.com>
References: <56E2F2C7.9090301@oracle.com>
Message-ID: <56E4860A.2060109@oracle.com>

Erik:

> When building hotspot with closed sources present and configuring with 
> --enable-openjdk-only, various closed parts are included in the build 
> anyway, at least on Windows. This needs to be fixed in preparation for 
> the new hotspot build for build output comparisons to be meaningful 
> between the old and new.
>
> The major culprit here, which applies to all platforms, is the trace 
> source generation. The base trace.xml uses XInclude to explicitly and 
> unconditionally include closed xml files if present. I'm fixing this 
> by introducing a closed version of trace.xml which includes the open 
> and closed parts, while the open trace.xml only includes the open parts.
>
> The rest of the changes are just for Windows, making sure the OPENJDK 
> variable is propagated into the nmake build and making all 
> conditionals on including closed source also check that variable.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8151653
> Webrev: 
> http://cr.openjdk.java.net/~erikj/8151653/webrev.hotspot.01/index.html

This looks good to me.

/Tim

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20160312/0419d026/attachment.html>

From dmitry.samersoff at oracle.com  Sun Mar 13 11:03:45 2016
From: dmitry.samersoff at oracle.com (Dmitry Samersoff)
Date: Sun, 13 Mar 2016 14:03:45 +0300
Subject: RFR: 8146879: Add option for handling existing log files in UL
In-Reply-To: <56E2D8AD.8040902@oracle.com>
References: <5697B7F2.50104@oracle.com> <56D578F9.6090602@oracle.com>
	<56D5A1BB.6030403@oracle.com> <56E2D478.3090202@oracle.com>
	<56E2D7AA.1060803@oracle.com> <56E2D8AD.8040902@oracle.com>
Message-ID: <56E54911.9090807@oracle.com>

Marcus,

1. os_posix/os_windows.cpp

Windows version is expensive and change access time of a log file.

So it's better to create os::get_mtime() that uses stat() for both,
windows and posix and LogFileOutput::calc_mtime_diff().

Also it saves a bit of compiler power unrolling loop.

2. log.cpp

size_t number_of_lines_with_substring_in_file()

When you plan to use it ? Current implementation is rather expensive,
but if you plan to run it manually only, I'm OK with it.

3. logFileOutput.cpp

82.
Please, change file_exists to can_be_rotated() and check that log output
is a *regular file* and you have a write access to it.

87.
Please, don't use floating point math. Just allocate 10 extra bytes, it
fit all possible file length value.

93.
if we have log.01, log.03 etc this function creates log.02 instead of
log.04.

Sorry! I'm not follow logic of ll.118
What happens if some log parsing tool change log file mtime?

Please, limit the number of old logs (FileCountOption) to some
reasonable value (e.g. 999) and use binary search to find the name of a
next file.

Also please check full log file name against MAX_PATH constant.

-Dmitry




On 2016-03-11 17:39, Marcus Larsson wrote:
> Hi,
> 
> On 2016-03-11 15:35, Bengt Rutisson wrote:
>>
>> Hi Marcus,
>>
>> On 2016-03-11 15:21, Marcus Larsson wrote:
>>> Third time's the charm.
>>>
>>> Webrev:
>>> http://cr.openjdk.java.net/~mlarsson/8146879/webrev.03/
>>
>> I had a quick look at the code changes. It is not really my area of
>> the code, so I'll leave to someone else to formally review it.
>>
>> However, I downloaded the patch a played a bit with the logging. This
>> is much more like the way I would like it! Thanks!
>>
>> So, from a functional perspective this looks good to me.
>>
> 
> Thanks for the feedback!
> 
> Marcus
> 
>> Thanks,
>> Bengt
>>
>>>
>>> This patch makes log file rotation the default. Default thresholds
>>> are 5 rotated files with a target size of 20MiB. Truncating behavior
>>> can be achieved by setting filecount to 0
>>> (-Xlog::myfile.log::filecount=0).
>>>
>>> If a log file already exists during log file initialization it will
>>> be rotated. If any of the target file names (file.0 to file.4 in the
>>> default case) are available, that filename will be used for the
>>> existing log. If all names are taken the VM will attempt to overwrite
>>> the oldest file.
>>>
>>> This should prevent unlimited log file creations and avoid accidental
>>> loss of log files from previous runs. The default thresholds (5
>>> files, 20MiB each) is just a suggestion. If you think it should be
>>> higher/lower let me know.
>>>
>>> Tested with included internal VM tests through RBT.
>>>
>>> Thanks,
>>> Marcus
>>>
>>> On 2016-03-01 15:05, Marcus Larsson wrote:
>>>> Hi,
>>>>
>>>> After some offline discussions I'm withdrawing this patch. I will
>>>> instead investigate if I can achieve similar behavior using log
>>>> rotation as the default.
>>>>
>>>> Thanks,
>>>> Marcus
>>>>
>>>> On 03/01/2016 12:11 PM, Marcus Larsson wrote:
>>>>> Hi again,
>>>>>
>>>>> Taking a different approach to this.
>>>>>
>>>>> New webrev:
>>>>> http://cr.openjdk.java.net/~mlarsson/8146879/webrev.01/
>>>>>
>>>>> Existing files will now by default be renamed/archived with a .X
>>>>> suffix where X is the lowest number such that the resulting file
>>>>> name is available (jvm.log becomes jvm.log.0). A mode option for
>>>>> controlling this behavior has been added as well. It can be set to
>>>>> archive, append, or truncate (i.e. -Xlog::jvm.log::mode=truncate).
>>>>>
>>>>> Tested with included jtreg test through JPRT.
>>>>>
>>>>> Thanks,
>>>>> Marcus
>>>>>
>>>>> On 01/14/2016 04:00 PM, Marcus Larsson wrote:
>>>>>> Hi,
>>>>>>
>>>>>> Please review the following patch to make sure UL truncates
>>>>>> existing log files before writing to them. Since files are opened
>>>>>> in append mode, truncation isn't done automatically, so instead
>>>>>> the patch adds an attempt to remove the log file before opening it.
>>>>>>
>>>>>> Webrev:
>>>>>> http://cr.openjdk.java.net/~mlarsson/8146879/webrev.00/
>>>>>>
>>>>>> Issue:
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8146879
>>>>>>
>>>>>> Testing:
>>>>>> Included test through JPRT
>>>>>>
>>>>>> Thanks,
>>>>>> Marcus
>>>>>
>>>>
>>>
>>
> 


-- 
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the sources.

From dmitry.samersoff at oracle.com  Sun Mar 13 14:52:46 2016
From: dmitry.samersoff at oracle.com (Dmitry Samersoff)
Date: Sun, 13 Mar 2016 17:52:46 +0300
Subject: RFR: JDK-8151709: jhsdb should show help message in SALauncher.
In-Reply-To: <56E428BC.8050108@gmail.com>
References: <56E2C790.4020802@gmail.com> <56E428BC.8050108@gmail.com>
Message-ID: <56E57EBE.5050901@oracle.com>

Yasumasa,

1.
We shouldn't introduce dependency from Tool.java back to SALuancher.

So please, change runJSTACK (and other similar functions)  to catch
invalid arguments.

It might require changing of SAGetopt.java and/or
jdk/test/sun/tools/jhsdb/SAGetoptTest.java

2. For JInfo changes, please create

private static final int MODE_UNKNOWN = -1;


-Dmitry


On 2016-03-12 17:33, Yasumasa Suenaga wrote:
> I updated webrev:
>     http://cr.openjdk.java.net/~ysuenaga/JDK-8151709/webrev.01/
> 
> I added changes for JInfo.java because help message is shown in twice.
> 
> Please review.
> 
> 
> Thanks,
> 
> Yasumasa
> 
> 
> On 2016/03/11 22:26, Yasumasa Suenaga wrote:
>> Hi all,
>>
>> jhsdb shows error message in each tool implemantation as below:
>> --------------
>> $ jhsdb jstack -aaa
>> Usage: jstack [option] <pid>
>>                  (to connect to a live java process)
>>     or jstack [option] <executable> <core>
>>                  (to connect to a core file)
>>     or jstack [option] [server_id@]<remote server IP or hostname>
>>                  (to connect to a remote debug server)
>>
>> where option must be one of:
>>      -l  to print java.util.concurrent locks
>>      -m  to print both java and native frames (mixed mode)
>>      -h | -help  to print this help message
>> --------------
>>
>> If we run SA tool via jhsdb, we should get help message of SALauncher as below:
>> --------------
>> $ jhsdb jstack -aaa
>>      --locks     to print java.util.concurrent locks
>>      --mixed     to print both java and native frames (mixed mode)
>>      --exe       executable image name
>>      --core      path to coredump
>>      --pid       pid of process to attach
>> --------------
>>
>> I uploaded webrev. Could you review it?
>>      http://cr.openjdk.java.net/~ysuenaga/JDK-8151709/webrev.00/
>>
>> I cannot access JPRT.
>> So I need a Sponsor.
>>
>>
>> Thanks,
>>
>> Yasumasa
>>


-- 
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the sources.

From david.holmes at oracle.com  Mon Mar 14 00:25:26 2016
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 14 Mar 2016 10:25:26 +1000
Subject: Check core dumping is enabled when set CrashOnOutOfMemoryError
In-Reply-To: <CABU-27P4ZvQZio761Q2W8_w0=SXA9p=a3c4HRW9KEq+rVXrEsA@mail.gmail.com>
References: <CABU-27P4ZvQZio761Q2W8_w0=SXA9p=a3c4HRW9KEq+rVXrEsA@mail.gmail.com>
Message-ID: <56E604F6.80505@oracle.com>

Hi,

On 13/03/2016 12:46 AM, KUBOTA Yuji wrote:
> Hi everyone.
>
> When set -XX:+CrashOnOutOfMemoryError, I think we should know
> whether core dumping has been enabled or not before launching
> process to prevent lack of information for after-the-fact analysis.

First I'm not convinced that you necessarily want to enable core dumps 
just because you want to crash on OOM.

Second I think anyone setting CrashOnOutOfMemoryError can easily 
remember to set CreateCoredumpOnCrash if they want it.

Third if I was going to force this on then I would do it directly in 
arguments.cpp, not by adding a constraint function.

Thanks,
David
-----

> So I create a patch to check the core dumping, please review it.
> I do not have an account of openjdk, so I need sponsor.
>
> I send to serviceability-dev because JDK-8138745 [1] has been
> reviewed here. If unfit, please let me know.
>
> [1]:Implement ExitOnOutOfMemory and CrashOnOutOfMemory in HotSpot
>       https://bugs.openjdk.java.net/browse/JDK-8138745
>
> diff --git a/src/share/vm/runtime/commandLineFlagConstraintsRuntime.cpp
> b/src/share/vm/runtime/commandLineFlagConstraintsRuntime.cpp
> --- a/src/share/vm/runtime/commandLineFlagConstraintsRuntime.cpp
> +++ b/src/share/vm/runtime/commandLineFlagConstraintsRuntime.cpp
> @@ -119,6 +119,17 @@
>     }
>   }
>
> +Flag::Error CrashOnOutOfMemoryErrorFunc(bool value, bool verbose) {
> +  char buffer[O_BUFLEN];
> +  os::check_dump_limit(buffer, sizeof(buffer));
> +  if (!VMError::coredump_status) {
> +    CommandLineError::print(verbose,
> +                            "%s\n", VMError::coredump_message);
> +    return Flag::VIOLATES_CONSTRAINT;
> +  }
> +  return Flag::SUCCESS;
> +}
> +
>   Flag::Error PerfDataSamplingIntervalFunc(intx value, bool verbose) {
>     if ((value % PeriodicTask::interval_gran != 0)) {
>       CommandLineError::print(verbose,
> diff --git a/src/share/vm/runtime/commandLineFlagConstraintsRuntime.hpp
> b/src/share/vm/runtime/commandLineFlagConstraintsRuntime.hpp
> --- a/src/share/vm/runtime/commandLineFlagConstraintsRuntime.hpp
> +++ b/src/share/vm/runtime/commandLineFlagConstraintsRuntime.hpp
> @@ -43,6 +43,8 @@
>   Flag::Error BiasedLockingBulkRevokeThresholdFunc(intx value, bool verbose);
>   Flag::Error BiasedLockingDecayTimeFunc(intx value, bool verbose);
>
> +Flag::Error CrashOnOutOfMemoryErrorFunc(bool value, bool verbose);
> +
>   Flag::Error PerfDataSamplingIntervalFunc(intx value, bool verbose);
>
>   #endif /* SHARE_VM_RUNTIME_COMMANDLINEFLAGCONSTRAINTSRUNTIME_HPP */
> diff --git a/src/share/vm/runtime/globals.hpp b/src/share/vm/runtime/globals.hpp
> --- a/src/share/vm/runtime/globals.hpp
> +++ b/src/share/vm/runtime/globals.hpp
> @@ -1401,6 +1401,7 @@
>     product(bool, CrashOnOutOfMemoryError, false,                             \
>             "JVM aborts, producing an error log and core/mini dump, on the "  \
>             "first occurrence of an out-of-memory error")                     \
> +          constraint(CrashOnOutOfMemoryErrorFunc,AfterErgo)                 \
>                                                                               \
>     /* tracing */                                                             \
>                                                                               \
> diff --git a/src/share/vm/utilities/vmError.hpp
> b/src/share/vm/utilities/vmError.hpp
> --- a/src/share/vm/utilities/vmError.hpp
> +++ b/src/share/vm/utilities/vmError.hpp
> @@ -65,14 +65,6 @@
>     // so use thread id instead of Thread* to identify thread.
>     static volatile intptr_t first_error_tid;
>
> -  // Core dump status, false if we have been unable to write a
> core/minidump for some reason
> -  static bool coredump_status;
> -
> -  // When coredump_status is set to true this will contain the
> name/path to the core/minidump,
> -  // if coredump_status if false, this will (hopefully) contain a
> useful error explaining why
> -  // no core/minidump has been written to disk
> -  static char coredump_message[O_BUFLEN];
> -
>
>     // set signal handlers on Solaris/Linux or the default exception filter
>     // on Windows, to handle recursive crashes.
> @@ -111,6 +103,14 @@
>     // Record status of core/minidump
>     static void record_coredump_status(const char* message, bool status);
>
> +  // Core dump status, false if we have been unable to write a
> core/minidump for some reason
> +  static bool coredump_status;
> +
> +  // When coredump_status is set to true this will contain the
> name/path to the core/minidump,
> +  // if coredump_status if false, this will (hopefully) contain a
> useful error explaining why
> +  // no core/minidump has been written to disk
> +  static char coredump_message[O_BUFLEN];
> +
>     // support for VM.info diagnostic command
>     static void print_vm_info(outputStream* st);
>
>
> Thanks,
> Yuji
>

From david.holmes at oracle.com  Mon Mar 14 01:22:05 2016
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 14 Mar 2016 11:22:05 +1000
Subject: RFR: JDK-8151653: Hotspot build does not respect
	--enable-openjdk-only
In-Reply-To: <56E2F2C7.9090301@oracle.com>
References: <56E2F2C7.9090301@oracle.com>
Message-ID: <56E6123D.9020209@oracle.com>

Hi Erik,

On 12/03/2016 2:31 AM, Erik Joelsson wrote:
> Hello,
>
> When building hotspot with closed sources present and configuring with
> --enable-openjdk-only, various closed parts are included in the build
> anyway, at least on Windows. This needs to be fixed in preparation for
> the new hotspot build for build output comparisons to be meaningful
> between the old and new.
>
> The major culprit here, which applies to all platforms, is the trace
> source generation. The base trace.xml uses XInclude to explicitly and
> unconditionally include closed xml files if present. I'm fixing this by
> introducing a closed version of trace.xml which includes the open and
> closed parts, while the open trace.xml only includes the open parts.

You've also done a significant amount of refactoring of that file and 
split it into three parts. It's hard to spot the actual functional 
differences in all that.

Given we have distinct directories from which we locate files it is a 
pity to introduce something like this:

  XML_DEPS += $(TraceAltSrcDir)/traceeventsclosed.xml

where traceevents.xml is now traceeventsclosed.xml. This "alt src" 
mechanism was supposed to abstract away the details of any particular 
alternative configuration so that we didn't hardcode "closed" all over 
the place. Other community members are supposed to be able to utilize 
these mechanisms for their own customized build environments.

> The rest of the changes are just for Windows, making sure the OPENJDK
> variable is propagated into the nmake build and making all conditionals
> on including closed source also check that variable.

make/windows/build.make

The combination !openjdk && !exists "closed" should be an error.

As a meta-comment I think we've lost the plot somewhat with these "alt" 
locations and how we manage them. The Oracle "closed" variants should 
only be used when not trying to build OpenJDK (even if the files exist 
in a forest), but other custom implementations may work in conjunction 
with an OpenJDK build. To that end the "do nothing if building OpenJDK" 
should be located within the "alt" files themselves, not at the point of 
inclusion/use in the open files.

David
-----

> Bug: https://bugs.openjdk.java.net/browse/JDK-8151653
> Webrev:
> http://cr.openjdk.java.net/~erikj/8151653/webrev.hotspot.01/index.html
>
> /Erik

From david.holmes at oracle.com  Mon Mar 14 01:49:14 2016
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 14 Mar 2016 11:49:14 +1000
Subject: RFR[9u-dev]: 8151509: In check_addr0() function pointer is not
	updated correctly
In-Reply-To: <bb6749b1-6e3e-45e2-b96d-111d9a82b799@default>
References: <c136e4ba-60f8-493b-8179-1b8178083a8c@default>
	<56E16C85.30102@oracle.com>
	<CAA-vtUyfV1BiJBXNiO5Qk_=z_ZKGOVx7bvBDOpGuxPXxZ7zhXA@mail.gmail.com>
	<CAA-vtUxJA7FzDaXAvebPdfcCGqCtwrCjt-Hqz_4_snhvGqWB6w@mail.gmail.com>
	<6472a6fc-3197-4f42-927a-2b0ab0663a60@default>
	<56E2AC28.4040306@oracle.com>
	<bb6749b1-6e3e-45e2-b96d-111d9a82b799@default>
Message-ID: <56E6189A.1010409@oracle.com>

On 11/03/2016 9:38 PM, Cheleswer Sahu wrote:
> Thanks Dmitry and Thomas for reviews. After adding space I will  request for the push.

Consider this Reviewed.

But this needs to pushed to hs-rt and currently the webrev is against 
jdk9/dev.

Thanks,
David

>
>
> Regards,
>
> Cheleswer
>
>
>
> From: Dmitry Dmitriev
> Sent: Friday, March 11, 2016 5:00 PM
> To: Cheleswer Sahu; Thomas St?fe
> Cc: serviceability-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net
> Subject: Re: RFR[9u-dev]: 8151509: In check_addr0() function pointer is not updated correctly
>
>
>
> Hi Cheleswer,
>
> Please, add space between SIZE_FORMAT and " because C++11 requires a space between literal and identifier. Not need a new webrev for that.
>
> Thanks,
> Dmitry
>
>
>
> On 11.03.2016 12:31, Cheleswer Sahu wrote:
>
> Hi Thomas, Dmitry,
>
>
>
> Thanks for your review comments.  My answers are below for your review comments
>
>
>
> 1873       if( 0 != ret % sizeof(prmap_t)){
> 1874         break;
> 1875       }
>
>
>
>
>>> For this it has been thought that mostly read() will return the desired number of bytes, but only in case if something goes wrong and read() will  not able to read the data, it will return lesser number of bytes, which contains the partial data of  ?prmap_t? structure. The reason could be like file is corrupted, in such cases we don?t want to read anymore and feel it?s safe to skip the rest of file.
>
>
>
> 2) Just interesting, do you really need to set memory to 0 by memset?
>
>>>   I thought this it is good to have a clean buffer every time we read something into it, but it?s really not that much required as we are reading a binary data. So I am removing this line from the code.
>
>
>
> For rest of the comments I have made correction in the code. The new webrev is available in the below location
>
> HYPERLINK "http://cr.openjdk.java.net/%7Ecsahu/8151509/webrev.01/"http://cr.openjdk.java.net/~csahu/8151509/webrev.01/
>
>
>
>
>
> Regards,
>
> Cheleswer
>
>
>
> From: Thomas St?fe [mailto:thomas.stuefe at gmail.com]
> Sent: Thursday, March 10, 2016 7:39 PM
> To: Dmitry Dmitriev
> Cc: Cheleswer Sahu; HYPERLINK "mailto:serviceability-dev at openjdk.java.net"serviceability-dev at openjdk.java.net; HYPERLINK "mailto:hotspot-runtime-dev at openjdk.java.net"hotspot-runtime-dev at openjdk.java.net
> Subject: Re: RFR[9u-dev]: 8151509: In check_addr0() function pointer is not updated correctly
>
>
>
> (Sorry, pressed Send button too early)
>
> Just wanted to add that
>
> 1873       if( 0 != ret % sizeof(prmap_t)){
> 1874         break;
> 1875       }
>
> may be a bit harsh, as it skips the entire mapping in case read() stopped reading in a middle of a record. You could just continue to read until you read the rest of the record.
>
> Kind Regards, Thomas
>
>
>
> On Thu, Mar 10, 2016 at 3:07 PM, Thomas St?fe <HYPERLINK "mailto:thomas.stuefe at gmail.com"thomas.stuefe at gmail.com> wrote:
>
> Hi Cheleswer,
>
>
>
> thanks for fixing this.
>
>
>
> Some more issues:
>
>
>
> - 1866 char *mbuff = (char *) calloc(read_chunk, sizeof(prmap_t) + 1);
>
>
>
> Why the "+1"? It is unnecessary and causes the allocation to be 200 bytes larger than necessary.
>
>
>
> - 1880 st->print("Warning: Address: " PTR_FORMAT ", Size: %dK, ",p->pr_vaddr, p->pr_size/1024);
>
>
>
> Format specifier for Size is wrong.%d is int, but p->pr_size is size_t. Theoretical truncation for mappings larger than 4g*1024.
>
> (But I know this coding was there before)
>
>
>
> Beside those points, I think both points of Dmitry are valid.
>
>
>
> Also, I find
>
>
>
>
>
> Kind Regards, Thomas
>
>
>
> On Thu, Mar 10, 2016 at 1:45 PM, Dmitry Dmitriev <HYPERLINK "mailto:dmitry.dmitriev at oracle.com"dmitry.dmitriev at oracle.com> wrote:
>
> Hi Cheleswer,
>
> Looks good, but I have questions/comments about other code in this function:
> 1) I think that "::close(fd);" should be inside "if (fd >= 0) {".
> 2) Just interesting, do you really need to set memory to 0 by memset?
>
> Thanks,
> Dmitry
>
>
> On 10.03.2016 13:43, Cheleswer Sahu wrote:
>
>
> Hi,
>
> Please review the code changes for https://bugs.openjdk.java.net/browse/JDK-8151509.
>
> Webrev link: HYPERLINK "http://cr.openjdk.java.net/%7Ecsahu/8151509/"http://cr.openjdk.java.net/~csahu/8151509/ <http://cr.openjdk.java.net/%7Ecsahu/8151509/>
>
> Bug Brief:
>
> In check_addr0(),  pointer ?p? is not updated correctly, because of this it was reading only first two entries from buffer.
>
> Regards,
>
> Cheleswer
>
>
>
>
>
>
>
>
>

From david.holmes at oracle.com  Mon Mar 14 01:50:14 2016
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 14 Mar 2016 11:50:14 +1000
Subject: RFR[9u-dev]: 8151509: In check_addr0() function pointer is not
	updated correctly
In-Reply-To: <bb6749b1-6e3e-45e2-b96d-111d9a82b799@default>
References: <c136e4ba-60f8-493b-8179-1b8178083a8c@default>
	<56E16C85.30102@oracle.com>
	<CAA-vtUyfV1BiJBXNiO5Qk_=z_ZKGOVx7bvBDOpGuxPXxZ7zhXA@mail.gmail.com>
	<CAA-vtUxJA7FzDaXAvebPdfcCGqCtwrCjt-Hqz_4_snhvGqWB6w@mail.gmail.com>
	<6472a6fc-3197-4f42-927a-2b0ab0663a60@default>
	<56E2AC28.4040306@oracle.com>
	<bb6749b1-6e3e-45e2-b96d-111d9a82b799@default>
Message-ID: <56E618D6.8000207@oracle.com>

PS. Copyright year needs updating.

David

On 11/03/2016 9:38 PM, Cheleswer Sahu wrote:
> Thanks Dmitry and Thomas for reviews. After adding space I will  request for the push.
>
>
>
> Regards,
>
> Cheleswer
>
>
>
> From: Dmitry Dmitriev
> Sent: Friday, March 11, 2016 5:00 PM
> To: Cheleswer Sahu; Thomas St?fe
> Cc: serviceability-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net
> Subject: Re: RFR[9u-dev]: 8151509: In check_addr0() function pointer is not updated correctly
>
>
>
> Hi Cheleswer,
>
> Please, add space between SIZE_FORMAT and " because C++11 requires a space between literal and identifier. Not need a new webrev for that.
>
> Thanks,
> Dmitry
>
>
>
> On 11.03.2016 12:31, Cheleswer Sahu wrote:
>
> Hi Thomas, Dmitry,
>
>
>
> Thanks for your review comments.  My answers are below for your review comments
>
>
>
> 1873       if( 0 != ret % sizeof(prmap_t)){
> 1874         break;
> 1875       }
>
>
>
>
>>> For this it has been thought that mostly read() will return the desired number of bytes, but only in case if something goes wrong and read() will  not able to read the data, it will return lesser number of bytes, which contains the partial data of  ?prmap_t? structure. The reason could be like file is corrupted, in such cases we don?t want to read anymore and feel it?s safe to skip the rest of file.
>
>
>
> 2) Just interesting, do you really need to set memory to 0 by memset?
>
>>>   I thought this it is good to have a clean buffer every time we read something into it, but it?s really not that much required as we are reading a binary data. So I am removing this line from the code.
>
>
>
> For rest of the comments I have made correction in the code. The new webrev is available in the below location
>
> HYPERLINK "http://cr.openjdk.java.net/%7Ecsahu/8151509/webrev.01/"http://cr.openjdk.java.net/~csahu/8151509/webrev.01/
>
>
>
>
>
> Regards,
>
> Cheleswer
>
>
>
> From: Thomas St?fe [mailto:thomas.stuefe at gmail.com]
> Sent: Thursday, March 10, 2016 7:39 PM
> To: Dmitry Dmitriev
> Cc: Cheleswer Sahu; HYPERLINK "mailto:serviceability-dev at openjdk.java.net"serviceability-dev at openjdk.java.net; HYPERLINK "mailto:hotspot-runtime-dev at openjdk.java.net"hotspot-runtime-dev at openjdk.java.net
> Subject: Re: RFR[9u-dev]: 8151509: In check_addr0() function pointer is not updated correctly
>
>
>
> (Sorry, pressed Send button too early)
>
> Just wanted to add that
>
> 1873       if( 0 != ret % sizeof(prmap_t)){
> 1874         break;
> 1875       }
>
> may be a bit harsh, as it skips the entire mapping in case read() stopped reading in a middle of a record. You could just continue to read until you read the rest of the record.
>
> Kind Regards, Thomas
>
>
>
> On Thu, Mar 10, 2016 at 3:07 PM, Thomas St?fe <HYPERLINK "mailto:thomas.stuefe at gmail.com"thomas.stuefe at gmail.com> wrote:
>
> Hi Cheleswer,
>
>
>
> thanks for fixing this.
>
>
>
> Some more issues:
>
>
>
> - 1866 char *mbuff = (char *) calloc(read_chunk, sizeof(prmap_t) + 1);
>
>
>
> Why the "+1"? It is unnecessary and causes the allocation to be 200 bytes larger than necessary.
>
>
>
> - 1880 st->print("Warning: Address: " PTR_FORMAT ", Size: %dK, ",p->pr_vaddr, p->pr_size/1024);
>
>
>
> Format specifier for Size is wrong.%d is int, but p->pr_size is size_t. Theoretical truncation for mappings larger than 4g*1024.
>
> (But I know this coding was there before)
>
>
>
> Beside those points, I think both points of Dmitry are valid.
>
>
>
> Also, I find
>
>
>
>
>
> Kind Regards, Thomas
>
>
>
> On Thu, Mar 10, 2016 at 1:45 PM, Dmitry Dmitriev <HYPERLINK "mailto:dmitry.dmitriev at oracle.com"dmitry.dmitriev at oracle.com> wrote:
>
> Hi Cheleswer,
>
> Looks good, but I have questions/comments about other code in this function:
> 1) I think that "::close(fd);" should be inside "if (fd >= 0) {".
> 2) Just interesting, do you really need to set memory to 0 by memset?
>
> Thanks,
> Dmitry
>
>
> On 10.03.2016 13:43, Cheleswer Sahu wrote:
>
>
> Hi,
>
> Please review the code changes for https://bugs.openjdk.java.net/browse/JDK-8151509.
>
> Webrev link: HYPERLINK "http://cr.openjdk.java.net/%7Ecsahu/8151509/"http://cr.openjdk.java.net/~csahu/8151509/ <http://cr.openjdk.java.net/%7Ecsahu/8151509/>
>
> Bug Brief:
>
> In check_addr0(),  pointer ?p? is not updated correctly, because of this it was reading only first two entries from buffer.
>
> Regards,
>
> Cheleswer
>
>
>
>
>
>
>
>
>

From yasuenag at gmail.com  Mon Mar 14 03:58:52 2016
From: yasuenag at gmail.com (Yasumasa Suenaga)
Date: Mon, 14 Mar 2016 12:58:52 +0900
Subject: RFR: JDK-8151709: jhsdb should show help message in SALauncher.
In-Reply-To: <56E57EBE.5050901@oracle.com>
References: <56E2C790.4020802@gmail.com> <56E428BC.8050108@gmail.com>
	<56E57EBE.5050901@oracle.com>
Message-ID: <56E636FC.5040002@gmail.com>

Hi Dmitry,

I changed for arguments processing in jhsdb in new webrev:
    hotspot: http://cr.openjdk.java.net/~ysuenaga/JDK-8151709/webrev.02/hotspot/
        jdk: http://cr.openjdk.java.net/~ysuenaga/JDK-8151709/webrev.02/jdk/

I encountered ArrayIndexOutOfBoundsException when I ran `jhsdb jstack --pid`.
So I fix its problem.


I guess JDK-8151181: Add JSnap to jhsdb is in progress.
JDK-8151709 is affected it.
So I want to send review request after that.


Thanks,

Yasumasa


On 2016/03/13 23:52, Dmitry Samersoff wrote:
> Yasumasa,
> 
> 1.
> We shouldn't introduce dependency from Tool.java back to SALuancher.
> 
> So please, change runJSTACK (and other similar functions)  to catch
> invalid arguments.
> 
> It might require changing of SAGetopt.java and/or
> jdk/test/sun/tools/jhsdb/SAGetoptTest.java
> 
> 2. For JInfo changes, please create
> 
> private static final int MODE_UNKNOWN = -1;
> 
> 
> -Dmitry
> 
> 
> On 2016-03-12 17:33, Yasumasa Suenaga wrote:
>> I updated webrev:
>>      http://cr.openjdk.java.net/~ysuenaga/JDK-8151709/webrev.01/
>>
>> I added changes for JInfo.java because help message is shown in twice.
>>
>> Please review.
>>
>>
>> Thanks,
>>
>> Yasumasa
>>
>>
>> On 2016/03/11 22:26, Yasumasa Suenaga wrote:
>>> Hi all,
>>>
>>> jhsdb shows error message in each tool implemantation as below:
>>> --------------
>>> $ jhsdb jstack -aaa
>>> Usage: jstack [option] <pid>
>>>                   (to connect to a live java process)
>>>      or jstack [option] <executable> <core>
>>>                   (to connect to a core file)
>>>      or jstack [option] [server_id@]<remote server IP or hostname>
>>>                   (to connect to a remote debug server)
>>>
>>> where option must be one of:
>>>       -l  to print java.util.concurrent locks
>>>       -m  to print both java and native frames (mixed mode)
>>>       -h | -help  to print this help message
>>> --------------
>>>
>>> If we run SA tool via jhsdb, we should get help message of SALauncher as below:
>>> --------------
>>> $ jhsdb jstack -aaa
>>>       --locks     to print java.util.concurrent locks
>>>       --mixed     to print both java and native frames (mixed mode)
>>>       --exe       executable image name
>>>       --core      path to coredump
>>>       --pid       pid of process to attach
>>> --------------
>>>
>>> I uploaded webrev. Could you review it?
>>>       http://cr.openjdk.java.net/~ysuenaga/JDK-8151709/webrev.00/
>>>
>>> I cannot access JPRT.
>>> So I need a Sponsor.
>>>
>>>
>>> Thanks,
>>>
>>> Yasumasa
>>>
> 
> 

From kubota.yuji at gmail.com  Mon Mar 14 05:59:43 2016
From: kubota.yuji at gmail.com (KUBOTA Yuji)
Date: Mon, 14 Mar 2016 14:59:43 +0900
Subject: Check core dumping is enabled when set CrashOnOutOfMemoryError
In-Reply-To: <56E604F6.80505@oracle.com>
References: <CABU-27P4ZvQZio761Q2W8_w0=SXA9p=a3c4HRW9KEq+rVXrEsA@mail.gmail.com>
	<56E604F6.80505@oracle.com>
Message-ID: <CABU-27Px4XsGaXddvUwrrExhNQ2BZ-cu3k0MrHtXNzT2xaYn=g@mail.gmail.com>

Thanks David for looking and comments,

2016-03-14 9:25 GMT+09:00 David Holmes <david.holmes at oracle.com>:
> First I'm not convinced that you necessarily want to enable core dumps just
> because you want to crash on OOM.

Yes, that's right. I just want to avoid the failed of core dumping
when we want it clearly by setting options.

> Second I think anyone setting CrashOnOutOfMemoryError can easily remember to
> set CreateCoredumpOnCrash if they want it.
>
> Third if I was going to force this on then I would do it directly in
> arguments.cpp, not by adding a constraint function.

Thanks for sharing information! I will check the implementation of
CreateCoredumpOnCrash and update my patch to use arguments.cpp.

Thanks,
Yuji

>
> Thanks,
> David
> -----
>
>
>> So I create a patch to check the core dumping, please review it.
>> I do not have an account of openjdk, so I need sponsor.
>>
>> I send to serviceability-dev because JDK-8138745 [1] has been
>> reviewed here. If unfit, please let me know.
>>
>> [1]:Implement ExitOnOutOfMemory and CrashOnOutOfMemory in HotSpot
>>       https://bugs.openjdk.java.net/browse/JDK-8138745
>>
>> diff --git a/src/share/vm/runtime/commandLineFlagConstraintsRuntime.cpp
>> b/src/share/vm/runtime/commandLineFlagConstraintsRuntime.cpp
>> --- a/src/share/vm/runtime/commandLineFlagConstraintsRuntime.cpp
>> +++ b/src/share/vm/runtime/commandLineFlagConstraintsRuntime.cpp
>> @@ -119,6 +119,17 @@
>>     }
>>   }
>>
>> +Flag::Error CrashOnOutOfMemoryErrorFunc(bool value, bool verbose) {
>> +  char buffer[O_BUFLEN];
>> +  os::check_dump_limit(buffer, sizeof(buffer));
>> +  if (!VMError::coredump_status) {
>> +    CommandLineError::print(verbose,
>> +                            "%s\n", VMError::coredump_message);
>> +    return Flag::VIOLATES_CONSTRAINT;
>> +  }
>> +  return Flag::SUCCESS;
>> +}
>> +
>>   Flag::Error PerfDataSamplingIntervalFunc(intx value, bool verbose) {
>>     if ((value % PeriodicTask::interval_gran != 0)) {
>>       CommandLineError::print(verbose,
>> diff --git a/src/share/vm/runtime/commandLineFlagConstraintsRuntime.hpp
>> b/src/share/vm/runtime/commandLineFlagConstraintsRuntime.hpp
>> --- a/src/share/vm/runtime/commandLineFlagConstraintsRuntime.hpp
>> +++ b/src/share/vm/runtime/commandLineFlagConstraintsRuntime.hpp
>> @@ -43,6 +43,8 @@
>>   Flag::Error BiasedLockingBulkRevokeThresholdFunc(intx value, bool
>> verbose);
>>   Flag::Error BiasedLockingDecayTimeFunc(intx value, bool verbose);
>>
>> +Flag::Error CrashOnOutOfMemoryErrorFunc(bool value, bool verbose);
>> +
>>   Flag::Error PerfDataSamplingIntervalFunc(intx value, bool verbose);
>>
>>   #endif /* SHARE_VM_RUNTIME_COMMANDLINEFLAGCONSTRAINTSRUNTIME_HPP */
>> diff --git a/src/share/vm/runtime/globals.hpp
>> b/src/share/vm/runtime/globals.hpp
>> --- a/src/share/vm/runtime/globals.hpp
>> +++ b/src/share/vm/runtime/globals.hpp
>> @@ -1401,6 +1401,7 @@
>>     product(bool, CrashOnOutOfMemoryError, false,
>> \
>>             "JVM aborts, producing an error log and core/mini dump, on the
>> "  \
>>             "first occurrence of an out-of-memory error")
>> \
>> +          constraint(CrashOnOutOfMemoryErrorFunc,AfterErgo)
>> \
>>
>> \
>>     /* tracing */
>> \
>>
>> \
>> diff --git a/src/share/vm/utilities/vmError.hpp
>> b/src/share/vm/utilities/vmError.hpp
>> --- a/src/share/vm/utilities/vmError.hpp
>> +++ b/src/share/vm/utilities/vmError.hpp
>> @@ -65,14 +65,6 @@
>>     // so use thread id instead of Thread* to identify thread.
>>     static volatile intptr_t first_error_tid;
>>
>> -  // Core dump status, false if we have been unable to write a
>> core/minidump for some reason
>> -  static bool coredump_status;
>> -
>> -  // When coredump_status is set to true this will contain the
>> name/path to the core/minidump,
>> -  // if coredump_status if false, this will (hopefully) contain a
>> useful error explaining why
>> -  // no core/minidump has been written to disk
>> -  static char coredump_message[O_BUFLEN];
>> -
>>
>>     // set signal handlers on Solaris/Linux or the default exception
>> filter
>>     // on Windows, to handle recursive crashes.
>> @@ -111,6 +103,14 @@
>>     // Record status of core/minidump
>>     static void record_coredump_status(const char* message, bool status);
>>
>> +  // Core dump status, false if we have been unable to write a
>> core/minidump for some reason
>> +  static bool coredump_status;
>> +
>> +  // When coredump_status is set to true this will contain the
>> name/path to the core/minidump,
>> +  // if coredump_status if false, this will (hopefully) contain a
>> useful error explaining why
>> +  // no core/minidump has been written to disk
>> +  static char coredump_message[O_BUFLEN];
>> +
>>     // support for VM.info diagnostic command
>>     static void print_vm_info(outputStream* st);
>>
>>
>> Thanks,
>> Yuji
>>
>

From david.holmes at oracle.com  Mon Mar 14 06:46:58 2016
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 14 Mar 2016 16:46:58 +1000
Subject: RFR (S): 8137165: Tests fail in SR_Handler because thread is not
	VMThread or JavaThread
Message-ID: <56E65E62.8040003@oracle.com>

Bug: https://bugs.openjdk.java.net/browse/JDK-8137165
Webrev: http://cr.openjdk.java.net/~dholmes/8137165/webrev/

This isn't a fix per-se but some additional diagnostic code to try and 
detect the conditions where the bug might manifest. The basic failure 
mode was:

# Internal Error 
(/opt/jprt/T/P1/175841.hseigel/s/hotspot/src/os/linux/vm/os_linux.cpp:3950), 
pid=27906, tid=13248
# assert(thread->is_VM_thread() || thread->is_Java_thread()) failed: 
Must be VMThread or JavaThread

with a stack showing in part:

#34 0xf6623ec0 in report_vm_error (
     file=0xf71b6140 
"/scratch/opt/jprt/T/P1/205457.cphillim/s/hotspot/src/os/linux/vm/os_linux.cpp", 
line=3901,
     error_msg=0xf71b62e0 "assert(thread->is_VM_thread() || 
thread->is_Java_thread()) failed", detail_fmt=0xf71b62c0 "Must be 
VMThread or JavaThread")
     at 
/scratch/opt/jprt/T/P1/205457.cphillim/s/hotspot/src/share/vm/utilities/debug.cpp:218
#35 0xf6d21b3f in SR_handler (sig=12, siginfo=0xc1b58ccc, 
context=0xc1b58d4c)
     at 
/scratch/opt/jprt/T/P1/205457.cphillim/s/hotspot/src/os/linux/vm/os_linux.cpp:3901
#36 <signal handler called>
#37 0xf776b430 in __kernel_vsyscall ()
#38 0xf773ccef in pthread_sigmask () from /lib/libpthread.so.0
#39 0xf6d23e6c in os::free_thread (osthread=0xc20cf8b8)
     at 
/scratch/opt/jprt/T/P1/205457.cphillim/s/hotspot/src/os/linux/vm/os_linux.cpp:879
#40 0xf6f6811d in Thread::~Thread (this=0xc20cd800, __in_chrg=<optimized 
out>)
     at 
/scratch/opt/jprt/T/P1/205457.cphillim/s/hotspot/src/share/vm/runtime/thread.cpp:367
#41 0xf6f6866f in JavaThread::~JavaThread (this=0xc20cd800,
     __in_chrg=<optimized out>)
     at 
/scratch/opt/jprt/T/P1/205457.cphillim/s/hotspot/src/share/vm/runtime/thread.cpp:1611
#42 0xf6f6877c in JavaThread::~JavaThread (this=0xc20cd800,
     __in_chrg=<optimized out>)
     at 
/scratch/opt/jprt/T/P1/205457.cphillim/s/hotspot/src/share/vm/runtime/thread.cpp:1655
#43 0xf6f74a38 in JavaThread::thread_main_inner (this=0xc20cd800)
     at 
/scratch/opt/jprt/T/P1/205457.cphillim/s/hotspot/src/share/vm/runtime/thread.cpp:1724
#44 0xf6f74e12 in JavaThread::run (this=0xc20cd800)
     at 
/scratch/opt/jprt/T/P1/205457.cphillim/s/hotspot/src/share/vm/runtime/thread.cpp:1698
#45 0xf6d238ec in java_start (thread=0xc20cd800)

What appears to be happening is that the thread has blocked SR_signum 
(SIGUSR2) at some point (though there is no code that does this), and 
the signal has become pending on the thread due to the event sampling 
logic. The thread terminates, executing well into the destructor until 
it gets to os::free_thread which restores the original signal mask for 
the thread - that signal mask has SR_signum unblocked and so the signal 
is delivered immediately and we enter the SR_handler. For some reason 
this triggers the assertion failure - though why exactly is unclear as 
we have not released the thread memory as yet, nor done anything that 
should invalidate that call. Whatever the reason the state of the thread 
causes secondary failures in the error reporting code as well.

Attempts to reproduce this bug have been unsuccessful (so maybe we had a 
random memory stomp on the thread state - who knows.)

So what I am doing is simply adding an additional assertion to try and 
catch, during regular testing, any  occurrence of SR_signum being 
blocked while a thread is terminating.

In addition a couple of minor cleanups in the signal related code:
- strictly speaking SR_handler needs to use 
Thread::current_or_null_safe() because it needs ot use library-based TLS 
in a signal context.
- sigsets should (POSIX recommendation) be explicitly emptied/filled 
before being set via pthread_sigmask
- change 0 to NULL in call to pthread_sigmask

Testing: - JPRT, original failing testcase

Thanks,
David

From kubota.yuji at gmail.com  Mon Mar 14 08:16:33 2016
From: kubota.yuji at gmail.com (KUBOTA Yuji)
Date: Mon, 14 Mar 2016 17:16:33 +0900
Subject: Check core dumping is enabled when set CrashOnOutOfMemoryError
In-Reply-To: <CABU-27Px4XsGaXddvUwrrExhNQ2BZ-cu3k0MrHtXNzT2xaYn=g@mail.gmail.com>
References: <CABU-27P4ZvQZio761Q2W8_w0=SXA9p=a3c4HRW9KEq+rVXrEsA@mail.gmail.com>
	<56E604F6.80505@oracle.com>
	<CABU-27Px4XsGaXddvUwrrExhNQ2BZ-cu3k0MrHtXNzT2xaYn=g@mail.gmail.com>
Message-ID: <CABU-27OgFQdE0_m+zCBMmQNUQjdxCinxaS+tcyC9DFrEpsdR5g@mail.gmail.com>

Hi David,

Sorry, please let discussion a bit more.

2016-03-14 9:25 GMT+09:00 David Holmes <david.holmes at oracle.com>:
> First I'm not convinced that you necessarily want to enable core dumps just
> because you want to crash on OOM.
>
> Second I think anyone setting CrashOnOutOfMemoryError can easily remember to
> set CreateCoredumpOnCrash if they want it.

I think most users do not pay attention about core dumping because
 * CreateCoredumpOnCrash is enabled by default (jdk9/hs-rt).
 * Core images not necessarily needed (except crash).
So we should warn if core dumping is disabled and
CreateCoredumpOnCrash is enabled, but continue to launch jvm.

However, the user who set CrashOnOutOfMemoryError need core images
clearly, so I think jvm should return error if core dumping is
disabled.
For example, I want to use CrashOnOOME instead of HeapDumpOnOOME,
because we can exit jvm definitely and get heapdump and other helpful
information by serviceability tools.

In conclusion, I have two proposals for avoiding the lack of information.
1. Launch jvm with warn message if CreateCoredumpOnCrash is enabled
but core dumping is disabled.
2. 1 + Quit with error message if CrashOnOutOfMemoryError is enabled
but core dumping is disabled.
I think I should implement 2 in arguments.cpp.

Could you share me your thought?

2016-03-14 14:59 GMT+09:00 KUBOTA Yuji <kubota.yuji at gmail.com>:
> Thanks David for looking and comments,
>
> 2016-03-14 9:25 GMT+09:00 David Holmes <david.holmes at oracle.com>:
>> First I'm not convinced that you necessarily want to enable core dumps just
>> because you want to crash on OOM.
>
> Yes, that's right. I just want to avoid the failed of core dumping
> when we want it clearly by setting options.
>
>> Second I think anyone setting CrashOnOutOfMemoryError can easily remember to
>> set CreateCoredumpOnCrash if they want it.
>>
>> Third if I was going to force this on then I would do it directly in
>> arguments.cpp, not by adding a constraint function.
>
> Thanks for sharing information! I will check the implementation of
> CreateCoredumpOnCrash and update my patch to use arguments.cpp.
>
> Thanks,
> Yuji
>
>>
>> Thanks,
>> David
>> -----
>>
>>
>>> So I create a patch to check the core dumping, please review it.
>>> I do not have an account of openjdk, so I need sponsor.
>>>
>>> I send to serviceability-dev because JDK-8138745 [1] has been
>>> reviewed here. If unfit, please let me know.
>>>
>>> [1]:Implement ExitOnOutOfMemory and CrashOnOutOfMemory in HotSpot
>>>       https://bugs.openjdk.java.net/browse/JDK-8138745
>>>
>>> diff --git a/src/share/vm/runtime/commandLineFlagConstraintsRuntime.cpp
>>> b/src/share/vm/runtime/commandLineFlagConstraintsRuntime.cpp
>>> --- a/src/share/vm/runtime/commandLineFlagConstraintsRuntime.cpp
>>> +++ b/src/share/vm/runtime/commandLineFlagConstraintsRuntime.cpp
>>> @@ -119,6 +119,17 @@
>>>     }
>>>   }
>>>
>>> +Flag::Error CrashOnOutOfMemoryErrorFunc(bool value, bool verbose) {
>>> +  char buffer[O_BUFLEN];
>>> +  os::check_dump_limit(buffer, sizeof(buffer));
>>> +  if (!VMError::coredump_status) {
>>> +    CommandLineError::print(verbose,
>>> +                            "%s\n", VMError::coredump_message);
>>> +    return Flag::VIOLATES_CONSTRAINT;
>>> +  }
>>> +  return Flag::SUCCESS;
>>> +}
>>> +
>>>   Flag::Error PerfDataSamplingIntervalFunc(intx value, bool verbose) {
>>>     if ((value % PeriodicTask::interval_gran != 0)) {
>>>       CommandLineError::print(verbose,
>>> diff --git a/src/share/vm/runtime/commandLineFlagConstraintsRuntime.hpp
>>> b/src/share/vm/runtime/commandLineFlagConstraintsRuntime.hpp
>>> --- a/src/share/vm/runtime/commandLineFlagConstraintsRuntime.hpp
>>> +++ b/src/share/vm/runtime/commandLineFlagConstraintsRuntime.hpp
>>> @@ -43,6 +43,8 @@
>>>   Flag::Error BiasedLockingBulkRevokeThresholdFunc(intx value, bool
>>> verbose);
>>>   Flag::Error BiasedLockingDecayTimeFunc(intx value, bool verbose);
>>>
>>> +Flag::Error CrashOnOutOfMemoryErrorFunc(bool value, bool verbose);
>>> +
>>>   Flag::Error PerfDataSamplingIntervalFunc(intx value, bool verbose);
>>>
>>>   #endif /* SHARE_VM_RUNTIME_COMMANDLINEFLAGCONSTRAINTSRUNTIME_HPP */
>>> diff --git a/src/share/vm/runtime/globals.hpp
>>> b/src/share/vm/runtime/globals.hpp
>>> --- a/src/share/vm/runtime/globals.hpp
>>> +++ b/src/share/vm/runtime/globals.hpp
>>> @@ -1401,6 +1401,7 @@
>>>     product(bool, CrashOnOutOfMemoryError, false,
>>> \
>>>             "JVM aborts, producing an error log and core/mini dump, on the
>>> "  \
>>>             "first occurrence of an out-of-memory error")
>>> \
>>> +          constraint(CrashOnOutOfMemoryErrorFunc,AfterErgo)
>>> \
>>>
>>> \
>>>     /* tracing */
>>> \
>>>
>>> \
>>> diff --git a/src/share/vm/utilities/vmError.hpp
>>> b/src/share/vm/utilities/vmError.hpp
>>> --- a/src/share/vm/utilities/vmError.hpp
>>> +++ b/src/share/vm/utilities/vmError.hpp
>>> @@ -65,14 +65,6 @@
>>>     // so use thread id instead of Thread* to identify thread.
>>>     static volatile intptr_t first_error_tid;
>>>
>>> -  // Core dump status, false if we have been unable to write a
>>> core/minidump for some reason
>>> -  static bool coredump_status;
>>> -
>>> -  // When coredump_status is set to true this will contain the
>>> name/path to the core/minidump,
>>> -  // if coredump_status if false, this will (hopefully) contain a
>>> useful error explaining why
>>> -  // no core/minidump has been written to disk
>>> -  static char coredump_message[O_BUFLEN];
>>> -
>>>
>>>     // set signal handlers on Solaris/Linux or the default exception
>>> filter
>>>     // on Windows, to handle recursive crashes.
>>> @@ -111,6 +103,14 @@
>>>     // Record status of core/minidump
>>>     static void record_coredump_status(const char* message, bool status);
>>>
>>> +  // Core dump status, false if we have been unable to write a
>>> core/minidump for some reason
>>> +  static bool coredump_status;
>>> +
>>> +  // When coredump_status is set to true this will contain the
>>> name/path to the core/minidump,
>>> +  // if coredump_status if false, this will (hopefully) contain a
>>> useful error explaining why
>>> +  // no core/minidump has been written to disk
>>> +  static char coredump_message[O_BUFLEN];
>>> +
>>>     // support for VM.info diagnostic command
>>>     static void print_vm_info(outputStream* st);
>>>
>>>
>>> Thanks,
>>> Yuji
>>>
>>

From cheleswer.sahu at oracle.com  Mon Mar 14 09:15:11 2016
From: cheleswer.sahu at oracle.com (Cheleswer Sahu)
Date: Mon, 14 Mar 2016 02:15:11 -0700 (PDT)
Subject: RFR[9u-dev]: 8151509: In check_addr0() function pointer is not
	updated correctly
In-Reply-To: <56E6189A.1010409@oracle.com>
References: <c136e4ba-60f8-493b-8179-1b8178083a8c@default>
	<56E16C85.30102@oracle.com>
	<CAA-vtUyfV1BiJBXNiO5Qk_=z_ZKGOVx7bvBDOpGuxPXxZ7zhXA@mail.gmail.com>
	<CAA-vtUxJA7FzDaXAvebPdfcCGqCtwrCjt-Hqz_4_snhvGqWB6w@mail.gmail.com>
	<6472a6fc-3197-4f42-927a-2b0ab0663a60@default>
	<56E2AC28.4040306@oracle.com>
	<bb6749b1-6e3e-45e2-b96d-111d9a82b799@default>
	<56E6189A.1010409@oracle.com>
Message-ID: <9c3cfd9b-69a3-418f-869b-ec5fcbff6bde@default>

Thanks David.
I have created change-set against hs-rt which is identical to jdk9/dev. Copyright year is already updated in hs-rt file.  Just for reference I have uploaded the latest change-set in the below link.
http://cr.openjdk.java.net/~csahu/8151509/webrev.02/

Thanks ,
Cheleswer 

-----Original Message-----
From: David Holmes 
Sent: Monday, March 14, 2016 7:19 AM
To: Cheleswer Sahu; Dmitry Dmitriev; Thomas St?fe
Cc: serviceability-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net
Subject: Re: RFR[9u-dev]: 8151509: In check_addr0() function pointer is not updated correctly

On 11/03/2016 9:38 PM, Cheleswer Sahu wrote:
> Thanks Dmitry and Thomas for reviews. After adding space I will  request for the push.

Consider this Reviewed.

But this needs to pushed to hs-rt and currently the webrev is against jdk9/dev.

Thanks,
David

>
>
> Regards,
>
> Cheleswer
>
>
>
> From: Dmitry Dmitriev
> Sent: Friday, March 11, 2016 5:00 PM
> To: Cheleswer Sahu; Thomas St?fe
> Cc: serviceability-dev at openjdk.java.net; 
> hotspot-runtime-dev at openjdk.java.net
> Subject: Re: RFR[9u-dev]: 8151509: In check_addr0() function pointer 
> is not updated correctly
>
>
>
> Hi Cheleswer,
>
> Please, add space between SIZE_FORMAT and " because C++11 requires a space between literal and identifier. Not need a new webrev for that.
>
> Thanks,
> Dmitry
>
>
>
> On 11.03.2016 12:31, Cheleswer Sahu wrote:
>
> Hi Thomas, Dmitry,
>
>
>
> Thanks for your review comments.  My answers are below for your review 
> comments
>
>
>
> 1873       if( 0 != ret % sizeof(prmap_t)){
> 1874         break;
> 1875       }
>
>
>
>
>>> For this it has been thought that mostly read() will return the desired number of bytes, but only in case if something goes wrong and read() will  not able to read the data, it will return lesser number of bytes, which contains the partial data of  ?prmap_t? structure. The reason could be like file is corrupted, in such cases we don?t want to read anymore and feel it?s safe to skip the rest of file.
>
>
>
> 2) Just interesting, do you really need to set memory to 0 by memset?
>
>>>   I thought this it is good to have a clean buffer every time we read something into it, but it?s really not that much required as we are reading a binary data. So I am removing this line from the code.
>
>
>
> For rest of the comments I have made correction in the code. The new 
> webrev is available in the below location
>
> HYPERLINK 
> "http://cr.openjdk.java.net/%7Ecsahu/8151509/webrev.01/"http://cr.open
> jdk.java.net/~csahu/8151509/webrev.01/
>
>
>
>
>
> Regards,
>
> Cheleswer
>
>
>
> From: Thomas St?fe [mailto:thomas.stuefe at gmail.com]
> Sent: Thursday, March 10, 2016 7:39 PM
> To: Dmitry Dmitriev
> Cc: Cheleswer Sahu; HYPERLINK 
> "mailto:serviceability-dev at openjdk.java.net"serviceability-dev at openjdk
> .java.net; HYPERLINK 
> "mailto:hotspot-runtime-dev at openjdk.java.net"hotspot-runtime-dev at openj
> dk.java.net
> Subject: Re: RFR[9u-dev]: 8151509: In check_addr0() function pointer 
> is not updated correctly
>
>
>
> (Sorry, pressed Send button too early)
>
> Just wanted to add that
>
> 1873       if( 0 != ret % sizeof(prmap_t)){
> 1874         break;
> 1875       }
>
> may be a bit harsh, as it skips the entire mapping in case read() stopped reading in a middle of a record. You could just continue to read until you read the rest of the record.
>
> Kind Regards, Thomas
>
>
>
> On Thu, Mar 10, 2016 at 3:07 PM, Thomas St?fe <HYPERLINK "mailto:thomas.stuefe at gmail.com"thomas.stuefe at gmail.com> wrote:
>
> Hi Cheleswer,
>
>
>
> thanks for fixing this.
>
>
>
> Some more issues:
>
>
>
> - 1866 char *mbuff = (char *) calloc(read_chunk, sizeof(prmap_t) + 1);
>
>
>
> Why the "+1"? It is unnecessary and causes the allocation to be 200 bytes larger than necessary.
>
>
>
> - 1880 st->print("Warning: Address: " PTR_FORMAT ", Size: %dK, 
> ",p->pr_vaddr, p->pr_size/1024);
>
>
>
> Format specifier for Size is wrong.%d is int, but p->pr_size is size_t. Theoretical truncation for mappings larger than 4g*1024.
>
> (But I know this coding was there before)
>
>
>
> Beside those points, I think both points of Dmitry are valid.
>
>
>
> Also, I find
>
>
>
>
>
> Kind Regards, Thomas
>
>
>
> On Thu, Mar 10, 2016 at 1:45 PM, Dmitry Dmitriev <HYPERLINK "mailto:dmitry.dmitriev at oracle.com"dmitry.dmitriev at oracle.com> wrote:
>
> Hi Cheleswer,
>
> Looks good, but I have questions/comments about other code in this function:
> 1) I think that "::close(fd);" should be inside "if (fd >= 0) {".
> 2) Just interesting, do you really need to set memory to 0 by memset?
>
> Thanks,
> Dmitry
>
>
> On 10.03.2016 13:43, Cheleswer Sahu wrote:
>
>
> Hi,
>
> Please review the code changes for https://bugs.openjdk.java.net/browse/JDK-8151509.
>
> Webrev link: HYPERLINK 
> "http://cr.openjdk.java.net/%7Ecsahu/8151509/"http://cr.openjdk.java.n
> et/~csahu/8151509/ <http://cr.openjdk.java.net/%7Ecsahu/8151509/>
>
> Bug Brief:
>
> In check_addr0(),  pointer ?p? is not updated correctly, because of this it was reading only first two entries from buffer.
>
> Regards,
>
> Cheleswer
>
>
>
>
>
>
>
>
>

From marcus.larsson at oracle.com  Mon Mar 14 10:29:56 2016
From: marcus.larsson at oracle.com (Marcus Larsson)
Date: Mon, 14 Mar 2016 11:29:56 +0100
Subject: RFR: 8146879: Add option for handling existing log files in UL
In-Reply-To: <56E54911.9090807@oracle.com>
References: <5697B7F2.50104@oracle.com> <56D578F9.6090602@oracle.com>
	<56D5A1BB.6030403@oracle.com> <56E2D478.3090202@oracle.com>
	<56E2D7AA.1060803@oracle.com> <56E2D8AD.8040902@oracle.com>
	<56E54911.9090807@oracle.com>
Message-ID: <56E692A4.6010204@oracle.com>

Hi,

Thanks for looking at this!

On 03/13/2016 12:03 PM, Dmitry Samersoff wrote:
> Marcus,
>
> 1. os_posix/os_windows.cpp
>
> Windows version is expensive and change access time of a log file.
>
> So it's better to create os::get_mtime() that uses stat() for both,
> windows and posix and LogFileOutput::calc_mtime_diff().
>
> Also it saves a bit of compiler power unrolling loop.

This is similar to my first approach but I ran into problems with it 
because st_mtime is a struct timespec on posix and a time_t on windows. 
 From the start I wanted better precision than seconds, which is why I 
wanted to use CompareFileTime(). Given that we can not depend on any 
particular precision, perhaps it's better to just use stat() on windows 
as well, like you say.

>
> 2. log.cpp
>
> size_t number_of_lines_with_substring_in_file()
>
> When you plan to use it ? Current implementation is rather expensive,
> but if you plan to run it manually only, I'm OK with it.

It's used for testing only.

>
> 3. logFileOutput.cpp
>
> 82.
> Please, change file_exists to can_be_rotated() and check that log output
> is a *regular file* and you have a write access to it.

I guess it would be useful to give an error in the case someone 
specifies logging to something that's not a regular file. Checking for 
write permissions shouldn't be necessary here though. If any of the 
required operations fail because of lacking permissions we'll notice 
that at that time.

>
> 87.
> Please, don't use floating point math. Just allocate 10 extra bytes, it
> fit all possible file length value.

I can use a fixed size for the allocations, but we will still want to 
figure out how many numbers should be used so that we can use the 
appropriate amount of padding. Logging with 10 files in rotation should 
use log.0 to log.9, not log.0000000 to log.0000009.

>
> 93.
> if we have log.01, log.03 etc this function creates log.02 instead of
> log.04.

Yes, that's intentional.

>
> Sorry! I'm not follow logic of ll.118
> What happens if some log parsing tool change log file mtime?

We'll always prefer to overwrite the file that hasn't been modified for 
the longest time.

>
> Please, limit the number of old logs (FileCountOption) to some
> reasonable value (e.g. 999) and use binary search to find the name of a
> next file.

I can limit it, but I'm not sure we should make the effort of binary 
searching for the file name. It's a one time search during startup and I 
would expect most people to use around 10 files.

>
> Also please check full log file name against MAX_PATH constant.

Is it really necessary? Won't fopen() just fail and return the 
appropriate error for this?

Thanks,
Marcus

>
> -Dmitry
>
>
>
>
> On 2016-03-11 17:39, Marcus Larsson wrote:
>> Hi,
>>
>> On 2016-03-11 15:35, Bengt Rutisson wrote:
>>> Hi Marcus,
>>>
>>> On 2016-03-11 15:21, Marcus Larsson wrote:
>>>> Third time's the charm.
>>>>
>>>> Webrev:
>>>> http://cr.openjdk.java.net/~mlarsson/8146879/webrev.03/
>>> I had a quick look at the code changes. It is not really my area of
>>> the code, so I'll leave to someone else to formally review it.
>>>
>>> However, I downloaded the patch a played a bit with the logging. This
>>> is much more like the way I would like it! Thanks!
>>>
>>> So, from a functional perspective this looks good to me.
>>>
>> Thanks for the feedback!
>>
>> Marcus
>>
>>> Thanks,
>>> Bengt
>>>
>>>> This patch makes log file rotation the default. Default thresholds
>>>> are 5 rotated files with a target size of 20MiB. Truncating behavior
>>>> can be achieved by setting filecount to 0
>>>> (-Xlog::myfile.log::filecount=0).
>>>>
>>>> If a log file already exists during log file initialization it will
>>>> be rotated. If any of the target file names (file.0 to file.4 in the
>>>> default case) are available, that filename will be used for the
>>>> existing log. If all names are taken the VM will attempt to overwrite
>>>> the oldest file.
>>>>
>>>> This should prevent unlimited log file creations and avoid accidental
>>>> loss of log files from previous runs. The default thresholds (5
>>>> files, 20MiB each) is just a suggestion. If you think it should be
>>>> higher/lower let me know.
>>>>
>>>> Tested with included internal VM tests through RBT.
>>>>
>>>> Thanks,
>>>> Marcus
>>>>
>>>> On 2016-03-01 15:05, Marcus Larsson wrote:
>>>>> Hi,
>>>>>
>>>>> After some offline discussions I'm withdrawing this patch. I will
>>>>> instead investigate if I can achieve similar behavior using log
>>>>> rotation as the default.
>>>>>
>>>>> Thanks,
>>>>> Marcus
>>>>>
>>>>> On 03/01/2016 12:11 PM, Marcus Larsson wrote:
>>>>>> Hi again,
>>>>>>
>>>>>> Taking a different approach to this.
>>>>>>
>>>>>> New webrev:
>>>>>> http://cr.openjdk.java.net/~mlarsson/8146879/webrev.01/
>>>>>>
>>>>>> Existing files will now by default be renamed/archived with a .X
>>>>>> suffix where X is the lowest number such that the resulting file
>>>>>> name is available (jvm.log becomes jvm.log.0). A mode option for
>>>>>> controlling this behavior has been added as well. It can be set to
>>>>>> archive, append, or truncate (i.e. -Xlog::jvm.log::mode=truncate).
>>>>>>
>>>>>> Tested with included jtreg test through JPRT.
>>>>>>
>>>>>> Thanks,
>>>>>> Marcus
>>>>>>
>>>>>> On 01/14/2016 04:00 PM, Marcus Larsson wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> Please review the following patch to make sure UL truncates
>>>>>>> existing log files before writing to them. Since files are opened
>>>>>>> in append mode, truncation isn't done automatically, so instead
>>>>>>> the patch adds an attempt to remove the log file before opening it.
>>>>>>>
>>>>>>> Webrev:
>>>>>>> http://cr.openjdk.java.net/~mlarsson/8146879/webrev.00/
>>>>>>>
>>>>>>> Issue:
>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8146879
>>>>>>>
>>>>>>> Testing:
>>>>>>> Included test through JPRT
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Marcus
>


From marcus.larsson at oracle.com  Mon Mar 14 10:34:16 2016
From: marcus.larsson at oracle.com (Marcus Larsson)
Date: Mon, 14 Mar 2016 11:34:16 +0100
Subject: RFR: 8146879: Add option for handling existing log files in UL
In-Reply-To: <56E2E95B.8050500@oracle.com>
References: <5697B7F2.50104@oracle.com> <56D578F9.6090602@oracle.com>
	<56D5A1BB.6030403@oracle.com> <56E2D478.3090202@oracle.com>
	<56E2E95B.8050500@oracle.com>
Message-ID: <56E693A8.8010108@oracle.com>

Hi,

On 03/11/2016 04:50 PM, Robbin Ehn wrote:
> Hi Marcus,
>
> Two small things.
>
> src/share/vm/runtime/os.hpp:
> +  static int compare_file_modified_times(const char* file1, const 
> char* file2);
> Is this so generic that we should have it os.[h,c]pp?
> E.g. if we want to compare ctime, etc.. ?

I didn't want to add a bunch of unused functionality for this so I kept 
it simple. If we need ctime or atime at a later point I think we should 
just refactor this or add it separately.

>
> On 03/11/2016 03:21 PM, Marcus Larsson wrote:
>> Third time's the charm.
>>
>> Webrev:
>> http://cr.openjdk.java.net/~mlarsson/8146879/webrev.03/
>>
>> This patch makes log file rotation the default. Default thresholds are 5
>> rotated files with a target size of 20MiB. Truncating behavior can be
>> achieved by setting filecount to 0 (-Xlog::myfile.log::filecount=0).
>
> src/share/vm/logging/logFileOutput.hpp:
> + static const size_t DefaultRotationFileSize = 2097152; // 20MiB
> Missing a 0 here, I prefer to write this as 20*1024*1024

Great catch! I'll change this to use the M constant, making it 20*M.

>
>>
>> If a log file already exists during log file initialization it will be
>> rotated. If any of the target file names (file.0 to file.4 in the
>> default case) are available, that filename will be used for the existing
>> log. If all names are taken the VM will attempt to overwrite the oldest
>> file.
>>
>> This should prevent unlimited log file creations and avoid accidental
>> loss of log files from previous runs. The default thresholds (5 files,
>> 20MiB each) is just a suggestion. If you think it should be higher/lower
>> let me know.
>>
>> Tested with included internal VM tests through RBT.
>
> I also functional tested this and it works as intended.
> There is an issue regarding removing the current log file.
> Discussed in side-channel it will be handled outside this CS since it 
> not directly related.
>
> Otherwise looks good!

Thanks for looking at it!
Marcus

>
> /Robbin
>
>>
>> Thanks,
>> Marcus
>>
>> On 2016-03-01 15:05, Marcus Larsson wrote:
>>> Hi,
>>>
>>> After some offline discussions I'm withdrawing this patch. I will
>>> instead investigate if I can achieve similar behavior using log
>>> rotation as the default.
>>>
>>> Thanks,
>>> Marcus
>>>
>>> On 03/01/2016 12:11 PM, Marcus Larsson wrote:
>>>> Hi again,
>>>>
>>>> Taking a different approach to this.
>>>>
>>>> New webrev:
>>>> http://cr.openjdk.java.net/~mlarsson/8146879/webrev.01/
>>>>
>>>> Existing files will now by default be renamed/archived with a .X
>>>> suffix where X is the lowest number such that the resulting file name
>>>> is available (jvm.log becomes jvm.log.0). A mode option for
>>>> controlling this behavior has been added as well. It can be set to
>>>> archive, append, or truncate (i.e. -Xlog::jvm.log::mode=truncate).
>>>>
>>>> Tested with included jtreg test through JPRT.
>>>>
>>>> Thanks,
>>>> Marcus
>>>>
>>>> On 01/14/2016 04:00 PM, Marcus Larsson wrote:
>>>>> Hi,
>>>>>
>>>>> Please review the following patch to make sure UL truncates existing
>>>>> log files before writing to them. Since files are opened in append
>>>>> mode, truncation isn't done automatically, so instead the patch adds
>>>>> an attempt to remove the log file before opening it.
>>>>>
>>>>> Webrev:
>>>>> http://cr.openjdk.java.net/~mlarsson/8146879/webrev.00/
>>>>>
>>>>> Issue:
>>>>> https://bugs.openjdk.java.net/browse/JDK-8146879
>>>>>
>>>>> Testing:
>>>>> Included test through JPRT
>>>>>
>>>>> Thanks,
>>>>> Marcus
>>>>
>>>
>>


From marcus.larsson at oracle.com  Mon Mar 14 10:52:41 2016
From: marcus.larsson at oracle.com (Marcus Larsson)
Date: Mon, 14 Mar 2016 11:52:41 +0100
Subject: RFR: 8146879: Add option for handling existing log files in UL
In-Reply-To: <D794E59F-5B0F-463E-A855-1F185330BD27@oracle.com>
References: <5697B7F2.50104@oracle.com> <56D578F9.6090602@oracle.com>
	<56D5A1BB.6030403@oracle.com> <56E2D478.3090202@oracle.com>
	<D794E59F-5B0F-463E-A855-1F185330BD27@oracle.com>
Message-ID: <56E697F9.7020301@oracle.com>

Hi,

On 03/11/2016 05:40 PM, Gerard Ziemski wrote:
> hi Marcus,
>
> I?m still going through the webrev, but I thought I would report my feedback so far.

Thanks for looking at this!

>
> ------------------------------------------------
> #1 File src/os/posix/vm/os_posix.cpp
>
> How about instead of:
>
> +int os::compare_file_modified_times(const char* file1, const char* file2) {
> +  struct stat st[2];
> +  struct timespec filetime[2];
> +
> +  for (int i = 0; i < 2; i++) {
> +    const char* file = (i == 0 ? file1 : file2);
> +    int ret = os::stat(file, &st[i]);
> +    assert(ret == 0, "failed to stat() file '%s': %s", file, strerror(errno));
> +#ifdef __APPLE__
> +    filetime[i] = st[i].st_mtimespec;
> +#else
> +    filetime[i] = st[i].st_mtim;
> +#endif
> +  }
> +
> +  int diff = filetime[0].tv_sec - filetime[1].tv_sec;
> +  if (diff == 0) {
> +    return filetime[0].tv_nsec - filetime[1].tv_nsec;
> +  }
> +  return diff;
> +}
>
> we have something like this, which doesn?t use arrays or a loop mimicking inline function:
>
> static inline struct timespec get_timespec(const char* file) {
>    struct stat st;
>    int ret = stat(file, &st);
>    assert(ret == 0, "failed to stat() file '%s': %s", file, strerror(errno));
>    #ifdef __APPLE__
>      return st.st_mtimespec;
>    #else
>      return st.st_mtim;
>    #endif
> }
>
> int compare_file_modified_times(const char* file1, const char* file2) {
>    struct timespec filetime1 = get_timespec(file1);
>    struct timespec filetime2 = get_timespec(file2);
>    int diff = filetime1.tv_sec - filetime2.tv_sec;
>    if (diff == 0) {
>       return filetime1.tv_nsec - filetime2.tv_nsec;
>    }
>    return diff;
> }
>
> Similarly we should use static inline function instead of a loop in src/os/windows/vm/os_windows.cpp

Good suggestions, will update.

>
> -----------------------------------------------
> #2 File src/share/vm/logging/log.cpp
>
> Doesn?t this function produce an error or at least a warning on a product build without asserts?
>
> +static void delete_file(const char* filename) {
> +  if (!file_exists(filename)) {
> +    return;
> +  }
> +  int ret = remove(filename);
> +  assert(ret == 0, "failed to remove file '%s': %s", filename, strerror(errno));
> +}

I haven't run in to any problems with this. I'm guessing I should've 
failed to build in JPRT if this was a problem, given that we treat 
warnings as errors.

>
> -----------------------------------------------
> #3 File src/share/vm/logging/log.cpp
>
> The number_of_lines_with_substring_in_file() function will not count the substrings that happen to lay across the boundary at sizeof(buf). For example with:
>
>   char buf[16];
>
> and file consisting of ?12345678901234gerard1234567890? it will return 0 for number_of_lines_with_substring_in_file(file, ?gerard")

Yeah I'm aware of this limitation. It's only used in the test though, 
where I'm hoping it won't be a problem. Would a comment about this be 
enough?

>
> -----------------------------------------------
> #4 File src/share/vm/logging/log.cpp
>
> Should we clarify that we are rounding the results of log10 down by explicitly using floor and explicitly casting it to uint?
>
> static uint number_of_digits_new(uint number) {
>    double d = static_cast<double>(number);
>    uint res = 1 + static_cast<uint>(floor(log10(d)));
>    return res;
> }
>
> cheers

Seems like a good idea to me.

Thanks,
Marcus

>
>
>> On Mar 11, 2016, at 8:21 AM, Marcus Larsson <marcus.larsson at oracle.com> wrote:
>>
>> Third time's the charm.
>>
>> Webrev:
>> http://cr.openjdk.java.net/~mlarsson/8146879/webrev.03/
>>
>> This patch makes log file rotation the default. Default thresholds are 5 rotated files with a target size of 20MiB. Truncating behavior can be achieved by setting filecount to 0 (-Xlog::myfile.log::filecount=0).
>>
>> If a log file already exists during log file initialization it will be rotated. If any of the target file names (file.0 to file.4 in the default case) are available, that filename will be used for the existing log. If all names are taken the VM will attempt to overwrite the oldest file.
>>
>> This should prevent unlimited log file creations and avoid accidental loss of log files from previous runs. The default thresholds (5 files, 20MiB each) is just a suggestion. If you think it should be higher/lower let me know.
>>
>> Tested with included internal VM tests through RBT.
>>
>> Thanks,
>> Marcus
>>
>> On 2016-03-01 15:05, Marcus Larsson wrote:
>>> Hi,
>>>
>>> After some offline discussions I'm withdrawing this patch. I will instead investigate if I can achieve similar behavior using log rotation as the default.
>>>
>>> Thanks,
>>> Marcus
>>>
>>> On 03/01/2016 12:11 PM, Marcus Larsson wrote:
>>>> Hi again,
>>>>
>>>> Taking a different approach to this.
>>>>
>>>> New webrev:
>>>> http://cr.openjdk.java.net/~mlarsson/8146879/webrev.01/
>>>>
>>>> Existing files will now by default be renamed/archived with a .X suffix where X is the lowest number such that the resulting file name is available (jvm.log becomes jvm.log.0). A mode option for controlling this behavior has been added as well. It can be set to archive, append, or truncate (i.e. -Xlog::jvm.log::mode=truncate).
>>>>
>>>> Tested with included jtreg test through JPRT.
>>>>
>>>> Thanks,
>>>> Marcus
>>>>
>>>> On 01/14/2016 04:00 PM, Marcus Larsson wrote:
>>>>> Hi,
>>>>>
>>>>> Please review the following patch to make sure UL truncates existing log files before writing to them. Since files are opened in append mode, truncation isn't done automatically, so instead the patch adds an attempt to remove the log file before opening it.
>>>>>
>>>>> Webrev:
>>>>> http://cr.openjdk.java.net/~mlarsson/8146879/webrev.00/
>>>>>
>>>>> Issue:
>>>>> https://bugs.openjdk.java.net/browse/JDK-8146879
>>>>>
>>>>> Testing:
>>>>> Included test through JPRT
>>>>>
>>>>> Thanks,
>>>>> Marcus


From david.holmes at oracle.com  Mon Mar 14 12:20:46 2016
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 14 Mar 2016 22:20:46 +1000
Subject: RFR[9u-dev]: 8151509: In check_addr0() function pointer is not
	updated correctly
In-Reply-To: <9c3cfd9b-69a3-418f-869b-ec5fcbff6bde@default>
References: <c136e4ba-60f8-493b-8179-1b8178083a8c@default>
	<56E16C85.30102@oracle.com>
	<CAA-vtUyfV1BiJBXNiO5Qk_=z_ZKGOVx7bvBDOpGuxPXxZ7zhXA@mail.gmail.com>
	<CAA-vtUxJA7FzDaXAvebPdfcCGqCtwrCjt-Hqz_4_snhvGqWB6w@mail.gmail.com>
	<6472a6fc-3197-4f42-927a-2b0ab0663a60@default>
	<56E2AC28.4040306@oracle.com>
	<bb6749b1-6e3e-45e2-b96d-111d9a82b799@default>
	<56E6189A.1010409@oracle.com>
	<9c3cfd9b-69a3-418f-869b-ec5fcbff6bde@default>
Message-ID: <56E6AC9E.8070605@oracle.com>

On 14/03/2016 7:15 PM, Cheleswer Sahu wrote:
> Thanks David.
> I have created change-set against hs-rt which is identical to jdk9/dev. Copyright year is already updated in hs-rt file.  Just for reference I have uploaded the latest change-set in the below link.
> http://cr.openjdk.java.net/~csahu/8151509/webrev.02/

Looks good.

Thanks,
David

> Thanks ,
> Cheleswer
>
> -----Original Message-----
> From: David Holmes
> Sent: Monday, March 14, 2016 7:19 AM
> To: Cheleswer Sahu; Dmitry Dmitriev; Thomas St?fe
> Cc: serviceability-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net
> Subject: Re: RFR[9u-dev]: 8151509: In check_addr0() function pointer is not updated correctly
>
> On 11/03/2016 9:38 PM, Cheleswer Sahu wrote:
>> Thanks Dmitry and Thomas for reviews. After adding space I will  request for the push.
>
> Consider this Reviewed.
>
> But this needs to pushed to hs-rt and currently the webrev is against jdk9/dev.
>
> Thanks,
> David
>
>>
>>
>> Regards,
>>
>> Cheleswer
>>
>>
>>
>> From: Dmitry Dmitriev
>> Sent: Friday, March 11, 2016 5:00 PM
>> To: Cheleswer Sahu; Thomas St?fe
>> Cc: serviceability-dev at openjdk.java.net;
>> hotspot-runtime-dev at openjdk.java.net
>> Subject: Re: RFR[9u-dev]: 8151509: In check_addr0() function pointer
>> is not updated correctly
>>
>>
>>
>> Hi Cheleswer,
>>
>> Please, add space between SIZE_FORMAT and " because C++11 requires a space between literal and identifier. Not need a new webrev for that.
>>
>> Thanks,
>> Dmitry
>>
>>
>>
>> On 11.03.2016 12:31, Cheleswer Sahu wrote:
>>
>> Hi Thomas, Dmitry,
>>
>>
>>
>> Thanks for your review comments.  My answers are below for your review
>> comments
>>
>>
>>
>> 1873       if( 0 != ret % sizeof(prmap_t)){
>> 1874         break;
>> 1875       }
>>
>>
>>
>>
>>>> For this it has been thought that mostly read() will return the desired number of bytes, but only in case if something goes wrong and read() will  not able to read the data, it will return lesser number of bytes, which contains the partial data of  ?prmap_t? structure. The reason could be like file is corrupted, in such cases we don?t want to read anymore and feel it?s safe to skip the rest of file.
>>
>>
>>
>> 2) Just interesting, do you really need to set memory to 0 by memset?
>>
>>>>    I thought this it is good to have a clean buffer every time we read something into it, but it?s really not that much required as we are reading a binary data. So I am removing this line from the code.
>>
>>
>>
>> For rest of the comments I have made correction in the code. The new
>> webrev is available in the below location
>>
>> HYPERLINK
>> "http://cr.openjdk.java.net/%7Ecsahu/8151509/webrev.01/"http://cr.open
>> jdk.java.net/~csahu/8151509/webrev.01/
>>
>>
>>
>>
>>
>> Regards,
>>
>> Cheleswer
>>
>>
>>
>> From: Thomas St?fe [mailto:thomas.stuefe at gmail.com]
>> Sent: Thursday, March 10, 2016 7:39 PM
>> To: Dmitry Dmitriev
>> Cc: Cheleswer Sahu; HYPERLINK
>> "mailto:serviceability-dev at openjdk.java.net"serviceability-dev at openjdk
>> .java.net; HYPERLINK
>> "mailto:hotspot-runtime-dev at openjdk.java.net"hotspot-runtime-dev at openj
>> dk.java.net
>> Subject: Re: RFR[9u-dev]: 8151509: In check_addr0() function pointer
>> is not updated correctly
>>
>>
>>
>> (Sorry, pressed Send button too early)
>>
>> Just wanted to add that
>>
>> 1873       if( 0 != ret % sizeof(prmap_t)){
>> 1874         break;
>> 1875       }
>>
>> may be a bit harsh, as it skips the entire mapping in case read() stopped reading in a middle of a record. You could just continue to read until you read the rest of the record.
>>
>> Kind Regards, Thomas
>>
>>
>>
>> On Thu, Mar 10, 2016 at 3:07 PM, Thomas St?fe <HYPERLINK "mailto:thomas.stuefe at gmail.com"thomas.stuefe at gmail.com> wrote:
>>
>> Hi Cheleswer,
>>
>>
>>
>> thanks for fixing this.
>>
>>
>>
>> Some more issues:
>>
>>
>>
>> - 1866 char *mbuff = (char *) calloc(read_chunk, sizeof(prmap_t) + 1);
>>
>>
>>
>> Why the "+1"? It is unnecessary and causes the allocation to be 200 bytes larger than necessary.
>>
>>
>>
>> - 1880 st->print("Warning: Address: " PTR_FORMAT ", Size: %dK,
>> ",p->pr_vaddr, p->pr_size/1024);
>>
>>
>>
>> Format specifier for Size is wrong.%d is int, but p->pr_size is size_t. Theoretical truncation for mappings larger than 4g*1024.
>>
>> (But I know this coding was there before)
>>
>>
>>
>> Beside those points, I think both points of Dmitry are valid.
>>
>>
>>
>> Also, I find
>>
>>
>>
>>
>>
>> Kind Regards, Thomas
>>
>>
>>
>> On Thu, Mar 10, 2016 at 1:45 PM, Dmitry Dmitriev <HYPERLINK "mailto:dmitry.dmitriev at oracle.com"dmitry.dmitriev at oracle.com> wrote:
>>
>> Hi Cheleswer,
>>
>> Looks good, but I have questions/comments about other code in this function:
>> 1) I think that "::close(fd);" should be inside "if (fd >= 0) {".
>> 2) Just interesting, do you really need to set memory to 0 by memset?
>>
>> Thanks,
>> Dmitry
>>
>>
>> On 10.03.2016 13:43, Cheleswer Sahu wrote:
>>
>>
>> Hi,
>>
>> Please review the code changes for https://bugs.openjdk.java.net/browse/JDK-8151509.
>>
>> Webrev link: HYPERLINK
>> "http://cr.openjdk.java.net/%7Ecsahu/8151509/"http://cr.openjdk.java.n
>> et/~csahu/8151509/ <http://cr.openjdk.java.net/%7Ecsahu/8151509/>
>>
>> Bug Brief:
>>
>> In check_addr0(),  pointer ?p? is not updated correctly, because of this it was reading only first two entries from buffer.
>>
>> Regards,
>>
>> Cheleswer
>>
>>
>>
>>
>>
>>
>>
>>
>>

From robbin.ehn at oracle.com  Mon Mar 14 13:34:42 2016
From: robbin.ehn at oracle.com (Robbin Ehn)
Date: Mon, 14 Mar 2016 14:34:42 +0100
Subject: RFR (S): 8137165: Tests fail in SR_Handler because thread is not
	VMThread or JavaThread
In-Reply-To: <56E65E62.8040003@oracle.com>
References: <56E65E62.8040003@oracle.com>
Message-ID: <56E6BDF2.2010201@oracle.com>

Hi David,

On 03/14/2016 07:46 AM, David Holmes wrote:
> Bug: https://bugs.openjdk.java.net/browse/JDK-8137165
> Webrev: http://cr.openjdk.java.net/~dholmes/8137165/webrev/

This looks good to me.

/Robbin

>
> This isn't a fix per-se but some additional diagnostic code to try and
> detect the conditions where the bug might manifest. The basic failure
> mode was:
>
> # Internal Error
> (/opt/jprt/T/P1/175841.hseigel/s/hotspot/src/os/linux/vm/os_linux.cpp:3950),
> pid=27906, tid=13248
> # assert(thread->is_VM_thread() || thread->is_Java_thread()) failed:
> Must be VMThread or JavaThread
>
> with a stack showing in part:
>
> #34 0xf6623ec0 in report_vm_error (
>      file=0xf71b6140
> "/scratch/opt/jprt/T/P1/205457.cphillim/s/hotspot/src/os/linux/vm/os_linux.cpp",
> line=3901,
>      error_msg=0xf71b62e0 "assert(thread->is_VM_thread() ||
> thread->is_Java_thread()) failed", detail_fmt=0xf71b62c0 "Must be
> VMThread or JavaThread")
>      at
> /scratch/opt/jprt/T/P1/205457.cphillim/s/hotspot/src/share/vm/utilities/debug.cpp:218
>
> #35 0xf6d21b3f in SR_handler (sig=12, siginfo=0xc1b58ccc,
> context=0xc1b58d4c)
>      at
> /scratch/opt/jprt/T/P1/205457.cphillim/s/hotspot/src/os/linux/vm/os_linux.cpp:3901
>
> #36 <signal handler called>
> #37 0xf776b430 in __kernel_vsyscall ()
> #38 0xf773ccef in pthread_sigmask () from /lib/libpthread.so.0
> #39 0xf6d23e6c in os::free_thread (osthread=0xc20cf8b8)
>      at
> /scratch/opt/jprt/T/P1/205457.cphillim/s/hotspot/src/os/linux/vm/os_linux.cpp:879
>
> #40 0xf6f6811d in Thread::~Thread (this=0xc20cd800, __in_chrg=<optimized
> out>)
>      at
> /scratch/opt/jprt/T/P1/205457.cphillim/s/hotspot/src/share/vm/runtime/thread.cpp:367
>
> #41 0xf6f6866f in JavaThread::~JavaThread (this=0xc20cd800,
>      __in_chrg=<optimized out>)
>      at
> /scratch/opt/jprt/T/P1/205457.cphillim/s/hotspot/src/share/vm/runtime/thread.cpp:1611
>
> #42 0xf6f6877c in JavaThread::~JavaThread (this=0xc20cd800,
>      __in_chrg=<optimized out>)
>      at
> /scratch/opt/jprt/T/P1/205457.cphillim/s/hotspot/src/share/vm/runtime/thread.cpp:1655
>
> #43 0xf6f74a38 in JavaThread::thread_main_inner (this=0xc20cd800)
>      at
> /scratch/opt/jprt/T/P1/205457.cphillim/s/hotspot/src/share/vm/runtime/thread.cpp:1724
>
> #44 0xf6f74e12 in JavaThread::run (this=0xc20cd800)
>      at
> /scratch/opt/jprt/T/P1/205457.cphillim/s/hotspot/src/share/vm/runtime/thread.cpp:1698
>
> #45 0xf6d238ec in java_start (thread=0xc20cd800)
>
> What appears to be happening is that the thread has blocked SR_signum
> (SIGUSR2) at some point (though there is no code that does this), and
> the signal has become pending on the thread due to the event sampling
> logic. The thread terminates, executing well into the destructor until
> it gets to os::free_thread which restores the original signal mask for
> the thread - that signal mask has SR_signum unblocked and so the signal
> is delivered immediately and we enter the SR_handler. For some reason
> this triggers the assertion failure - though why exactly is unclear as
> we have not released the thread memory as yet, nor done anything that
> should invalidate that call. Whatever the reason the state of the thread
> causes secondary failures in the error reporting code as well.
>
> Attempts to reproduce this bug have been unsuccessful (so maybe we had a
> random memory stomp on the thread state - who knows.)
>
> So what I am doing is simply adding an additional assertion to try and
> catch, during regular testing, any  occurrence of SR_signum being
> blocked while a thread is terminating.
>
> In addition a couple of minor cleanups in the signal related code:
> - strictly speaking SR_handler needs to use
> Thread::current_or_null_safe() because it needs ot use library-based TLS
> in a signal context.
> - sigsets should (POSIX recommendation) be explicitly emptied/filled
> before being set via pthread_sigmask
> - change 0 to NULL in call to pthread_sigmask
>
> Testing: - JPRT, original failing testcase
>
> Thanks,
> David

From yasuenag at gmail.com  Mon Mar 14 14:12:09 2016
From: yasuenag at gmail.com (Yasumasa Suenaga)
Date: Mon, 14 Mar 2016 23:12:09 +0900
Subject: RFR: JDK-8151709: jhsdb should show help message in SALauncher.
In-Reply-To: <56E636FC.5040002@gmail.com>
References: <56E2C790.4020802@gmail.com> <56E428BC.8050108@gmail.com>
	<56E57EBE.5050901@oracle.com> <56E636FC.5040002@gmail.com>
Message-ID: <56E6C6B9.5010708@gmail.com>

Hi,

> I guess JDK-8151181: Add JSnap to jhsdb is in progress.
> JDK-8151709 is affected it.
> So I want to send review request after that.

JDK-8151181 is merged.
So I uploaded new webrev. Could you review it?

  hotspot: http://cr.openjdk.java.net/~ysuenaga/JDK-8151709/webrev.03/hotspot/
      jdk: http://cr.openjdk.java.net/~ysuenaga/JDK-8151709/webrev.03/jdk/


Thanks,

Yasumasa


On 2016/03/14 12:58, Yasumasa Suenaga wrote:
> Hi Dmitry,
> 
> I changed for arguments processing in jhsdb in new webrev:
>      hotspot: http://cr.openjdk.java.net/~ysuenaga/JDK-8151709/webrev.02/hotspot/
>          jdk: http://cr.openjdk.java.net/~ysuenaga/JDK-8151709/webrev.02/jdk/
> 
> I encountered ArrayIndexOutOfBoundsException when I ran `jhsdb jstack --pid`.
> So I fix its problem.
> 
> 
> I guess JDK-8151181: Add JSnap to jhsdb is in progress.
> JDK-8151709 is affected it.
> So I want to send review request after that.
> 
> 
> Thanks,
> 
> Yasumasa
> 
> 
> On 2016/03/13 23:52, Dmitry Samersoff wrote:
>> Yasumasa,
>>
>> 1.
>> We shouldn't introduce dependency from Tool.java back to SALuancher.
>>
>> So please, change runJSTACK (and other similar functions)  to catch
>> invalid arguments.
>>
>> It might require changing of SAGetopt.java and/or
>> jdk/test/sun/tools/jhsdb/SAGetoptTest.java
>>
>> 2. For JInfo changes, please create
>>
>> private static final int MODE_UNKNOWN = -1;
>>
>>
>> -Dmitry
>>
>>
>> On 2016-03-12 17:33, Yasumasa Suenaga wrote:
>>> I updated webrev:
>>>       http://cr.openjdk.java.net/~ysuenaga/JDK-8151709/webrev.01/
>>>
>>> I added changes for JInfo.java because help message is shown in twice.
>>>
>>> Please review.
>>>
>>>
>>> Thanks,
>>>
>>> Yasumasa
>>>
>>>
>>> On 2016/03/11 22:26, Yasumasa Suenaga wrote:
>>>> Hi all,
>>>>
>>>> jhsdb shows error message in each tool implemantation as below:
>>>> --------------
>>>> $ jhsdb jstack -aaa
>>>> Usage: jstack [option] <pid>
>>>>                    (to connect to a live java process)
>>>>       or jstack [option] <executable> <core>
>>>>                    (to connect to a core file)
>>>>       or jstack [option] [server_id@]<remote server IP or hostname>
>>>>                    (to connect to a remote debug server)
>>>>
>>>> where option must be one of:
>>>>        -l  to print java.util.concurrent locks
>>>>        -m  to print both java and native frames (mixed mode)
>>>>        -h | -help  to print this help message
>>>> --------------
>>>>
>>>> If we run SA tool via jhsdb, we should get help message of SALauncher as below:
>>>> --------------
>>>> $ jhsdb jstack -aaa
>>>>        --locks     to print java.util.concurrent locks
>>>>        --mixed     to print both java and native frames (mixed mode)
>>>>        --exe       executable image name
>>>>        --core      path to coredump
>>>>        --pid       pid of process to attach
>>>> --------------
>>>>
>>>> I uploaded webrev. Could you review it?
>>>>        http://cr.openjdk.java.net/~ysuenaga/JDK-8151709/webrev.00/
>>>>
>>>> I cannot access JPRT.
>>>> So I need a Sponsor.
>>>>
>>>>
>>>> Thanks,
>>>>
>>>> Yasumasa
>>>>
>>
>>

From yasuenag at gmail.com  Mon Mar 14 14:39:32 2016
From: yasuenag at gmail.com (Yasumasa Suenaga)
Date: Mon, 14 Mar 2016 23:39:32 +0900
Subject: RFR: JDK-81518: Could not parse core image with JSnap.
Message-ID: <56E6CD24.40002@gmail.com>

Hi all,

When I use `jhsdb jsnap` to get PerfCounter from core images, I encountered NPE: 
------------- 
Exception in thread "main" java.lang.NullPointerException 
        at sun.jvm.hotspot.tools.JSnap.run(JSnap.java:45) 
        at sun.jvm.hotspot.tools.Tool.startInternal(Tool.java:260) 
        at sun.jvm.hotspot.tools.Tool.start(Tool.java:223) 
        at sun.jvm.hotspot.tools.Tool.execute(Tool.java:118) 
        at sun.jvm.hotspot.tools.JSnap.main(JSnap.java:67) 
        at sun.jvm.hotspot.SALauncher.runJSNAP(SALauncher.java:352) 
        at sun.jvm.hotspot.SALauncher.main(SALauncher.java:404) 
------------- 

PerfMemory::destroy() clears all members which are used in JSnap. 
Thus NPE is occurred. 

I uploaded webrev for this issue.
Could you review it?

  http://cr.openjdk.java.net/~ysuenaga/JDK-8151815/webrev.00/

I cannot access JPRT.
So I need a Sponsor.


Thanks,

Yasumasa


From dmitry.samersoff at oracle.com  Mon Mar 14 15:06:45 2016
From: dmitry.samersoff at oracle.com (Dmitry Samersoff)
Date: Mon, 14 Mar 2016 18:06:45 +0300
Subject: RFR: 8146879: Add option for handling existing log files in UL
In-Reply-To: <56E692A4.6010204@oracle.com>
References: <5697B7F2.50104@oracle.com> <56D578F9.6090602@oracle.com>
	<56D5A1BB.6030403@oracle.com> <56E2D478.3090202@oracle.com>
	<56E2D7AA.1060803@oracle.com> <56E2D8AD.8040902@oracle.com>
	<56E54911.9090807@oracle.com> <56E692A4.6010204@oracle.com>
Message-ID: <56E6D385.4000708@oracle.com>

Marcus,

1.
Most of log analyzing tools utilize the fact that filesystem returns
files in alphabetical order or uses scandir()/alphasort()

So good log rotation strategy is log, log.001, log.002, log.003 etc
where "log" is current one and log.MAX_COUNT is the oldest one.

To save startup time we can declare that log.001 is the oldest one, and
log.MAX_COUNT is the newest one but log.002 that is more recent than
log.001 and log.003 seems not obvious to me.

Also it's very common that log producer and log analyzer resides on a
different machines (e.g. with NFS share) and log file mtime could be
unrelated to the age of VM events in this log. So we shouldn't use log
mtime for any decision.

2.
rename() can cause a burden in complicated environment, so it's better
to check most common cases (permissions, PATH_MAX, etc) explicitly, as
early as possible, to give meaningful error message to a user.

See also below.

On 2016-03-14 13:29, Marcus Larsson wrote:
> Hi,
> 
> Thanks for looking at this!
> 
> On 03/13/2016 12:03 PM, Dmitry Samersoff wrote:
>> Marcus,
>>
>> 1. os_posix/os_windows.cpp
>>
>> Windows version is expensive and change access time of a log file.
>>
>> So it's better to create os::get_mtime() that uses stat() for both,
>> windows and posix and LogFileOutput::calc_mtime_diff().
>>
>> Also it saves a bit of compiler power unrolling loop.
> 
> This is similar to my first approach but I ran into problems with it
> because st_mtime is a struct timespec on posix and a time_t on windows.
> From the start I wanted better precision than seconds, which is why I
> wanted to use CompareFileTime(). Given that we can not depend on any
> particular precision, perhaps it's better to just use stat() on windows
> as well, like you say.

OK.

>> 2. log.cpp
>>
>> size_t number_of_lines_with_substring_in_file()
>>
>> When you plan to use it ? Current implementation is rather expensive,
>> but if you plan to run it manually only, I'm OK with it.
> 
> It's used for testing only.

If you plan to use it in jprt or nightly - please change it.

>> 3. logFileOutput.cpp
>>
>> 82.
>> Please, change file_exists to can_be_rotated() and check that log output
>> is a *regular file* and you have a write access to it.
> 
> I guess it would be useful to give an error in the case someone
> specifies logging to something that's not a regular file. Checking for
> write permissions shouldn't be necessary here though. If any of the
> required operations fail because of lacking permissions we'll notice
> that at that time.

Logging to /dev/tape or /dev/console is perfectly valid usecase but we
should detect it and don't attempt to rotate or truncate device ever if
sysadmin enable rotation by mistake.

Also common sysadmin mistake is a log pointing to directory or presence
of log.NNN directory - we should detect it as well.

One more case when we shouldn't rotate - log is symlink


>> 87.
>> Please, don't use floating point math. Just allocate 10 extra bytes, it
>> fit all possible file length value.
> 
> I can use a fixed size for the allocations, but we will still want to
> figure out how many numbers should be used so that we can use the
> appropriate amount of padding. Logging with 10 files in rotation should
> use log.0 to log.9, not log.0000000 to log.0000009.

It's OK to always write log.001 etc or use something like:

return (num < 10) ? 1 : (num < 100) ? 2 : 5;

>> 93.
>> if we have log.01, log.03 etc this function creates log.02 instead of
>> log.04.
> 
> Yes, that's intentional.

log.01 and log.03 both containing older data than log.02 seems not
obvious for me.

Could we always use largest possible number?

>>
>> Sorry! I'm not follow logic of ll.118
>> What happens if some log parsing tool change log file mtime?
> 
> We'll always prefer to overwrite the file that hasn't been modified for
> the longest time.

Log file mtime can be unrelated to the age of VM events in this file
(think sysadmin do: vi log.003, :wq) so we shouldn't rely on mtime.

>> Please, limit the number of old logs (FileCountOption) to some
>> reasonable value (e.g. 999) and use binary search to find the name of a
>> next file.
> 
> I can limit it, but I'm not sure we should make the effort of binary
> searching for the file name. It's a one time search during startup and I
> would expect most people to use around 10 files.

OK,  as soon as DefaultRotationFileCount is less than 10

>> Also please check full log file name against MAX_PATH constant.
> 
> Is it really necessary? Won't fopen() just fail and return the
> appropriate error for this?

rename errors is not always obvious. see comments above.

-Dmitry

> 
> Thanks,
> Marcus
> 
>>
>> -Dmitry
>>
>>
>>
>>
>> On 2016-03-11 17:39, Marcus Larsson wrote:
>>> Hi,
>>>
>>> On 2016-03-11 15:35, Bengt Rutisson wrote:
>>>> Hi Marcus,
>>>>
>>>> On 2016-03-11 15:21, Marcus Larsson wrote:
>>>>> Third time's the charm.
>>>>>
>>>>> Webrev:
>>>>> http://cr.openjdk.java.net/~mlarsson/8146879/webrev.03/
>>>> I had a quick look at the code changes. It is not really my area of
>>>> the code, so I'll leave to someone else to formally review it.
>>>>
>>>> However, I downloaded the patch a played a bit with the logging. This
>>>> is much more like the way I would like it! Thanks!
>>>>
>>>> So, from a functional perspective this looks good to me.
>>>>
>>> Thanks for the feedback!
>>>
>>> Marcus
>>>
>>>> Thanks,
>>>> Bengt
>>>>
>>>>> This patch makes log file rotation the default. Default thresholds
>>>>> are 5 rotated files with a target size of 20MiB. Truncating behavior
>>>>> can be achieved by setting filecount to 0
>>>>> (-Xlog::myfile.log::filecount=0).
>>>>>
>>>>> If a log file already exists during log file initialization it will
>>>>> be rotated. If any of the target file names (file.0 to file.4 in the
>>>>> default case) are available, that filename will be used for the
>>>>> existing log. If all names are taken the VM will attempt to overwrite
>>>>> the oldest file.
>>>>>
>>>>> This should prevent unlimited log file creations and avoid accidental
>>>>> loss of log files from previous runs. The default thresholds (5
>>>>> files, 20MiB each) is just a suggestion. If you think it should be
>>>>> higher/lower let me know.
>>>>>
>>>>> Tested with included internal VM tests through RBT.
>>>>>
>>>>> Thanks,
>>>>> Marcus
>>>>>
>>>>> On 2016-03-01 15:05, Marcus Larsson wrote:
>>>>>> Hi,
>>>>>>
>>>>>> After some offline discussions I'm withdrawing this patch. I will
>>>>>> instead investigate if I can achieve similar behavior using log
>>>>>> rotation as the default.
>>>>>>
>>>>>> Thanks,
>>>>>> Marcus
>>>>>>
>>>>>> On 03/01/2016 12:11 PM, Marcus Larsson wrote:
>>>>>>> Hi again,
>>>>>>>
>>>>>>> Taking a different approach to this.
>>>>>>>
>>>>>>> New webrev:
>>>>>>> http://cr.openjdk.java.net/~mlarsson/8146879/webrev.01/
>>>>>>>
>>>>>>> Existing files will now by default be renamed/archived with a .X
>>>>>>> suffix where X is the lowest number such that the resulting file
>>>>>>> name is available (jvm.log becomes jvm.log.0). A mode option for
>>>>>>> controlling this behavior has been added as well. It can be set to
>>>>>>> archive, append, or truncate (i.e. -Xlog::jvm.log::mode=truncate).
>>>>>>>
>>>>>>> Tested with included jtreg test through JPRT.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Marcus
>>>>>>>
>>>>>>> On 01/14/2016 04:00 PM, Marcus Larsson wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> Please review the following patch to make sure UL truncates
>>>>>>>> existing log files before writing to them. Since files are opened
>>>>>>>> in append mode, truncation isn't done automatically, so instead
>>>>>>>> the patch adds an attempt to remove the log file before opening it.
>>>>>>>>
>>>>>>>> Webrev:
>>>>>>>> http://cr.openjdk.java.net/~mlarsson/8146879/webrev.00/
>>>>>>>>
>>>>>>>> Issue:
>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8146879
>>>>>>>>
>>>>>>>> Testing:
>>>>>>>> Included test through JPRT
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Marcus
>>
> 


-- 
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the sources.

From dmitry.samersoff at oracle.com  Mon Mar 14 15:08:25 2016
From: dmitry.samersoff at oracle.com (Dmitry Samersoff)
Date: Mon, 14 Mar 2016 18:08:25 +0300
Subject: RFR: JDK-8151709: jhsdb should show help message in SALauncher.
In-Reply-To: <56E6C6B9.5010708@gmail.com>
References: <56E2C790.4020802@gmail.com> <56E428BC.8050108@gmail.com>
	<56E57EBE.5050901@oracle.com> <56E636FC.5040002@gmail.com>
	<56E6C6B9.5010708@gmail.com>
Message-ID: <56E6D3E9.3050703@oracle.com>

Yasumasa,

Looks good for me.

-Dmitry

On 2016-03-14 17:12, Yasumasa Suenaga wrote:
> Hi,
> 
>> I guess JDK-8151181: Add JSnap to jhsdb is in progress.
>> JDK-8151709 is affected it.
>> So I want to send review request after that.
> 
> JDK-8151181 is merged.
> So I uploaded new webrev. Could you review it?
> 
>   hotspot: http://cr.openjdk.java.net/~ysuenaga/JDK-8151709/webrev.03/hotspot/
>       jdk: http://cr.openjdk.java.net/~ysuenaga/JDK-8151709/webrev.03/jdk/
> 
> 
> Thanks,
> 
> Yasumasa
> 
> 
> On 2016/03/14 12:58, Yasumasa Suenaga wrote:
>> Hi Dmitry,
>>
>> I changed for arguments processing in jhsdb in new webrev:
>>      hotspot: http://cr.openjdk.java.net/~ysuenaga/JDK-8151709/webrev.02/hotspot/
>>          jdk: http://cr.openjdk.java.net/~ysuenaga/JDK-8151709/webrev.02/jdk/
>>
>> I encountered ArrayIndexOutOfBoundsException when I ran `jhsdb jstack --pid`.
>> So I fix its problem.
>>
>>
>> I guess JDK-8151181: Add JSnap to jhsdb is in progress.
>> JDK-8151709 is affected it.
>> So I want to send review request after that.
>>
>>
>> Thanks,
>>
>> Yasumasa
>>
>>
>> On 2016/03/13 23:52, Dmitry Samersoff wrote:
>>> Yasumasa,
>>>
>>> 1.
>>> We shouldn't introduce dependency from Tool.java back to SALuancher.
>>>
>>> So please, change runJSTACK (and other similar functions)  to catch
>>> invalid arguments.
>>>
>>> It might require changing of SAGetopt.java and/or
>>> jdk/test/sun/tools/jhsdb/SAGetoptTest.java
>>>
>>> 2. For JInfo changes, please create
>>>
>>> private static final int MODE_UNKNOWN = -1;
>>>
>>>
>>> -Dmitry
>>>
>>>
>>> On 2016-03-12 17:33, Yasumasa Suenaga wrote:
>>>> I updated webrev:
>>>>       http://cr.openjdk.java.net/~ysuenaga/JDK-8151709/webrev.01/
>>>>
>>>> I added changes for JInfo.java because help message is shown in twice.
>>>>
>>>> Please review.
>>>>
>>>>
>>>> Thanks,
>>>>
>>>> Yasumasa
>>>>
>>>>
>>>> On 2016/03/11 22:26, Yasumasa Suenaga wrote:
>>>>> Hi all,
>>>>>
>>>>> jhsdb shows error message in each tool implemantation as below:
>>>>> --------------
>>>>> $ jhsdb jstack -aaa
>>>>> Usage: jstack [option] <pid>
>>>>>                    (to connect to a live java process)
>>>>>       or jstack [option] <executable> <core>
>>>>>                    (to connect to a core file)
>>>>>       or jstack [option] [server_id@]<remote server IP or hostname>
>>>>>                    (to connect to a remote debug server)
>>>>>
>>>>> where option must be one of:
>>>>>        -l  to print java.util.concurrent locks
>>>>>        -m  to print both java and native frames (mixed mode)
>>>>>        -h | -help  to print this help message
>>>>> --------------
>>>>>
>>>>> If we run SA tool via jhsdb, we should get help message of SALauncher as below:
>>>>> --------------
>>>>> $ jhsdb jstack -aaa
>>>>>        --locks     to print java.util.concurrent locks
>>>>>        --mixed     to print both java and native frames (mixed mode)
>>>>>        --exe       executable image name
>>>>>        --core      path to coredump
>>>>>        --pid       pid of process to attach
>>>>> --------------
>>>>>
>>>>> I uploaded webrev. Could you review it?
>>>>>        http://cr.openjdk.java.net/~ysuenaga/JDK-8151709/webrev.00/
>>>>>
>>>>> I cannot access JPRT.
>>>>> So I need a Sponsor.
>>>>>
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Yasumasa
>>>>>
>>>
>>>


-- 
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the sources.

From david.holmes at oracle.com  Tue Mar 15 00:29:10 2016
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 15 Mar 2016 10:29:10 +1000
Subject: RFR (S): 8137165: Tests fail in SR_Handler because thread is not
	VMThread or JavaThread
In-Reply-To: <56E6BDF2.2010201@oracle.com>
References: <56E65E62.8040003@oracle.com> <56E6BDF2.2010201@oracle.com>
Message-ID: <56E75756.8060200@oracle.com>

Thanks Robbin.

Can I have a Reviewer too please.

David

On 14/03/2016 11:34 PM, Robbin Ehn wrote:
> Hi David,
>
> On 03/14/2016 07:46 AM, David Holmes wrote:
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8137165
>> Webrev: http://cr.openjdk.java.net/~dholmes/8137165/webrev/
>
> This looks good to me.
>
> /Robbin
>
>>
>> This isn't a fix per-se but some additional diagnostic code to try and
>> detect the conditions where the bug might manifest. The basic failure
>> mode was:
>>
>> # Internal Error
>> (/opt/jprt/T/P1/175841.hseigel/s/hotspot/src/os/linux/vm/os_linux.cpp:3950),
>>
>> pid=27906, tid=13248
>> # assert(thread->is_VM_thread() || thread->is_Java_thread()) failed:
>> Must be VMThread or JavaThread
>>
>> with a stack showing in part:
>>
>> #34 0xf6623ec0 in report_vm_error (
>>      file=0xf71b6140
>> "/scratch/opt/jprt/T/P1/205457.cphillim/s/hotspot/src/os/linux/vm/os_linux.cpp",
>>
>> line=3901,
>>      error_msg=0xf71b62e0 "assert(thread->is_VM_thread() ||
>> thread->is_Java_thread()) failed", detail_fmt=0xf71b62c0 "Must be
>> VMThread or JavaThread")
>>      at
>> /scratch/opt/jprt/T/P1/205457.cphillim/s/hotspot/src/share/vm/utilities/debug.cpp:218
>>
>>
>> #35 0xf6d21b3f in SR_handler (sig=12, siginfo=0xc1b58ccc,
>> context=0xc1b58d4c)
>>      at
>> /scratch/opt/jprt/T/P1/205457.cphillim/s/hotspot/src/os/linux/vm/os_linux.cpp:3901
>>
>>
>> #36 <signal handler called>
>> #37 0xf776b430 in __kernel_vsyscall ()
>> #38 0xf773ccef in pthread_sigmask () from /lib/libpthread.so.0
>> #39 0xf6d23e6c in os::free_thread (osthread=0xc20cf8b8)
>>      at
>> /scratch/opt/jprt/T/P1/205457.cphillim/s/hotspot/src/os/linux/vm/os_linux.cpp:879
>>
>>
>> #40 0xf6f6811d in Thread::~Thread (this=0xc20cd800, __in_chrg=<optimized
>> out>)
>>      at
>> /scratch/opt/jprt/T/P1/205457.cphillim/s/hotspot/src/share/vm/runtime/thread.cpp:367
>>
>>
>> #41 0xf6f6866f in JavaThread::~JavaThread (this=0xc20cd800,
>>      __in_chrg=<optimized out>)
>>      at
>> /scratch/opt/jprt/T/P1/205457.cphillim/s/hotspot/src/share/vm/runtime/thread.cpp:1611
>>
>>
>> #42 0xf6f6877c in JavaThread::~JavaThread (this=0xc20cd800,
>>      __in_chrg=<optimized out>)
>>      at
>> /scratch/opt/jprt/T/P1/205457.cphillim/s/hotspot/src/share/vm/runtime/thread.cpp:1655
>>
>>
>> #43 0xf6f74a38 in JavaThread::thread_main_inner (this=0xc20cd800)
>>      at
>> /scratch/opt/jprt/T/P1/205457.cphillim/s/hotspot/src/share/vm/runtime/thread.cpp:1724
>>
>>
>> #44 0xf6f74e12 in JavaThread::run (this=0xc20cd800)
>>      at
>> /scratch/opt/jprt/T/P1/205457.cphillim/s/hotspot/src/share/vm/runtime/thread.cpp:1698
>>
>>
>> #45 0xf6d238ec in java_start (thread=0xc20cd800)
>>
>> What appears to be happening is that the thread has blocked SR_signum
>> (SIGUSR2) at some point (though there is no code that does this), and
>> the signal has become pending on the thread due to the event sampling
>> logic. The thread terminates, executing well into the destructor until
>> it gets to os::free_thread which restores the original signal mask for
>> the thread - that signal mask has SR_signum unblocked and so the signal
>> is delivered immediately and we enter the SR_handler. For some reason
>> this triggers the assertion failure - though why exactly is unclear as
>> we have not released the thread memory as yet, nor done anything that
>> should invalidate that call. Whatever the reason the state of the thread
>> causes secondary failures in the error reporting code as well.
>>
>> Attempts to reproduce this bug have been unsuccessful (so maybe we had a
>> random memory stomp on the thread state - who knows.)
>>
>> So what I am doing is simply adding an additional assertion to try and
>> catch, during regular testing, any  occurrence of SR_signum being
>> blocked while a thread is terminating.
>>
>> In addition a couple of minor cleanups in the signal related code:
>> - strictly speaking SR_handler needs to use
>> Thread::current_or_null_safe() because it needs ot use library-based TLS
>> in a signal context.
>> - sigsets should (POSIX recommendation) be explicitly emptied/filled
>> before being set via pthread_sigmask
>> - change 0 to NULL in call to pthread_sigmask
>>
>> Testing: - JPRT, original failing testcase
>>
>> Thanks,
>> David

From david.holmes at oracle.com  Tue Mar 15 00:38:46 2016
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 15 Mar 2016 10:38:46 +1000
Subject: Check core dumping is enabled when set CrashOnOutOfMemoryError
In-Reply-To: <CABU-27OgFQdE0_m+zCBMmQNUQjdxCinxaS+tcyC9DFrEpsdR5g@mail.gmail.com>
References: <CABU-27P4ZvQZio761Q2W8_w0=SXA9p=a3c4HRW9KEq+rVXrEsA@mail.gmail.com>
	<56E604F6.80505@oracle.com>
	<CABU-27Px4XsGaXddvUwrrExhNQ2BZ-cu3k0MrHtXNzT2xaYn=g@mail.gmail.com>
	<CABU-27OgFQdE0_m+zCBMmQNUQjdxCinxaS+tcyC9DFrEpsdR5g@mail.gmail.com>
Message-ID: <56E75996.8040609@oracle.com>

On 14/03/2016 6:16 PM, KUBOTA Yuji wrote:
> Hi David,
>
> Sorry, please let discussion a bit more.
>
> 2016-03-14 9:25 GMT+09:00 David Holmes <david.holmes at oracle.com>:
>> First I'm not convinced that you necessarily want to enable core dumps just
>> because you want to crash on OOM.
>>
>> Second I think anyone setting CrashOnOutOfMemoryError can easily remember to
>> set CreateCoredumpOnCrash if they want it.
>
> I think most users do not pay attention about core dumping because
>   * CreateCoredumpOnCrash is enabled by default (jdk9/hs-rt).
>   * Core images not necessarily needed (except crash).
> So we should warn if core dumping is disabled and
> CreateCoredumpOnCrash is enabled, but continue to launch jvm.

What do you mean by "core dumping is disabled"? What is it you expect to 
be checked?

CreateCoredumpOnCrash (formerly CreateMinidumpOnCrash) was primarily a 
windows flag to disable mini-dumps by default on Windows client builds. 
Otherwise we expect the VM to always produce a core dump on crash.

> However, the user who set CrashOnOutOfMemoryError need core images
> clearly, so I think jvm should return error if core dumping is
> disabled.

I disagree. The user who sets CrashOnOutOfMemoryError may also be 
setting ShowMessageBoxOnError so they can attach a debugger or run other 
tools.

The user who wants a core dump can enable core dumps explicitly if needed.

> For example, I want to use CrashOnOOME instead of HeapDumpOnOOME,
> because we can exit jvm definitely and get heapdump and other helpful
> information by serviceability tools.
>
> In conclusion, I have two proposals for avoiding the lack of information.
> 1. Launch jvm with warn message if CreateCoredumpOnCrash is enabled
> but core dumping is disabled.

Again clarify what you mean by this? Given CreateCoredumpOnCrash is 
usually on this would produce warning messages in many execution 
contexts where core dumps are disable (ie ulimit -c 0).  That would be a 
bad thing.

> 2. 1 + Quit with error message if CrashOnOutOfMemoryError is enabled
> but core dumping is disabled.
> I think I should implement 2 in arguments.cpp.
>
> Could you share me your thought?

I don't agree that anything needs to be modified here - sorry.

Thanks,
David
-----


> 2016-03-14 14:59 GMT+09:00 KUBOTA Yuji <kubota.yuji at gmail.com>:
>> Thanks David for looking and comments,
>>
>> 2016-03-14 9:25 GMT+09:00 David Holmes <david.holmes at oracle.com>:
>>> First I'm not convinced that you necessarily want to enable core dumps just
>>> because you want to crash on OOM.
>>
>> Yes, that's right. I just want to avoid the failed of core dumping
>> when we want it clearly by setting options.
>>
>>> Second I think anyone setting CrashOnOutOfMemoryError can easily remember to
>>> set CreateCoredumpOnCrash if they want it.
>>>
>>> Third if I was going to force this on then I would do it directly in
>>> arguments.cpp, not by adding a constraint function.
>>
>> Thanks for sharing information! I will check the implementation of
>> CreateCoredumpOnCrash and update my patch to use arguments.cpp.
>>
>> Thanks,
>> Yuji
>>
>>>
>>> Thanks,
>>> David
>>> -----
>>>
>>>
>>>> So I create a patch to check the core dumping, please review it.
>>>> I do not have an account of openjdk, so I need sponsor.
>>>>
>>>> I send to serviceability-dev because JDK-8138745 [1] has been
>>>> reviewed here. If unfit, please let me know.
>>>>
>>>> [1]:Implement ExitOnOutOfMemory and CrashOnOutOfMemory in HotSpot
>>>>        https://bugs.openjdk.java.net/browse/JDK-8138745
>>>>
>>>> diff --git a/src/share/vm/runtime/commandLineFlagConstraintsRuntime.cpp
>>>> b/src/share/vm/runtime/commandLineFlagConstraintsRuntime.cpp
>>>> --- a/src/share/vm/runtime/commandLineFlagConstraintsRuntime.cpp
>>>> +++ b/src/share/vm/runtime/commandLineFlagConstraintsRuntime.cpp
>>>> @@ -119,6 +119,17 @@
>>>>      }
>>>>    }
>>>>
>>>> +Flag::Error CrashOnOutOfMemoryErrorFunc(bool value, bool verbose) {
>>>> +  char buffer[O_BUFLEN];
>>>> +  os::check_dump_limit(buffer, sizeof(buffer));
>>>> +  if (!VMError::coredump_status) {
>>>> +    CommandLineError::print(verbose,
>>>> +                            "%s\n", VMError::coredump_message);
>>>> +    return Flag::VIOLATES_CONSTRAINT;
>>>> +  }
>>>> +  return Flag::SUCCESS;
>>>> +}
>>>> +
>>>>    Flag::Error PerfDataSamplingIntervalFunc(intx value, bool verbose) {
>>>>      if ((value % PeriodicTask::interval_gran != 0)) {
>>>>        CommandLineError::print(verbose,
>>>> diff --git a/src/share/vm/runtime/commandLineFlagConstraintsRuntime.hpp
>>>> b/src/share/vm/runtime/commandLineFlagConstraintsRuntime.hpp
>>>> --- a/src/share/vm/runtime/commandLineFlagConstraintsRuntime.hpp
>>>> +++ b/src/share/vm/runtime/commandLineFlagConstraintsRuntime.hpp
>>>> @@ -43,6 +43,8 @@
>>>>    Flag::Error BiasedLockingBulkRevokeThresholdFunc(intx value, bool
>>>> verbose);
>>>>    Flag::Error BiasedLockingDecayTimeFunc(intx value, bool verbose);
>>>>
>>>> +Flag::Error CrashOnOutOfMemoryErrorFunc(bool value, bool verbose);
>>>> +
>>>>    Flag::Error PerfDataSamplingIntervalFunc(intx value, bool verbose);
>>>>
>>>>    #endif /* SHARE_VM_RUNTIME_COMMANDLINEFLAGCONSTRAINTSRUNTIME_HPP */
>>>> diff --git a/src/share/vm/runtime/globals.hpp
>>>> b/src/share/vm/runtime/globals.hpp
>>>> --- a/src/share/vm/runtime/globals.hpp
>>>> +++ b/src/share/vm/runtime/globals.hpp
>>>> @@ -1401,6 +1401,7 @@
>>>>      product(bool, CrashOnOutOfMemoryError, false,
>>>> \
>>>>              "JVM aborts, producing an error log and core/mini dump, on the
>>>> "  \
>>>>              "first occurrence of an out-of-memory error")
>>>> \
>>>> +          constraint(CrashOnOutOfMemoryErrorFunc,AfterErgo)
>>>> \
>>>>
>>>> \
>>>>      /* tracing */
>>>> \
>>>>
>>>> \
>>>> diff --git a/src/share/vm/utilities/vmError.hpp
>>>> b/src/share/vm/utilities/vmError.hpp
>>>> --- a/src/share/vm/utilities/vmError.hpp
>>>> +++ b/src/share/vm/utilities/vmError.hpp
>>>> @@ -65,14 +65,6 @@
>>>>      // so use thread id instead of Thread* to identify thread.
>>>>      static volatile intptr_t first_error_tid;
>>>>
>>>> -  // Core dump status, false if we have been unable to write a
>>>> core/minidump for some reason
>>>> -  static bool coredump_status;
>>>> -
>>>> -  // When coredump_status is set to true this will contain the
>>>> name/path to the core/minidump,
>>>> -  // if coredump_status if false, this will (hopefully) contain a
>>>> useful error explaining why
>>>> -  // no core/minidump has been written to disk
>>>> -  static char coredump_message[O_BUFLEN];
>>>> -
>>>>
>>>>      // set signal handlers on Solaris/Linux or the default exception
>>>> filter
>>>>      // on Windows, to handle recursive crashes.
>>>> @@ -111,6 +103,14 @@
>>>>      // Record status of core/minidump
>>>>      static void record_coredump_status(const char* message, bool status);
>>>>
>>>> +  // Core dump status, false if we have been unable to write a
>>>> core/minidump for some reason
>>>> +  static bool coredump_status;
>>>> +
>>>> +  // When coredump_status is set to true this will contain the
>>>> name/path to the core/minidump,
>>>> +  // if coredump_status if false, this will (hopefully) contain a
>>>> useful error explaining why
>>>> +  // no core/minidump has been written to disk
>>>> +  static char coredump_message[O_BUFLEN];
>>>> +
>>>>      // support for VM.info diagnostic command
>>>>      static void print_vm_info(outputStream* st);
>>>>
>>>>
>>>> Thanks,
>>>> Yuji
>>>>
>>>

From david.holmes at oracle.com  Tue Mar 15 00:46:54 2016
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 15 Mar 2016 10:46:54 +1000
Subject: RFR: JDK-8151653: Hotspot build does not respect
	--enable-openjdk-only
In-Reply-To: <56E6123D.9020209@oracle.com>
References: <56E2F2C7.9090301@oracle.com> <56E6123D.9020209@oracle.com>
Message-ID: <56E75B7E.1020400@oracle.com>

On 14/03/2016 11:22 AM, David Holmes wrote:
> Hi Erik,
>
> On 12/03/2016 2:31 AM, Erik Joelsson wrote:
>> Hello,
>>
>> When building hotspot with closed sources present and configuring with
>> --enable-openjdk-only, various closed parts are included in the build
>> anyway, at least on Windows. This needs to be fixed in preparation for
>> the new hotspot build for build output comparisons to be meaningful
>> between the old and new.
>>
>> The major culprit here, which applies to all platforms, is the trace
>> source generation. The base trace.xml uses XInclude to explicitly and
>> unconditionally include closed xml files if present. I'm fixing this by
>> introducing a closed version of trace.xml which includes the open and
>> closed parts, while the open trace.xml only includes the open parts.
>
> You've also done a significant amount of refactoring of that file and
> split it into three parts. It's hard to spot the actual functional
> differences in all that.

Sorry that was a bit terse. It would have been clearer if you had 
explained about the refactoring. I can see why the refactoring was needed.

Thanks,
David
-----

> Given we have distinct directories from which we locate files it is a
> pity to introduce something like this:
>
>   XML_DEPS += $(TraceAltSrcDir)/traceeventsclosed.xml
>
> where traceevents.xml is now traceeventsclosed.xml. This "alt src"
> mechanism was supposed to abstract away the details of any particular
> alternative configuration so that we didn't hardcode "closed" all over
> the place. Other community members are supposed to be able to utilize
> these mechanisms for their own customized build environments.
>
>> The rest of the changes are just for Windows, making sure the OPENJDK
>> variable is propagated into the nmake build and making all conditionals
>> on including closed source also check that variable.
>
> make/windows/build.make
>
> The combination !openjdk && !exists "closed" should be an error.
>
> As a meta-comment I think we've lost the plot somewhat with these "alt"
> locations and how we manage them. The Oracle "closed" variants should
> only be used when not trying to build OpenJDK (even if the files exist
> in a forest), but other custom implementations may work in conjunction
> with an OpenJDK build. To that end the "do nothing if building OpenJDK"
> should be located within the "alt" files themselves, not at the point of
> inclusion/use in the open files.
>
> David
> -----
>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8151653
>> Webrev:
>> http://cr.openjdk.java.net/~erikj/8151653/webrev.hotspot.01/index.html
>>
>> /Erik

From kim.barrett at oracle.com  Tue Mar 15 06:34:16 2016
From: kim.barrett at oracle.com (Kim Barrett)
Date: Tue, 15 Mar 2016 02:34:16 -0400
Subject: RFR (S): 8137165: Tests fail in SR_Handler because thread is not
	VMThread or JavaThread
In-Reply-To: <56E65E62.8040003@oracle.com>
References: <56E65E62.8040003@oracle.com>
Message-ID: <47C4626A-38E6-480D-A651-764E57C4B075@oracle.com>

> On Mar 14, 2016, at 2:46 AM, David Holmes <david.holmes at oracle.com> wrote:
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8137165
> Webrev: http://cr.openjdk.java.net/~dholmes/8137165/webrev/
> 
> This isn't a fix per-se but some additional diagnostic code to try and detect the conditions where the bug might manifest. The basic failure mode was:

Changes look good.

Good cleanup with the sigemptyset calls.  Pedantic is a good thing when dealing with POSIX.

Since this isn?t an actual fix, should the change be associated with a different bug number?
Or are you treating this as the moral equivalent of resolving as not reproducible? 


From david.holmes at oracle.com  Tue Mar 15 06:43:01 2016
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 15 Mar 2016 16:43:01 +1000
Subject: RFR (S): 8137165: Tests fail in SR_Handler because thread is not
	VMThread or JavaThread
In-Reply-To: <47C4626A-38E6-480D-A651-764E57C4B075@oracle.com>
References: <56E65E62.8040003@oracle.com>
	<47C4626A-38E6-480D-A651-764E57C4B075@oracle.com>
Message-ID: <56E7AEF5.3070507@oracle.com>

Hi Kim,

On 15/03/2016 4:34 PM, Kim Barrett wrote:
>> On Mar 14, 2016, at 2:46 AM, David Holmes <david.holmes at oracle.com> wrote:
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8137165
>> Webrev: http://cr.openjdk.java.net/~dholmes/8137165/webrev/
>>
>> This isn't a fix per-se but some additional diagnostic code to try and detect the conditions where the bug might manifest. The basic failure mode was:
>
> Changes look good.
>
> Good cleanup with the sigemptyset calls.  Pedantic is a good thing when dealing with POSIX.

Thanks for the Review.

> Since this isn?t an actual fix, should the change be associated with a different bug number?
> Or are you treating this as the moral equivalent of resolving as not reproducible?

I toyed with creating a subtask for this change and leaving the original 
open, but realistically I think it may turn out to be "not 
reproducible". I can be swayed if you think a new subtask would be better?

Thanks,
David


From kim.barrett at oracle.com  Tue Mar 15 06:48:52 2016
From: kim.barrett at oracle.com (Kim Barrett)
Date: Tue, 15 Mar 2016 02:48:52 -0400
Subject: RFR (S): 8137165: Tests fail in SR_Handler because thread is not
	VMThread or JavaThread
In-Reply-To: <56E7AEF5.3070507@oracle.com>
References: <56E65E62.8040003@oracle.com>
	<47C4626A-38E6-480D-A651-764E57C4B075@oracle.com>
	<56E7AEF5.3070507@oracle.com>
Message-ID: <92B8BE29-66DF-4CDE-B737-B063AE2BCD85@oracle.com>

> On Mar 15, 2016, at 2:43 AM, David Holmes <david.holmes at oracle.com> wrote:
> 
> Hi Kim,
> 
> On 15/03/2016 4:34 PM, Kim Barrett wrote:
>>> On Mar 14, 2016, at 2:46 AM, David Holmes <david.holmes at oracle.com> wrote:
>>> 
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8137165
>>> Webrev: http://cr.openjdk.java.net/~dholmes/8137165/webrev/
>>> 
>>> This isn't a fix per-se but some additional diagnostic code to try and detect the conditions where the bug might manifest. The basic failure mode was:
>> 
>> Changes look good.
>> 
>> Good cleanup with the sigemptyset calls.  Pedantic is a good thing when dealing with POSIX.
> 
> Thanks for the Review.
> 
>> Since this isn?t an actual fix, should the change be associated with a different bug number?
>> Or are you treating this as the moral equivalent of resolving as not reproducible?
> 
> I toyed with creating a subtask for this change and leaving the original open, but realistically I think it may turn out to be "not reproducible". I can be swayed if you think a new subtask would be better?

Just making sure I understood your intent.  It doesn?t look like there?s so much information in this one that creating a new one with a reference would be a big problem if it ever shows up again.  Go ahead as is.



From david.holmes at oracle.com  Tue Mar 15 07:07:06 2016
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 15 Mar 2016 17:07:06 +1000
Subject: RFR (S): 8137165: Tests fail in SR_Handler because thread is not
	VMThread or JavaThread
In-Reply-To: <92B8BE29-66DF-4CDE-B737-B063AE2BCD85@oracle.com>
References: <56E65E62.8040003@oracle.com>
	<47C4626A-38E6-480D-A651-764E57C4B075@oracle.com>
	<56E7AEF5.3070507@oracle.com>
	<92B8BE29-66DF-4CDE-B737-B063AE2BCD85@oracle.com>
Message-ID: <56E7B49A.5000304@oracle.com>

Thanks Kim - pushing now.

In a way this does "fix" the original problem as we should no longer get 
to that particular assert :)

Robbin: you don't have an OpenJDK user name yet! So I couldn't give you 
reviewing credit. :(

David
-----

On 15/03/2016 4:48 PM, Kim Barrett wrote:
>> On Mar 15, 2016, at 2:43 AM, David Holmes <david.holmes at oracle.com> wrote:
>>
>> Hi Kim,
>>
>> On 15/03/2016 4:34 PM, Kim Barrett wrote:
>>>> On Mar 14, 2016, at 2:46 AM, David Holmes <david.holmes at oracle.com> wrote:
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8137165
>>>> Webrev: http://cr.openjdk.java.net/~dholmes/8137165/webrev/
>>>>
>>>> This isn't a fix per-se but some additional diagnostic code to try and detect the conditions where the bug might manifest. The basic failure mode was:
>>>
>>> Changes look good.
>>>
>>> Good cleanup with the sigemptyset calls.  Pedantic is a good thing when dealing with POSIX.
>>
>> Thanks for the Review.
>>
>>> Since this isn?t an actual fix, should the change be associated with a different bug number?
>>> Or are you treating this as the moral equivalent of resolving as not reproducible?
>>
>> I toyed with creating a subtask for this change and leaving the original open, but realistically I think it may turn out to be "not reproducible". I can be swayed if you think a new subtask would be better?
>
> Just making sure I understood your intent.  It doesn?t look like there?s so much information in this one that creating a new one with a reference would be a big problem if it ever shows up again.  Go ahead as is.
>
>

From kubota.yuji at gmail.com  Tue Mar 15 08:30:40 2016
From: kubota.yuji at gmail.com (KUBOTA Yuji)
Date: Tue, 15 Mar 2016 17:30:40 +0900
Subject: Check core dumping is enabled when set CrashOnOutOfMemoryError
In-Reply-To: <56E75996.8040609@oracle.com>
References: <CABU-27P4ZvQZio761Q2W8_w0=SXA9p=a3c4HRW9KEq+rVXrEsA@mail.gmail.com>
	<56E604F6.80505@oracle.com>
	<CABU-27Px4XsGaXddvUwrrExhNQ2BZ-cu3k0MrHtXNzT2xaYn=g@mail.gmail.com>
	<CABU-27OgFQdE0_m+zCBMmQNUQjdxCinxaS+tcyC9DFrEpsdR5g@mail.gmail.com>
	<56E75996.8040609@oracle.com>
Message-ID: <CABU-27NjDYegm5zU+iHS=p=d-qb0=uFM5GKSoDOUeNu_rLZ5UA@mail.gmail.com>

Thank David for taking time. And sorry for misunderstand about the
purpose of each VM options.

2016-03-15 9:38 GMT+09:00 David Holmes <david.holmes at oracle.com>:
> Again clarify what you mean by this? Given CreateCoredumpOnCrash is usually
> on this would produce warning messages in many execution contexts where core
> dumps are disable (ie ulimit -c 0).  That would be a bad thing.

I aimed to notify warn before being faced with a crash if we run JVM
on the execution context where core dumps are disabled (e.g. ulimit -c
0 by default) by something carelessness.
I received many hs_err files which include the warm "Core dumps have
been disabled." from users, so I want a notice to prevent it.
Because hs_err includes useful information for after-the-fact
analysis, but sometimes we need core image to reach the cause of
crash, e.g., confirming the value of specified internal variables /
structures.

Thank you again for the detailed, I understood that my proposals are
not reasonable.
I have no good reasonable alternative ideas now, so withdraw this.

Thanks,
Yuji

2016-03-15 9:38 GMT+09:00 David Holmes <david.holmes at oracle.com>:
> On 14/03/2016 6:16 PM, KUBOTA Yuji wrote:
>>
>> Hi David,
>>
>> Sorry, please let discussion a bit more.
>>
>> 2016-03-14 9:25 GMT+09:00 David Holmes <david.holmes at oracle.com>:
>>>
>>> First I'm not convinced that you necessarily want to enable core dumps
>>> just
>>> because you want to crash on OOM.
>>>
>>> Second I think anyone setting CrashOnOutOfMemoryError can easily remember
>>> to
>>> set CreateCoredumpOnCrash if they want it.
>>
>>
>> I think most users do not pay attention about core dumping because
>>   * CreateCoredumpOnCrash is enabled by default (jdk9/hs-rt).
>>   * Core images not necessarily needed (except crash).
>> So we should warn if core dumping is disabled and
>> CreateCoredumpOnCrash is enabled, but continue to launch jvm.
>
>
> What do you mean by "core dumping is disabled"? What is it you expect to be
> checked?
>
> CreateCoredumpOnCrash (formerly CreateMinidumpOnCrash) was primarily a
> windows flag to disable mini-dumps by default on Windows client builds.
> Otherwise we expect the VM to always produce a core dump on crash.
>
>> However, the user who set CrashOnOutOfMemoryError need core images
>> clearly, so I think jvm should return error if core dumping is
>> disabled.
>
>
> I disagree. The user who sets CrashOnOutOfMemoryError may also be setting
> ShowMessageBoxOnError so they can attach a debugger or run other tools.
>
> The user who wants a core dump can enable core dumps explicitly if needed.
>
>> For example, I want to use CrashOnOOME instead of HeapDumpOnOOME,
>> because we can exit jvm definitely and get heapdump and other helpful
>> information by serviceability tools.
>>
>> In conclusion, I have two proposals for avoiding the lack of information.
>> 1. Launch jvm with warn message if CreateCoredumpOnCrash is enabled
>> but core dumping is disabled.
>
>
> Again clarify what you mean by this? Given CreateCoredumpOnCrash is usually
> on this would produce warning messages in many execution contexts where core
> dumps are disable (ie ulimit -c 0).  That would be a bad thing.
>
>> 2. 1 + Quit with error message if CrashOnOutOfMemoryError is enabled
>> but core dumping is disabled.
>> I think I should implement 2 in arguments.cpp.
>>
>> Could you share me your thought?
>
>
> I don't agree that anything needs to be modified here - sorry.
>
> Thanks,
> David
> -----
>
>
>
>> 2016-03-14 14:59 GMT+09:00 KUBOTA Yuji <kubota.yuji at gmail.com>:
>>>
>>> Thanks David for looking and comments,
>>>
>>> 2016-03-14 9:25 GMT+09:00 David Holmes <david.holmes at oracle.com>:
>>>>
>>>> First I'm not convinced that you necessarily want to enable core dumps
>>>> just
>>>> because you want to crash on OOM.
>>>
>>>
>>> Yes, that's right. I just want to avoid the failed of core dumping
>>> when we want it clearly by setting options.
>>>
>>>> Second I think anyone setting CrashOnOutOfMemoryError can easily
>>>> remember to
>>>> set CreateCoredumpOnCrash if they want it.
>>>>
>>>> Third if I was going to force this on then I would do it directly in
>>>> arguments.cpp, not by adding a constraint function.
>>>
>>>
>>> Thanks for sharing information! I will check the implementation of
>>> CreateCoredumpOnCrash and update my patch to use arguments.cpp.
>>>
>>> Thanks,
>>> Yuji
>>>
>>>>
>>>> Thanks,
>>>> David
>>>> -----
>>>>
>>>>
>>>>> So I create a patch to check the core dumping, please review it.
>>>>> I do not have an account of openjdk, so I need sponsor.
>>>>>
>>>>> I send to serviceability-dev because JDK-8138745 [1] has been
>>>>> reviewed here. If unfit, please let me know.
>>>>>
>>>>> [1]:Implement ExitOnOutOfMemory and CrashOnOutOfMemory in HotSpot
>>>>>        https://bugs.openjdk.java.net/browse/JDK-8138745
>>>>>
>>>>> diff --git a/src/share/vm/runtime/commandLineFlagConstraintsRuntime.cpp
>>>>> b/src/share/vm/runtime/commandLineFlagConstraintsRuntime.cpp
>>>>> --- a/src/share/vm/runtime/commandLineFlagConstraintsRuntime.cpp
>>>>> +++ b/src/share/vm/runtime/commandLineFlagConstraintsRuntime.cpp
>>>>> @@ -119,6 +119,17 @@
>>>>>      }
>>>>>    }
>>>>>
>>>>> +Flag::Error CrashOnOutOfMemoryErrorFunc(bool value, bool verbose) {
>>>>> +  char buffer[O_BUFLEN];
>>>>> +  os::check_dump_limit(buffer, sizeof(buffer));
>>>>> +  if (!VMError::coredump_status) {
>>>>> +    CommandLineError::print(verbose,
>>>>> +                            "%s\n", VMError::coredump_message);
>>>>> +    return Flag::VIOLATES_CONSTRAINT;
>>>>> +  }
>>>>> +  return Flag::SUCCESS;
>>>>> +}
>>>>> +
>>>>>    Flag::Error PerfDataSamplingIntervalFunc(intx value, bool verbose) {
>>>>>      if ((value % PeriodicTask::interval_gran != 0)) {
>>>>>        CommandLineError::print(verbose,
>>>>> diff --git a/src/share/vm/runtime/commandLineFlagConstraintsRuntime.hpp
>>>>> b/src/share/vm/runtime/commandLineFlagConstraintsRuntime.hpp
>>>>> --- a/src/share/vm/runtime/commandLineFlagConstraintsRuntime.hpp
>>>>> +++ b/src/share/vm/runtime/commandLineFlagConstraintsRuntime.hpp
>>>>> @@ -43,6 +43,8 @@
>>>>>    Flag::Error BiasedLockingBulkRevokeThresholdFunc(intx value, bool
>>>>> verbose);
>>>>>    Flag::Error BiasedLockingDecayTimeFunc(intx value, bool verbose);
>>>>>
>>>>> +Flag::Error CrashOnOutOfMemoryErrorFunc(bool value, bool verbose);
>>>>> +
>>>>>    Flag::Error PerfDataSamplingIntervalFunc(intx value, bool verbose);
>>>>>
>>>>>    #endif /* SHARE_VM_RUNTIME_COMMANDLINEFLAGCONSTRAINTSRUNTIME_HPP */
>>>>> diff --git a/src/share/vm/runtime/globals.hpp
>>>>> b/src/share/vm/runtime/globals.hpp
>>>>> --- a/src/share/vm/runtime/globals.hpp
>>>>> +++ b/src/share/vm/runtime/globals.hpp
>>>>> @@ -1401,6 +1401,7 @@
>>>>>      product(bool, CrashOnOutOfMemoryError, false,
>>>>> \
>>>>>              "JVM aborts, producing an error log and core/mini dump, on
>>>>> the
>>>>> "  \
>>>>>              "first occurrence of an out-of-memory error")
>>>>> \
>>>>> +          constraint(CrashOnOutOfMemoryErrorFunc,AfterErgo)
>>>>> \
>>>>>
>>>>> \
>>>>>      /* tracing */
>>>>> \
>>>>>
>>>>> \
>>>>> diff --git a/src/share/vm/utilities/vmError.hpp
>>>>> b/src/share/vm/utilities/vmError.hpp
>>>>> --- a/src/share/vm/utilities/vmError.hpp
>>>>> +++ b/src/share/vm/utilities/vmError.hpp
>>>>> @@ -65,14 +65,6 @@
>>>>>      // so use thread id instead of Thread* to identify thread.
>>>>>      static volatile intptr_t first_error_tid;
>>>>>
>>>>> -  // Core dump status, false if we have been unable to write a
>>>>> core/minidump for some reason
>>>>> -  static bool coredump_status;
>>>>> -
>>>>> -  // When coredump_status is set to true this will contain the
>>>>> name/path to the core/minidump,
>>>>> -  // if coredump_status if false, this will (hopefully) contain a
>>>>> useful error explaining why
>>>>> -  // no core/minidump has been written to disk
>>>>> -  static char coredump_message[O_BUFLEN];
>>>>> -
>>>>>
>>>>>      // set signal handlers on Solaris/Linux or the default exception
>>>>> filter
>>>>>      // on Windows, to handle recursive crashes.
>>>>> @@ -111,6 +103,14 @@
>>>>>      // Record status of core/minidump
>>>>>      static void record_coredump_status(const char* message, bool
>>>>> status);
>>>>>
>>>>> +  // Core dump status, false if we have been unable to write a
>>>>> core/minidump for some reason
>>>>> +  static bool coredump_status;
>>>>> +
>>>>> +  // When coredump_status is set to true this will contain the
>>>>> name/path to the core/minidump,
>>>>> +  // if coredump_status if false, this will (hopefully) contain a
>>>>> useful error explaining why
>>>>> +  // no core/minidump has been written to disk
>>>>> +  static char coredump_message[O_BUFLEN];
>>>>> +
>>>>>      // support for VM.info diagnostic command
>>>>>      static void print_vm_info(outputStream* st);
>>>>>
>>>>>
>>>>> Thanks,
>>>>> Yuji
>>>>>
>>>>
>

From marcus.larsson at oracle.com  Tue Mar 15 09:17:33 2016
From: marcus.larsson at oracle.com (Marcus Larsson)
Date: Tue, 15 Mar 2016 10:17:33 +0100
Subject: RFR: 8146879: Add option for handling existing log files in UL
In-Reply-To: <56E6D385.4000708@oracle.com>
References: <5697B7F2.50104@oracle.com> <56D578F9.6090602@oracle.com>
	<56D5A1BB.6030403@oracle.com> <56E2D478.3090202@oracle.com>
	<56E2D7AA.1060803@oracle.com> <56E2D8AD.8040902@oracle.com>
	<56E54911.9090807@oracle.com> <56E692A4.6010204@oracle.com>
	<56E6D385.4000708@oracle.com>
Message-ID: <56E7D32D.1010408@oracle.com>


On 03/14/2016 04:06 PM, Dmitry Samersoff wrote:
> Marcus,
>
> 1.
> Most of log analyzing tools utilize the fact that filesystem returns
> files in alphabetical order or uses scandir()/alphasort()
>
> So good log rotation strategy is log, log.001, log.002, log.003 etc
> where "log" is current one and log.MAX_COUNT is the oldest one.

The current log rotation scheme keeps the current log file as just 
"log", and when rotating it will move this log to "log.X", where X is 
initially 1 and increases at each rotation. It will simply overwrite the 
file if it already exists. When X reaches the file-count, it wraps 
around and starts over from 1 again. There's no guarantee that the 
highest number is the oldest/youngest file.

This patch doesn't change the rotation scheme, it only makes rotation 
the default, with the addition of a smarter choice of initial X value, 
namely either the next unused X or the oldest X based on mtime if all 
X:es are in use. It's a best-effort to prevent accidental overwriting of 
your logs, but it doesn't guarantee anything.

>
> To save startup time we can declare that log.001 is the oldest one, and
> log.MAX_COUNT is the newest one but log.002 that is more recent than
> log.001 and log.003 seems not obvious to me.

This is a different rotation scheme and would require rotating every log 
file at each rotation in order to keep the invariant. I'm not against 
changing the current scheme, but I think it's outside the scope of this 
change and would prefer to do it separately in that case.

>
> Also it's very common that log producer and log analyzer resides on a
> different machines (e.g. with NFS share) and log file mtime could be
> unrelated to the age of VM events in this log. So we shouldn't use log
> mtime for any decision.

The mtime is just our best guess in the case we don't know which file to 
delete.

>
> 2.
> rename() can cause a burden in complicated environment, so it's better
> to check most common cases (permissions, PATH_MAX, etc) explicitly, as
> early as possible, to give meaningful error message to a user.

I see. I wanted to avoid the complexity, but if you feel it is important 
I'll add some checks for these things.

>
> See also below.
>
> On 2016-03-14 13:29, Marcus Larsson wrote:
>> Hi,
>>
>> Thanks for looking at this!
>>
>> On 03/13/2016 12:03 PM, Dmitry Samersoff wrote:
>>> Marcus,
>>>
>>> 1. os_posix/os_windows.cpp
>>>
>>> Windows version is expensive and change access time of a log file.
>>>
>>> So it's better to create os::get_mtime() that uses stat() for both,
>>> windows and posix and LogFileOutput::calc_mtime_diff().
>>>
>>> Also it saves a bit of compiler power unrolling loop.
>> This is similar to my first approach but I ran into problems with it
>> because st_mtime is a struct timespec on posix and a time_t on windows.
>>  From the start I wanted better precision than seconds, which is why I
>> wanted to use CompareFileTime(). Given that we can not depend on any
>> particular precision, perhaps it's better to just use stat() on windows
>> as well, like you say.
> OK.
>
>>> 2. log.cpp
>>>
>>> size_t number_of_lines_with_substring_in_file()
>>>
>>> When you plan to use it ? Current implementation is rather expensive,
>>> but if you plan to run it manually only, I'm OK with it.
>> It's used for testing only.
> If you plan to use it in jprt or nightly - please change it.

It's part of the internal vm tests, so it should be in both. I don't see 
the problem though. It's used once to verify a very small log file. The 
test completes in a matter of milliseconds, and I don't think we should 
worry about it.

>
>>> 3. logFileOutput.cpp
>>>
>>> 82.
>>> Please, change file_exists to can_be_rotated() and check that log output
>>> is a *regular file* and you have a write access to it.
>> I guess it would be useful to give an error in the case someone
>> specifies logging to something that's not a regular file. Checking for
>> write permissions shouldn't be necessary here though. If any of the
>> required operations fail because of lacking permissions we'll notice
>> that at that time.
> Logging to /dev/tape or /dev/console is perfectly valid usecase but we
> should detect it and don't attempt to rotate or truncate device ever if
> sysadmin enable rotation by mistake.
>
> Also common sysadmin mistake is a log pointing to directory or presence
> of log.NNN directory - we should detect it as well.
>
> One more case when we shouldn't rotate - log is symlink
>
>
>>> 87.
>>> Please, don't use floating point math. Just allocate 10 extra bytes, it
>>> fit all possible file length value.
>> I can use a fixed size for the allocations, but we will still want to
>> figure out how many numbers should be used so that we can use the
>> appropriate amount of padding. Logging with 10 files in rotation should
>> use log.0 to log.9, not log.0000000 to log.0000009.
> It's OK to always write log.001 etc or use something like:
>
> return (num < 10) ? 1 : (num < 100) ? 2 : 5;

Ok.

>
>>> 93.
>>> if we have log.01, log.03 etc this function creates log.02 instead of
>>> log.04.
>> Yes, that's intentional.
> log.01 and log.03 both containing older data than log.02 seems not
> obvious for me.
>
> Could we always use largest possible number?

Like I said, this is the current rotation scheme, and I would prefer to 
not change it with this patch.

Thanks,
Marcus

>
>>> Sorry! I'm not follow logic of ll.118
>>> What happens if some log parsing tool change log file mtime?
>> We'll always prefer to overwrite the file that hasn't been modified for
>> the longest time.
> Log file mtime can be unrelated to the age of VM events in this file
> (think sysadmin do: vi log.003, :wq) so we shouldn't rely on mtime.
>
>>> Please, limit the number of old logs (FileCountOption) to some
>>> reasonable value (e.g. 999) and use binary search to find the name of a
>>> next file.
>> I can limit it, but I'm not sure we should make the effort of binary
>> searching for the file name. It's a one time search during startup and I
>> would expect most people to use around 10 files.
> OK,  as soon as DefaultRotationFileCount is less than 10
>
>>> Also please check full log file name against MAX_PATH constant.
>> Is it really necessary? Won't fopen() just fail and return the
>> appropriate error for this?
> rename errors is not always obvious. see comments above.
>
> -Dmitry
>
>> Thanks,
>> Marcus
>>
>>> -Dmitry
>>>
>>>
>>>
>>>
>>> On 2016-03-11 17:39, Marcus Larsson wrote:
>>>> Hi,
>>>>
>>>> On 2016-03-11 15:35, Bengt Rutisson wrote:
>>>>> Hi Marcus,
>>>>>
>>>>> On 2016-03-11 15:21, Marcus Larsson wrote:
>>>>>> Third time's the charm.
>>>>>>
>>>>>> Webrev:
>>>>>> http://cr.openjdk.java.net/~mlarsson/8146879/webrev.03/
>>>>> I had a quick look at the code changes. It is not really my area of
>>>>> the code, so I'll leave to someone else to formally review it.
>>>>>
>>>>> However, I downloaded the patch a played a bit with the logging. This
>>>>> is much more like the way I would like it! Thanks!
>>>>>
>>>>> So, from a functional perspective this looks good to me.
>>>>>
>>>> Thanks for the feedback!
>>>>
>>>> Marcus
>>>>
>>>>> Thanks,
>>>>> Bengt
>>>>>
>>>>>> This patch makes log file rotation the default. Default thresholds
>>>>>> are 5 rotated files with a target size of 20MiB. Truncating behavior
>>>>>> can be achieved by setting filecount to 0
>>>>>> (-Xlog::myfile.log::filecount=0).
>>>>>>
>>>>>> If a log file already exists during log file initialization it will
>>>>>> be rotated. If any of the target file names (file.0 to file.4 in the
>>>>>> default case) are available, that filename will be used for the
>>>>>> existing log. If all names are taken the VM will attempt to overwrite
>>>>>> the oldest file.
>>>>>>
>>>>>> This should prevent unlimited log file creations and avoid accidental
>>>>>> loss of log files from previous runs. The default thresholds (5
>>>>>> files, 20MiB each) is just a suggestion. If you think it should be
>>>>>> higher/lower let me know.
>>>>>>
>>>>>> Tested with included internal VM tests through RBT.
>>>>>>
>>>>>> Thanks,
>>>>>> Marcus
>>>>>>
>>>>>> On 2016-03-01 15:05, Marcus Larsson wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> After some offline discussions I'm withdrawing this patch. I will
>>>>>>> instead investigate if I can achieve similar behavior using log
>>>>>>> rotation as the default.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Marcus
>>>>>>>
>>>>>>> On 03/01/2016 12:11 PM, Marcus Larsson wrote:
>>>>>>>> Hi again,
>>>>>>>>
>>>>>>>> Taking a different approach to this.
>>>>>>>>
>>>>>>>> New webrev:
>>>>>>>> http://cr.openjdk.java.net/~mlarsson/8146879/webrev.01/
>>>>>>>>
>>>>>>>> Existing files will now by default be renamed/archived with a .X
>>>>>>>> suffix where X is the lowest number such that the resulting file
>>>>>>>> name is available (jvm.log becomes jvm.log.0). A mode option for
>>>>>>>> controlling this behavior has been added as well. It can be set to
>>>>>>>> archive, append, or truncate (i.e. -Xlog::jvm.log::mode=truncate).
>>>>>>>>
>>>>>>>> Tested with included jtreg test through JPRT.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Marcus
>>>>>>>>
>>>>>>>> On 01/14/2016 04:00 PM, Marcus Larsson wrote:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> Please review the following patch to make sure UL truncates
>>>>>>>>> existing log files before writing to them. Since files are opened
>>>>>>>>> in append mode, truncation isn't done automatically, so instead
>>>>>>>>> the patch adds an attempt to remove the log file before opening it.
>>>>>>>>>
>>>>>>>>> Webrev:
>>>>>>>>> http://cr.openjdk.java.net/~mlarsson/8146879/webrev.00/
>>>>>>>>>
>>>>>>>>> Issue:
>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8146879
>>>>>>>>>
>>>>>>>>> Testing:
>>>>>>>>> Included test through JPRT
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Marcus
>


From erik.joelsson at oracle.com  Tue Mar 15 10:36:50 2016
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Tue, 15 Mar 2016 11:36:50 +0100
Subject: RFR: JDK-8151653: Hotspot build does not respect
	--enable-openjdk-only
In-Reply-To: <56E75B7E.1020400@oracle.com>
References: <56E2F2C7.9090301@oracle.com> <56E6123D.9020209@oracle.com>
	<56E75B7E.1020400@oracle.com>
Message-ID: <56E7E5C2.3080108@oracle.com>

Hello,

New webrev where "closed" is replaced with "custom".
http://cr.openjdk.java.net/~erikj/8151653/webrev.hotspot.02/

Also, to clarify the refactoring of trace.xml here on the list too. I 
needed to create 2 separate entry points, one open and one closed 
trace.xml. The way xinclude works, I can't just include the open 
trace.xml from the closed one, I have to refactor them to instead 
include the same content. That's why I moved the contents of the current 
open trace.xml to two new files, one for each XML-tag at that level in 
the XML.

/Erik

On 2016-03-15 01:46, David Holmes wrote:
> On 14/03/2016 11:22 AM, David Holmes wrote:
>> Hi Erik,
>>
>> On 12/03/2016 2:31 AM, Erik Joelsson wrote:
>>> Hello,
>>>
>>> When building hotspot with closed sources present and configuring with
>>> --enable-openjdk-only, various closed parts are included in the build
>>> anyway, at least on Windows. This needs to be fixed in preparation for
>>> the new hotspot build for build output comparisons to be meaningful
>>> between the old and new.
>>>
>>> The major culprit here, which applies to all platforms, is the trace
>>> source generation. The base trace.xml uses XInclude to explicitly and
>>> unconditionally include closed xml files if present. I'm fixing this by
>>> introducing a closed version of trace.xml which includes the open and
>>> closed parts, while the open trace.xml only includes the open parts.
>>
>> You've also done a significant amount of refactoring of that file and
>> split it into three parts. It's hard to spot the actual functional
>> differences in all that.
>
> Sorry that was a bit terse. It would have been clearer if you had 
> explained about the refactoring. I can see why the refactoring was 
> needed.
>
> Thanks,
> David
> -----
>
>> Given we have distinct directories from which we locate files it is a
>> pity to introduce something like this:
>>
>>   XML_DEPS += $(TraceAltSrcDir)/traceeventsclosed.xml
>>
>> where traceevents.xml is now traceeventsclosed.xml. This "alt src"
>> mechanism was supposed to abstract away the details of any particular
>> alternative configuration so that we didn't hardcode "closed" all over
>> the place. Other community members are supposed to be able to utilize
>> these mechanisms for their own customized build environments.
>>
>>> The rest of the changes are just for Windows, making sure the OPENJDK
>>> variable is propagated into the nmake build and making all conditionals
>>> on including closed source also check that variable.
>>
>> make/windows/build.make
>>
>> The combination !openjdk && !exists "closed" should be an error.
>>
>> As a meta-comment I think we've lost the plot somewhat with these "alt"
>> locations and how we manage them. The Oracle "closed" variants should
>> only be used when not trying to build OpenJDK (even if the files exist
>> in a forest), but other custom implementations may work in conjunction
>> with an OpenJDK build. To that end the "do nothing if building OpenJDK"
>> should be located within the "alt" files themselves, not at the point of
>> inclusion/use in the open files.
>>
>> David
>> -----
>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8151653
>>> Webrev:
>>> http://cr.openjdk.java.net/~erikj/8151653/webrev.hotspot.01/index.html
>>>
>>> /Erik


From david.holmes at oracle.com  Tue Mar 15 12:33:49 2016
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 15 Mar 2016 22:33:49 +1000
Subject: RFR: JDK-8151653: Hotspot build does not respect
	--enable-openjdk-only
In-Reply-To: <56E7E5C2.3080108@oracle.com>
References: <56E2F2C7.9090301@oracle.com> <56E6123D.9020209@oracle.com>
	<56E75B7E.1020400@oracle.com> <56E7E5C2.3080108@oracle.com>
Message-ID: <56E8012D.3030202@oracle.com>

Thanks Erik! Looks okay to me.

David

On 15/03/2016 8:36 PM, Erik Joelsson wrote:
> Hello,
>
> New webrev where "closed" is replaced with "custom".
> http://cr.openjdk.java.net/~erikj/8151653/webrev.hotspot.02/
>
> Also, to clarify the refactoring of trace.xml here on the list too. I
> needed to create 2 separate entry points, one open and one closed
> trace.xml. The way xinclude works, I can't just include the open
> trace.xml from the closed one, I have to refactor them to instead
> include the same content. That's why I moved the contents of the current
> open trace.xml to two new files, one for each XML-tag at that level in
> the XML.
>
> /Erik
>
> On 2016-03-15 01:46, David Holmes wrote:
>> On 14/03/2016 11:22 AM, David Holmes wrote:
>>> Hi Erik,
>>>
>>> On 12/03/2016 2:31 AM, Erik Joelsson wrote:
>>>> Hello,
>>>>
>>>> When building hotspot with closed sources present and configuring with
>>>> --enable-openjdk-only, various closed parts are included in the build
>>>> anyway, at least on Windows. This needs to be fixed in preparation for
>>>> the new hotspot build for build output comparisons to be meaningful
>>>> between the old and new.
>>>>
>>>> The major culprit here, which applies to all platforms, is the trace
>>>> source generation. The base trace.xml uses XInclude to explicitly and
>>>> unconditionally include closed xml files if present. I'm fixing this by
>>>> introducing a closed version of trace.xml which includes the open and
>>>> closed parts, while the open trace.xml only includes the open parts.
>>>
>>> You've also done a significant amount of refactoring of that file and
>>> split it into three parts. It's hard to spot the actual functional
>>> differences in all that.
>>
>> Sorry that was a bit terse. It would have been clearer if you had
>> explained about the refactoring. I can see why the refactoring was
>> needed.
>>
>> Thanks,
>> David
>> -----
>>
>>> Given we have distinct directories from which we locate files it is a
>>> pity to introduce something like this:
>>>
>>>   XML_DEPS += $(TraceAltSrcDir)/traceeventsclosed.xml
>>>
>>> where traceevents.xml is now traceeventsclosed.xml. This "alt src"
>>> mechanism was supposed to abstract away the details of any particular
>>> alternative configuration so that we didn't hardcode "closed" all over
>>> the place. Other community members are supposed to be able to utilize
>>> these mechanisms for their own customized build environments.
>>>
>>>> The rest of the changes are just for Windows, making sure the OPENJDK
>>>> variable is propagated into the nmake build and making all conditionals
>>>> on including closed source also check that variable.
>>>
>>> make/windows/build.make
>>>
>>> The combination !openjdk && !exists "closed" should be an error.
>>>
>>> As a meta-comment I think we've lost the plot somewhat with these "alt"
>>> locations and how we manage them. The Oracle "closed" variants should
>>> only be used when not trying to build OpenJDK (even if the files exist
>>> in a forest), but other custom implementations may work in conjunction
>>> with an OpenJDK build. To that end the "do nothing if building OpenJDK"
>>> should be located within the "alt" files themselves, not at the point of
>>> inclusion/use in the open files.
>>>
>>> David
>>> -----
>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8151653
>>>> Webrev:
>>>> http://cr.openjdk.java.net/~erikj/8151653/webrev.hotspot.01/index.html
>>>>
>>>> /Erik
>

From yasuenag at gmail.com  Tue Mar 15 14:31:39 2016
From: yasuenag at gmail.com (Yasumasa Suenaga)
Date: Tue, 15 Mar 2016 23:31:39 +0900
Subject: JDK-8148659: Add all option to JSnap
In-Reply-To: <56D84E30.4090902@gmail.com>
References: <56ACDB68.9080505@gmail.com> <56D8423B.2020509@oracle.com>
	<56D84E30.4090902@gmail.com>
Message-ID: <56E81CCB.4020404@gmail.com>

Hi all,

I updated webrev to adapt to current repos. Could you review it?

    http://cr.openjdk.java.net/~ysuenaga/JDK-8148659/webrev.01/


Thanks,

Yasumasa


On 2016/03/03 23:46, Yasumasa Suenaga wrote:
> Hi Dmitry,
> 
>> Overall direction is to support jhsdb as the only entry point for SA and
>> all coredump related staff.
> 
> I'm working on another issue (JDK-8151181) for it.
>    http://mail.openjdk.java.net/pipermail/serviceability-dev/2016-March/019007.html
> 
> After that, I will work for this issue (JDK-8148659) and adding all option
> to JSnap.
>    http://mail.openjdk.java.net/pipermail/serviceability-dev/2016-March/018962.html
> 
> 
> Thanks,
> 
> Yasumasa
> 
> 
> On 2016/03/03 22:55, Dmitry Samersoff wrote:
>> Yasumasa,
>>
>> Overall direction is to support jhsdb as the only entry point for SA and
>> all coredump related staff.
>>
>> Could you move JSnap "into jhsdb".
>>
>> And this change requires CCC approval (I'll file it for you)
>>
>> -Dmitry
>>
>> On 2016-01-30 18:48, Yasumasa Suenaga wrote:
>>> I want to add -a (all) option to JSnap because JSnap is very useful to analyze core image.
>>>
>>> Currently, JSnap can show PerfDataEntry which namespace is java.* or com.sun.* .
>>> We can use jcmd with PerfCounter.print when we want to attach live process, however,
>>> as JDK-6224040 shows, we have to use JSnap.
>>>
>>> In terms of core image analysis, -a option is very useful for troubleshooting.
>>>
>>> I uploaded a webrev for this enhancement.
>>> Could you review it?
>>>
>>>     http://cr.openjdk.java.net/~ysuenaga/JDK-8148659/webrev.00/
>>>
>>> I'm jdk9 committer, however I cannot access JPRT.
>>> So I need a sponsor.
>>>
>>>
>>> Thanks,
>>>
>>> Yasumasa
>>>
>>
>>

From robbin.ehn at oracle.com  Tue Mar 15 20:31:51 2016
From: robbin.ehn at oracle.com (Robbin Ehn)
Date: Tue, 15 Mar 2016 21:31:51 +0100
Subject: RFR(m): 8150015: Integrate TraceTime with Unified Logging more
	seamlessly
Message-ID: <56E87137.4080109@oracle.com>

Hi, please review this enhancement.

This adds support for multiple UL tags in TraceTime.

Bug: https://bugs.openjdk.java.net/browse/JDK-8150015/
Webrev: http://cr.openjdk.java.net/~rehn/8150015/v1/webrev/

Tested with jprt hotspot and manually tested log output.

Thanks!

/Robbin

From gerard.ziemski at oracle.com  Tue Mar 15 20:46:42 2016
From: gerard.ziemski at oracle.com (Gerard Ziemski)
Date: Tue, 15 Mar 2016 15:46:42 -0500
Subject: RFR: 8146879: Add option for handling existing log files in UL
In-Reply-To: <56E697F9.7020301@oracle.com>
References: <5697B7F2.50104@oracle.com> <56D578F9.6090602@oracle.com>
	<56D5A1BB.6030403@oracle.com> <56E2D478.3090202@oracle.com>
	<D794E59F-5B0F-463E-A855-1F185330BD27@oracle.com>
	<56E697F9.7020301@oracle.com>
Message-ID: <94EB6432-260A-4DA8-89A6-DA4CB717CEF7@oracle.com>

hi Marcus,

Sorry for getting back so late, but I got sick last Friday.

> On Mar 14, 2016, at 5:52 AM, Marcus Larsson <marcus.larsson at oracle.com> wrote:
> 
>> 
>> -----------------------------------------------
>> #3 File src/share/vm/logging/log.cpp
>> 
>> The number_of_lines_with_substring_in_file() function will not count the substrings that happen to lay across the boundary at sizeof(buf). For example with:
>> 
>>  char buf[16];
>> 
>> and file consisting of ?12345678901234gerard1234567890? it will return 0 for number_of_lines_with_substring_in_file(file, ?gerard")
> 
> Yeah I'm aware of this limitation. It's only used in the test though, where I'm hoping it won't be a problem. Would a comment about this be enough?

It would be very unfortunate if the test failed because of some corner case involving this limitation. Since the code is not on a performance path, and only used in the test, couldn?t we use fseek(); rewind(); to find the buffer size we need, and then use NEW_C_HEAP_ARRAY() to allocate exactly as much memory as we need?


cheers


> Seems like a good idea to me.
> 
> Thanks,
> Marcus
> 
>> 
>> 
>>> On Mar 11, 2016, at 8:21 AM, Marcus Larsson <marcus.larsson at oracle.com> wrote:
>>> 
>>> Third time's the charm.
>>> 
>>> Webrev:
>>> http://cr.openjdk.java.net/~mlarsson/8146879/webrev.03/
>>> 
>>> This patch makes log file rotation the default. Default thresholds are 5 rotated files with a target size of 20MiB. Truncating behavior can be achieved by setting filecount to 0 (-Xlog::myfile.log::filecount=0).
>>> 
>>> If a log file already exists during log file initialization it will be rotated. If any of the target file names (file.0 to file.4 in the default case) are available, that filename will be used for the existing log. If all names are taken the VM will attempt to overwrite the oldest file.
>>> 
>>> This should prevent unlimited log file creations and avoid accidental loss of log files from previous runs. The default thresholds (5 files, 20MiB each) is just a suggestion. If you think it should be higher/lower let me know.
>>> 
>>> Tested with included internal VM tests through RBT.
>>> 
>>> Thanks,
>>> Marcus
>>> 
>>> On 2016-03-01 15:05, Marcus Larsson wrote:
>>>> Hi,
>>>> 
>>>> After some offline discussions I'm withdrawing this patch. I will instead investigate if I can achieve similar behavior using log rotation as the default.
>>>> 
>>>> Thanks,
>>>> Marcus
>>>> 
>>>> On 03/01/2016 12:11 PM, Marcus Larsson wrote:
>>>>> Hi again,
>>>>> 
>>>>> Taking a different approach to this.
>>>>> 
>>>>> New webrev:
>>>>> http://cr.openjdk.java.net/~mlarsson/8146879/webrev.01/
>>>>> 
>>>>> Existing files will now by default be renamed/archived with a .X suffix where X is the lowest number such that the resulting file name is available (jvm.log becomes jvm.log.0). A mode option for controlling this behavior has been added as well. It can be set to archive, append, or truncate (i.e. -Xlog::jvm.log::mode=truncate).
>>>>> 
>>>>> Tested with included jtreg test through JPRT.
>>>>> 
>>>>> Thanks,
>>>>> Marcus
>>>>> 
>>>>> On 01/14/2016 04:00 PM, Marcus Larsson wrote:
>>>>>> Hi,
>>>>>> 
>>>>>> Please review the following patch to make sure UL truncates existing log files before writing to them. Since files are opened in append mode, truncation isn't done automatically, so instead the patch adds an attempt to remove the log file before opening it.
>>>>>> 
>>>>>> Webrev:
>>>>>> http://cr.openjdk.java.net/~mlarsson/8146879/webrev.00/
>>>>>> 
>>>>>> Issue:
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8146879
>>>>>> 
>>>>>> Testing:
>>>>>> Included test through JPRT
>>>>>> 
>>>>>> Thanks,
>>>>>> Marcus


From david.holmes at oracle.com  Wed Mar 16 05:14:20 2016
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 16 Mar 2016 15:14:20 +1000
Subject: RFR(m): 8150015: Integrate TraceTime with Unified Logging more
	seamlessly
In-Reply-To: <56E87137.4080109@oracle.com>
References: <56E87137.4080109@oracle.com>
Message-ID: <56E8EBAC.3000603@oracle.com>

Hi Robbin,

Thanks for tackling this. :)

On 16/03/2016 6:31 AM, Robbin Ehn wrote:
> Hi, please review this enhancement.
>
> This adds support for multiple UL tags in TraceTime.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8150015/
> Webrev: http://cr.openjdk.java.net/~rehn/8150015/v1/webrev/

Initial query: why do so many .cpp files now include the timerTrace.hpp 
file yet have no other changes?

I'm still mulling over the verbosity of the new format. You may recall 
there was a lot of discussion about this last time round :)

Thanks,
David

> Tested with jprt hotspot and manually tested log output.
>
> Thanks!
>
> /Robbin

From david.holmes at oracle.com  Wed Mar 16 05:27:26 2016
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 16 Mar 2016 15:27:26 +1000
Subject: RFR(m): 8150015: Integrate TraceTime with Unified Logging more
	seamlessly
In-Reply-To: <56E8EBAC.3000603@oracle.com>
References: <56E87137.4080109@oracle.com> <56E8EBAC.3000603@oracle.com>
Message-ID: <56E8EEBE.9040208@oracle.com>

On 16/03/2016 3:14 PM, David Holmes wrote:
> Hi Robbin,
>
> Thanks for tackling this. :)
>
> On 16/03/2016 6:31 AM, Robbin Ehn wrote:
>> Hi, please review this enhancement.
>>
>> This adds support for multiple UL tags in TraceTime.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8150015/
>> Webrev: http://cr.openjdk.java.net/~rehn/8150015/v1/webrev/
>
> Initial query: why do so many .cpp files now include the timerTrace.hpp
> file yet have no other changes?

Okay this is because they already implicitly include timer.hpp but now 
have to include the new timerTrace.hpp. Fair enough.

Minor nit: src/share/vm/compiler/compileBroker.cpp - the include was not 
put in in alphabetical order.

> I'm still mulling over the verbosity of the new format. You may recall
> there was a lot of discussion about this last time round :)

Do we perhaps want to keep the wrapper classes in logTimer.hpp? 
Additional uses of TraceTime with UL can then either add their own 
wrappers or use the direct form you have added support for.

Thanks,
David

> Thanks,
> David
>
>> Tested with jprt hotspot and manually tested log output.
>>
>> Thanks!
>>
>> /Robbin

From robbin.ehn at oracle.com  Wed Mar 16 06:53:52 2016
From: robbin.ehn at oracle.com (Robbin Ehn)
Date: Wed, 16 Mar 2016 07:53:52 +0100
Subject: RFR(m): 8150015: Integrate TraceTime with Unified Logging more
	seamlessly
In-Reply-To: <56E8EEBE.9040208@oracle.com>
References: <56E87137.4080109@oracle.com> <56E8EBAC.3000603@oracle.com>
	<56E8EEBE.9040208@oracle.com>
Message-ID: <56E90300.1040200@oracle.com>

Thanks David for looking at this!

On 03/16/2016 06:27 AM, David Holmes wrote:
> On 16/03/2016 3:14 PM, David Holmes wrote:
>> Hi Robbin,
>>
>> Thanks for tackling this. :)
>>
>> On 16/03/2016 6:31 AM, Robbin Ehn wrote:
>>> Hi, please review this enhancement.
>>>
>>> This adds support for multiple UL tags in TraceTime.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8150015/
>>> Webrev: http://cr.openjdk.java.net/~rehn/8150015/v1/webrev/
>>
>> Initial query: why do so many .cpp files now include the timerTrace.hpp
>> file yet have no other changes?
>
> Okay this is because they already implicitly include timer.hpp but now
> have to include the new timerTrace.hpp. Fair enough.
>
> Minor nit: src/share/vm/compiler/compileBroker.cpp - the include was not
> put in in alphabetical order.

Thanks

>
>> I'm still mulling over the verbosity of the new format. You may recall
>> there was a lot of discussion about this last time round :)
>

Yes :)

It's as verbose as gcTraceTime (which might be to verbose).

> Do we perhaps want to keep the wrapper classes in logTimer.hpp?
> Additional uses of TraceTime with UL can then either add their own
> wrappers or use the direct form you have added support for.

Either way is fine by me.

/Robbin

>
> Thanks,
> David
>
>> Thanks,
>> David
>>
>>> Tested with jprt hotspot and manually tested log output.
>>>
>>> Thanks!
>>>
>>> /Robbin

From bengt.rutisson at oracle.com  Wed Mar 16 10:38:05 2016
From: bengt.rutisson at oracle.com (Bengt Rutisson)
Date: Wed, 16 Mar 2016 11:38:05 +0100
Subject: RFR(m): 8150015: Integrate TraceTime with Unified Logging more
	seamlessly
In-Reply-To: <56E87137.4080109@oracle.com>
References: <56E87137.4080109@oracle.com>
Message-ID: <56E9378D.5050706@oracle.com>


Hi Robbin,

On 2016-03-15 21:31, Robbin Ehn wrote:
> Hi, please review this enhancement.
>
> This adds support for multiple UL tags in TraceTime.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8150015/
> Webrev: http://cr.openjdk.java.net/~rehn/8150015/v1/webrev/

I think this is fine but I just wanted to mention an alternative 
approach. For the GC logging I introduced a GCTraceTimerImpl class and a 
GCTraceTime macro. See:

http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/file/4030d7f9946d/src/share/vm/gc/shared/gcTraceTime.inline.hpp#l146

If you do something similar the code on the call site would look like this:

TraceTime(Info, safepointcleanup) timer("deflating idle monitors");

instead of this:

TraceTime timer("deflating idle monitors", TRACETIME_LOG(Info, 
safepointcleanup));

Your call. I just wanted to mention it.

Thanks,
Bengt

>
> Tested with jprt hotspot and manually tested log output.
>
> Thanks!
>
> /Robbin


From robbin.ehn at oracle.com  Wed Mar 16 12:33:41 2016
From: robbin.ehn at oracle.com (Robbin Ehn)
Date: Wed, 16 Mar 2016 13:33:41 +0100
Subject: RFR(xs): 8151993: Remove inclusion of inline.hpp in log.hpp
Message-ID: <56E952A5.6050708@oracle.com>

Hi, please review this small change.

This also change allocation methods.

Bug: https://bugs.openjdk.java.net/browse/JDK-8151993/
Webrev: http://cr.openjdk.java.net/~rehn/8151993/webrev/

Thanks!

/Robbin

From dmitry.samersoff at oracle.com  Wed Mar 16 14:14:51 2016
From: dmitry.samersoff at oracle.com (Dmitry Samersoff)
Date: Wed, 16 Mar 2016 17:14:51 +0300
Subject: RFR(S): JDK-8151991 jvmti diagnostics commands requires
	INCLUDE_SERVICES
In-Reply-To: <56E94B3B.2060208@oracle.com>
References: <56E858BD.4030401@oracle.com> <56E867C8.4070200@oracle.com>
	<56E94B3B.2060208@oracle.com>
Message-ID: <56E96A5B.5000105@oracle.com>

Everybody,

Please, review small fix.

http://cr.openjdk.java.net/~dsamersoff/JDK-8151991/webrev.01/

New diagnostic command (JVMTI.agent_load) should be guarded by
#if INCLUDE_SERVICES and don't brake minimal VM build.

-Dmitry

-- 
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the sources.

From kim.barrett at oracle.com  Wed Mar 16 16:13:41 2016
From: kim.barrett at oracle.com (Kim Barrett)
Date: Wed, 16 Mar 2016 12:13:41 -0400
Subject: RFR(xs): 8151993: Remove inclusion of inline.hpp in log.hpp
In-Reply-To: <56E952A5.6050708@oracle.com>
References: <56E952A5.6050708@oracle.com>
Message-ID: <816216C7-85B9-4E1F-8A4A-BBB5FFD728D4@oracle.com>

> On Mar 16, 2016, at 8:33 AM, Robbin Ehn <robbin.ehn at oracle.com> wrote:
> 
> Hi, please review this small change.
> 
> This also change allocation methods.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8151993/
> Webrev: http://cr.openjdk.java.net/~rehn/8151993/webrev/
> 
> Thanks!
> 
> /Robbin

------------------------------------------------------------------------------
src/share/vm/logging/log.hpp
Changing this:
 138       char* newbuf = NEW_C_HEAP_ARRAY(char, newbuf_len, mtLogging);
to this:
 137       char* newbuf = (char*) os::malloc(sizeof(char) * newbuf_len, mtLogging);

New code is missing out of memory handling that was present in the old
code.  New code will just try to use newbuf, with bad results if the
allocation failed.

New code is missing ASSERT-conditionalized PrintMallocFree support
that was present in the old.  I don't know how important this is,
given that we also have PrintMalloc.  (And I have to wonder why we
have both PrintMalloc (develop) and PrintMallocFree (notproduct).)

------------------------------------------------------------------------------


From varming at gmail.com  Wed Mar 16 16:27:21 2016
From: varming at gmail.com (Carsten Varming)
Date: Wed, 16 Mar 2016 12:27:21 -0400
Subject: RFR(xs): 8151993: Remove inclusion of inline.hpp in log.hpp
In-Reply-To: <816216C7-85B9-4E1F-8A4A-BBB5FFD728D4@oracle.com>
References: <56E952A5.6050708@oracle.com>
	<816216C7-85B9-4E1F-8A4A-BBB5FFD728D4@oracle.com>
Message-ID: <CAP_pwnWb0c4fSHCkX1PV9ZuPC8YGjufuXvFSSDUW1j7DQS51HA@mail.gmail.com>

Dear Robbin,

It would be much nicer if the code was changed to call a new method in a
cpp file (this is clearly a slow path) and the new method could use a
bufferedStream to automatically expand the needed buffer. You would need to
implement vprint on bufferedStream to make is expand when needed, but that
should be doable.

Carsten

On Wed, Mar 16, 2016 at 12:13 PM, Kim Barrett <kim.barrett at oracle.com>
wrote:

> > On Mar 16, 2016, at 8:33 AM, Robbin Ehn <robbin.ehn at oracle.com> wrote:
> >
> > Hi, please review this small change.
> >
> > This also change allocation methods.
> >
> > Bug: https://bugs.openjdk.java.net/browse/JDK-8151993/
> > Webrev: http://cr.openjdk.java.net/~rehn/8151993/webrev/
> >
> > Thanks!
> >
> > /Robbin
>
>
> ------------------------------------------------------------------------------
> src/share/vm/logging/log.hpp
> Changing this:
>  138       char* newbuf = NEW_C_HEAP_ARRAY(char, newbuf_len, mtLogging);
> to this:
>  137       char* newbuf = (char*) os::malloc(sizeof(char) * newbuf_len,
> mtLogging);
>
> New code is missing out of memory handling that was present in the old
> code.  New code will just try to use newbuf, with bad results if the
> allocation failed.
>
> New code is missing ASSERT-conditionalized PrintMallocFree support
> that was present in the old.  I don't know how important this is,
> given that we also have PrintMalloc.  (And I have to wonder why we
> have both PrintMalloc (develop) and PrintMallocFree (notproduct).)
>
>
> ------------------------------------------------------------------------------
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20160316/297e2e20/attachment.html>

From jon.masamitsu at oracle.com  Wed Mar 16 18:13:04 2016
From: jon.masamitsu at oracle.com (Jon Masamitsu)
Date: Wed, 16 Mar 2016 11:13:04 -0700
Subject: RFR: JDK-8151674: STW phases at Concurrent GC should count in
	PerfCounter
In-Reply-To: <56E242B5.1070206@gmail.com>
References: <56E242B5.1070206@gmail.com>
Message-ID: <56E9A230.1060607@oracle.com>



On 03/10/2016 07:59 PM, Yasumasa Suenaga wrote:
> Hi all,
>
> This review request continues from:
>    http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2016-March/016774.html
>    http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2016-March/016896.html
>
> I wonder that STW phases (Remark and Cleanup) at G1 are not counted in jstat FGC column.
> For example, Initial Mark and Remark at CMS are counted as FGC.
> We discussed on hotspot-gc-dev for this issue, and I proposed to add new PerfCounter
> for CGC STW phases.
>
> I uploaded webrev. Could you review it?
>      hotspot: http://cr.openjdk.java.net/~ysuenaga/JDK-8151674/webrev.00/hotspot/
>          jdk: http://cr.openjdk.java.net/~ysuenaga/JDK-8151674/webrev.00/jdk/
>
> For compatibility, this patch works the same as the current by default.
> If you set -XX:+EnableConcGCPerfCounter, CGC counter will work fine.
> (I want to set +EnableConcGCPerfCounter by default)

I would prefer not to have the flag (EnableConcGCPerfCounte)
and just make the change for CMS.  This is a change for a major
release and I think we can accept the incompatibility.

http://cr.openjdk.java.net/~ysuenaga/JDK-8151674/webrev.00/hotspot/src/share/vm/gc/g1/g1MonitoringSupport.cpp.udiff.html

+ // name "collector.2". In a generational collector this would be the
+ // STW phases in concurrent collection.
+ _conc_collection_counters =
+ new CollectorCounters("G1 stop-the-world phases", 2);


Is there a hard connection between these phases and a generational
collector (i.e., should the "In a generational collector this would be the"
be dropped in the comment)?

A comment such as

// name "collector.2". STW phases as part of a concurrent collection.


A set of JDK changes had been previously been reviewed (not by me). Are 
these
the same?

http://cr.openjdk.java.net/~ysuenaga/JDK-8151674/webrev.00/jdk/


Jon


>
>
> I cannot access JPRT.
> So I need a sponsor.
>
>
> Thanks,
>
> Yasumasa


From ebaron at redhat.com  Wed Mar 16 21:27:24 2016
From: ebaron at redhat.com (Elliott Baron)
Date: Wed, 16 Mar 2016 17:27:24 -0400
Subject: [PATCH] JDK-8036559: Attach API does not allow root to connect to
	process owned by others
Message-ID: <56E9CFBC.2080808@redhat.com>

Hi,

I've been working on an updated patch for JDK-8036559, where root does 
not have the ability to attach to unprivileged users' JVMs. I originally 
mentioned this problem back in 2013, and proposed a patch only for Linux 
[1]. The result was that the fix had to provide support for all affected 
platforms, and to include tests.

We worked around this issue in our project, but I revisited this bug 
recently. I investigated the issue on Windows, which has a very 
different implementation from the other platforms. I discovered that 
this bug does not appear to affect Windows. Using the test programs 
attached to Red Hat Bugzilla bug #1311638 [2], I verified the correct 
behaviour using the following steps:
> (Open cmd.exe)
> runas /user:test cmd.exe
> runas /user:Administrator cmd.exe
>
> (In test's shell)
> set TMP=C:\Users\Public\java_temp
> cd C:\Users\Public\Documents
> javac AttachTarget.java
> java AttachTarget
>
> (In Administrator's shell)
> set TMP=C:\Users\Public\java_temp
> cd C:\Users\Public\Documents
> javac -cp .;C:\Progra~1\Java\jdk1.8.0_74\lib\tools.jar AttachClient.java
> java -cp .;C:\Progra~1\Java\jdk1.8.0_74\lib\tools.jar AttachClient
> (outputs 'Target ok: AttachTarget')

My updated patches target JDK 9, and includes support for Linux, 
Solaris, Mac OSX, and AIX. As far as tests are concerned, I'm not sure 
how to add tests for this bug, since doing so would require the test to 
be run as root. I am attaching the patches to this email, since I am not 
an OpenJDK committer and do not have access to cr.openjdk.java.net.

Thanks,
Elliott

[1] 
http://mail.openjdk.java.net/pipermail/serviceability-dev/2013-June/010077.html
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1311638
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jdk-attach-root-v4.patch
Type: text/x-patch
Size: 5981 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20160316/0d45c723/jdk-attach-root-v4-0001.patch>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: hotspot-attach-root-v4.patch
Type: text/x-patch
Size: 6183 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20160316/0d45c723/hotspot-attach-root-v4-0001.patch>

From yasuenag at gmail.com  Wed Mar 16 23:23:33 2016
From: yasuenag at gmail.com (Yasumasa Suenaga)
Date: Thu, 17 Mar 2016 08:23:33 +0900
Subject: RFR: JDK-8151674: STW phases at Concurrent GC should count in
	PerfCounter
In-Reply-To: <56E9A230.1060607@oracle.com>
References: <56E242B5.1070206@gmail.com>
	<56E9A230.1060607@oracle.com>
Message-ID: <CAGFVN2ATsvSfyzc-_AzBRXcUJMShENHog6XinvgyJiZBUMTXgQ@mail.gmail.com>

Hi Jon,

2016/03/17 3:25 "Jon Masamitsu" <jon.masamitsu at oracle.com>:
>
>
>
> On 03/10/2016 07:59 PM, Yasumasa Suenaga wrote:
>>
>> Hi all,
>>
>> This review request continues from:
>>
http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2016-March/016774.html
>>
http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2016-March/016896.html
>>
>> I wonder that STW phases (Remark and Cleanup) at G1 are not counted in
jstat FGC column.
>> For example, Initial Mark and Remark at CMS are counted as FGC.
>> We discussed on hotspot-gc-dev for this issue, and I proposed to add new
PerfCounter
>> for CGC STW phases.
>>
>> I uploaded webrev. Could you review it?
>>      hotspot:
http://cr.openjdk.java.net/~ysuenaga/JDK-8151674/webrev.00/hotspot/
>>          jdk:
http://cr.openjdk.java.net/~ysuenaga/JDK-8151674/webrev.00/jdk/
>>
>> For compatibility, this patch works the same as the current by default.
>> If you set -XX:+EnableConcGCPerfCounter, CGC counter will work fine.
>> (I want to set +EnableConcGCPerfCounter by default)
>
>
> I would prefer not to have the flag (EnableConcGCPerfCounte)
> and just make the change for CMS.  This is a change for a major
> release and I think we can accept the incompatibility.

Okay, I will remove this flag.

I added a comment to JBS about G1 initial mark.
I will upload new webrev after discussing for it.

>
http://cr.openjdk.java.net/~ysuenaga/JDK-8151674/webrev.00/hotspot/src/share/vm/gc/g1/g1MonitoringSupport.cpp.udiff.html
>
> + // name "collector.2". In a generational collector this would be the
> + // STW phases in concurrent collection.
> + _conc_collection_counters =
> + new CollectorCounters("G1 stop-the-world phases", 2);
>
>
> Is there a hard connection between these phases and a generational
> collector (i.e., should the "In a generational collector this would be
the"
> be dropped in the comment)?
>
> A comment such as
>
> // name "collector.2". STW phases as part of a concurrent collection.

Thanks, I will fix.

> A set of JDK changes had been previously been reviewed (not by me). Are
these
> the same?
>
> http://cr.openjdk.java.net/~ysuenaga/JDK-8151674/webrev.00/jdk/

Yes, same patch.

Yasumasa

> Jon
>
>
>
>>
>>
>> I cannot access JPRT.
>> So I need a sponsor.
>>
>>
>> Thanks,
>>
>> Yasumasa
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20160317/eabba6cb/attachment.html>

From robbin.ehn at oracle.com  Thu Mar 17 06:33:51 2016
From: robbin.ehn at oracle.com (Robbin Ehn)
Date: Thu, 17 Mar 2016 07:33:51 +0100
Subject: RFR(xs): 8151993: Remove inclusion of inline.hpp in log.hpp
In-Reply-To: <CAP_pwnWb0c4fSHCkX1PV9ZuPC8YGjufuXvFSSDUW1j7DQS51HA@mail.gmail.com>
References: <56E952A5.6050708@oracle.com>
	<816216C7-85B9-4E1F-8A4A-BBB5FFD728D4@oracle.com>
	<CAP_pwnWb0c4fSHCkX1PV9ZuPC8YGjufuXvFSSDUW1j7DQS51HA@mail.gmail.com>
Message-ID: <56EA4FCF.60107@oracle.com>

Hi Carsten, thanks for looking at this.

On 03/16/2016 05:27 PM, Carsten Varming wrote:
> Dear Robbin,
>
> It would be much nicer if the code was changed to call a new method in a
> cpp file (this is clearly a slow path) and the new method could use a

This is a template class.

> bufferedStream to automatically expand the needed buffer. You would need
> to implement vprint on bufferedStream to make is expand when needed, but
> that should be doable.

After 'fastpath' we know the size, so there should never be any need for 
'expand' anything?

Thanks!

/Robbin

>
> Carsten
>
> On Wed, Mar 16, 2016 at 12:13 PM, Kim Barrett <kim.barrett at oracle.com
> <mailto:kim.barrett at oracle.com>> wrote:
>
>      > On Mar 16, 2016, at 8:33 AM, Robbin Ehn <robbin.ehn at oracle.com
>     <mailto:robbin.ehn at oracle.com>> wrote:
>      >
>      > Hi, please review this small change.
>      >
>      > This also change allocation methods.
>      >
>      > Bug: https://bugs.openjdk.java.net/browse/JDK-8151993/
>      > Webrev: http://cr.openjdk.java.net/~rehn/8151993/webrev/
>      >
>      > Thanks!
>      >
>      > /Robbin
>
>     ------------------------------------------------------------------------------
>     src/share/vm/logging/log.hpp
>     Changing this:
>       138       char* newbuf = NEW_C_HEAP_ARRAY(char, newbuf_len,
>     mtLogging);
>     to this:
>       137       char* newbuf = (char*) os::malloc(sizeof(char) *
>     newbuf_len, mtLogging);
>
>     New code is missing out of memory handling that was present in the old
>     code.  New code will just try to use newbuf, with bad results if the
>     allocation failed.
>
>     New code is missing ASSERT-conditionalized PrintMallocFree support
>     that was present in the old.  I don't know how important this is,
>     given that we also have PrintMalloc.  (And I have to wonder why we
>     have both PrintMalloc (develop) and PrintMallocFree (notproduct).)
>
>     ------------------------------------------------------------------------------
>
>

From robbin.ehn at oracle.com  Thu Mar 17 06:44:32 2016
From: robbin.ehn at oracle.com (Robbin Ehn)
Date: Thu, 17 Mar 2016 07:44:32 +0100
Subject: RFR(xs): 8151993: Remove inclusion of inline.hpp in log.hpp
In-Reply-To: <816216C7-85B9-4E1F-8A4A-BBB5FFD728D4@oracle.com>
References: <56E952A5.6050708@oracle.com>
	<816216C7-85B9-4E1F-8A4A-BBB5FFD728D4@oracle.com>
Message-ID: <56EA5250.8090001@oracle.com>

Hi Kim,

On 03/16/2016 05:13 PM, Kim Barrett wrote:
>> On Mar 16, 2016, at 8:33 AM, Robbin Ehn <robbin.ehn at oracle.com> wrote:
>>
>> Hi, please review this small change.
>>
>> This also change allocation methods.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8151993/
>> Webrev: http://cr.openjdk.java.net/~rehn/8151993/webrev/
>>
>> Thanks!
>>
>> /Robbin
>
> ------------------------------------------------------------------------------
> src/share/vm/logging/log.hpp
> Changing this:
>   138       char* newbuf = NEW_C_HEAP_ARRAY(char, newbuf_len, mtLogging);
> to this:
>   137       char* newbuf = (char*) os::malloc(sizeof(char) * newbuf_len, mtLogging);
>
> New code is missing out of memory handling that was present in the old
> code.  New code will just try to use newbuf, with bad results if the
> allocation failed.

Yes

>
> New code is missing ASSERT-conditionalized PrintMallocFree support
> that was present in the old.  I don't know how important this is,
> given that we also have PrintMalloc.  (And I have to wonder why we
> have both PrintMalloc (develop) and PrintMallocFree (notproduct).)
>
> ------------------------------------------------------------------------------
>

I wonder if this is even is the right path, we have 25 hpp including 
allocation.inline.
The other ones seem to do their allocation from their inline.hpp file.

Making me believe that we should either ignore this or do log.inline.hpp.

Either way this patch should be dropped, thoughts?

Thanks for having a look Kim!

/Robbin

From dmitry.samersoff at oracle.com  Thu Mar 17 08:58:20 2016
From: dmitry.samersoff at oracle.com (Dmitry Samersoff)
Date: Thu, 17 Mar 2016 11:58:20 +0300
Subject: [PATCH] JDK-8036559: Attach API does not allow root to connect to
	process owned by others
In-Reply-To: <56E9CFBC.2080808@redhat.com>
References: <56E9CFBC.2080808@redhat.com>
Message-ID: <56EA71AC.5070801@oracle.com>

Elliott,

I'll take care of the CR.

But as soon as the changes have security implication we should carefully
evaluate possible side effects. So it takes some time.

-Dmitry



On 2016-03-17 00:27, Elliott Baron wrote:
> Hi,
> 
> I've been working on an updated patch for JDK-8036559, where root does
> not have the ability to attach to unprivileged users' JVMs. I originally
> mentioned this problem back in 2013, and proposed a patch only for Linux
> [1]. The result was that the fix had to provide support for all affected
> platforms, and to include tests.
> 
> We worked around this issue in our project, but I revisited this bug
> recently. I investigated the issue on Windows, which has a very
> different implementation from the other platforms. I discovered that
> this bug does not appear to affect Windows. Using the test programs
> attached to Red Hat Bugzilla bug #1311638 [2], I verified the correct
> behaviour using the following steps:
>> (Open cmd.exe)
>> runas /user:test cmd.exe
>> runas /user:Administrator cmd.exe
>>
>> (In test's shell)
>> set TMP=C:\Users\Public\java_temp
>> cd C:\Users\Public\Documents
>> javac AttachTarget.java
>> java AttachTarget
>>
>> (In Administrator's shell)
>> set TMP=C:\Users\Public\java_temp
>> cd C:\Users\Public\Documents
>> javac -cp .;C:\Progra~1\Java\jdk1.8.0_74\lib\tools.jar AttachClient.java
>> java -cp .;C:\Progra~1\Java\jdk1.8.0_74\lib\tools.jar AttachClient
>> (outputs 'Target ok: AttachTarget')
> 
> My updated patches target JDK 9, and includes support for Linux,
> Solaris, Mac OSX, and AIX. As far as tests are concerned, I'm not sure
> how to add tests for this bug, since doing so would require the test to
> be run as root. I am attaching the patches to this email, since I am not
> an OpenJDK committer and do not have access to cr.openjdk.java.net.
> 
> Thanks,
> Elliott
> 
> [1]
> http://mail.openjdk.java.net/pipermail/serviceability-dev/2013-June/010077.html
> 
> [2] https://bugzilla.redhat.com/show_bug.cgi?id=1311638


-- 
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the sources.

From robbin.ehn at oracle.com  Thu Mar 17 10:51:08 2016
From: robbin.ehn at oracle.com (Robbin Ehn)
Date: Thu, 17 Mar 2016 11:51:08 +0100
Subject: RFR(m): 8150015: Integrate TraceTime with Unified Logging more
	seamlessly
In-Reply-To: <56E9378D.5050706@oracle.com>
References: <56E87137.4080109@oracle.com> <56E9378D.5050706@oracle.com>
Message-ID: <56EA8C1C.9020901@oracle.com>

Hi Bengt

Thanks for your input.

On 03/16/2016 11:38 AM, Bengt Rutisson wrote:
>
> Hi Robbin,
>
> On 2016-03-15 21:31, Robbin Ehn wrote:
>> Hi, please review this enhancement.
>>
>> This adds support for multiple UL tags in TraceTime.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8150015/
>> Webrev: http://cr.openjdk.java.net/~rehn/8150015/v1/webrev/
>
> I think this is fine but I just wanted to mention an alternative
> approach. For the GC logging I introduced a GCTraceTimerImpl class and a
> GCTraceTime macro. See:
>
> http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/file/4030d7f9946d/src/share/vm/gc/shared/gcTraceTime.inline.hpp#l146
>
>
> If you do something similar the code on the call site would look like this:
>
> TraceTime(Info, safepointcleanup) timer("deflating idle monitors");
>
> instead of this:
>
> TraceTime timer("deflating idle monitors", TRACETIME_LOG(Info,
> safepointcleanup));
>
> Your call. I just wanted to mention it.

As discussed in other forums, I have created: 
https://bugs.openjdk.java.net/browse/JDK-8152089
for this.

As we also agreed on, I'll be pushing this change-set.

Thanks,

/Robbin

>
> Thanks,
> Bengt
>
>>
>> Tested with jprt hotspot and manually tested log output.
>>
>> Thanks!
>>
>> /Robbin
>

From bengt.rutisson at oracle.com  Thu Mar 17 12:32:38 2016
From: bengt.rutisson at oracle.com (Bengt Rutisson)
Date: Thu, 17 Mar 2016 13:32:38 +0100
Subject: RFR(m): 8150015: Integrate TraceTime with Unified Logging more
	seamlessly
In-Reply-To: <56EA8C1C.9020901@oracle.com>
References: <56E87137.4080109@oracle.com> <56E9378D.5050706@oracle.com>
	<56EA8C1C.9020901@oracle.com>
Message-ID: <56EAA3E6.1000508@oracle.com>


Hi Robbin,

Thanks for filing the RFE.

Bengt

On 2016-03-17 11:51, Robbin Ehn wrote:
> Hi Bengt
>
> Thanks for your input.
>
> On 03/16/2016 11:38 AM, Bengt Rutisson wrote:
>>
>> Hi Robbin,
>>
>> On 2016-03-15 21:31, Robbin Ehn wrote:
>>> Hi, please review this enhancement.
>>>
>>> This adds support for multiple UL tags in TraceTime.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8150015/
>>> Webrev: http://cr.openjdk.java.net/~rehn/8150015/v1/webrev/
>>
>> I think this is fine but I just wanted to mention an alternative
>> approach. For the GC logging I introduced a GCTraceTimerImpl class and a
>> GCTraceTime macro. See:
>>
>> http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/file/4030d7f9946d/src/share/vm/gc/shared/gcTraceTime.inline.hpp#l146 
>>
>>
>>
>> If you do something similar the code on the call site would look like 
>> this:
>>
>> TraceTime(Info, safepointcleanup) timer("deflating idle monitors");
>>
>> instead of this:
>>
>> TraceTime timer("deflating idle monitors", TRACETIME_LOG(Info,
>> safepointcleanup));
>>
>> Your call. I just wanted to mention it.
>
> As discussed in other forums, I have created: 
> https://bugs.openjdk.java.net/browse/JDK-8152089
> for this.
>
> As we also agreed on, I'll be pushing this change-set.
>
> Thanks,
>
> /Robbin
>
>>
>> Thanks,
>> Bengt
>>
>>>
>>> Tested with jprt hotspot and manually tested log output.
>>>
>>> Thanks!
>>>
>>> /Robbin
>>


From markus.gronlund at oracle.com  Thu Mar 17 18:43:36 2016
From: markus.gronlund at oracle.com (Markus Gronlund)
Date: Thu, 17 Mar 2016 11:43:36 -0700 (PDT)
Subject: RFR(XS): 8152119: Event-based tracing to allow for tracing Klass
	definition
Message-ID: <4d9d0f40-f8cc-461b-8fb6-cd6d9663bdf9@default>

Greetings,

 

Kindly asking for reviews for the following change to allow for tracing Klass definitions.

 

Bug: https://bugs.openjdk.java.net/browse/JDK-8152119

 

Webrev: http://cr.openjdk.java.net/~mgronlun/8152119/webrev01/ 

 

This change complements the change associated with Klass creation which is already integrated:

https://bugs.openjdk.java.net/browse/JDK-8147442

 

Thanks

Markus

 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20160317/3ec9eef3/attachment.html>

From kim.barrett at oracle.com  Thu Mar 17 22:33:49 2016
From: kim.barrett at oracle.com (Kim Barrett)
Date: Thu, 17 Mar 2016 18:33:49 -0400
Subject: RFR(xs): 8151993: Remove inclusion of inline.hpp in log.hpp
In-Reply-To: <56EA5250.8090001@oracle.com>
References: <56E952A5.6050708@oracle.com>
	<816216C7-85B9-4E1F-8A4A-BBB5FFD728D4@oracle.com>
	<56EA5250.8090001@oracle.com>
Message-ID: <2D6479D0-C76F-4A8F-980F-B8788ACBC4A7@oracle.com>

> On Mar 17, 2016, at 2:44 AM, Robbin Ehn <robbin.ehn at oracle.com> wrote:
> On 03/16/2016 05:13 PM, Kim Barrett wrote:
>>> On Mar 16, 2016, at 8:33 AM, Robbin Ehn <robbin.ehn at oracle.com> wrote:
>>> 
>>> Hi, please review this small change.
>>> 
>>> This also change allocation methods.
>>> 
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8151993/
>>> Webrev: http://cr.openjdk.java.net/~rehn/8151993/webrev/
>>> 
>>> Thanks!
>>> 
>>> /Robbin
>> 
>> ------------------------------------------------------------------------------
>> src/share/vm/logging/log.hpp
>> Changing this:
>>  138       char* newbuf = NEW_C_HEAP_ARRAY(char, newbuf_len, mtLogging);
>> to this:
>>  137       char* newbuf = (char*) os::malloc(sizeof(char) * newbuf_len, mtLogging);
>> 
>> New code is missing out of memory handling that was present in the old
>> code.  New code will just try to use newbuf, with bad results if the
>> allocation failed.
> 
> Yes
> 
>> 
>> New code is missing ASSERT-conditionalized PrintMallocFree support
>> that was present in the old.  I don't know how important this is,
>> given that we also have PrintMalloc.  (And I have to wonder why we
>> have both PrintMalloc (develop) and PrintMallocFree (notproduct).)
>> 
>> ------------------------------------------------------------------------------
>> 
> 
> I wonder if this is even is the right path, we have 25 hpp including allocation.inline.
> The other ones seem to do their allocation from their inline.hpp file.
> 
> Making me believe that we should either ignore this or do log.inline.hpp.
> 
> Either way this patch should be dropped, thoughts?

I don't think ignoring is the right long-term approach, though is
probably ok in the short term.  In particular, I think adding
log.inline.hpp would touch a lot of files, which seems like a bad
thing to do just now, with largish changes coming soon that would need
to be merged.  And I'm not convinced log.inline.hpp is the right long
term approach anyway.

Rather, I prefer Carsten's suggestion of an out of line slow-path
function in a .cpp.  This approach is possible, even though we're
dealing with templates, by using type-erasure.  The generic
(non-templated) slow-path function would need to receive a couple of
function pointers from the vwrite template, e.g. the prefix and puts
functions that are referenced by the present template code.  The
function pointer types don't refer to template parameters, e.g. the
prefix function's type is

  size_t (*prefix_fn)(char*, size_t)

and puts is

  void (*puts_fn)(LogLevelType, const char*)



From erik.gahlin at oracle.com  Thu Mar 17 23:39:00 2016
From: erik.gahlin at oracle.com (Erik Gahlin)
Date: Fri, 18 Mar 2016 00:39:00 +0100
Subject: RFR(XS): 8152119: Event-based tracing to allow for tracing Klass
	definition
In-Reply-To: <4d9d0f40-f8cc-461b-8fb6-cd6d9663bdf9@default>
References: <4d9d0f40-f8cc-461b-8fb6-cd6d9663bdf9@default>
Message-ID: <56EB4014.8010009@oracle.com>

Looks good. Not a reviewer.

Erik

On 2016-03-17 19:43, Markus Gronlund wrote:
>
> Greetings,
>
> Kindly asking for reviews for the following change to allow for 
> tracing Klass definitions.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8152119
>
> Webrev: http://cr.openjdk.java.net/~mgronlun/8152119/webrev01/ 
> <http://cr.openjdk.java.net/%7Emgronlun/8152119/webrev01/>
>
> This change complements the change associated with Klass creation 
> which is already integrated:
>
> https://bugs.openjdk.java.net/browse/JDK-8147442
>
> Thanks
>
> Markus
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20160318/cecf4a43/attachment.html>

From david.holmes at oracle.com  Fri Mar 18 00:10:12 2016
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 18 Mar 2016 10:10:12 +1000
Subject: RFR(XS): 8152119: Event-based tracing to allow for tracing Klass
	definition
In-Reply-To: <4d9d0f40-f8cc-461b-8fb6-cd6d9663bdf9@default>
References: <4d9d0f40-f8cc-461b-8fb6-cd6d9663bdf9@default>
Message-ID: <56EB4764.7030101@oracle.com>

Hi Markus,

On 18/03/2016 4:43 AM, Markus Gronlund wrote:
> Greetings,
>
> Kindly asking for reviews for the following change to allow for tracing
> Klass definitions.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8152119
>
> Webrev: http://cr.openjdk.java.net/~mgronlun/8152119/webrev01/

You either need to change this:

   77 #if INCLUDE_TRACE
   78 #include "trace/tracing.hpp"
   79 #include "trace/traceMacros.hpp"
   80 #endif

to include outside the INCLUDE_TRACE guard, or else this:

1501   TRACE_KLASS_DEFINITION(k, THREAD);

needs to be inside an INCLUDE_TRACE guard.

Based on existing code it should be the former, though I realize this 
will look strange:

#if INCLUDE_TRACE
#include "trace/tracing.hpp"
#endif
#include "trace/traceMacros.hpp"

Thanks,
David

> This change complements the change associated with Klass creation which
> is already integrated:
>
> https://bugs.openjdk.java.net/browse/JDK-8147442
>
> Thanks
>
> Markus
>

From david.holmes at oracle.com  Fri Mar 18 04:42:14 2016
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 18 Mar 2016 14:42:14 +1000
Subject: RFR(S): JDK-8151991 jvmti diagnostics commands requires
	INCLUDE_SERVICES
In-Reply-To: <56E96A5B.5000105@oracle.com>
References: <56E858BD.4030401@oracle.com> <56E867C8.4070200@oracle.com>
	<56E94B3B.2060208@oracle.com> <56E96A5B.5000105@oracle.com>
Message-ID: <56EB8726.9060101@oracle.com>

On 17/03/2016 12:14 AM, Dmitry Samersoff wrote:
> Everybody,
>
> Please, review small fix.
>
> http://cr.openjdk.java.net/~dsamersoff/JDK-8151991/webrev.01/
>
> New diagnostic command (JVMTI.agent_load) should be guarded by
> #if INCLUDE_SERVICES and don't brake minimal VM build.

Initially I was confused as to why this was associated with 
INCLUDE_SERVICES as it seems unrelated to the all the other things 
guarded by INCLUDE_SERVICES. But now I see that the attachListener code 
is completely excluded by INCLUDE_SERVICES (excludeSrc.gmk) so it makes 
sense that the same guard is used in the diagnosticCommand sources (or 
else an independent guard introduced?).

However you would then also need the same guard in:

src/share/vm/prims/jvmtiExport.cpp

to allow INCLUDE_JVMTI to be true and INCLUDE_SERVICES to be false.

lso can you update this comment:

  64 #if INCLUDE_SERVICES // Heap dumping/inspection supported

to also refer to the JVM TI agent/attach support

Thanks,
David
-----


> -Dmitry
>

From cheleswer.sahu at oracle.com  Fri Mar 18 07:54:02 2016
From: cheleswer.sahu at oracle.com (Cheleswer Sahu)
Date: Fri, 18 Mar 2016 00:54:02 -0700 (PDT)
Subject: RFR[9u-dev]: 8151442: jstack doesn't close quotation marks properly
	with threads' name greater than 1996 characters
Message-ID: <556325b3-e8b2-4622-8b59-1df2ef4b1f02@default>

Hi,

 

Please review the code changes for https://bugs.openjdk.java.net/browse/JDK-8151442.

 

Webrev Link: http://cr.openjdk.java.net/~csahu/8151442/

 

Bug Brief: 

In jstack thread dumps , thread name greater than 1996 characters doesn't close quotation marks properly. 

 

Problem Identified:

Jstack is using below code to print thread name

 

src/share/vm/runtime/thread.cpp

void JavaThread::print_on(outputStream *st) const {

  st->print("\"%s\" ", get_thread_name());

 

Here "st->print()"  internally uses max buffer length as O_BUFLEN (2000).

 

void outputStream::do_vsnprintf_and_write_with_automatic_buffer(const char* format, va_list ap, bool add_cr) {
  char buffer[O_BUFLEN];

 

 

do_vsnprintf_and_write_with_automatic_buffer() finally calls  "vsnprintf()"  which truncates the anything greater than the max size(2000). In this case thread's name(> 1996) along with quotation marks (2) 

plus one terminating character exceeds the  max buffer size (2000), therefore the closing quotation  marks gets truncated.

 

 

Solution:

Split the  "st->print("\"%s\" ", get_thread_name())" in two statements

1.       st->print("\"%s", get_thread_name());

2.       st->print("\" ");

 

This will ensure presence of closing quotation mark always.

 

 

Regards,

Cheleswer

 

 

 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20160318/26f5177b/attachment-0001.html>

From dmitry.samersoff at oracle.com  Fri Mar 18 09:04:36 2016
From: dmitry.samersoff at oracle.com (Dmitry Samersoff)
Date: Fri, 18 Mar 2016 12:04:36 +0300
Subject: RFR[9u-dev]: 8151442: jstack doesn't close quotation marks
	properly with threads' name greater than 1996 characters
In-Reply-To: <556325b3-e8b2-4622-8b59-1df2ef4b1f02@default>
References: <556325b3-e8b2-4622-8b59-1df2ef4b1f02@default>
Message-ID: <56EBC4A4.7060904@oracle.com>

Cheleswer,

Fix (as immediate solution) looks good for me.

But IMHO, silent truncation of the output inside output stream is not a
correct behavior. So please file a follow-up CR to have it addressed.

-Dmitry

On 2016-03-18 10:54, Cheleswer Sahu wrote:
> Hi,
> 
>  
> 
> Please review the code changes for https://bugs.openjdk.java.net/browse/JDK-8151442.
> 
>  
> 
> Webrev Link: http://cr.openjdk.java.net/~csahu/8151442/
> 
>  
> 
> Bug Brief: 
> 
> In jstack thread dumps , thread name greater than 1996 characters doesn't close quotation marks properly. 
> 
>  
> 
> Problem Identified:
> 
> Jstack is using below code to print thread name
> 
>  
> 
> src/share/vm/runtime/thread.cpp
> 
> void JavaThread::print_on(outputStream *st) const {
> 
>   st->print("\"%s\" ", get_thread_name());
> 
>  
> 
> Here "st->print()"  internally uses max buffer length as O_BUFLEN (2000).
> 
>  
> 
> void outputStream::do_vsnprintf_and_write_with_automatic_buffer(const char* format, va_list ap, bool add_cr) {
>   char buffer[O_BUFLEN];
> 
>  
> 
>  
> 
> do_vsnprintf_and_write_with_automatic_buffer() finally calls  "vsnprintf()"  which truncates the anything greater than the max size(2000). In this case thread's name(> 1996) along with quotation marks (2) 
> 
> plus one terminating character exceeds the  max buffer size (2000), therefore the closing quotation  marks gets truncated.
> 
>  
> 
>  
> 
> Solution:
> 
> Split the  "st->print("\"%s\" ", get_thread_name())" in two statements
> 
> 1.       st->print("\"%s", get_thread_name());
> 
> 2.       st->print("\" ");
> 
>  
> 
> This will ensure presence of closing quotation mark always.
> 
>  
> 
>  
> 
> Regards,
> 
> Cheleswer
> 
>  
> 
>  
> 
>  
> 


-- 
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the sources.

From david.holmes at oracle.com  Fri Mar 18 09:11:35 2016
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 18 Mar 2016 19:11:35 +1000
Subject: RFR[9u-dev]: 8151442: jstack doesn't close quotation marks
	properly with threads' name greater than 1996 characters
In-Reply-To: <556325b3-e8b2-4622-8b59-1df2ef4b1f02@default>
References: <556325b3-e8b2-4622-8b59-1df2ef4b1f02@default>
Message-ID: <56EBC647.6020704@oracle.com>

On 18/03/2016 5:54 PM, Cheleswer Sahu wrote:
> Hi,
>
> Please review the code changes for
> https://bugs.openjdk.java.net/browse/JDK-8151442.
>
> Webrev Link: http://cr.openjdk.java.net/~csahu/8151442/
>
> Bug Brief:
>
> In jstack thread dumps , thread name greater than 1996 characters
> doesn?t close quotation marks properly.

Anyone giving a thread a name that long deserves to get a core dump! ;-)

> Problem Identified:
>
> Jstack is using below code to print thread name
>
> src/share/vm/runtime/thread.cpp
>
> void JavaThread::print_on(outputStream *st) const {
>
>    st->print("\"%s\" ", get_thread_name());
>
> Here ?st->print()?  internally uses max buffer length as O_BUFLEN (2000).
>
> void outputStream::do_vsnprintf_and_write_with_automatic_buffer(const
> char* format, va_list ap, bool add_cr) {
>
>    char buffer[O_BUFLEN];
>
> do_vsnprintf_and_write_with_automatic_buffer() finally calls
>   ?vsnprintf()?  which truncates the anything greater than the max
> size(2000). In this case thread?s name(> 1996) along with quotation
> marks (2)
>
> plus one terminating character exceeds the  max buffer size (2000),
> therefore the closing quotation  marks gets truncated.
>
> Solution:
>
> Split the  ?st->print("\"%s\" ", get_thread_name())? in two statements
>
> 1.st->print("\"%s", get_thread_name());
>
> 2.st->print("\" ?);
>
> This will ensure presence of closing quotation mark always.

Can't we just limit the number of characters read by %s?

David

> Regards,
>
> Cheleswer
>

From markus.gronlund at oracle.com  Fri Mar 18 09:33:13 2016
From: markus.gronlund at oracle.com (Markus Gronlund)
Date: Fri, 18 Mar 2016 02:33:13 -0700 (PDT)
Subject: RFR(XS): 8152119: Event-based tracing to allow for tracing Klass
	definition
In-Reply-To: <56EB4764.7030101@oracle.com>
References: <4d9d0f40-f8cc-461b-8fb6-cd6d9663bdf9@default>
	<56EB4764.7030101@oracle.com>
Message-ID: <60ebd13a-ff91-440e-94b2-17bcda9885a5@default>

Hi David,

Thanks for noticing, of course it should go outside the INCLUDE_TRACE macro. I should have checked this better - cheers.

Both tracing.hpp and traceMacro.hpp can be unconditionally included, but I think I will just move out the traceMacros.hpp.

Agree it will look a bit strange, but maybe not so much if it is moved outside of all the extra #defines:

...
#include "services/threadService.hpp"
#include "trace/traceMacros.hpp" <<--------
#include "utilities/macros.hpp"
#include "utilities/ticks.hpp"
#if INCLUDE_CDS
#include "classfile/sharedClassUtil.hpp"
#include "classfile/systemDictionaryShared.hpp"
#endif
#if INCLUDE_JVMCI
#include "jvmci/jvmciRuntime.hpp"
#endif
#if INCLUDE_TRACE
#include "trace/tracing.hpp"
#endif

Thanks again
Markus


-----Original Message-----
From: David Holmes 
Sent: den 18 mars 2016 01:10
To: Markus Gronlund; serviceability-dev at openjdk.java.net
Subject: Re: RFR(XS): 8152119: Event-based tracing to allow for tracing Klass definition

Hi Markus,

On 18/03/2016 4:43 AM, Markus Gronlund wrote:
> Greetings,
>
> Kindly asking for reviews for the following change to allow for 
> tracing Klass definitions.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8152119
>
> Webrev: http://cr.openjdk.java.net/~mgronlun/8152119/webrev01/

You either need to change this:

   77 #if INCLUDE_TRACE
   78 #include "trace/tracing.hpp"
   79 #include "trace/traceMacros.hpp"
   80 #endif

to include outside the INCLUDE_TRACE guard, or else this:

1501   TRACE_KLASS_DEFINITION(k, THREAD);

needs to be inside an INCLUDE_TRACE guard.

Based on existing code it should be the former, though I realize this will look strange:

#if INCLUDE_TRACE
#include "trace/tracing.hpp"
#endif
#include "trace/traceMacros.hpp"

Thanks,
David

> This change complements the change associated with Klass creation 
> which is already integrated:
>
> https://bugs.openjdk.java.net/browse/JDK-8147442
>
> Thanks
>
> Markus
>

From markus.gronlund at oracle.com  Fri Mar 18 09:33:37 2016
From: markus.gronlund at oracle.com (Markus Gronlund)
Date: Fri, 18 Mar 2016 02:33:37 -0700 (PDT)
Subject: RFR(XS): 8152119: Event-based tracing to allow for tracing Klass
	definition
In-Reply-To: <56EB4014.8010009@oracle.com>
References: <4d9d0f40-f8cc-461b-8fb6-cd6d9663bdf9@default>
	<56EB4014.8010009@oracle.com>
Message-ID: <c579de4f-b181-41cb-9341-461679a90e8e@default>

Thanks Erik!

 

Markus

 

From: Erik Gahlin 
Sent: den 18 mars 2016 00:39
To: serviceability-dev at openjdk.java.net
Subject: Re: RFR(XS): 8152119: Event-based tracing to allow for tracing Klass definition

 

Looks good. Not a reviewer.

Erik

On 2016-03-17 19:43, Markus Gronlund wrote:

Greetings,

 

Kindly asking for reviews for the following change to allow for tracing Klass definitions.

 

Bug: https://bugs.openjdk.java.net/browse/JDK-8152119

 

Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Emgronlun/8152119/webrev01/"http://cr.openjdk.java.net/~mgronlun/8152119/webrev01/ 

 

This change complements the change associated with Klass creation which is already integrated:

https://bugs.openjdk.java.net/browse/JDK-8147442

 

Thanks

Markus

 

 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20160318/c0d16460/attachment.html>

From cheleswer.sahu at oracle.com  Fri Mar 18 09:58:07 2016
From: cheleswer.sahu at oracle.com (Cheleswer Sahu)
Date: Fri, 18 Mar 2016 02:58:07 -0700 (PDT)
Subject: RFR[9u-dev]: 8151442: jstack doesn't close quotation marks
	properly with threads' name greater than 1996 characters
In-Reply-To: <56EBC4A4.7060904@oracle.com>
References: <556325b3-e8b2-4622-8b59-1df2ef4b1f02@default>
	<56EBC4A4.7060904@oracle.com>
Message-ID: <01acffa1-ff7f-43d0-8ea4-7af6ecc92f6d@default>

Thanks Dmitry for review. I will file CR and let you know once done.


Cheleswer


-----Original Message-----
From: Dmitry Samersoff 
Sent: Friday, March 18, 2016 2:35 PM
To: Cheleswer Sahu; hotspot-runtime-dev at openjdk.java.net; serviceability-dev at openjdk.java.net
Subject: Re: RFR[9u-dev]: 8151442: jstack doesn't close quotation marks properly with threads' name greater than 1996 characters

Cheleswer,

Fix (as immediate solution) looks good for me.

But IMHO, silent truncation of the output inside output stream is not a correct behavior. So please file a follow-up CR to have it addressed.

-Dmitry

On 2016-03-18 10:54, Cheleswer Sahu wrote:
> Hi,
> 
>  
> 
> Please review the code changes for https://bugs.openjdk.java.net/browse/JDK-8151442.
> 
>  
> 
> Webrev Link: http://cr.openjdk.java.net/~csahu/8151442/
> 
>  
> 
> Bug Brief: 
> 
> In jstack thread dumps , thread name greater than 1996 characters doesn't close quotation marks properly. 
> 
>  
> 
> Problem Identified:
> 
> Jstack is using below code to print thread name
> 
>  
> 
> src/share/vm/runtime/thread.cpp
> 
> void JavaThread::print_on(outputStream *st) const {
> 
>   st->print("\"%s\" ", get_thread_name());
> 
>  
> 
> Here "st->print()"  internally uses max buffer length as O_BUFLEN (2000).
> 
>  
> 
> void outputStream::do_vsnprintf_and_write_with_automatic_buffer(const char* format, va_list ap, bool add_cr) {
>   char buffer[O_BUFLEN];
> 
>  
> 
>  
> 
> do_vsnprintf_and_write_with_automatic_buffer() finally calls  
> "vsnprintf()"  which truncates the anything greater than the max 
> size(2000). In this case thread's name(> 1996) along with quotation 
> marks (2)
> 
> plus one terminating character exceeds the  max buffer size (2000), therefore the closing quotation  marks gets truncated.
> 
>  
> 
>  
> 
> Solution:
> 
> Split the  "st->print("\"%s\" ", get_thread_name())" in two statements
> 
> 1.       st->print("\"%s", get_thread_name());
> 
> 2.       st->print("\" ");
> 
>  
> 
> This will ensure presence of closing quotation mark always.
> 
>  
> 
>  
> 
> Regards,
> 
> Cheleswer
> 
>  
> 
>  
> 
>  
> 


--
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the sources.

From dmitry.dmitriev at oracle.com  Fri Mar 18 10:00:29 2016
From: dmitry.dmitriev at oracle.com (Dmitry Dmitriev)
Date: Fri, 18 Mar 2016 13:00:29 +0300
Subject: RFR[9u-dev]: 8151442: jstack doesn't close quotation marks
	properly with threads' name greater than 1996 characters
In-Reply-To: <556325b3-e8b2-4622-8b59-1df2ef4b1f02@default>
References: <556325b3-e8b2-4622-8b59-1df2ef4b1f02@default>
Message-ID: <56EBD1BD.6090406@oracle.com>

Hello Cheleswer,

It is possible to create a regression test for that?

Dmitry

On 18.03.2016 10:54, Cheleswer Sahu wrote:
>
> Hi,
>
> Please review the code changes for 
> https://bugs.openjdk.java.net/browse/JDK-8151442.
>
> Webrev Link: http://cr.openjdk.java.net/~csahu/8151442/
>
> Bug Brief:
>
> In jstack thread dumps , thread name greater than 1996 characters 
> doesn?t close quotation marks properly.
>
> Problem Identified:
>
> Jstack is using below code to print thread name
>
> src/share/vm/runtime/thread.cpp
>
> void JavaThread::print_on(outputStream *st) const {
>
>   st->print("\"%s\" ", get_thread_name());
>
> Here ?st->print()?  internally uses max buffer length as O_BUFLEN (2000).
>
> void outputStream::do_vsnprintf_and_write_with_automatic_buffer(const 
> char* format, va_list ap, bool add_cr) {
>   char buffer[O_BUFLEN];
>
> do_vsnprintf_and_write_with_automatic_buffer() finally calls 
>  ?vsnprintf()?  which truncates the anything greater than the max 
> size(2000). In this case thread?s name(> 1996) along with quotation 
> marks (2)
>
> plus one terminating character exceeds the max buffer size (2000), 
> therefore the closing quotation  marks gets truncated.
>
> Solution:
>
> Split the  ?st->print("\"%s\" ", get_thread_name())? in two statements
>
> 1.st->print("\"%s", get_thread_name());
>
> 2.st->print("\" ?);
>
> This will ensure presence of closing quotation mark always.
>
> Regards,
>
> Cheleswer
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20160318/998abb2a/attachment-0001.html>

From harsha.wardhana.b at oracle.com  Fri Mar 18 11:17:52 2016
From: harsha.wardhana.b at oracle.com (Harsha Wardhana B)
Date: Fri, 18 Mar 2016 16:47:52 +0530
Subject: RFR : JDK-8151797 -
	java/lang/management/ThreadMXBean/ThreadLists.java : inconsistent
	results
Message-ID: <56EBE3E0.7040109@oracle.com>

Hello All,

Please review fix for,

Issue : JDK-8151797 <http://JDK-8151797> - 
java/lang/management/ThreadMXBean/ThreadLists.java : inconsistent results
Webrev : http://cr.openjdk.java.net/~hb/8151797/webrev.00/

Root-cause :  call-site cleaner thread not started before counting 
threads via Thread.getAllStackTraces();.
Fix : Create ThreadMXBean at the beginning of test so that call-site 
cleaner thread will be started.

Thanks
Harsha

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20160318/96588396/attachment.html>

From marcus.larsson at oracle.com  Fri Mar 18 11:25:20 2016
From: marcus.larsson at oracle.com (Marcus Larsson)
Date: Fri, 18 Mar 2016 12:25:20 +0100
Subject: RFR: 8150823: UL handles disabling logs incorrectly
In-Reply-To: <56E2D8ED.3040204@oracle.com>
References: <56E2D8ED.3040204@oracle.com>
Message-ID: <56EBE5A0.5070806@oracle.com>

Hi,

Updated the patch after offline discussion. New patch attempts to 
normalize the output name before searching for it or adding it. This 
includes adding the implicit file= prefix if missing, and/or removing 
quotes from a quoted name.

Webrev:
http://cr.openjdk.java.net/~mlarsson/8150823/webrev.01/

Incremental:
http://cr.openjdk.java.net/~mlarsson/8150823/webrev.00-01/

Tested with serviceability/logging tests through RBT.

Thanks,
Marcus

On 03/11/2016 03:40 PM, Marcus Larsson wrote:
> Hi,
>
> Please review the following patch to fix a problem with disabling log 
> outputs using -Xlog:disable or disable_logging() when there are 
> multiple file outputs configured. The patch also resolves an issue 
> with log file lookups that could cause multiple outputs to be created 
> for the same log file.
>
> Log output removal now iterates backwards to not invalidate the loop 
> index, and file outputs are always prepended with "file=" during 
> lookups and listings.
>
> Webrev:
> http://cr.openjdk.java.net/~mlarsson/8150823/webrev.00/
>
> Issue:
> https://bugs.openjdk.java.net/browse/JDK-8150823
>
> Testing:
> Included tests through RBT
>
> Thanks,
> Marcus


From staffan.larsen at oracle.com  Fri Mar 18 11:31:05 2016
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Fri, 18 Mar 2016 12:31:05 +0100
Subject: RFR : JDK-8151797 -
	java/lang/management/ThreadMXBean/ThreadLists.java :
	inconsistent results
In-Reply-To: <56EBE3E0.7040109@oracle.com>
References: <56EBE3E0.7040109@oracle.com>
Message-ID: <0F53E9D3-2FC8-4C23-88EB-4F2C0BF0A039@oracle.com>

You should move the Arrays.stream trigger call to before the ManagementFactory.getThreadMXBean, otherwise the threads you get from ThreadMXBean will not match the threads you get from the ThreadGroups.

> On 18 mars 2016, at 12:17, Harsha Wardhana B <harsha.wardhana.b at oracle.com> wrote:
> 
> Hello All,
> 
> Please review fix for,
> 
> Issue : JDK-8151797 <http://jdk-8151797/> -  java/lang/management/ThreadMXBean/ThreadLists.java : inconsistent results
> Webrev : http://cr.openjdk.java.net/~hb/8151797/webrev.00/ <http://cr.openjdk.java.net/%7Ehb/8151797/webrev.00/>
> 
> Root-cause :  call-site cleaner thread not started before counting threads via Thread.getAllStackTraces();. 
> Fix : Create ThreadMXBean at the beginning of test so that call-site cleaner thread will be started. 
> 
> Thanks
> Harsha
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20160318/643051cc/attachment.html>

From cheleswer.sahu at oracle.com  Fri Mar 18 12:03:55 2016
From: cheleswer.sahu at oracle.com (Cheleswer Sahu)
Date: Fri, 18 Mar 2016 05:03:55 -0700 (PDT)
Subject: RFR[9u-dev]: 8151442: jstack doesn't close quotation marks
	properly with threads' name greater than 1996 characters
In-Reply-To: <56EBC647.6020704@oracle.com>
References: <556325b3-e8b2-4622-8b59-1df2ef4b1f02@default>
	<56EBC647.6020704@oracle.com>
Message-ID: <0db522da-1cbe-494a-8aa3-e82ec7b7f5aa@default>

Hi David,

-----Original Message-----
From: David Holmes 
Sent: Friday, March 18, 2016 2:42 PM
To: Cheleswer Sahu; hotspot-runtime-dev at openjdk.java.net; serviceability-dev at openjdk.java.net
Subject: Re: RFR[9u-dev]: 8151442: jstack doesn't close quotation marks properly with threads' name greater than 1996 characters

On 18/03/2016 5:54 PM, Cheleswer Sahu wrote:
> Hi,
>
> Please review the code changes for
> https://bugs.openjdk.java.net/browse/JDK-8151442.
>
> Webrev Link: http://cr.openjdk.java.net/~csahu/8151442/
>
> Bug Brief:
>
> In jstack thread dumps , thread name greater than 1996 characters 
> doesn't close quotation marks properly.

Anyone giving a thread a name that long deserves to get a core dump! ;-)

> Problem Identified:
>
> Jstack is using below code to print thread name
>
> src/share/vm/runtime/thread.cpp
>
> void JavaThread::print_on(outputStream *st) const {
>
>    st->print("\"%s\" ", get_thread_name());
>
> Here "st->print()"  internally uses max buffer length as O_BUFLEN (2000).
>
> void outputStream::do_vsnprintf_and_write_with_automatic_buffer(const
> char* format, va_list ap, bool add_cr) {
>
>    char buffer[O_BUFLEN];
>
> do_vsnprintf_and_write_with_automatic_buffer() finally calls
>   "vsnprintf()"  which truncates the anything greater than the max 
> size(2000). In this case thread's name(> 1996) along with quotation 
> marks (2)
>
> plus one terminating character exceeds the  max buffer size (2000), 
> therefore the closing quotation  marks gets truncated.
>
> Solution:
>
> Split the  "st->print("\"%s\" ", get_thread_name())" in two statements
>
> 1.st->print("\"%s", get_thread_name());
>
> 2.st->print("\" ");
>
> This will ensure presence of closing quotation mark always.

Can't we just limit the number of characters read by %s?
 
Yes we can do it, but just one thing which I think of is, if the truncation of output inside  output stream issue get resolves as Dmritry suggested or O_BUFFLEN size gets increased in any  future fix then we have to again make changes in this code, as limiting the no. of character read by %s will give truncated output . In such case present fix will have no effect.
 
David

> Regards,
>
> Cheleswer
>

From david.holmes at oracle.com  Fri Mar 18 12:31:28 2016
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 18 Mar 2016 22:31:28 +1000
Subject: RFR(XS): 8152119: Event-based tracing to allow for tracing Klass
	definition
In-Reply-To: <60ebd13a-ff91-440e-94b2-17bcda9885a5@default>
References: <4d9d0f40-f8cc-461b-8fb6-cd6d9663bdf9@default>
	<56EB4764.7030101@oracle.com>
	<60ebd13a-ff91-440e-94b2-17bcda9885a5@default>
Message-ID: <56EBF520.4050503@oracle.com>

On 18/03/2016 7:33 PM, Markus Gronlund wrote:
> Hi David,
>
> Thanks for noticing, of course it should go outside the INCLUDE_TRACE macro. I should have checked this better - cheers.
>
> Both tracing.hpp and traceMacro.hpp can be unconditionally included, but I think I will just move out the traceMacros.hpp.
>
> Agree it will look a bit strange, but maybe not so much if it is moved outside of all the extra #defines:
>
> ...
> #include "services/threadService.hpp"
> #include "trace/traceMacros.hpp" <<--------

Right - not so strange looking there :)

Thanks,
David

> #include "utilities/macros.hpp"
> #include "utilities/ticks.hpp"
> #if INCLUDE_CDS
> #include "classfile/sharedClassUtil.hpp"
> #include "classfile/systemDictionaryShared.hpp"
> #endif
> #if INCLUDE_JVMCI
> #include "jvmci/jvmciRuntime.hpp"
> #endif
> #if INCLUDE_TRACE
> #include "trace/tracing.hpp"
> #endif
>
> Thanks again
> Markus
>
>
> -----Original Message-----
> From: David Holmes
> Sent: den 18 mars 2016 01:10
> To: Markus Gronlund; serviceability-dev at openjdk.java.net
> Subject: Re: RFR(XS): 8152119: Event-based tracing to allow for tracing Klass definition
>
> Hi Markus,
>
> On 18/03/2016 4:43 AM, Markus Gronlund wrote:
>> Greetings,
>>
>> Kindly asking for reviews for the following change to allow for
>> tracing Klass definitions.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8152119
>>
>> Webrev: http://cr.openjdk.java.net/~mgronlun/8152119/webrev01/
>
> You either need to change this:
>
>     77 #if INCLUDE_TRACE
>     78 #include "trace/tracing.hpp"
>     79 #include "trace/traceMacros.hpp"
>     80 #endif
>
> to include outside the INCLUDE_TRACE guard, or else this:
>
> 1501   TRACE_KLASS_DEFINITION(k, THREAD);
>
> needs to be inside an INCLUDE_TRACE guard.
>
> Based on existing code it should be the former, though I realize this will look strange:
>
> #if INCLUDE_TRACE
> #include "trace/tracing.hpp"
> #endif
> #include "trace/traceMacros.hpp"
>
> Thanks,
> David
>
>> This change complements the change associated with Klass creation
>> which is already integrated:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8147442
>>
>> Thanks
>>
>> Markus
>>

From david.holmes at oracle.com  Fri Mar 18 12:51:24 2016
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 18 Mar 2016 22:51:24 +1000
Subject: RFR[9u-dev]: 8151442: jstack doesn't close quotation marks
	properly with threads' name greater than 1996 characters
In-Reply-To: <0db522da-1cbe-494a-8aa3-e82ec7b7f5aa@default>
References: <556325b3-e8b2-4622-8b59-1df2ef4b1f02@default>
	<56EBC647.6020704@oracle.com>
	<0db522da-1cbe-494a-8aa3-e82ec7b7f5aa@default>
Message-ID: <56EBF9CC.8000809@oracle.com>

On 18/03/2016 10:03 PM, Cheleswer Sahu wrote:
> Hi David,
>
> -----Original Message-----
> From: David Holmes
> Sent: Friday, March 18, 2016 2:42 PM
> To: Cheleswer Sahu; hotspot-runtime-dev at openjdk.java.net; serviceability-dev at openjdk.java.net
> Subject: Re: RFR[9u-dev]: 8151442: jstack doesn't close quotation marks properly with threads' name greater than 1996 characters
>
> On 18/03/2016 5:54 PM, Cheleswer Sahu wrote:
>> Hi,
>>
>> Please review the code changes for
>> https://bugs.openjdk.java.net/browse/JDK-8151442.
>>
>> Webrev Link: http://cr.openjdk.java.net/~csahu/8151442/
>>
>> Bug Brief:
>>
>> In jstack thread dumps , thread name greater than 1996 characters
>> doesn't close quotation marks properly.
>
> Anyone giving a thread a name that long deserves to get a core dump! ;-)
>
>> Problem Identified:
>>
>> Jstack is using below code to print thread name
>>
>> src/share/vm/runtime/thread.cpp
>>
>> void JavaThread::print_on(outputStream *st) const {
>>
>>     st->print("\"%s\" ", get_thread_name());
>>
>> Here "st->print()"  internally uses max buffer length as O_BUFLEN (2000).
>>
>> void outputStream::do_vsnprintf_and_write_with_automatic_buffer(const
>> char* format, va_list ap, bool add_cr) {
>>
>>     char buffer[O_BUFLEN];
>>
>> do_vsnprintf_and_write_with_automatic_buffer() finally calls
>>    "vsnprintf()"  which truncates the anything greater than the max
>> size(2000). In this case thread's name(> 1996) along with quotation
>> marks (2)
>>
>> plus one terminating character exceeds the  max buffer size (2000),
>> therefore the closing quotation  marks gets truncated.
>>
>> Solution:
>>
>> Split the  "st->print("\"%s\" ", get_thread_name())" in two statements
>>
>> 1.st->print("\"%s", get_thread_name());
>>
>> 2.st->print("\" ");
>>
>> This will ensure presence of closing quotation mark always.
>
> Can't we just limit the number of characters read by %s?
>
> Yes we can do it, but just one thing which I think of is, if the truncation of output inside  output stream issue get resolves as Dmritry suggested or O_BUFFLEN size gets increased in any  future fix then we have to again make changes in this code, as limiting the no. of character read by %s will give truncated output . In such case present fix will have no effect.

Ignoring Dmitry's issue it still seems simpler/cleaner to just add the 
desired precision value to the %s than to split into two print 
statements. Or bite the bullet now and make the length immaterial by 
breaking the name into chunks. It's as easy to fix as to write the RFE :)

David

> David
>
>> Regards,
>>
>> Cheleswer
>>

From marcus.larsson at oracle.com  Fri Mar 18 13:04:12 2016
From: marcus.larsson at oracle.com (Marcus Larsson)
Date: Fri, 18 Mar 2016 14:04:12 +0100
Subject: RFR: 8146879: Add option for handling existing log files in UL
In-Reply-To: <56E2D478.3090202@oracle.com>
References: <5697B7F2.50104@oracle.com> <56D578F9.6090602@oracle.com>
	<56D5A1BB.6030403@oracle.com> <56E2D478.3090202@oracle.com>
Message-ID: <56EBFCCC.1080701@oracle.com>

Updated patch after feedback.

New webrev:
http://cr.openjdk.java.net/~mlarsson/8146879/webrev.04/

Incremental:
http://cr.openjdk.java.net/~mlarsson/8146879/webrev.03-04/

Tested with internal VM tests through RBT.

Changes:
* Rotation filecount is now limited to 1000 files.
* Removed loop in os::compare_file_modified_times.
* Added a check before rotating/truncating an existing log file, and 
will only do so if it's a regular file.
* Added test case to check that logging to a directory gives the 
intended error message.
* Fixed test help method to handle arbitrary length log lines.

Thanks,
Marcus

On 03/11/2016 03:21 PM, Marcus Larsson wrote:
> Third time's the charm.
>
> Webrev:
> http://cr.openjdk.java.net/~mlarsson/8146879/webrev.03/
>
> This patch makes log file rotation the default. Default thresholds are 
> 5 rotated files with a target size of 20MiB. Truncating behavior can 
> be achieved by setting filecount to 0 (-Xlog::myfile.log::filecount=0).
>
> If a log file already exists during log file initialization it will be 
> rotated. If any of the target file names (file.0 to file.4 in the 
> default case) are available, that filename will be used for the 
> existing log. If all names are taken the VM will attempt to overwrite 
> the oldest file.
>
> This should prevent unlimited log file creations and avoid accidental 
> loss of log files from previous runs. The default thresholds (5 files, 
> 20MiB each) is just a suggestion. If you think it should be 
> higher/lower let me know.
>
> Tested with included internal VM tests through RBT.
>
> Thanks,
> Marcus
>
> On 2016-03-01 15:05, Marcus Larsson wrote:
>> Hi,
>>
>> After some offline discussions I'm withdrawing this patch. I will 
>> instead investigate if I can achieve similar behavior using log 
>> rotation as the default.
>>
>> Thanks,
>> Marcus
>>
>> On 03/01/2016 12:11 PM, Marcus Larsson wrote:
>>> Hi again,
>>>
>>> Taking a different approach to this.
>>>
>>> New webrev:
>>> http://cr.openjdk.java.net/~mlarsson/8146879/webrev.01/
>>>
>>> Existing files will now by default be renamed/archived with a .X 
>>> suffix where X is the lowest number such that the resulting file 
>>> name is available (jvm.log becomes jvm.log.0). A mode option for 
>>> controlling this behavior has been added as well. It can be set to 
>>> archive, append, or truncate (i.e. -Xlog::jvm.log::mode=truncate).
>>>
>>> Tested with included jtreg test through JPRT.
>>>
>>> Thanks,
>>> Marcus
>>>
>>> On 01/14/2016 04:00 PM, Marcus Larsson wrote:
>>>> Hi,
>>>>
>>>> Please review the following patch to make sure UL truncates 
>>>> existing log files before writing to them. Since files are opened 
>>>> in append mode, truncation isn't done automatically, so instead the 
>>>> patch adds an attempt to remove the log file before opening it.
>>>>
>>>> Webrev:
>>>> http://cr.openjdk.java.net/~mlarsson/8146879/webrev.00/
>>>>
>>>> Issue:
>>>> https://bugs.openjdk.java.net/browse/JDK-8146879
>>>>
>>>> Testing:
>>>> Included test through JPRT
>>>>
>>>> Thanks,
>>>> Marcus
>>>
>>
>


From dmitry.samersoff at oracle.com  Fri Mar 18 13:28:37 2016
From: dmitry.samersoff at oracle.com (Dmitry Samersoff)
Date: Fri, 18 Mar 2016 16:28:37 +0300
Subject: RFR[9u-dev]: 8151442: jstack doesn't close quotation marks
	properly with threads' name greater than 1996 characters
In-Reply-To: <56EBF9CC.8000809@oracle.com>
References: <556325b3-e8b2-4622-8b59-1df2ef4b1f02@default>
	<56EBC647.6020704@oracle.com>
	<0db522da-1cbe-494a-8aa3-e82ec7b7f5aa@default>
	<56EBF9CC.8000809@oracle.com>
Message-ID: <56EC0285.9080004@oracle.com>

David,

> Ignoring Dmitry's issue it still seems simpler/cleaner to just add the
> desired precision value to the %s than to split into two print
> statements. Or bite the bullet now and make the length immaterial by
> breaking the name into chunks. It's as easy to fix as to write the
> RFE :)

For this particular case the simplest solution is to use print_raw:

print_raw("\""\"); print_raw(get_thread_name()); print_raw("\""\");


But as soon as print() finally ends up with:

const int written = vsnprintf(buffer, buflen, format, ap);
...
DEBUG_ONLY(warning("increase O_BUFLEN in ostream.hpp -- output truncated");)

Complete fix should be something like:

int desired_size = vsnprintf(NULL, 0, format, ap);
if (desired_size > O_BUFLEN) {
    malloc
    ....
}

but it has performance penalty, so we should use some tricks to cover
most common %s/%d/%p cases.

-Dmitry




On 2016-03-18 15:51, David Holmes wrote:
> On 18/03/2016 10:03 PM, Cheleswer Sahu wrote:
>> Hi David,
>>
>> -----Original Message-----
>> From: David Holmes
>> Sent: Friday, March 18, 2016 2:42 PM
>> To: Cheleswer Sahu; hotspot-runtime-dev at openjdk.java.net;
>> serviceability-dev at openjdk.java.net
>> Subject: Re: RFR[9u-dev]: 8151442: jstack doesn't close quotation
>> marks properly with threads' name greater than 1996 characters
>>
>> On 18/03/2016 5:54 PM, Cheleswer Sahu wrote:
>>> Hi,
>>>
>>> Please review the code changes for
>>> https://bugs.openjdk.java.net/browse/JDK-8151442.
>>>
>>> Webrev Link: http://cr.openjdk.java.net/~csahu/8151442/
>>>
>>> Bug Brief:
>>>
>>> In jstack thread dumps , thread name greater than 1996 characters
>>> doesn't close quotation marks properly.
>>
>> Anyone giving a thread a name that long deserves to get a core dump! ;-)
>>
>>> Problem Identified:
>>>
>>> Jstack is using below code to print thread name
>>>
>>> src/share/vm/runtime/thread.cpp
>>>
>>> void JavaThread::print_on(outputStream *st) const {
>>>
>>>     st->print("\"%s\" ", get_thread_name());
>>>
>>> Here "st->print()"  internally uses max buffer length as O_BUFLEN
>>> (2000).
>>>
>>> void outputStream::do_vsnprintf_and_write_with_automatic_buffer(const
>>> char* format, va_list ap, bool add_cr) {
>>>
>>>     char buffer[O_BUFLEN];
>>>
>>> do_vsnprintf_and_write_with_automatic_buffer() finally calls
>>>    "vsnprintf()"  which truncates the anything greater than the max
>>> size(2000). In this case thread's name(> 1996) along with quotation
>>> marks (2)
>>>
>>> plus one terminating character exceeds the  max buffer size (2000),
>>> therefore the closing quotation  marks gets truncated.
>>>
>>> Solution:
>>>
>>> Split the  "st->print("\"%s\" ", get_thread_name())" in two statements
>>>
>>> 1.st->print("\"%s", get_thread_name());
>>>
>>> 2.st->print("\" ");
>>>
>>> This will ensure presence of closing quotation mark always.
>>
>> Can't we just limit the number of characters read by %s?
>>
>> Yes we can do it, but just one thing which I think of is, if the
>> truncation of output inside  output stream issue get resolves as
>> Dmritry suggested or O_BUFFLEN size gets increased in any  future fix
>> then we have to again make changes in this code, as limiting the no.
>> of character read by %s will give truncated output . In such case
>> present fix will have no effect.
> 
> Ignoring Dmitry's issue it still seems simpler/cleaner to just add the
> desired precision value to the %s than to split into two print
> statements. Or bite the bullet now and make the length immaterial by
> breaking the name into chunks. It's as easy to fix as to write the RFE :)
> 
> David
> 
>> David
>>
>>> Regards,
>>>
>>> Cheleswer
>>>


-- 
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the sources.

From yasuenag at gmail.com  Fri Mar 18 14:14:44 2016
From: yasuenag at gmail.com (Yasumasa Suenaga)
Date: Fri, 18 Mar 2016 23:14:44 +0900
Subject: RFR: JDK-8151674: STW phases at Concurrent GC should count in
	PerfCounter
In-Reply-To: <CAGFVN2ATsvSfyzc-_AzBRXcUJMShENHog6XinvgyJiZBUMTXgQ@mail.gmail.com>
References: <56E242B5.1070206@gmail.com> <56E9A230.1060607@oracle.com>
	<CAGFVN2ATsvSfyzc-_AzBRXcUJMShENHog6XinvgyJiZBUMTXgQ@mail.gmail.com>
Message-ID: <56EC0D54.3090907@gmail.com>

Hi,

> I added a comment to JBS about G1 initial mark.
> I will upload new webrev after discussing for it.

We discussed about it on JBS, and we decided not to count initial mark on G1
to CGC counter. [1]

I uploaded new webrev. Could you review it?

   hotspot: http://cr.openjdk.java.net/~ysuenaga/JDK-8151674/webrev.01/hotspot/
       jdk: http://cr.openjdk.java.net/~ysuenaga/JDK-8151674/webrev.01/jdk/

jdk part is the same with the patch which is reviewed by Staffan Larsen. [2]


Thanks,

Yasumasa


[1] https://bugs.openjdk.java.net/browse/JDK-8151674?focusedCommentId=13914167&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13914167
[2] http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2016-March/016911.html


On 2016/03/17 8:23, Yasumasa Suenaga wrote:
> Hi Jon,
>
> 2016/03/17 3:25 "Jon Masamitsu" <jon.masamitsu at oracle.com <mailto:jon.masamitsu at oracle.com>>:
>  >
>  >
>  >
>  > On 03/10/2016 07:59 PM, Yasumasa Suenaga wrote:
>  >>
>  >> Hi all,
>  >>
>  >> This review request continues from:
>  >> http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2016-March/016774.html
>  >> http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2016-March/016896.html
>  >>
>  >> I wonder that STW phases (Remark and Cleanup) at G1 are not counted in jstat FGC column.
>  >> For example, Initial Mark and Remark at CMS are counted as FGC.
>  >> We discussed on hotspot-gc-dev for this issue, and I proposed to add new PerfCounter
>  >> for CGC STW phases.
>  >>
>  >> I uploaded webrev. Could you review it?
>  >>      hotspot: http://cr.openjdk.java.net/~ysuenaga/JDK-8151674/webrev.00/hotspot/
>  >>          jdk: http://cr.openjdk.java.net/~ysuenaga/JDK-8151674/webrev.00/jdk/
>  >>
>  >> For compatibility, this patch works the same as the current by default.
>  >> If you set -XX:+EnableConcGCPerfCounter, CGC counter will work fine.
>  >> (I want to set +EnableConcGCPerfCounter by default)
>  >
>  >
>  > I would prefer not to have the flag (EnableConcGCPerfCounte)
>  > and just make the change for CMS.  This is a change for a major
>  > release and I think we can accept the incompatibility.
>
> Okay, I will remove this flag.
>
> I added a comment to JBS about G1 initial mark.
> I will upload new webrev after discussing for it.
>
>  > http://cr.openjdk.java.net/~ysuenaga/JDK-8151674/webrev.00/hotspot/src/share/vm/gc/g1/g1MonitoringSupport.cpp.udiff.html
>  >
>  > + // name "collector.2". In a generational collector this would be the
>  > + // STW phases in concurrent collection.
>  > + _conc_collection_counters =
>  > + new CollectorCounters("G1 stop-the-world phases", 2);
>  >
>  >
>  > Is there a hard connection between these phases and a generational
>  > collector (i.e., should the "In a generational collector this would be the"
>  > be dropped in the comment)?
>  >
>  > A comment such as
>  >
>  > // name "collector.2". STW phases as part of a concurrent collection.
>
> Thanks, I will fix.
>
>  > A set of JDK changes had been previously been reviewed (not by me). Are these
>  > the same?
>  >
>  > http://cr.openjdk.java.net/~ysuenaga/JDK-8151674/webrev.00/jdk/
>
> Yes, same patch.
>
> Yasumasa
>
>  > Jon
>  >
>  >
>  >
>  >>
>  >>
>  >> I cannot access JPRT.
>  >> So I need a sponsor.
>  >>
>  >>
>  >> Thanks,
>  >>
>  >> Yasumasa
>  >
>  >
>

From jon.masamitsu at oracle.com  Fri Mar 18 19:45:40 2016
From: jon.masamitsu at oracle.com (Jon Masamitsu)
Date: Fri, 18 Mar 2016 12:45:40 -0700
Subject: RFR: JDK-8151674: STW phases at Concurrent GC should count in
	PerfCounter
In-Reply-To: <56EC0D54.3090907@gmail.com>
References: <56E242B5.1070206@gmail.com> <56E9A230.1060607@oracle.com>
	<CAGFVN2ATsvSfyzc-_AzBRXcUJMShENHog6XinvgyJiZBUMTXgQ@mail.gmail.com>
	<56EC0D54.3090907@gmail.com>
Message-ID: <56EC5AE4.4080909@oracle.com>



On 3/18/2016 7:14 AM, Yasumasa Suenaga wrote:
> Hi,
>
>> I added a comment to JBS about G1 initial mark.
>> I will upload new webrev after discussing for it.
>
> We discussed about it on JBS, and we decided not to count initial mark 
> on G1
> to CGC counter. [1]
>
> I uploaded new webrev. Could you review it?

Changes look good.   We'll need one more review of the hotspot changes.

Jon

>
>   hotspot: 
> http://cr.openjdk.java.net/~ysuenaga/JDK-8151674/webrev.01/hotspot/
>       jdk: 
> http://cr.openjdk.java.net/~ysuenaga/JDK-8151674/webrev.01/jdk/
>
> jdk part is the same with the patch which is reviewed by Staffan 
> Larsen. [2]
>
>
> Thanks,
>
> Yasumasa
>
>
> [1] 
> https://bugs.openjdk.java.net/browse/JDK-8151674?focusedCommentId=13914167&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13914167
> [2] 
> http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2016-March/016911.html
>
>
> On 2016/03/17 8:23, Yasumasa Suenaga wrote:
>> Hi Jon,
>>
>> 2016/03/17 3:25 "Jon Masamitsu" <jon.masamitsu at oracle.com 
>> <mailto:jon.masamitsu at oracle.com>>:
>>  >
>>  >
>>  >
>>  > On 03/10/2016 07:59 PM, Yasumasa Suenaga wrote:
>>  >>
>>  >> Hi all,
>>  >>
>>  >> This review request continues from:
>>  >> 
>> http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2016-March/016774.html
>>  >> 
>> http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2016-March/016896.html
>>  >>
>>  >> I wonder that STW phases (Remark and Cleanup) at G1 are not 
>> counted in jstat FGC column.
>>  >> For example, Initial Mark and Remark at CMS are counted as FGC.
>>  >> We discussed on hotspot-gc-dev for this issue, and I proposed to 
>> add new PerfCounter
>>  >> for CGC STW phases.
>>  >>
>>  >> I uploaded webrev. Could you review it?
>>  >>      hotspot: 
>> http://cr.openjdk.java.net/~ysuenaga/JDK-8151674/webrev.00/hotspot/
>>  >>          jdk: 
>> http://cr.openjdk.java.net/~ysuenaga/JDK-8151674/webrev.00/jdk/
>>  >>
>>  >> For compatibility, this patch works the same as the current by 
>> default.
>>  >> If you set -XX:+EnableConcGCPerfCounter, CGC counter will work fine.
>>  >> (I want to set +EnableConcGCPerfCounter by default)
>>  >
>>  >
>>  > I would prefer not to have the flag (EnableConcGCPerfCounte)
>>  > and just make the change for CMS.  This is a change for a major
>>  > release and I think we can accept the incompatibility.
>>
>> Okay, I will remove this flag.
>>
>> I added a comment to JBS about G1 initial mark.
>> I will upload new webrev after discussing for it.
>>
>>  > 
>> http://cr.openjdk.java.net/~ysuenaga/JDK-8151674/webrev.00/hotspot/src/share/vm/gc/g1/g1MonitoringSupport.cpp.udiff.html
>>  >
>>  > + // name "collector.2". In a generational collector this would be 
>> the
>>  > + // STW phases in concurrent collection.
>>  > + _conc_collection_counters =
>>  > + new CollectorCounters("G1 stop-the-world phases", 2);
>>  >
>>  >
>>  > Is there a hard connection between these phases and a generational
>>  > collector (i.e., should the "In a generational collector this 
>> would be the"
>>  > be dropped in the comment)?
>>  >
>>  > A comment such as
>>  >
>>  > // name "collector.2". STW phases as part of a concurrent collection.
>>
>> Thanks, I will fix.
>>
>>  > A set of JDK changes had been previously been reviewed (not by 
>> me). Are these
>>  > the same?
>>  >
>>  > http://cr.openjdk.java.net/~ysuenaga/JDK-8151674/webrev.00/jdk/
>>
>> Yes, same patch.
>>
>> Yasumasa
>>
>>  > Jon
>>  >
>>  >
>>  >
>>  >>
>>  >>
>>  >> I cannot access JPRT.
>>  >> So I need a sponsor.
>>  >>
>>  >>
>>  >> Thanks,
>>  >>
>>  >> Yasumasa
>>  >
>>  >
>>


From david.holmes at oracle.com  Fri Mar 18 21:37:10 2016
From: david.holmes at oracle.com (David Holmes)
Date: Sat, 19 Mar 2016 07:37:10 +1000
Subject: RFR[9u-dev]: 8151442: jstack doesn't close quotation marks
	properly with threads' name greater than 1996 characters
In-Reply-To: <56EC0285.9080004@oracle.com>
References: <556325b3-e8b2-4622-8b59-1df2ef4b1f02@default>
	<56EBC647.6020704@oracle.com>
	<0db522da-1cbe-494a-8aa3-e82ec7b7f5aa@default>
	<56EBF9CC.8000809@oracle.com> <56EC0285.9080004@oracle.com>
Message-ID: <56EC7506.902@oracle.com>



On 18/03/2016 11:28 PM, Dmitry Samersoff wrote:
> David,
>
>> Ignoring Dmitry's issue it still seems simpler/cleaner to just add the
>> desired precision value to the %s than to split into two print
>> statements. Or bite the bullet now and make the length immaterial by
>> breaking the name into chunks. It's as easy to fix as to write the
>> RFE :)
>
> For this particular case the simplest solution is to use print_raw:
>
> print_raw("\""\"); print_raw(get_thread_name()); print_raw("\""\");

I still see %.Ns as the simplest solution - but whatever.

>
> But as soon as print() finally ends up with:
>
> const int written = vsnprintf(buffer, buflen, format, ap);
> ...
> DEBUG_ONLY(warning("increase O_BUFLEN in ostream.hpp -- output truncated");)
>
> Complete fix should be something like:
>
> int desired_size = vsnprintf(NULL, 0, format, ap);
> if (desired_size > O_BUFLEN) {
>      malloc
>      ....
> }
>
> but it has performance penalty, so we should use some tricks to cover
> most common %s/%d/%p cases.

So you want to remove the internal limitation instead of have the 
clients deal with it? Not sure it is worth the effort - IIRC that code 
can be used at sensitive times hence the simple approach to buffer 
management.

David

> -Dmitry
>
>
>
>
> On 2016-03-18 15:51, David Holmes wrote:
>> On 18/03/2016 10:03 PM, Cheleswer Sahu wrote:
>>> Hi David,
>>>
>>> -----Original Message-----
>>> From: David Holmes
>>> Sent: Friday, March 18, 2016 2:42 PM
>>> To: Cheleswer Sahu; hotspot-runtime-dev at openjdk.java.net;
>>> serviceability-dev at openjdk.java.net
>>> Subject: Re: RFR[9u-dev]: 8151442: jstack doesn't close quotation
>>> marks properly with threads' name greater than 1996 characters
>>>
>>> On 18/03/2016 5:54 PM, Cheleswer Sahu wrote:
>>>> Hi,
>>>>
>>>> Please review the code changes for
>>>> https://bugs.openjdk.java.net/browse/JDK-8151442.
>>>>
>>>> Webrev Link: http://cr.openjdk.java.net/~csahu/8151442/
>>>>
>>>> Bug Brief:
>>>>
>>>> In jstack thread dumps , thread name greater than 1996 characters
>>>> doesn't close quotation marks properly.
>>>
>>> Anyone giving a thread a name that long deserves to get a core dump! ;-)
>>>
>>>> Problem Identified:
>>>>
>>>> Jstack is using below code to print thread name
>>>>
>>>> src/share/vm/runtime/thread.cpp
>>>>
>>>> void JavaThread::print_on(outputStream *st) const {
>>>>
>>>>      st->print("\"%s\" ", get_thread_name());
>>>>
>>>> Here "st->print()"  internally uses max buffer length as O_BUFLEN
>>>> (2000).
>>>>
>>>> void outputStream::do_vsnprintf_and_write_with_automatic_buffer(const
>>>> char* format, va_list ap, bool add_cr) {
>>>>
>>>>      char buffer[O_BUFLEN];
>>>>
>>>> do_vsnprintf_and_write_with_automatic_buffer() finally calls
>>>>     "vsnprintf()"  which truncates the anything greater than the max
>>>> size(2000). In this case thread's name(> 1996) along with quotation
>>>> marks (2)
>>>>
>>>> plus one terminating character exceeds the  max buffer size (2000),
>>>> therefore the closing quotation  marks gets truncated.
>>>>
>>>> Solution:
>>>>
>>>> Split the  "st->print("\"%s\" ", get_thread_name())" in two statements
>>>>
>>>> 1.st->print("\"%s", get_thread_name());
>>>>
>>>> 2.st->print("\" ");
>>>>
>>>> This will ensure presence of closing quotation mark always.
>>>
>>> Can't we just limit the number of characters read by %s?
>>>
>>> Yes we can do it, but just one thing which I think of is, if the
>>> truncation of output inside  output stream issue get resolves as
>>> Dmritry suggested or O_BUFFLEN size gets increased in any  future fix
>>> then we have to again make changes in this code, as limiting the no.
>>> of character read by %s will give truncated output . In such case
>>> present fix will have no effect.
>>
>> Ignoring Dmitry's issue it still seems simpler/cleaner to just add the
>> desired precision value to the %s than to split into two print
>> statements. Or bite the bullet now and make the length immaterial by
>> breaking the name into chunks. It's as easy to fix as to write the RFE :)
>>
>> David
>>
>>> David
>>>
>>>> Regards,
>>>>
>>>> Cheleswer
>>>>
>
>

From harsha.wardhana.b at oracle.com  Mon Mar 21 04:10:41 2016
From: harsha.wardhana.b at oracle.com (Harsha Wardhana B)
Date: Mon, 21 Mar 2016 09:40:41 +0530
Subject: RFR : JDK-8151797 -
	java/lang/management/ThreadMXBean/ThreadLists.java : inconsistent
	results
In-Reply-To: <0F53E9D3-2FC8-4C23-88EB-4F2C0BF0A039@oracle.com>
References: <56EBE3E0.7040109@oracle.com>
	<0F53E9D3-2FC8-4C23-88EB-4F2C0BF0A039@oracle.com>
Message-ID: <56EF7441.8010306@oracle.com>

Hello,

Please review the new patch located at,

http://cr.openjdk.java.net/~hb/8151797/webrev.01/

-Harsha

On Friday 18 March 2016 05:01 PM, Staffan Larsen wrote:
> You should move the Arrays.stream trigger call to before 
> the ManagementFactory.getThreadMXBean, otherwise the threads you get 
> from ThreadMXBean will not match the threads you get from the 
> ThreadGroups.
>
>> On 18 mars 2016, at 12:17, Harsha Wardhana B 
>> <harsha.wardhana.b at oracle.com <mailto:harsha.wardhana.b at oracle.com>> 
>> wrote:
>>
>> Hello All,
>>
>> Please review fix for,
>>
>> Issue : JDK-8151797 <http://jdk-8151797/> - 
>> java/lang/management/ThreadMXBean/ThreadLists.java : inconsistent results
>> Webrev : http://cr.openjdk.java.net/~hb/8151797/webrev.00/
>>
>> Root-cause :  call-site cleaner thread not started before counting 
>> threads via Thread.getAllStackTraces();.
>> Fix : Create ThreadMXBean at the beginning of test so that call-site 
>> cleaner thread will be started.
>>
>> Thanks
>> Harsha
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20160321/7326c4fc/attachment.html>

From staffan.larsen at oracle.com  Mon Mar 21 08:16:35 2016
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Mon, 21 Mar 2016 09:16:35 +0100
Subject: RFR: 7153107 com/sun/jdi/InterruptHangTest.java fails in nightlies
Message-ID: <597AD7AC-60FE-4A5E-8B82-81990CA61B25@oracle.com>

Hi,

For a while we have had various timeout related problem in the JDI tests. The root cause of this seems to be the Indy String Concatenation work which makes stepping over the first string concatenation horrendously slow in debug version of the jdk. It is not ISC itself that is to blame, instead it gets the blame for the full setup of the invokedynamic framework. See JDK-8151887 for a longer discussion about this.

One of the tests that fail because of this is com/sun/jdi/InterruptHangTest.java. In this fix, I have simply increased the timeout that is used internally in the test to take the jtreg timeoutfactor into consideration. This seems to allow enough time for stepping through the indy setup code. 

I have also added timestamped logging to the TestScaffold superclass to make it easier to see what is taking a long time and how far a test has proceeded. 

webrev: http://cr.openjdk.java.net/~sla/7153107/webrev.01/
bug: https://bugs.openjdk.java.net/browse/JDK-7153107

Thanks,
/Staffan


From robbin.ehn at oracle.com  Mon Mar 21 08:18:59 2016
From: robbin.ehn at oracle.com (Robbin Ehn)
Date: Mon, 21 Mar 2016 09:18:59 +0100
Subject: RFR[9u-dev]: 8151442: jstack doesn't close quotation marks
	properly with threads' name greater than 1996 characters
In-Reply-To: <556325b3-e8b2-4622-8b59-1df2ef4b1f02@default>
References: <556325b3-e8b2-4622-8b59-1df2ef4b1f02@default>
Message-ID: <56EFAE73.7040106@oracle.com>

Hi Cheleswer,

On 03/18/2016 08:54 AM, Cheleswer Sahu wrote:
> Hi,
>
> Please review the code changes for
> https://bugs.openjdk.java.net/browse/JDK-8151442.
>
> Webrev Link: http://cr.openjdk.java.net/~csahu/8151442/
>
> Bug Brief:
>
> In jstack thread dumps , thread name greater than 1996 characters
> doesn?t close quotation marks properly.
>
> Problem Identified:
>
> Jstack is using below code to print thread name
>
> src/share/vm/runtime/thread.cpp
>
> void JavaThread::print_on(outputStream *st) const {
>
>    st->print("\"%s\" ", get_thread_name());
>
> Here ?st->print()?  internally uses max buffer length as O_BUFLEN (2000).
>
> void outputStream::do_vsnprintf_and_write_with_automatic_buffer(const
> char* format, va_list ap, bool add_cr) {
>
>    char buffer[O_BUFLEN];
>
> do_vsnprintf_and_write_with_automatic_buffer() finally calls
>   ?vsnprintf()?  which truncates the anything greater than the max
> size(2000). In this case thread?s name(> 1996) along with quotation
> marks (2)
>
> plus one terminating character exceeds the  max buffer size (2000),
> therefore the closing quotation  marks gets truncated.
>
> Solution:
>
> Split the  ?st->print("\"%s\" ", get_thread_name())? in two statements
>
> 1.st->print("\"%s", get_thread_name());
>
> 2.st->print("\" ?);

This looks good, thanks for fixing.

/Robbin (not a reviewer)

(I must admit I'm very curious why anyone would have a thread name that 
long)

>
> This will ensure presence of closing quotation mark always.
>
> Regards,
>
> Cheleswer
>

From staffan.larsen at oracle.com  Mon Mar 21 08:22:53 2016
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Mon, 21 Mar 2016 09:22:53 +0100
Subject: RFR: 8151887 com/sun/jdi/RedefineClearBreakpoint.sh failed with
	timeout
Message-ID: <87F34551-A454-40EC-85F4-951AD5E42D46@oracle.com>

Hi,

See the JIRA issue or my recent review request of JDK-7153107 for a discussion about the cause of this timeout.

In this change I am changing the ShellScaffold to take the jtreg timeoutfactor into account. This allow more time for these tests on slower platforms. 

The timeoutfactor is a floating point number, but I could not find a way to do floating point calculations in bash without adding more dependencies. Instead I opted to truncate the resulting value into an integer. At most, this decreases the timeout by almost a second and should not matter.

webrev: http://cr.openjdk.java.net/~sla/8151887/webrev.00/test/com/sun/jdi/ShellScaffold.sh.sdiff.html
bug: https://bugs.openjdk.java.net/browse/JDK-8151887

Thanks,
/Staffan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20160321/d4e439a1/attachment.html>

From staffan.larsen at oracle.com  Mon Mar 21 08:23:35 2016
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Mon, 21 Mar 2016 09:23:35 +0100
Subject: RFR : JDK-8151797 -
	java/lang/management/ThreadMXBean/ThreadLists.java :
	inconsistent results
In-Reply-To: <56EF7441.8010306@oracle.com>
References: <56EBE3E0.7040109@oracle.com>
	<0F53E9D3-2FC8-4C23-88EB-4F2C0BF0A039@oracle.com>
	<56EF7441.8010306@oracle.com>
Message-ID: <C831E2BB-9592-4296-AC50-EE32919F2579@oracle.com>

Looks good!

Thanks,
/Staffan

> On 21 mars 2016, at 05:10, Harsha Wardhana B <harsha.wardhana.b at oracle.com> wrote:
> 
> Hello,
> 
> Please review the new patch located at,
> 
> http://cr.openjdk.java.net/~hb/8151797/webrev.01/ <http://cr.openjdk.java.net/%7Ehb/8151797/webrev.01/>
> 
> -Harsha
> 
> On Friday 18 March 2016 05:01 PM, Staffan Larsen wrote:
>> You should move the Arrays.stream trigger call to before the ManagementFactory.getThreadMXBean, otherwise the threads you get from ThreadMXBean will not match the threads you get from the ThreadGroups.
>> 
>>> On 18 mars 2016, at 12:17, Harsha Wardhana B <harsha.wardhana.b at oracle.com <mailto:harsha.wardhana.b at oracle.com>> wrote:
>>> 
>>> Hello All,
>>> 
>>> Please review fix for,
>>> 
>>> Issue : JDK-8151797 <http://jdk-8151797/> -  java/lang/management/ThreadMXBean/ThreadLists.java : inconsistent results
>>> Webrev : http://cr.openjdk.java.net/~hb/8151797/webrev.00/ <http://cr.openjdk.java.net/%7Ehb/8151797/webrev.00/>
>>> 
>>> Root-cause :  call-site cleaner thread not started before counting threads via Thread.getAllStackTraces();. 
>>> Fix : Create ThreadMXBean at the beginning of test so that call-site cleaner thread will be started. 
>>> 
>>> Thanks
>>> Harsha
>>> 
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20160321/9c1ff5f5/attachment-0001.html>

From dmitry.samersoff at oracle.com  Mon Mar 21 08:39:45 2016
From: dmitry.samersoff at oracle.com (Dmitry Samersoff)
Date: Mon, 21 Mar 2016 11:39:45 +0300
Subject: RFR[9u-dev]: 8151442: jstack doesn't close quotation marks
	properly with threads' name greater than 1996 characters
In-Reply-To: <56EC7506.902@oracle.com>
References: <556325b3-e8b2-4622-8b59-1df2ef4b1f02@default>
	<56EBC647.6020704@oracle.com>
	<0db522da-1cbe-494a-8aa3-e82ec7b7f5aa@default>
	<56EBF9CC.8000809@oracle.com> <56EC0285.9080004@oracle.com>
	<56EC7506.902@oracle.com>
Message-ID: <56EFB351.7010707@oracle.com>

David,

> I still see %.Ns as the simplest solution - but whatever.

It spreads artificial limitation of thread name length across hotspot
sources.

Brief grepping[1] shows couple of other places with the same problem and
if some days we decide to change default O_BUFLEN, we have to not forget
to change .N value in couple of places as well.

1.
./share/vm/prims/jni.cpp
673: "in thread \"%s\" ", thread->get_thread_name());

./share/vm/runtime/thread.cpp
1766: get_thread_profiler()->print(get_thread_name());
1974: get_thread_profiler()->print(get_thread_name());
2896: st->print("\"%s\" ", get_thread_name());
2926: st->print("%s", get_thread_name_string(buf, buflen));
2932: st->print("JavaThread \"%s\"", get_thread_name_string(buf, buflen));


./share/vm/services/threadService.cpp
882: ... st->print_cr("\"%s\":", currentThread->get_thread_name());
919: ..."%s \"%s\"", owner_desc, currentThread->get_thread_name());
932: ... st->print_cr("\"%s\":", currentThread->get_thread_name());

-Dmitry


On 2016-03-19 00:37, David Holmes wrote:
> 
> 
> On 18/03/2016 11:28 PM, Dmitry Samersoff wrote:
>> David,
>>
>>> Ignoring Dmitry's issue it still seems simpler/cleaner to just add the
>>> desired precision value to the %s than to split into two print
>>> statements. Or bite the bullet now and make the length immaterial by
>>> breaking the name into chunks. It's as easy to fix as to write the
>>> RFE :)
>>
>> For this particular case the simplest solution is to use print_raw:
>>
>> print_raw("\""\"); print_raw(get_thread_name()); print_raw("\""\");
> 
> I still see %.Ns as the simplest solution - but whatever.
> 
>>
>> But as soon as print() finally ends up with:
>>
>> const int written = vsnprintf(buffer, buflen, format, ap);
>> ...
>> DEBUG_ONLY(warning("increase O_BUFLEN in ostream.hpp -- output
>> truncated");)
>>
>> Complete fix should be something like:
>>
>> int desired_size = vsnprintf(NULL, 0, format, ap);
>> if (desired_size > O_BUFLEN) {
>>      malloc
>>      ....
>> }
>>
>> but it has performance penalty, so we should use some tricks to cover
>> most common %s/%d/%p cases.
> 
> So you want to remove the internal limitation instead of have the
> clients deal with it? Not sure it is worth the effort - IIRC that code
> can be used at sensitive times hence the simple approach to buffer
> management.
> 
> David
> 
>> -Dmitry
>>
>>
>>
>>
>> On 2016-03-18 15:51, David Holmes wrote:
>>> On 18/03/2016 10:03 PM, Cheleswer Sahu wrote:
>>>> Hi David,
>>>>
>>>> -----Original Message-----
>>>> From: David Holmes
>>>> Sent: Friday, March 18, 2016 2:42 PM
>>>> To: Cheleswer Sahu; hotspot-runtime-dev at openjdk.java.net;
>>>> serviceability-dev at openjdk.java.net
>>>> Subject: Re: RFR[9u-dev]: 8151442: jstack doesn't close quotation
>>>> marks properly with threads' name greater than 1996 characters
>>>>
>>>> On 18/03/2016 5:54 PM, Cheleswer Sahu wrote:
>>>>> Hi,
>>>>>
>>>>> Please review the code changes for
>>>>> https://bugs.openjdk.java.net/browse/JDK-8151442.
>>>>>
>>>>> Webrev Link: http://cr.openjdk.java.net/~csahu/8151442/
>>>>>
>>>>> Bug Brief:
>>>>>
>>>>> In jstack thread dumps , thread name greater than 1996 characters
>>>>> doesn't close quotation marks properly.
>>>>
>>>> Anyone giving a thread a name that long deserves to get a core dump!
>>>> ;-)
>>>>
>>>>> Problem Identified:
>>>>>
>>>>> Jstack is using below code to print thread name
>>>>>
>>>>> src/share/vm/runtime/thread.cpp
>>>>>
>>>>> void JavaThread::print_on(outputStream *st) const {
>>>>>
>>>>>      st->print("\"%s\" ", get_thread_name());
>>>>>
>>>>> Here "st->print()"  internally uses max buffer length as O_BUFLEN
>>>>> (2000).
>>>>>
>>>>> void outputStream::do_vsnprintf_and_write_with_automatic_buffer(const
>>>>> char* format, va_list ap, bool add_cr) {
>>>>>
>>>>>      char buffer[O_BUFLEN];
>>>>>
>>>>> do_vsnprintf_and_write_with_automatic_buffer() finally calls
>>>>>     "vsnprintf()"  which truncates the anything greater than the max
>>>>> size(2000). In this case thread's name(> 1996) along with quotation
>>>>> marks (2)
>>>>>
>>>>> plus one terminating character exceeds the  max buffer size (2000),
>>>>> therefore the closing quotation  marks gets truncated.
>>>>>
>>>>> Solution:
>>>>>
>>>>> Split the  "st->print("\"%s\" ", get_thread_name())" in two statements
>>>>>
>>>>> 1.st->print("\"%s", get_thread_name());
>>>>>
>>>>> 2.st->print("\" ");
>>>>>
>>>>> This will ensure presence of closing quotation mark always.
>>>>
>>>> Can't we just limit the number of characters read by %s?
>>>>
>>>> Yes we can do it, but just one thing which I think of is, if the
>>>> truncation of output inside  output stream issue get resolves as
>>>> Dmritry suggested or O_BUFFLEN size gets increased in any  future fix
>>>> then we have to again make changes in this code, as limiting the no.
>>>> of character read by %s will give truncated output . In such case
>>>> present fix will have no effect.
>>>
>>> Ignoring Dmitry's issue it still seems simpler/cleaner to just add the
>>> desired precision value to the %s than to split into two print
>>> statements. Or bite the bullet now and make the length immaterial by
>>> breaking the name into chunks. It's as easy to fix as to write the
>>> RFE :)
>>>
>>> David
>>>
>>>> David
>>>>
>>>>> Regards,
>>>>>
>>>>> Cheleswer
>>>>>
>>
>>


-- 
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the sources.

From dmitry.samersoff at oracle.com  Mon Mar 21 08:47:15 2016
From: dmitry.samersoff at oracle.com (Dmitry Samersoff)
Date: Mon, 21 Mar 2016 11:47:15 +0300
Subject: RFR: 8151887 com/sun/jdi/RedefineClearBreakpoint.sh failed with
	timeout
In-Reply-To: <87F34551-A454-40EC-85F4-951AD5E42D46@oracle.com>
References: <87F34551-A454-40EC-85F4-951AD5E42D46@oracle.com>
Message-ID: <56EFB513.5080609@oracle.com>

Staffan,

Looks good for me.

You may also consider to add -XDstringConcat=inline to javac options in
ShellScaffold

-Dmitry


On 2016-03-21 11:22, Staffan Larsen wrote:
> Hi,
> 
> See the JIRA issue or my recent review request of JDK-7153107 for a
> discussion about the cause of this timeout.
> 
> In this change I am changing the ShellScaffold to take the jtreg
> timeoutfactor into account. This allow more time for these tests on
> slower platforms. 
> 
> The timeoutfactor is a floating point number, but I could not find a way
> to do floating point calculations in bash without adding
> more dependencies. Instead I opted to truncate the resulting value into
> an integer. At most, this decreases the timeout by almost a second and
> should not matter.
> 
> webrev: http://cr.openjdk.java.net/~sla/8151887/webrev.00/test/com/sun/jdi/ShellScaffold.sh.sdiff.html
> bug: https://bugs.openjdk.java.net/browse/JDK-8151887
> 
> Thanks,
> /Staffan
> 


-- 
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the sources.

From robbin.ehn at oracle.com  Mon Mar 21 08:53:52 2016
From: robbin.ehn at oracle.com (Robbin Ehn)
Date: Mon, 21 Mar 2016 09:53:52 +0100
Subject: RFR[9u-dev]: 8151442: jstack doesn't close quotation marks
	properly with threads' name greater than 1996 characters
In-Reply-To: <56EFAE73.7040106@oracle.com>
References: <556325b3-e8b2-4622-8b59-1df2ef4b1f02@default>
	<56EFAE73.7040106@oracle.com>
Message-ID: <56EFB6A0.8090104@oracle.com>

Hi, sorry for the unnecessary review,

My mail-client spitted the mail thread into two different folders.

/Robbin

On 03/21/2016 09:18 AM, Robbin Ehn wrote:
> Hi Cheleswer,
>
> On 03/18/2016 08:54 AM, Cheleswer Sahu wrote:
>> Hi,
>>
>> Please review the code changes for
>> https://bugs.openjdk.java.net/browse/JDK-8151442.
>>
>> Webrev Link: http://cr.openjdk.java.net/~csahu/8151442/
>>
>> Bug Brief:
>>
>> In jstack thread dumps , thread name greater than 1996 characters
>> doesn?t close quotation marks properly.
>>
>> Problem Identified:
>>
>> Jstack is using below code to print thread name
>>
>> src/share/vm/runtime/thread.cpp
>>
>> void JavaThread::print_on(outputStream *st) const {
>>
>>    st->print("\"%s\" ", get_thread_name());
>>
>> Here ?st->print()?  internally uses max buffer length as O_BUFLEN (2000).
>>
>> void outputStream::do_vsnprintf_and_write_with_automatic_buffer(const
>> char* format, va_list ap, bool add_cr) {
>>
>>    char buffer[O_BUFLEN];
>>
>> do_vsnprintf_and_write_with_automatic_buffer() finally calls
>>   ?vsnprintf()?  which truncates the anything greater than the max
>> size(2000). In this case thread?s name(> 1996) along with quotation
>> marks (2)
>>
>> plus one terminating character exceeds the  max buffer size (2000),
>> therefore the closing quotation  marks gets truncated.
>>
>> Solution:
>>
>> Split the  ?st->print("\"%s\" ", get_thread_name())? in two statements
>>
>> 1.st->print("\"%s", get_thread_name());
>>
>> 2.st->print("\" ?);
>
> This looks good, thanks for fixing.
>
> /Robbin (not a reviewer)
>
> (I must admit I'm very curious why anyone would have a thread name that
> long)
>
>>
>> This will ensure presence of closing quotation mark always.
>>
>> Regards,
>>
>> Cheleswer
>>

From rainer.jung at kippdata.de  Mon Mar 21 09:05:23 2016
From: rainer.jung at kippdata.de (Rainer Jung)
Date: Mon, 21 Mar 2016 10:05:23 +0100
Subject: RFR[9u-dev]: 8151442: jstack doesn't close quotation marks
	properly with threads' name greater than 1996 characters
In-Reply-To: <56EFAE73.7040106@oracle.com>
References: <556325b3-e8b2-4622-8b59-1df2ef4b1f02@default>
	<56EFAE73.7040106@oracle.com>
Message-ID: <56EFB953.3010803@kippdata.de>

Am 21.03.2016 um 09:18 schrieb Robbin Ehn:
> (I must admit I'm very curious why anyone would have a thread name that
> long)

Since thread dumps are very useful for problem analysis but only contain 
stacks but no data, sometimes people switch the thread name on every new 
workload the thread handles, so that the thread name in the dump 
contains the info, kind of side-channel to tunnel data into the dump.

For example: in a web container one might append the request info (HTTP 
method, URI, query string, time the request began) with a separator to 
the original thread name at the beginning of the request, and strip it 
at the end. So if things hang or get slow and you take a thread dump, 
the info on what type or request each thread is working is present in 
that dump.

I'm not arguing whether this is a good pattern or not, but I have seen 
this pattern in production. Still, 1996 characters isn't easily reached 
even with this pattern.

Regards,

Rainer

From staffan.larsen at oracle.com  Mon Mar 21 09:20:32 2016
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Mon, 21 Mar 2016 10:20:32 +0100
Subject: RFR: 8151887 com/sun/jdi/RedefineClearBreakpoint.sh failed with
	timeout
In-Reply-To: <56EFB513.5080609@oracle.com>
References: <87F34551-A454-40EC-85F4-951AD5E42D46@oracle.com>
	<56EFB513.5080609@oracle.com>
Message-ID: <D6281CB3-B90F-4AF3-9581-DF9F5842C84F@oracle.com>

On 21 mars 2016, at 09:47, Dmitry Samersoff <dmitry.samersoff at oracle.com> wrote:
> 
> Staffan,
> 
> Looks good for me.

Thanks!

> 
> You may also consider to add -XDstringConcat=inline to javac options in
> ShellScaffold

I have considered it, but I?m reluctant to do it since it would mean that we are testing code paths that are different from what our users will see. 

/Staffan

> 
> -Dmitry
> 
> 
> On 2016-03-21 11:22, Staffan Larsen wrote:
>> Hi,
>> 
>> See the JIRA issue or my recent review request of JDK-7153107 for a
>> discussion about the cause of this timeout.
>> 
>> In this change I am changing the ShellScaffold to take the jtreg
>> timeoutfactor into account. This allow more time for these tests on
>> slower platforms. 
>> 
>> The timeoutfactor is a floating point number, but I could not find a way
>> to do floating point calculations in bash without adding
>> more dependencies. Instead I opted to truncate the resulting value into
>> an integer. At most, this decreases the timeout by almost a second and
>> should not matter.
>> 
>> webrev: http://cr.openjdk.java.net/~sla/8151887/webrev.00/test/com/sun/jdi/ShellScaffold.sh.sdiff.html
>> bug: https://bugs.openjdk.java.net/browse/JDK-8151887
>> 
>> Thanks,
>> /Staffan
>> 
> 
> 
> -- 
> Dmitry Samersoff
> Oracle Java development team, Saint Petersburg, Russia
> * I would love to change the world, but they won't give me the sources.


From kirk at kodewerk.com  Mon Mar 21 10:38:17 2016
From: kirk at kodewerk.com (kirk at kodewerk.com)
Date: Mon, 21 Mar 2016 11:38:17 +0100
Subject: RFR[9u-dev]: 8151442: jstack doesn't close quotation marks
	properly with threads' name greater than 1996 characters
In-Reply-To: <56EFB953.3010803@kippdata.de>
References: <556325b3-e8b2-4622-8b59-1df2ef4b1f02@default>
	<56EFAE73.7040106@oracle.com> <56EFB953.3010803@kippdata.de>
Message-ID: <57E6DDD9-DE2F-4156-8DEB-9D2ED78070F4@kodewerk.com>


> On Mar 21, 2016, at 10:05 AM, Rainer Jung <rainer.jung at kippdata.de> wrote:
> 
> Am 21.03.2016 um 09:18 schrieb Robbin Ehn:
>> (I must admit I'm very curious why anyone would have a thread name that
>> long)

I am also curious but that said, if the API allows for it, the tooling should do the right thing with the data.

Regards,
Kirk

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20160321/e32276b9/signature.asc>

From robbin.ehn at oracle.com  Mon Mar 21 13:36:11 2016
From: robbin.ehn at oracle.com (Robbin Ehn)
Date: Mon, 21 Mar 2016 14:36:11 +0100
Subject: RFR: 8150823: UL handles disabling logs incorrectly
In-Reply-To: <56EBE5A0.5070806@oracle.com>
References: <56E2D8ED.3040204@oracle.com> <56EBE5A0.5070806@oracle.com>
Message-ID: <56EFF8CB.1040807@oracle.com>

Hi Marcus

On 03/18/2016 12:25 PM, Marcus Larsson wrote:
> Hi,
>
> Updated the patch after offline discussion. New patch attempts to
> normalize the output name before searching for it or adding it. This
> includes adding the implicit file= prefix if missing, and/or removing
> quotes from a quoted name.

I think this looks good.

Thanks for fixing!

/Robbin (not a reviewer as you know)

>
> Webrev:
> http://cr.openjdk.java.net/~mlarsson/8150823/webrev.01/
>
> Incremental:
> http://cr.openjdk.java.net/~mlarsson/8150823/webrev.00-01/
>
> Tested with serviceability/logging tests through RBT.
>
> Thanks,
> Marcus
>
> On 03/11/2016 03:40 PM, Marcus Larsson wrote:
>> Hi,
>>
>> Please review the following patch to fix a problem with disabling log
>> outputs using -Xlog:disable or disable_logging() when there are
>> multiple file outputs configured. The patch also resolves an issue
>> with log file lookups that could cause multiple outputs to be created
>> for the same log file.
>>
>> Log output removal now iterates backwards to not invalidate the loop
>> index, and file outputs are always prepended with "file=" during
>> lookups and listings.
>>
>> Webrev:
>> http://cr.openjdk.java.net/~mlarsson/8150823/webrev.00/
>>
>> Issue:
>> https://bugs.openjdk.java.net/browse/JDK-8150823
>>
>> Testing:
>> Included tests through RBT
>>
>> Thanks,
>> Marcus
>

From ebaron at redhat.com  Mon Mar 21 15:00:26 2016
From: ebaron at redhat.com (Elliott Baron)
Date: Mon, 21 Mar 2016 11:00:26 -0400
Subject: [PATCH] JDK-8036559: Attach API does not allow root to connect to
	process owned by others
In-Reply-To: <56EA71AC.5070801@oracle.com>
References: <56E9CFBC.2080808@redhat.com> <56EA71AC.5070801@oracle.com>
Message-ID: <56F00C8A.9010509@redhat.com>

Hi Dmitry,

On 17/03/16 04:58 AM, Dmitry Samersoff wrote:
> Elliott,
>
> I'll take care of the CR.
>
> But as soon as the changes have security implication we should carefully
> evaluate possible side effects. So it takes some time.
>
> -Dmitry
>

Thanks, let me know if there is anything I can do to help.

Elliott

>
> On 2016-03-17 00:27, Elliott Baron wrote:
>> Hi,
>>
>> I've been working on an updated patch for JDK-8036559, where root does
>> not have the ability to attach to unprivileged users' JVMs. I originally
>> mentioned this problem back in 2013, and proposed a patch only for Linux
>> [1]. The result was that the fix had to provide support for all affected
>> platforms, and to include tests.
>>
>> We worked around this issue in our project, but I revisited this bug
>> recently. I investigated the issue on Windows, which has a very
>> different implementation from the other platforms. I discovered that
>> this bug does not appear to affect Windows. Using the test programs
>> attached to Red Hat Bugzilla bug #1311638 [2], I verified the correct
>> behaviour using the following steps:
>>> (Open cmd.exe)
>>> runas /user:test cmd.exe
>>> runas /user:Administrator cmd.exe
>>>
>>> (In test's shell)
>>> set TMP=C:\Users\Public\java_temp
>>> cd C:\Users\Public\Documents
>>> javac AttachTarget.java
>>> java AttachTarget
>>>
>>> (In Administrator's shell)
>>> set TMP=C:\Users\Public\java_temp
>>> cd C:\Users\Public\Documents
>>> javac -cp .;C:\Progra~1\Java\jdk1.8.0_74\lib\tools.jar AttachClient.java
>>> java -cp .;C:\Progra~1\Java\jdk1.8.0_74\lib\tools.jar AttachClient
>>> (outputs 'Target ok: AttachTarget')
>> My updated patches target JDK 9, and includes support for Linux,
>> Solaris, Mac OSX, and AIX. As far as tests are concerned, I'm not sure
>> how to add tests for this bug, since doing so would require the test to
>> be run as root. I am attaching the patches to this email, since I am not
>> an OpenJDK committer and do not have access to cr.openjdk.java.net.
>>
>> Thanks,
>> Elliott
>>
>> [1]
>> http://mail.openjdk.java.net/pipermail/serviceability-dev/2013-June/010077.html
>>
>> [2] https://bugzilla.redhat.com/show_bug.cgi?id=1311638
>


From marcus.larsson at oracle.com  Mon Mar 21 15:05:00 2016
From: marcus.larsson at oracle.com (Marcus Larsson)
Date: Mon, 21 Mar 2016 16:05:00 +0100
Subject: RFR: 8150823: UL handles disabling logs incorrectly
In-Reply-To: <56EFF8CB.1040807@oracle.com>
References: <56E2D8ED.3040204@oracle.com> <56EBE5A0.5070806@oracle.com>
	<56EFF8CB.1040807@oracle.com>
Message-ID: <56F00D9C.50303@oracle.com>

Thanks for reviewing, Robbin!

Marcus

On 03/21/2016 02:36 PM, Robbin Ehn wrote:
> Hi Marcus
>
> On 03/18/2016 12:25 PM, Marcus Larsson wrote:
>> Hi,
>>
>> Updated the patch after offline discussion. New patch attempts to
>> normalize the output name before searching for it or adding it. This
>> includes adding the implicit file= prefix if missing, and/or removing
>> quotes from a quoted name.
>
> I think this looks good.
>
> Thanks for fixing!
>
> /Robbin (not a reviewer as you know)
>
>>
>> Webrev:
>> http://cr.openjdk.java.net/~mlarsson/8150823/webrev.01/
>>
>> Incremental:
>> http://cr.openjdk.java.net/~mlarsson/8150823/webrev.00-01/
>>
>> Tested with serviceability/logging tests through RBT.
>>
>> Thanks,
>> Marcus
>>
>> On 03/11/2016 03:40 PM, Marcus Larsson wrote:
>>> Hi,
>>>
>>> Please review the following patch to fix a problem with disabling log
>>> outputs using -Xlog:disable or disable_logging() when there are
>>> multiple file outputs configured. The patch also resolves an issue
>>> with log file lookups that could cause multiple outputs to be created
>>> for the same log file.
>>>
>>> Log output removal now iterates backwards to not invalidate the loop
>>> index, and file outputs are always prepended with "file=" during
>>> lookups and listings.
>>>
>>> Webrev:
>>> http://cr.openjdk.java.net/~mlarsson/8150823/webrev.00/
>>>
>>> Issue:
>>> https://bugs.openjdk.java.net/browse/JDK-8150823
>>>
>>> Testing:
>>> Included tests through RBT
>>>
>>> Thanks,
>>> Marcus
>>


From robbin.ehn at oracle.com  Mon Mar 21 16:26:21 2016
From: robbin.ehn at oracle.com (Robbin Ehn)
Date: Mon, 21 Mar 2016 17:26:21 +0100
Subject: RFR(xs): 8151993: Remove inclusion of inline.hpp in log.hpp
In-Reply-To: <2D6479D0-C76F-4A8F-980F-B8788ACBC4A7@oracle.com>
References: <56E952A5.6050708@oracle.com>
	<816216C7-85B9-4E1F-8A4A-BBB5FFD728D4@oracle.com>
	<56EA5250.8090001@oracle.com>
	<2D6479D0-C76F-4A8F-980F-B8788ACBC4A7@oracle.com>
Message-ID: <56F020AD.6000708@oracle.com>

Hi Kim,

On 03/17/2016 11:33 PM, Kim Barrett wrote:
>> On Mar 17, 2016, at 2:44 AM, Robbin Ehn <robbin.ehn at oracle.com> wrote:
>> On 03/16/2016 05:13 PM, Kim Barrett wrote:
>>>> On Mar 16, 2016, at 8:33 AM, Robbin Ehn <robbin.ehn at oracle.com> wrote:
>>>>
>>>> Hi, please review this small change.
>>>>
>>>> This also change allocation methods.
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8151993/
>>>> Webrev: http://cr.openjdk.java.net/~rehn/8151993/webrev/
>>>>
>>>> Thanks!
>>>>
>>>> /Robbin
>>>
>>> ------------------------------------------------------------------------------
>>> src/share/vm/logging/log.hpp
>>> Changing this:
>>>   138       char* newbuf = NEW_C_HEAP_ARRAY(char, newbuf_len, mtLogging);
>>> to this:
>>>   137       char* newbuf = (char*) os::malloc(sizeof(char) * newbuf_len, mtLogging);
>>>
>>> New code is missing out of memory handling that was present in the old
>>> code.  New code will just try to use newbuf, with bad results if the
>>> allocation failed.
>>
>> Yes
>>
>>>
>>> New code is missing ASSERT-conditionalized PrintMallocFree support
>>> that was present in the old.  I don't know how important this is,
>>> given that we also have PrintMalloc.  (And I have to wonder why we
>>> have both PrintMalloc (develop) and PrintMallocFree (notproduct).)
>>>
>>> ------------------------------------------------------------------------------
>>>
>>
>> I wonder if this is even is the right path, we have 25 hpp including allocation.inline.
>> The other ones seem to do their allocation from their inline.hpp file.
>>
>> Making me believe that we should either ignore this or do log.inline.hpp.
>>
>> Either way this patch should be dropped, thoughts?
>
> I don't think ignoring is the right long-term approach, though is
> probably ok in the short term.  In particular, I think adding
> log.inline.hpp would touch a lot of files, which seems like a bad
> thing to do just now, with largish changes coming soon that would need
> to be merged.  And I'm not convinced log.inline.hpp is the right long
> term approach anyway.

Ok,

>
> Rather, I prefer Carsten's suggestion of an out of line slow-path
> function in a .cpp.  This approach is possible, even though we're
> dealing with templates, by using type-erasure.  The generic
> (non-templated) slow-path function would need to receive a couple of
> function pointers from the vwrite template, e.g. the prefix and puts
> functions that are referenced by the present template code.  The
> function pointer types don't refer to template parameters, e.g. the
> prefix function's type is
>
>    size_t (*prefix_fn)(char*, size_t)
>
> and puts is
>
>    void (*puts_fn)(LogLevelType, const char*)
>
>

I wanted to avoid introducing a lot of things not directly related to 
removing the include.

Thanks for your input!

/Robbin

From daniel.daugherty at oracle.com  Mon Mar 21 16:31:40 2016
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Mon, 21 Mar 2016 10:31:40 -0600
Subject: RFR[9u-dev]: 8151442: jstack doesn't close quotation marks
	properly with threads' name greater than 1996 characters
In-Reply-To: <56EFB351.7010707@oracle.com>
References: <556325b3-e8b2-4622-8b59-1df2ef4b1f02@default>
	<56EBC647.6020704@oracle.com>
	<0db522da-1cbe-494a-8aa3-e82ec7b7f5aa@default>
	<56EBF9CC.8000809@oracle.com> <56EC0285.9080004@oracle.com>
	<56EC7506.902@oracle.com> <56EFB351.7010707@oracle.com>
Message-ID: <56F021EC.4010105@oracle.com>

On 3/21/16 2:39 AM, Dmitry Samersoff wrote:
> David,
>
>> I still see %.Ns as the simplest solution - but whatever.
> It spreads artificial limitation of thread name length across hotspot
> sources.
>
> Brief grepping[1] shows couple of other places with the same problem and
> if some days we decide to change default O_BUFLEN, we have to not forget
> to change .N value in couple of places as well.

There should be a way to pass the precision value as a parameter instead
of hardcoding it in the format string. Something like:

     sprintf("%.*s", precision_value, string);

Dan

>
> 1.
> ./share/vm/prims/jni.cpp
> 673: "in thread \"%s\" ", thread->get_thread_name());
>
> ./share/vm/runtime/thread.cpp
> 1766: get_thread_profiler()->print(get_thread_name());
> 1974: get_thread_profiler()->print(get_thread_name());
> 2896: st->print("\"%s\" ", get_thread_name());
> 2926: st->print("%s", get_thread_name_string(buf, buflen));
> 2932: st->print("JavaThread \"%s\"", get_thread_name_string(buf, buflen));
>
>
> ./share/vm/services/threadService.cpp
> 882: ... st->print_cr("\"%s\":", currentThread->get_thread_name());
> 919: ..."%s \"%s\"", owner_desc, currentThread->get_thread_name());
> 932: ... st->print_cr("\"%s\":", currentThread->get_thread_name());
>
> -Dmitry
>
>
> On 2016-03-19 00:37, David Holmes wrote:
>>
>> On 18/03/2016 11:28 PM, Dmitry Samersoff wrote:
>>> David,
>>>
>>>> Ignoring Dmitry's issue it still seems simpler/cleaner to just add the
>>>> desired precision value to the %s than to split into two print
>>>> statements. Or bite the bullet now and make the length immaterial by
>>>> breaking the name into chunks. It's as easy to fix as to write the
>>>> RFE :)
>>> For this particular case the simplest solution is to use print_raw:
>>>
>>> print_raw("\""\"); print_raw(get_thread_name()); print_raw("\""\");
>> I still see %.Ns as the simplest solution - but whatever.
>>
>>> But as soon as print() finally ends up with:
>>>
>>> const int written = vsnprintf(buffer, buflen, format, ap);
>>> ...
>>> DEBUG_ONLY(warning("increase O_BUFLEN in ostream.hpp -- output
>>> truncated");)
>>>
>>> Complete fix should be something like:
>>>
>>> int desired_size = vsnprintf(NULL, 0, format, ap);
>>> if (desired_size > O_BUFLEN) {
>>>       malloc
>>>       ....
>>> }
>>>
>>> but it has performance penalty, so we should use some tricks to cover
>>> most common %s/%d/%p cases.
>> So you want to remove the internal limitation instead of have the
>> clients deal with it? Not sure it is worth the effort - IIRC that code
>> can be used at sensitive times hence the simple approach to buffer
>> management.
>>
>> David
>>
>>> -Dmitry
>>>
>>>
>>>
>>>
>>> On 2016-03-18 15:51, David Holmes wrote:
>>>> On 18/03/2016 10:03 PM, Cheleswer Sahu wrote:
>>>>> Hi David,
>>>>>
>>>>> -----Original Message-----
>>>>> From: David Holmes
>>>>> Sent: Friday, March 18, 2016 2:42 PM
>>>>> To: Cheleswer Sahu; hotspot-runtime-dev at openjdk.java.net;
>>>>> serviceability-dev at openjdk.java.net
>>>>> Subject: Re: RFR[9u-dev]: 8151442: jstack doesn't close quotation
>>>>> marks properly with threads' name greater than 1996 characters
>>>>>
>>>>> On 18/03/2016 5:54 PM, Cheleswer Sahu wrote:
>>>>>> Hi,
>>>>>>
>>>>>> Please review the code changes for
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8151442.
>>>>>>
>>>>>> Webrev Link: http://cr.openjdk.java.net/~csahu/8151442/
>>>>>>
>>>>>> Bug Brief:
>>>>>>
>>>>>> In jstack thread dumps , thread name greater than 1996 characters
>>>>>> doesn't close quotation marks properly.
>>>>> Anyone giving a thread a name that long deserves to get a core dump!
>>>>> ;-)
>>>>>
>>>>>> Problem Identified:
>>>>>>
>>>>>> Jstack is using below code to print thread name
>>>>>>
>>>>>> src/share/vm/runtime/thread.cpp
>>>>>>
>>>>>> void JavaThread::print_on(outputStream *st) const {
>>>>>>
>>>>>>       st->print("\"%s\" ", get_thread_name());
>>>>>>
>>>>>> Here "st->print()"  internally uses max buffer length as O_BUFLEN
>>>>>> (2000).
>>>>>>
>>>>>> void outputStream::do_vsnprintf_and_write_with_automatic_buffer(const
>>>>>> char* format, va_list ap, bool add_cr) {
>>>>>>
>>>>>>       char buffer[O_BUFLEN];
>>>>>>
>>>>>> do_vsnprintf_and_write_with_automatic_buffer() finally calls
>>>>>>      "vsnprintf()"  which truncates the anything greater than the max
>>>>>> size(2000). In this case thread's name(> 1996) along with quotation
>>>>>> marks (2)
>>>>>>
>>>>>> plus one terminating character exceeds the  max buffer size (2000),
>>>>>> therefore the closing quotation  marks gets truncated.
>>>>>>
>>>>>> Solution:
>>>>>>
>>>>>> Split the  "st->print("\"%s\" ", get_thread_name())" in two statements
>>>>>>
>>>>>> 1.st->print("\"%s", get_thread_name());
>>>>>>
>>>>>> 2.st->print("\" ");
>>>>>>
>>>>>> This will ensure presence of closing quotation mark always.
>>>>> Can't we just limit the number of characters read by %s?
>>>>>
>>>>> Yes we can do it, but just one thing which I think of is, if the
>>>>> truncation of output inside  output stream issue get resolves as
>>>>> Dmritry suggested or O_BUFFLEN size gets increased in any  future fix
>>>>> then we have to again make changes in this code, as limiting the no.
>>>>> of character read by %s will give truncated output . In such case
>>>>> present fix will have no effect.
>>>> Ignoring Dmitry's issue it still seems simpler/cleaner to just add the
>>>> desired precision value to the %s than to split into two print
>>>> statements. Or bite the bullet now and make the length immaterial by
>>>> breaking the name into chunks. It's as easy to fix as to write the
>>>> RFE :)
>>>>
>>>> David
>>>>
>>>>> David
>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> Cheleswer
>>>>>>
>>>
>


From robbin.ehn at oracle.com  Mon Mar 21 16:34:11 2016
From: robbin.ehn at oracle.com (Robbin Ehn)
Date: Mon, 21 Mar 2016 17:34:11 +0100
Subject: RFR(xs): 8151993: Remove inclusion of inline.hpp in log.hpp
In-Reply-To: <56E952A5.6050708@oracle.com>
References: <56E952A5.6050708@oracle.com>
Message-ID: <56F02283.10908@oracle.com>

Hi all, please review this a somewhat bigger change-set.

Updated with the feedback.

New webrev: http://cr.openjdk.java.net/~rehn/8151993/v2/webrev/

Tested with jprt hotspot and I added 2 internal vm tests.

(also 2 bugs fixed, missing va_end and a potential race when calling 
prefix function twice (very unlikely))

Thanks!

/Robbin

On 03/16/2016 01:33 PM, Robbin Ehn wrote:
> Hi, please review this small change.
>
> This also change allocation methods.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8151993/
> Webrev: http://cr.openjdk.java.net/~rehn/8151993/webrev/
>
> Thanks!
>
> /Robbin

From sgehwolf at redhat.com  Mon Mar 21 17:47:51 2016
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Mon, 21 Mar 2016 18:47:51 +0100
Subject: RFR(s) 4858370: JDWP: Memory Leak: GlobalRefs never deleted when
	processing invokeMethod command
Message-ID: <1458582471.3539.24.camel@redhat.com>

Hi,

Could somebody please review this fix for bug 4858370?

Bug:?https://bugs.openjdk.java.net/browse/JDK-4858370
webrev:?http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-4858370/webrev.01/

Testing done: jdk_jdi test group passes. Added regression test.

There is a memory leak in the JDWP implementation where method
parameters, method return values and the "this" object reference for
constructor invocations are kept in memory via a global reference and
get, thus, never GC'ed.

The proposed fix deletes global references again in
invoke_completeInvokeRequest(). The references got previously created
in?fillInvokeRequest() and invoker_invoke*() implementations.

Thoughts?

Note that I'd need somebody to sponsor the push to JDK 9 tree for me
(once approved). Thanks.

Cheers,
Severin


From david.holmes at oracle.com  Mon Mar 21 21:24:00 2016
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 22 Mar 2016 07:24:00 +1000
Subject: RFR[9u-dev]: 8151442: jstack doesn't close quotation marks
	properly with threads' name greater than 1996 characters
In-Reply-To: <56F021EC.4010105@oracle.com>
References: <556325b3-e8b2-4622-8b59-1df2ef4b1f02@default>
	<56EBC647.6020704@oracle.com>
	<0db522da-1cbe-494a-8aa3-e82ec7b7f5aa@default>
	<56EBF9CC.8000809@oracle.com> <56EC0285.9080004@oracle.com>
	<56EC7506.902@oracle.com> <56EFB351.7010707@oracle.com>
	<56F021EC.4010105@oracle.com>
Message-ID: <56F06670.5030802@oracle.com>

On 22/03/2016 2:31 AM, Daniel D. Daugherty wrote:
> On 3/21/16 2:39 AM, Dmitry Samersoff wrote:
>> David,
>>
>>> I still see %.Ns as the simplest solution - but whatever.
>> It spreads artificial limitation of thread name length across hotspot
>> sources.
>>
>> Brief grepping[1] shows couple of other places with the same problem and
>> if some days we decide to change default O_BUFLEN, we have to not forget
>> to change .N value in couple of places as well.
>
> There should be a way to pass the precision value as a parameter instead
> of hardcoding it in the format string. Something like:
>
>      sprintf("%.*s", precision_value, string);

Yes the length limit can be passed as a variable. But I think Dmitry 
just wants to allow for unlimited lengths. Not sure how to achieve that 
at the lowest level though as we need to avoid complex allocations etc 
in these print routines.

David


> Dan
>
>>
>> 1.
>> ./share/vm/prims/jni.cpp
>> 673: "in thread \"%s\" ", thread->get_thread_name());
>>
>> ./share/vm/runtime/thread.cpp
>> 1766: get_thread_profiler()->print(get_thread_name());
>> 1974: get_thread_profiler()->print(get_thread_name());
>> 2896: st->print("\"%s\" ", get_thread_name());
>> 2926: st->print("%s", get_thread_name_string(buf, buflen));
>> 2932: st->print("JavaThread \"%s\"", get_thread_name_string(buf,
>> buflen));
>>
>>
>> ./share/vm/services/threadService.cpp
>> 882: ... st->print_cr("\"%s\":", currentThread->get_thread_name());
>> 919: ..."%s \"%s\"", owner_desc, currentThread->get_thread_name());
>> 932: ... st->print_cr("\"%s\":", currentThread->get_thread_name());
>>
>> -Dmitry
>>
>>
>> On 2016-03-19 00:37, David Holmes wrote:
>>>
>>> On 18/03/2016 11:28 PM, Dmitry Samersoff wrote:
>>>> David,
>>>>
>>>>> Ignoring Dmitry's issue it still seems simpler/cleaner to just add the
>>>>> desired precision value to the %s than to split into two print
>>>>> statements. Or bite the bullet now and make the length immaterial by
>>>>> breaking the name into chunks. It's as easy to fix as to write the
>>>>> RFE :)
>>>> For this particular case the simplest solution is to use print_raw:
>>>>
>>>> print_raw("\""\"); print_raw(get_thread_name()); print_raw("\""\");
>>> I still see %.Ns as the simplest solution - but whatever.
>>>
>>>> But as soon as print() finally ends up with:
>>>>
>>>> const int written = vsnprintf(buffer, buflen, format, ap);
>>>> ...
>>>> DEBUG_ONLY(warning("increase O_BUFLEN in ostream.hpp -- output
>>>> truncated");)
>>>>
>>>> Complete fix should be something like:
>>>>
>>>> int desired_size = vsnprintf(NULL, 0, format, ap);
>>>> if (desired_size > O_BUFLEN) {
>>>>       malloc
>>>>       ....
>>>> }
>>>>
>>>> but it has performance penalty, so we should use some tricks to cover
>>>> most common %s/%d/%p cases.
>>> So you want to remove the internal limitation instead of have the
>>> clients deal with it? Not sure it is worth the effort - IIRC that code
>>> can be used at sensitive times hence the simple approach to buffer
>>> management.
>>>
>>> David
>>>
>>>> -Dmitry
>>>>
>>>>
>>>>
>>>>
>>>> On 2016-03-18 15:51, David Holmes wrote:
>>>>> On 18/03/2016 10:03 PM, Cheleswer Sahu wrote:
>>>>>> Hi David,
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: David Holmes
>>>>>> Sent: Friday, March 18, 2016 2:42 PM
>>>>>> To: Cheleswer Sahu; hotspot-runtime-dev at openjdk.java.net;
>>>>>> serviceability-dev at openjdk.java.net
>>>>>> Subject: Re: RFR[9u-dev]: 8151442: jstack doesn't close quotation
>>>>>> marks properly with threads' name greater than 1996 characters
>>>>>>
>>>>>> On 18/03/2016 5:54 PM, Cheleswer Sahu wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> Please review the code changes for
>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8151442.
>>>>>>>
>>>>>>> Webrev Link: http://cr.openjdk.java.net/~csahu/8151442/
>>>>>>>
>>>>>>> Bug Brief:
>>>>>>>
>>>>>>> In jstack thread dumps , thread name greater than 1996 characters
>>>>>>> doesn't close quotation marks properly.
>>>>>> Anyone giving a thread a name that long deserves to get a core dump!
>>>>>> ;-)
>>>>>>
>>>>>>> Problem Identified:
>>>>>>>
>>>>>>> Jstack is using below code to print thread name
>>>>>>>
>>>>>>> src/share/vm/runtime/thread.cpp
>>>>>>>
>>>>>>> void JavaThread::print_on(outputStream *st) const {
>>>>>>>
>>>>>>>       st->print("\"%s\" ", get_thread_name());
>>>>>>>
>>>>>>> Here "st->print()"  internally uses max buffer length as O_BUFLEN
>>>>>>> (2000).
>>>>>>>
>>>>>>> void
>>>>>>> outputStream::do_vsnprintf_and_write_with_automatic_buffer(const
>>>>>>> char* format, va_list ap, bool add_cr) {
>>>>>>>
>>>>>>>       char buffer[O_BUFLEN];
>>>>>>>
>>>>>>> do_vsnprintf_and_write_with_automatic_buffer() finally calls
>>>>>>>      "vsnprintf()"  which truncates the anything greater than the
>>>>>>> max
>>>>>>> size(2000). In this case thread's name(> 1996) along with quotation
>>>>>>> marks (2)
>>>>>>>
>>>>>>> plus one terminating character exceeds the  max buffer size (2000),
>>>>>>> therefore the closing quotation  marks gets truncated.
>>>>>>>
>>>>>>> Solution:
>>>>>>>
>>>>>>> Split the  "st->print("\"%s\" ", get_thread_name())" in two
>>>>>>> statements
>>>>>>>
>>>>>>> 1.st->print("\"%s", get_thread_name());
>>>>>>>
>>>>>>> 2.st->print("\" ");
>>>>>>>
>>>>>>> This will ensure presence of closing quotation mark always.
>>>>>> Can't we just limit the number of characters read by %s?
>>>>>>
>>>>>> Yes we can do it, but just one thing which I think of is, if the
>>>>>> truncation of output inside  output stream issue get resolves as
>>>>>> Dmritry suggested or O_BUFFLEN size gets increased in any  future fix
>>>>>> then we have to again make changes in this code, as limiting the no.
>>>>>> of character read by %s will give truncated output . In such case
>>>>>> present fix will have no effect.
>>>>> Ignoring Dmitry's issue it still seems simpler/cleaner to just add the
>>>>> desired precision value to the %s than to split into two print
>>>>> statements. Or bite the bullet now and make the length immaterial by
>>>>> breaking the name into chunks. It's as easy to fix as to write the
>>>>> RFE :)
>>>>>
>>>>> David
>>>>>
>>>>>> David
>>>>>>
>>>>>>> Regards,
>>>>>>>
>>>>>>> Cheleswer
>>>>>>>
>>>>
>>
>

From serguei.spitsyn at oracle.com  Mon Mar 21 21:38:15 2016
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Mon, 21 Mar 2016 14:38:15 -0700
Subject: RFR(s) 4858370: JDWP: Memory Leak: GlobalRefs never deleted when
	processing invokeMethod command
In-Reply-To: <1458582471.3539.24.camel@redhat.com>
References: <1458582471.3539.24.camel@redhat.com>
Message-ID: <56F069C7.8070209@oracle.com>

Hi Severin,

Thank you for taking care about this issue!

The fix looks pretty good.
A couple of minor comments though.

src/jdk.jdwp.agent/share/native/libjdwp/invoker.c

222 jint argIndex;
223 jbyte argumentTag;
224 jvalue *argument;
225 void *cursor; . . . 234 argIndex = 0;
235 argumentTag = firstArgumentTypeTag(request->methodSignature, &cursor);
236 argument = request->arguments;

   Could you make a small simplification and re-arrange the 
initialization of the locals:

void *cursor; jint argIndex = 0;
jvalue *argument= request->arguments;
jbyte argumentTag= firstArgumentTypeTag(request->methodSignature, &cursor);
  

   I'd also suggest to get rid of the extra spaces at the lines: 227, 
230, 237, 240, 252.   It will make the code style to be more consistent. 
   Could you, correct the comment at line 216 (invoker_invoke*() => 
invoker invoke*()):

216 * invoke request was carried out. See fillInvokeRequest() and 
invoker_invoke*()

test/com/sun/jdi/OomDebugTest.java   Some lines are too long: 142, 162, 
197, 212, 228, 264, 267, 289   It would be nice to make them shorter. I 
can push the fix once it has been reviewed. Thanks, Serguei On 3/21/16 
10:47, Severin Gehwolf wrote:
> Hi,
>
> Could somebody please review this fix for bug 4858370?
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-4858370
> webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-4858370/webrev.01/
>
> Testing done: jdk_jdi test group passes. Added regression test.
>
> There is a memory leak in the JDWP implementation where method
> parameters, method return values and the "this" object reference for
> constructor invocations are kept in memory via a global reference and
> get, thus, never GC'ed.
>
> The proposed fix deletes global references again in
> invoke_completeInvokeRequest(). The references got previously created
> in fillInvokeRequest() and invoker_invoke*() implementations.
>
> Thoughts?
>
> Note that I'd need somebody to sponsor the push to JDK 9 tree for me
> (once approved). Thanks.
>
> Cheers,
> Severin
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20160321/7677f233/attachment.html>

From serguei.spitsyn at oracle.com  Tue Mar 22 02:17:55 2016
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Mon, 21 Mar 2016 19:17:55 -0700
Subject: RFR : JDK-8151797 -
	java/lang/management/ThreadMXBean/ThreadLists.java : inconsistent
	results
In-Reply-To: <56EF7441.8010306@oracle.com>
References: <56EBE3E0.7040109@oracle.com>
	<0F53E9D3-2FC8-4C23-88EB-4F2C0BF0A039@oracle.com>
	<56EF7441.8010306@oracle.com>
Message-ID: <56F0AB53.3050504@oracle.com>

Hi Harsha,

Who are reviewers, only Staffan or there are more?

Thanks,
Serguei


On 3/20/16 21:10, Harsha Wardhana B wrote:
> Hello,
>
> Please review the new patch located at,
>
> http://cr.openjdk.java.net/~hb/8151797/webrev.01/
>
> -Harsha
>
> On Friday 18 March 2016 05:01 PM, Staffan Larsen wrote:
>> You should move the Arrays.stream trigger call to before 
>> the ManagementFactory.getThreadMXBean, otherwise the threads you get 
>> from ThreadMXBean will not match the threads you get from the 
>> ThreadGroups.
>>
>>> On 18 mars 2016, at 12:17, Harsha Wardhana B 
>>> <harsha.wardhana.b at oracle.com <mailto:harsha.wardhana.b at oracle.com>> 
>>> wrote:
>>>
>>> Hello All,
>>>
>>> Please review fix for,
>>>
>>> Issue : JDK-8151797 <http://jdk-8151797/> -  
>>> java/lang/management/ThreadMXBean/ThreadLists.java : inconsistent 
>>> results
>>> Webrev : http://cr.openjdk.java.net/~hb/8151797/webrev.00/
>>>
>>> Root-cause :  call-site cleaner thread not started before counting 
>>> threads via Thread.getAllStackTraces();.
>>> Fix : Create ThreadMXBean at the beginning of test so that call-site 
>>> cleaner thread will be started.
>>>
>>> Thanks
>>> Harsha
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20160321/9127cda4/attachment.html>

From kim.barrett at oracle.com  Tue Mar 22 03:32:34 2016
From: kim.barrett at oracle.com (Kim Barrett)
Date: Mon, 21 Mar 2016 23:32:34 -0400
Subject: RFR(xs): 8151993: Remove inclusion of inline.hpp in log.hpp
In-Reply-To: <56F02283.10908@oracle.com>
References: <56E952A5.6050708@oracle.com> <56F02283.10908@oracle.com>
Message-ID: <5632B653-58F1-44BF-9E3B-C75F971E485E@oracle.com>

> On Mar 21, 2016, at 12:34 PM, Robbin Ehn <robbin.ehn at oracle.com> wrote:
> 
> Hi all, please review this a somewhat bigger change-set.
> 
> Updated with the feedback.
> 
> New webrev: http://cr.openjdk.java.net/~rehn/8151993/v2/webrev/
> 
> Tested with jprt hotspot and I added 2 internal vm tests.
> 
> (also 2 bugs fixed, missing va_end and a potential race when calling prefix function twice (very unlikely))

I prefer this new approach to what was in the original RFR. A few
comments:

------------------------------------------------------------------------------ 
src/share/vm/logging/log.hpp 
  91 class LogWrite : AllStatic {

I think the name LogWrite is too generic and potentially useful in the
future for this facility.  I'd prefer something longer and more
descriptive, e.g. something like LogWriteLarge{Impl,Helper}.

------------------------------------------------------------------------------
src/share/vm/logging/log.hpp 
  89 // Non-template helper class for implementing write-slowpath in cpp
  90 template <LogTagType T0, LogTagType T1, LogTagType T2, LogTagType T3, LogTagType T4, LogTagType GuardTag> class Log;
  91 class LogWrite : AllStatic {
  92  private:
  93   template <LogTagType T0, LogTagType T1, LogTagType T2, LogTagType T3, LogTagType T4, LogTagType GuardTag> friend class Log;

The really long lines and lack of whitespace here makes this hard to
read and confusing.  It took several tries for me to spot the "class
Log" on line 90 and on line 93.  Only knowing that the LogWrite class
and the write_large function couldn't possibly have template specs
eventually helped me find them.

So I think it would help readability to break up the declarations into
shorter lines with the "[friend] class Log" parts on their own line,
with some whitespace around them. And attach the "Non-template helper
class" comment to the LogWrite class rather than the forward
declaration.

Aside: I keep wishing there were some macros for the various template
parameter sequences that are really just workarounds for the lack of
variadic templates. But that's a different problem.

------------------------------------------------------------------------------ 
src/share/vm/logging/log.hpp 
 95   static void write_large(LogTagSet& lts, 

Passing in the tagset is much better than my suggestion of some
function pointers. Good.

------------------------------------------------------------------------------ 
src/share/vm/logging/log.hpp 
 156     va_end(saved_args);

Good catch.

------------------------------------------------------------------------------ 
src/share/vm/logging/log.cpp

Thanks for new tests. However, I'm not sure it's safe to assume we can
create and remove files from the current directory when running these
tests. Maybe mkstemp with a file in os::get_temp_directory()? Or maybe
there's something like this already packaged up in hotspot? tmpfile
would be ideal if there were a way to configure logging to use a file
descriptor, but I don't see anything like that.

------------------------------------------------------------------------------
src/share/vm/logging/log.hpp
 148     int msg_len = os::log_vsnprintf(buf + prefix_len, sizeof(buf) - prefix_len, fmt, args);
 149     assert(msg_len >= 0, "Log message buffer issue");

I think I would prefer the pre-change

  int res = ...;
  assert(res >= 0, ...);

followed by

  size_t msg_len = res;

and eliminate the casts of msg_len.  But I dislike casts...

------------------------------------------------------------------------------


From harsha.wardhana.b at oracle.com  Tue Mar 22 05:09:28 2016
From: harsha.wardhana.b at oracle.com (Harsha Wardhana B)
Date: Tue, 22 Mar 2016 10:39:28 +0530
Subject: RFR : JDK-8151797 -
	java/lang/management/ThreadMXBean/ThreadLists.java : inconsistent
	results
In-Reply-To: <56F0AB53.3050504@oracle.com>
References: <56EBE3E0.7040109@oracle.com>
	<0F53E9D3-2FC8-4C23-88EB-4F2C0BF0A039@oracle.com>
	<56EF7441.8010306@oracle.com> <56F0AB53.3050504@oracle.com>
Message-ID: <56F0D388.8050807@oracle.com>

Hello Serguei,

So far Staffan is the only reviewer.

Thanks
Harsha

On Tuesday 22 March 2016 07:47 AM, serguei.spitsyn at oracle.com wrote:
> Hi Harsha,
>
> Who are reviewers, only Staffan or there are more?
>
> Thanks,
> Serguei
>
>
> On 3/20/16 21:10, Harsha Wardhana B wrote:
>> Hello,
>>
>> Please review the new patch located at,
>>
>> http://cr.openjdk.java.net/~hb/8151797/webrev.01/
>>
>> -Harsha
>>
>> On Friday 18 March 2016 05:01 PM, Staffan Larsen wrote:
>>> You should move the Arrays.stream trigger call to before 
>>> the ManagementFactory.getThreadMXBean, otherwise the threads you get 
>>> from ThreadMXBean will not match the threads you get from the 
>>> ThreadGroups.
>>>
>>>> On 18 mars 2016, at 12:17, Harsha Wardhana B 
>>>> <harsha.wardhana.b at oracle.com 
>>>> <mailto:harsha.wardhana.b at oracle.com>> wrote:
>>>>
>>>> Hello All,
>>>>
>>>> Please review fix for,
>>>>
>>>> Issue : JDK-8151797 <http://jdk-8151797/> - 
>>>> java/lang/management/ThreadMXBean/ThreadLists.java : inconsistent 
>>>> results
>>>> Webrev : http://cr.openjdk.java.net/~hb/8151797/webrev.00/
>>>>
>>>> Root-cause :  call-site cleaner thread not started before counting 
>>>> threads via Thread.getAllStackTraces();.
>>>> Fix : Create ThreadMXBean at the beginning of test so that 
>>>> call-site cleaner thread will be started.
>>>>
>>>> Thanks
>>>> Harsha
>>>>
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20160322/99f70542/attachment.html>

From serguei.spitsyn at oracle.com  Tue Mar 22 05:10:39 2016
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Mon, 21 Mar 2016 22:10:39 -0700
Subject: RFR : JDK-8151797 -
	java/lang/management/ThreadMXBean/ThreadLists.java : inconsistent
	results
In-Reply-To: <56F0D388.8050807@oracle.com>
References: <56EBE3E0.7040109@oracle.com>
	<0F53E9D3-2FC8-4C23-88EB-4F2C0BF0A039@oracle.com>
	<56EF7441.8010306@oracle.com> <56F0AB53.3050504@oracle.com>
	<56F0D388.8050807@oracle.com>
Message-ID: <56F0D3CF.7020106@oracle.com>

Ok, thanks!
Serguei


On 3/21/16 22:09, Harsha Wardhana B wrote:
> Hello Serguei,
>
> So far Staffan is the only reviewer.
>
> Thanks
> Harsha
>
> On Tuesday 22 March 2016 07:47 AM, serguei.spitsyn at oracle.com wrote:
>> Hi Harsha,
>>
>> Who are reviewers, only Staffan or there are more?
>>
>> Thanks,
>> Serguei
>>
>>
>> On 3/20/16 21:10, Harsha Wardhana B wrote:
>>> Hello,
>>>
>>> Please review the new patch located at,
>>>
>>> http://cr.openjdk.java.net/~hb/8151797/webrev.01/
>>>
>>> -Harsha
>>>
>>> On Friday 18 March 2016 05:01 PM, Staffan Larsen wrote:
>>>> You should move the Arrays.stream trigger call to before 
>>>> the ManagementFactory.getThreadMXBean, otherwise the threads you 
>>>> get from ThreadMXBean will not match the threads you get from the 
>>>> ThreadGroups.
>>>>
>>>>> On 18 mars 2016, at 12:17, Harsha Wardhana B 
>>>>> <harsha.wardhana.b at oracle.com 
>>>>> <mailto:harsha.wardhana.b at oracle.com>> wrote:
>>>>>
>>>>> Hello All,
>>>>>
>>>>> Please review fix for,
>>>>>
>>>>> Issue : JDK-8151797 <http://jdk-8151797/> - 
>>>>> java/lang/management/ThreadMXBean/ThreadLists.java : inconsistent 
>>>>> results
>>>>> Webrev : http://cr.openjdk.java.net/~hb/8151797/webrev.00/
>>>>>
>>>>> Root-cause :  call-site cleaner thread not started before counting 
>>>>> threads via Thread.getAllStackTraces();.
>>>>> Fix : Create ThreadMXBean at the beginning of test so that 
>>>>> call-site cleaner thread will be started.
>>>>>
>>>>> Thanks
>>>>> Harsha
>>>>>
>>>>
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20160321/0c1906be/attachment.html>

From sgehwolf at redhat.com  Tue Mar 22 09:54:17 2016
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Tue, 22 Mar 2016 10:54:17 +0100
Subject: RFR(s) 4858370: JDWP: Memory Leak: GlobalRefs never deleted
	when processing invokeMethod command
In-Reply-To: <56F069C7.8070209@oracle.com>
References: <1458582471.3539.24.camel@redhat.com> <56F069C7.8070209@oracle.com>
Message-ID: <1458640457.3934.3.camel@redhat.com>

Hi Serguei,

On Mon, 2016-03-21 at 14:38 -0700, serguei.spitsyn at oracle.com wrote:
> Hi Severin,
> 
> Thank you for taking care about this issue!
> 
> The fix looks pretty good.

Thanks for the quick review!

> A couple of minor comments though.
> 
> src/jdk.jdwp.agent/share/native/libjdwp/invoker.c
> ?222?????jint argIndex;
> ?223?????jbyte argumentTag;
> ?224?????jvalue *argument;
> ?225?????void *cursor;
> ?. . .
> ?234?????argIndex = 0;
> ?235?????argumentTag = firstArgumentTypeTag(request->methodSignature, &cursor);
> ?236?????argument = request->arguments;
> 
> ? Could you make a small simplification and re-arrange the initialization of the locals:
> ????void *cursor;
> ????jint argIndex = 0;
> ????jvalue *argument = request->arguments;
> ????jbyte argumentTag = firstArgumentTypeTag(request->methodSignature, &cursor);
> ?
> ? I'd also suggest to get rid of the extra spaces at the lines: 227, 230, 237, 240, 252. ? It will make the code style to be more consistent. ? Could you, correct the comment at line 216 (invoker_invoke*() => invoker invoke*()):
> ???216??* invoke request was carried out. See fillInvokeRequest() and invoker_invoke*()
> 
> 
> test/com/sun/jdi/OomDebugTest.java ? Some lines are too long: 142, 162, 197, 212, 228, 264, 267, 289 ? It would be nice to make them shorter. I can push the fix once it has been reviewed. Thanks, Serguei

Updated webrev with the changes above is here:
http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-4858370/webrev.02/

For convenience, I've uploaded the HG exported patch too:
http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-4858370/JDK-4858370-jdk9-jdk.export.patch

Cheers,
Severin

> On 3/21/16 10:47, Severin Gehwolf wrote:
> > Hi,
> > 
> > Could somebody please review this fix for bug 4858370?
> > 
> > Bug:?https://bugs.openjdk.java.net/browse/JDK-4858370
> > webrev:?http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-4858370/webrev.01/
> > 
> > Testing done: jdk_jdi test group passes. Added regression test.
> > 
> > There is a memory leak in the JDWP implementation where method
> > parameters, method return values and the "this" object reference for
> > constructor invocations are kept in memory via a global reference and
> > get, thus, never GC'ed.
> > 
> > The proposed fix deletes global references again in
> > invoke_completeInvokeRequest(). The references got previously created
> > in?fillInvokeRequest() and invoker_invoke*() implementations.
> > 
> > Thoughts?
> > 
> > Note that I'd need somebody to sponsor the push to JDK 9 tree for me
> > (once approved). Thanks.
> > 
> > Cheers,
> > Severin
> > 


From serguei.spitsyn at oracle.com  Tue Mar 22 10:05:27 2016
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Tue, 22 Mar 2016 03:05:27 -0700
Subject: RFR(s) 4858370: JDWP: Memory Leak: GlobalRefs never deleted when
	processing invokeMethod command
In-Reply-To: <1458640457.3934.3.camel@redhat.com>
References: <1458582471.3539.24.camel@redhat.com>
	<56F069C7.8070209@oracle.com> <1458640457.3934.3.camel@redhat.com>
Message-ID: <56F118E7.5030508@oracle.com>

Hi Severin,

It looks good to me.
Thank you for the changes!

I'll wait some time for any other review before the push.


Thanks,
Serguei



On 3/22/16 02:54, Severin Gehwolf wrote:
> Hi Serguei,
>
> On Mon, 2016-03-21 at 14:38 -0700, serguei.spitsyn at oracle.com wrote:
>> Hi Severin,
>>
>> Thank you for taking care about this issue!
>>
>> The fix looks pretty good.
> Thanks for the quick review!
>
>> A couple of minor comments though.
>>
>> src/jdk.jdwp.agent/share/native/libjdwp/invoker.c
>>   222     jint argIndex;
>>   223     jbyte argumentTag;
>>   224     jvalue *argument;
>>   225     void *cursor;
>>   . . .
>>   234     argIndex = 0;
>>   235     argumentTag = firstArgumentTypeTag(request->methodSignature, &cursor);
>>   236     argument = request->arguments;
>>
>>    Could you make a small simplification and re-arrange the initialization of the locals:
>>      void *cursor;
>>      jint argIndex = 0;
>>      jvalue *argument = request->arguments;
>>      jbyte argumentTag = firstArgumentTypeTag(request->methodSignature, &cursor);
>>   
>>    I'd also suggest to get rid of the extra spaces at the lines: 227, 230, 237, 240, 252.   It will make the code style to be more consistent.   Could you, correct the comment at line 216 (invoker_invoke*() => invoker invoke*()):
>>     216  * invoke request was carried out. See fillInvokeRequest() and invoker_invoke*()
>>
>>
>> test/com/sun/jdi/OomDebugTest.java   Some lines are too long: 142, 162, 197, 212, 228, 264, 267, 289   It would be nice to make them shorter. I can push the fix once it has been reviewed. Thanks, Serguei
> Updated webrev with the changes above is here:
> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-4858370/webrev.02/
>
> For convenience, I've uploaded the HG exported patch too:
> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-4858370/JDK-4858370-jdk9-jdk.export.patch
>
> Cheers,
> Severin
>
>> On 3/21/16 10:47, Severin Gehwolf wrote:
>>> Hi,
>>>
>>> Could somebody please review this fix for bug 4858370?
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-4858370
>>> webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-4858370/webrev.01/
>>>
>>> Testing done: jdk_jdi test group passes. Added regression test.
>>>
>>> There is a memory leak in the JDWP implementation where method
>>> parameters, method return values and the "this" object reference for
>>> constructor invocations are kept in memory via a global reference and
>>> get, thus, never GC'ed.
>>>
>>> The proposed fix deletes global references again in
>>> invoke_completeInvokeRequest(). The references got previously created
>>> in fillInvokeRequest() and invoker_invoke*() implementations.
>>>
>>> Thoughts?
>>>
>>> Note that I'd need somebody to sponsor the push to JDK 9 tree for me
>>> (once approved). Thanks.
>>>
>>> Cheers,
>>> Severin
>>>


From dmitry.samersoff at oracle.com  Tue Mar 22 11:51:54 2016
From: dmitry.samersoff at oracle.com (Dmitry Samersoff)
Date: Tue, 22 Mar 2016 14:51:54 +0300
Subject: RFR(S): JDK-8151444 JDP not working on some windows configurations
Message-ID: <56F131DA.7060205@oracle.com>

Everybody,

Please review the fix:

http://cr.openjdk.java.net/~dsamersoff/JDK-8151444/webrev.01/

Removed code attempts to set IP_MULTICAST_IF to enforce sending of JDP
packets to all available interfaces. It doesn't work on some multi-homed
windows configurations.

Also fixed minor bug in testcase.

-Dmitry



-- 
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the sources.

From yasuenag at gmail.com  Tue Mar 22 12:24:49 2016
From: yasuenag at gmail.com (Yasumasa Suenaga)
Date: Tue, 22 Mar 2016 21:24:49 +0900
Subject: PING: RFR: JDK-8151815: Could not parse core image with JSnap.
Message-ID: <CAGFVN2BkROkQnk5=xX4NaH+f19_YwoW1LzGMxu-1kksYE1BpRQ@mail.gmail.com>

PING: Could you review it?

Yasumasa
2016/03/14 23:39 "Yasumasa Suenaga" <yasuenag at gmail.com>:

> Hi all,
>
> When I use `jhsdb jsnap` to get PerfCounter from core images, I
> encountered NPE:
> -------------
> Exception in thread "main" java.lang.NullPointerException
>         at sun.jvm.hotspot.tools.JSnap.run(JSnap.java:45)
>         at sun.jvm.hotspot.tools.Tool.startInternal(Tool.java:260)
>         at sun.jvm.hotspot.tools.Tool.start(Tool.java:223)
>         at sun.jvm.hotspot.tools.Tool.execute(Tool.java:118)
>         at sun.jvm.hotspot.tools.JSnap.main(JSnap.java:67)
>         at sun.jvm.hotspot.SALauncher.runJSNAP(SALauncher.java:352)
>         at sun.jvm.hotspot.SALauncher.main(SALauncher.java:404)
> -------------
>
> PerfMemory::destroy() clears all members which are used in JSnap.
> Thus NPE is occurred.
>
> I uploaded webrev for this issue.
> Could you review it?
>
>   http://cr.openjdk.java.net/~ysuenaga/JDK-8151815/webrev.00/
>
> I cannot access JPRT.
> So I need a Sponsor.
>
>
> Thanks,
>
> Yasumasa
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20160322/9ccc1687/attachment.html>

From robbin.ehn at oracle.com  Tue Mar 22 12:25:34 2016
From: robbin.ehn at oracle.com (Robbin Ehn)
Date: Tue, 22 Mar 2016 13:25:34 +0100
Subject: RFR(xs): 8151993: Remove inclusion of inline.hpp in log.hpp
In-Reply-To: <5632B653-58F1-44BF-9E3B-C75F971E485E@oracle.com>
References: <56E952A5.6050708@oracle.com> <56F02283.10908@oracle.com>
	<5632B653-58F1-44BF-9E3B-C75F971E485E@oracle.com>
Message-ID: <56F139BE.6010605@oracle.com>

Hi Kim,

On 03/22/2016 04:32 AM, Kim Barrett wrote:
>> On Mar 21, 2016, at 12:34 PM, Robbin Ehn <robbin.ehn at oracle.com> wrote:
>>
>> Hi all, please review this a somewhat bigger change-set.
>>
>> Updated with the feedback.
>>
>> New webrev: http://cr.openjdk.java.net/~rehn/8151993/v2/webrev/
>>
>> Tested with jprt hotspot and I added 2 internal vm tests.
>>
>> (also 2 bugs fixed, missing va_end and a potential race when calling prefix function twice (very unlikely))
>
> I prefer this new approach to what was in the original RFR. A few
> comments:
>
> ------------------------------------------------------------------------------
> src/share/vm/logging/log.hpp
>    91 class LogWrite : AllStatic {
>
> I think the name LogWrite is too generic and potentially useful in the
> future for this facility.  I'd prefer something longer and more
> descriptive, e.g. something like LogWriteLarge{Impl,Helper}.

Fixed

>
> ------------------------------------------------------------------------------
> src/share/vm/logging/log.hpp
>    89 // Non-template helper class for implementing write-slowpath in cpp
>    90 template <LogTagType T0, LogTagType T1, LogTagType T2, LogTagType T3, LogTagType T4, LogTagType GuardTag> class Log;
>    91 class LogWrite : AllStatic {
>    92  private:
>    93   template <LogTagType T0, LogTagType T1, LogTagType T2, LogTagType T3, LogTagType T4, LogTagType GuardTag> friend class Log;
>
> The really long lines and lack of whitespace here makes this hard to
> read and confusing.  It took several tries for me to spot the "class
> Log" on line 90 and on line 93.  Only knowing that the LogWrite class
> and the write_large function couldn't possibly have template specs
> eventually helped me find them.
>
> So I think it would help readability to break up the declarations into
> shorter lines with the "[friend] class Log" parts on their own line,
> with some whitespace around them. And attach the "Non-template helper
> class" comment to the LogWrite class rather than the forward
> declaration.

Fixed

>
> Aside: I keep wishing there were some macros for the various template
> parameter sequences that are really just workarounds for the lack of
> variadic templates. But that's a different problem.
>
> ------------------------------------------------------------------------------
> src/share/vm/logging/log.hpp
>   95   static void write_large(LogTagSet& lts,
>
> Passing in the tagset is much better than my suggestion of some
> function pointers. Good.
>
> ------------------------------------------------------------------------------
> src/share/vm/logging/log.hpp
>   156     va_end(saved_args);
>
> Good catch.
>
> ------------------------------------------------------------------------------
> src/share/vm/logging/log.cpp
>
> Thanks for new tests. However, I'm not sure it's safe to assume we can
> create and remove files from the current directory when running these
> tests. Maybe mkstemp with a file in os::get_temp_directory()? Or maybe
> there's something like this already packaged up in hotspot? tmpfile
> would be ideal if there were a way to configure logging to use a file
> descriptor, but I don't see anything like that.

I used "os::get_temp_directory()" but generated 'naive' filename using 
pid and test name.
Using mkstemp and from fd lookup filename we need os dependent code, so 
I skipped this.
(we could use tempnam in this case, but it creates a warning since it's 
deprecated)

>
> ------------------------------------------------------------------------------
> src/share/vm/logging/log.hpp
>   148     int msg_len = os::log_vsnprintf(buf + prefix_len, sizeof(buf) - prefix_len, fmt, args);
>   149     assert(msg_len >= 0, "Log message buffer issue");
>
> I think I would prefer the pre-change
>
>    int res = ...;
>    assert(res >= 0, ...);
>
> followed by
>
>    size_t msg_len = res;
>
> and eliminate the casts of msg_len.  But I dislike casts...

Fixed

>
> ------------------------------------------------------------------------------
>

Here is the webrev: http://cr.openjdk.java.net/~rehn/8151993/v3/webrev/

Btw what's the normal workflow creating incrementals using hg mq ?

Thanks !

/Robbin

From yasuenag at gmail.com  Tue Mar 22 12:27:15 2016
From: yasuenag at gmail.com (Yasumasa Suenaga)
Date: Tue, 22 Mar 2016 21:27:15 +0900
Subject: PING: JDK-8148659: Add all option to JSnap
Message-ID: <CAGFVN2BX_kddSG4NvJVycEss1ZHbn9mwEGsRuGuax6-UBYRUQA@mail.gmail.com>

PING: Could you review it?

Yasumasa
2016/03/15 23:31 "Yasumasa Suenaga" <yasuenag at gmail.com>:

> Hi all,
>
> I updated webrev to adapt to current repos. Could you review it?
>
>     http://cr.openjdk.java.net/~ysuenaga/JDK-8148659/webrev.01/
>
>
> Thanks,
>
> Yasumasa
>
>
> On 2016/03/03 23:46, Yasumasa Suenaga wrote:
> > Hi Dmitry,
> >
> >> Overall direction is to support jhsdb as the only entry point for SA and
> >> all coredump related staff.
> >
> > I'm working on another issue (JDK-8151181) for it.
> >
> http://mail.openjdk.java.net/pipermail/serviceability-dev/2016-March/019007.html
> >
> > After that, I will work for this issue (JDK-8148659) and adding all
> option
> > to JSnap.
> >
> http://mail.openjdk.java.net/pipermail/serviceability-dev/2016-March/018962.html
> >
> >
> > Thanks,
> >
> > Yasumasa
> >
> >
> > On 2016/03/03 22:55, Dmitry Samersoff wrote:
> >> Yasumasa,
> >>
> >> Overall direction is to support jhsdb as the only entry point for SA and
> >> all coredump related staff.
> >>
> >> Could you move JSnap "into jhsdb".
> >>
> >> And this change requires CCC approval (I'll file it for you)
> >>
> >> -Dmitry
> >>
> >> On 2016-01-30 18:48, Yasumasa Suenaga wrote:
> >>> I want to add -a (all) option to JSnap because JSnap is very useful to
> analyze core image.
> >>>
> >>> Currently, JSnap can show PerfDataEntry which namespace is java.* or
> com.sun.* .
> >>> We can use jcmd with PerfCounter.print when we want to attach live
> process, however,
> >>> as JDK-6224040 shows, we have to use JSnap.
> >>>
> >>> In terms of core image analysis, -a option is very useful for
> troubleshooting.
> >>>
> >>> I uploaded a webrev for this enhancement.
> >>> Could you review it?
> >>>
> >>>     http://cr.openjdk.java.net/~ysuenaga/JDK-8148659/webrev.00/
> >>>
> >>> I'm jdk9 committer, however I cannot access JPRT.
> >>> So I need a sponsor.
> >>>
> >>>
> >>> Thanks,
> >>>
> >>> Yasumasa
> >>>
> >>
> >>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20160322/330372ee/attachment.html>

From staffan.larsen at oracle.com  Tue Mar 22 14:14:56 2016
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Tue, 22 Mar 2016 15:14:56 +0100
Subject: RFR: 7153107 com/sun/jdi/InterruptHangTest.java fails in nightlies
In-Reply-To: <597AD7AC-60FE-4A5E-8B82-81990CA61B25@oracle.com>
References: <597AD7AC-60FE-4A5E-8B82-81990CA61B25@oracle.com>
Message-ID: <FD30E9F5-3F6E-4FD2-9893-6832E2ACE1C1@oracle.com>

Anyone up for a review of this change?

> On 21 mars 2016, at 09:16, Staffan Larsen <staffan.larsen at oracle.com> wrote:
> 
> Hi,
> 
> For a while we have had various timeout related problem in the JDI tests. The root cause of this seems to be the Indy String Concatenation work which makes stepping over the first string concatenation horrendously slow in debug version of the jdk. It is not ISC itself that is to blame, instead it gets the blame for the full setup of the invokedynamic framework. See JDK-8151887 for a longer discussion about this.
> 
> One of the tests that fail because of this is com/sun/jdi/InterruptHangTest.java. In this fix, I have simply increased the timeout that is used internally in the test to take the jtreg timeoutfactor into consideration. This seems to allow enough time for stepping through the indy setup code. 
> 
> I have also added timestamped logging to the TestScaffold superclass to make it easier to see what is taking a long time and how far a test has proceeded. 
> 
> webrev: http://cr.openjdk.java.net/~sla/7153107/webrev.01/
> bug: https://bugs.openjdk.java.net/browse/JDK-7153107
> 
> Thanks,
> /Staffan
> 


From staffan.larsen at oracle.com  Tue Mar 22 14:18:05 2016
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Tue, 22 Mar 2016 15:18:05 +0100
Subject: RFR(S): JDK-8151444 JDP not working on some windows configurations
In-Reply-To: <56F131DA.7060205@oracle.com>
References: <56F131DA.7060205@oracle.com>
Message-ID: <916CFF12-B4CE-4EBC-97FB-B30AD1FB87BB@oracle.com>

Looks good!

Thanks,
/Staffan

> On 22 mars 2016, at 12:51, Dmitry Samersoff <dmitry.samersoff at oracle.com> wrote:
> 
> Everybody,
> 
> Please review the fix:
> 
> http://cr.openjdk.java.net/~dsamersoff/JDK-8151444/webrev.01/
> 
> Removed code attempts to set IP_MULTICAST_IF to enforce sending of JDP
> packets to all available interfaces. It doesn't work on some multi-homed
> windows configurations.
> 
> Also fixed minor bug in testcase.
> 
> -Dmitry
> 
> 
> 
> -- 
> Dmitry Samersoff
> Oracle Java development team, Saint Petersburg, Russia
> * I would love to change the world, but they won't give me the sources.


From robbin.ehn at oracle.com  Tue Mar 22 14:24:39 2016
From: robbin.ehn at oracle.com (Robbin Ehn)
Date: Tue, 22 Mar 2016 15:24:39 +0100
Subject: RFR: 8146879: Add option for handling existing log files in UL
In-Reply-To: <56EBFCCC.1080701@oracle.com>
References: <5697B7F2.50104@oracle.com> <56D578F9.6090602@oracle.com>
	<56D5A1BB.6030403@oracle.com> <56E2D478.3090202@oracle.com>
	<56EBFCCC.1080701@oracle.com>
Message-ID: <56F155A7.7060609@oracle.com>

Hi Marcus,

On 03/18/2016 02:04 PM, Marcus Larsson wrote:
> Updated patch after feedback.
>
> New webrev:
> http://cr.openjdk.java.net/~mlarsson/8146879/webrev.04/
>
> Incremental:
> http://cr.openjdk.java.net/~mlarsson/8146879/webrev.03-04/
>
> Tested with internal VM tests through RBT.
>
> Changes:
> * Rotation filecount is now limited to 1000 files.
> * Removed loop in os::compare_file_modified_times.
> * Added a check before rotating/truncating an existing log file, and
> will only do so if it's a regular file.
> * Added test case to check that logging to a directory gives the
> intended error message.
> * Fixed test help method to handle arbitrary length log lines.

I tested this and it works fine.

Code looks good to me.

Thanks for fixing this!

/Robbin

>
> Thanks,
> Marcus
>
> On 03/11/2016 03:21 PM, Marcus Larsson wrote:
>> Third time's the charm.
>>
>> Webrev:
>> http://cr.openjdk.java.net/~mlarsson/8146879/webrev.03/
>>
>> This patch makes log file rotation the default. Default thresholds are
>> 5 rotated files with a target size of 20MiB. Truncating behavior can
>> be achieved by setting filecount to 0 (-Xlog::myfile.log::filecount=0).
>>
>> If a log file already exists during log file initialization it will be
>> rotated. If any of the target file names (file.0 to file.4 in the
>> default case) are available, that filename will be used for the
>> existing log. If all names are taken the VM will attempt to overwrite
>> the oldest file.
>>
>> This should prevent unlimited log file creations and avoid accidental
>> loss of log files from previous runs. The default thresholds (5 files,
>> 20MiB each) is just a suggestion. If you think it should be
>> higher/lower let me know.
>>
>> Tested with included internal VM tests through RBT.
>>
>> Thanks,
>> Marcus
>>
>> On 2016-03-01 15:05, Marcus Larsson wrote:
>>> Hi,
>>>
>>> After some offline discussions I'm withdrawing this patch. I will
>>> instead investigate if I can achieve similar behavior using log
>>> rotation as the default.
>>>
>>> Thanks,
>>> Marcus
>>>
>>> On 03/01/2016 12:11 PM, Marcus Larsson wrote:
>>>> Hi again,
>>>>
>>>> Taking a different approach to this.
>>>>
>>>> New webrev:
>>>> http://cr.openjdk.java.net/~mlarsson/8146879/webrev.01/
>>>>
>>>> Existing files will now by default be renamed/archived with a .X
>>>> suffix where X is the lowest number such that the resulting file
>>>> name is available (jvm.log becomes jvm.log.0). A mode option for
>>>> controlling this behavior has been added as well. It can be set to
>>>> archive, append, or truncate (i.e. -Xlog::jvm.log::mode=truncate).
>>>>
>>>> Tested with included jtreg test through JPRT.
>>>>
>>>> Thanks,
>>>> Marcus
>>>>
>>>> On 01/14/2016 04:00 PM, Marcus Larsson wrote:
>>>>> Hi,
>>>>>
>>>>> Please review the following patch to make sure UL truncates
>>>>> existing log files before writing to them. Since files are opened
>>>>> in append mode, truncation isn't done automatically, so instead the
>>>>> patch adds an attempt to remove the log file before opening it.
>>>>>
>>>>> Webrev:
>>>>> http://cr.openjdk.java.net/~mlarsson/8146879/webrev.00/
>>>>>
>>>>> Issue:
>>>>> https://bugs.openjdk.java.net/browse/JDK-8146879
>>>>>
>>>>> Testing:
>>>>> Included test through JPRT
>>>>>
>>>>> Thanks,
>>>>> Marcus
>>>>
>>>
>>
>

From yasuenag at gmail.com  Tue Mar 22 14:49:16 2016
From: yasuenag at gmail.com (Yasumasa Suenaga)
Date: Tue, 22 Mar 2016 23:49:16 +0900
Subject: RFR: JDK-8152435: (CL)HSDB should be started with no argument
Message-ID: <56F15B6C.3080102@gmail.com>

HI all,

After JDK-8151709, CLHSDB and HSDB cannot be started with no argument via jhsdb. 
CLHSDB and HSDB can attach process / core after starting.
jhsdb should support it.

I uploaded webrev:

  http://cr.openjdk.java.net/~ysuenaga/JDK-8152435/webrev.00/

This patch passed jtreg test sun/tools/jhsdb in jdk repos.
Could you review it?

I cannot access JPRT.
So I need a sponsor.


Thanks,

Yasumasa


From marcus.larsson at oracle.com  Tue Mar 22 15:49:06 2016
From: marcus.larsson at oracle.com (Marcus Larsson)
Date: Tue, 22 Mar 2016 16:49:06 +0100
Subject: RFR: 8146879: Add option for handling existing log files in UL
In-Reply-To: <56F155A7.7060609@oracle.com>
References: <5697B7F2.50104@oracle.com> <56D578F9.6090602@oracle.com>
	<56D5A1BB.6030403@oracle.com> <56E2D478.3090202@oracle.com>
	<56EBFCCC.1080701@oracle.com> <56F155A7.7060609@oracle.com>
Message-ID: <56F16972.9010306@oracle.com>

Thanks for reviewing, Robbin!

Marcus

On 03/22/2016 03:24 PM, Robbin Ehn wrote:
> Hi Marcus,
>
> On 03/18/2016 02:04 PM, Marcus Larsson wrote:
>> Updated patch after feedback.
>>
>> New webrev:
>> http://cr.openjdk.java.net/~mlarsson/8146879/webrev.04/
>>
>> Incremental:
>> http://cr.openjdk.java.net/~mlarsson/8146879/webrev.03-04/
>>
>> Tested with internal VM tests through RBT.
>>
>> Changes:
>> * Rotation filecount is now limited to 1000 files.
>> * Removed loop in os::compare_file_modified_times.
>> * Added a check before rotating/truncating an existing log file, and
>> will only do so if it's a regular file.
>> * Added test case to check that logging to a directory gives the
>> intended error message.
>> * Fixed test help method to handle arbitrary length log lines.
>
> I tested this and it works fine.
>
> Code looks good to me.
>
> Thanks for fixing this!
>
> /Robbin
>
>>
>> Thanks,
>> Marcus
>>
>> On 03/11/2016 03:21 PM, Marcus Larsson wrote:
>>> Third time's the charm.
>>>
>>> Webrev:
>>> http://cr.openjdk.java.net/~mlarsson/8146879/webrev.03/
>>>
>>> This patch makes log file rotation the default. Default thresholds are
>>> 5 rotated files with a target size of 20MiB. Truncating behavior can
>>> be achieved by setting filecount to 0 (-Xlog::myfile.log::filecount=0).
>>>
>>> If a log file already exists during log file initialization it will be
>>> rotated. If any of the target file names (file.0 to file.4 in the
>>> default case) are available, that filename will be used for the
>>> existing log. If all names are taken the VM will attempt to overwrite
>>> the oldest file.
>>>
>>> This should prevent unlimited log file creations and avoid accidental
>>> loss of log files from previous runs. The default thresholds (5 files,
>>> 20MiB each) is just a suggestion. If you think it should be
>>> higher/lower let me know.
>>>
>>> Tested with included internal VM tests through RBT.
>>>
>>> Thanks,
>>> Marcus
>>>
>>> On 2016-03-01 15:05, Marcus Larsson wrote:
>>>> Hi,
>>>>
>>>> After some offline discussions I'm withdrawing this patch. I will
>>>> instead investigate if I can achieve similar behavior using log
>>>> rotation as the default.
>>>>
>>>> Thanks,
>>>> Marcus
>>>>
>>>> On 03/01/2016 12:11 PM, Marcus Larsson wrote:
>>>>> Hi again,
>>>>>
>>>>> Taking a different approach to this.
>>>>>
>>>>> New webrev:
>>>>> http://cr.openjdk.java.net/~mlarsson/8146879/webrev.01/
>>>>>
>>>>> Existing files will now by default be renamed/archived with a .X
>>>>> suffix where X is the lowest number such that the resulting file
>>>>> name is available (jvm.log becomes jvm.log.0). A mode option for
>>>>> controlling this behavior has been added as well. It can be set to
>>>>> archive, append, or truncate (i.e. -Xlog::jvm.log::mode=truncate).
>>>>>
>>>>> Tested with included jtreg test through JPRT.
>>>>>
>>>>> Thanks,
>>>>> Marcus
>>>>>
>>>>> On 01/14/2016 04:00 PM, Marcus Larsson wrote:
>>>>>> Hi,
>>>>>>
>>>>>> Please review the following patch to make sure UL truncates
>>>>>> existing log files before writing to them. Since files are opened
>>>>>> in append mode, truncation isn't done automatically, so instead the
>>>>>> patch adds an attempt to remove the log file before opening it.
>>>>>>
>>>>>> Webrev:
>>>>>> http://cr.openjdk.java.net/~mlarsson/8146879/webrev.00/
>>>>>>
>>>>>> Issue:
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8146879
>>>>>>
>>>>>> Testing:
>>>>>> Included test through JPRT
>>>>>>
>>>>>> Thanks,
>>>>>> Marcus
>>>>>
>>>>
>>>
>>


From serguei.spitsyn at oracle.com  Tue Mar 22 17:15:26 2016
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Tue, 22 Mar 2016 10:15:26 -0700
Subject: RFR: 7153107 com/sun/jdi/InterruptHangTest.java fails in nightlies
In-Reply-To: <FD30E9F5-3F6E-4FD2-9893-6832E2ACE1C1@oracle.com>
References: <597AD7AC-60FE-4A5E-8B82-81990CA61B25@oracle.com>
	<FD30E9F5-3F6E-4FD2-9893-6832E2ACE1C1@oracle.com>
Message-ID: <56F17DAE.9040803@oracle.com>

Hi Staffan,

It looks good.
One question though.

I do not see that the timeout is increased in the 
com/sun/jdi/InterruptHangTest.java.
It remains 20 sec as was before.

+ float timeoutFactor = 
Float.parseFloat(System.getProperty("test.timeout.factor", "1.0"));

+ long sleepSeconds = (long)(20 * timeoutFactor); ...

- Thread.sleep(20000);
+ Thread.sleep(sleepSeconds * 1000);

Or an increase is because of the "test.timeout.factor" property? Thanks, 
Serguei On 3/22/16 07:14, Staffan Larsen wrote:
> Anyone up for a review of this change?
>
>> On 21 mars 2016, at 09:16, Staffan Larsen <staffan.larsen at oracle.com> wrote:
>>
>> Hi,
>>
>> For a while we have had various timeout related problem in the JDI tests. The root cause of this seems to be the Indy String Concatenation work which makes stepping over the first string concatenation horrendously slow in debug version of the jdk. It is not ISC itself that is to blame, instead it gets the blame for the full setup of the invokedynamic framework. See JDK-8151887 for a longer discussion about this.
>>
>> One of the tests that fail because of this is com/sun/jdi/InterruptHangTest.java. In this fix, I have simply increased the timeout that is used internally in the test to take the jtreg timeoutfactor into consideration. This seems to allow enough time for stepping through the indy setup code.
>>
>> I have also added timestamped logging to the TestScaffold superclass to make it easier to see what is taking a long time and how far a test has proceeded.
>>
>> webrev: http://cr.openjdk.java.net/~sla/7153107/webrev.01/
>> bug: https://bugs.openjdk.java.net/browse/JDK-7153107
>>
>> Thanks,
>> /Staffan
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20160322/49b69ed3/attachment.html>

From dmitry.samersoff at oracle.com  Tue Mar 22 17:59:26 2016
From: dmitry.samersoff at oracle.com (Dmitry Samersoff)
Date: Tue, 22 Mar 2016 20:59:26 +0300
Subject: PING: JDK-8148659: Add all option to JSnap
In-Reply-To: <CAGFVN2BX_kddSG4NvJVycEss1ZHbn9mwEGsRuGuax6-UBYRUQA@mail.gmail.com>
References: <CAGFVN2BX_kddSG4NvJVycEss1ZHbn9mwEGsRuGuax6-UBYRUQA@mail.gmail.com>
Message-ID: <56F187FE.10807@oracle.com>

Yasumasa,

Looks good for me.

-Dmitry


On 2016-03-22 15:27, Yasumasa Suenaga wrote:
> PING: Could you review it?
> 
> Yasumasa
> 
> 2016/03/15 23:31 "Yasumasa Suenaga" <yasuenag at gmail.com
> <mailto:yasuenag at gmail.com>>:
> 
>     Hi all,
> 
>     I updated webrev to adapt to current repos. Could you review it?
> 
>         http://cr.openjdk.java.net/~ysuenaga/JDK-8148659/webrev.01/
> 
> 
>     Thanks,
> 
>     Yasumasa
> 
> 
>     On 2016/03/03 23:46, Yasumasa Suenaga wrote:
>     > Hi Dmitry,
>     >
>     >> Overall direction is to support jhsdb as the only entry point for
>     SA and
>     >> all coredump related staff.
>     >
>     > I'm working on another issue (JDK-8151181) for it.
>     >   
>     http://mail.openjdk.java.net/pipermail/serviceability-dev/2016-March/019007.html
>     >
>     > After that, I will work for this issue (JDK-8148659) and adding
>     all option
>     > to JSnap.
>     >   
>     http://mail.openjdk.java.net/pipermail/serviceability-dev/2016-March/018962.html
>     >
>     >
>     > Thanks,
>     >
>     > Yasumasa
>     >
>     >
>     > On 2016/03/03 22:55, Dmitry Samersoff wrote:
>     >> Yasumasa,
>     >>
>     >> Overall direction is to support jhsdb as the only entry point for
>     SA and
>     >> all coredump related staff.
>     >>
>     >> Could you move JSnap "into jhsdb".
>     >>
>     >> And this change requires CCC approval (I'll file it for you)
>     >>
>     >> -Dmitry
>     >>
>     >> On 2016-01-30 18:48, Yasumasa Suenaga wrote:
>     >>> I want to add -a (all) option to JSnap because JSnap is very
>     useful to analyze core image.
>     >>>
>     >>> Currently, JSnap can show PerfDataEntry which namespace is
>     java.* or com.sun.* .
>     >>> We can use jcmd with PerfCounter.print when we want to attach
>     live process, however,
>     >>> as JDK-6224040 shows, we have to use JSnap.
>     >>>
>     >>> In terms of core image analysis, -a option is very useful for
>     troubleshooting.
>     >>>
>     >>> I uploaded a webrev for this enhancement.
>     >>> Could you review it?
>     >>>
>     >>>     http://cr.openjdk.java.net/~ysuenaga/JDK-8148659/webrev.00/
>     >>>
>     >>> I'm jdk9 committer, however I cannot access JPRT.
>     >>> So I need a sponsor.
>     >>>
>     >>>
>     >>> Thanks,
>     >>>
>     >>> Yasumasa
>     >>>
>     >>
>     >>
> 


-- 
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the sources.

From staffan.larsen at oracle.com  Tue Mar 22 18:09:12 2016
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Tue, 22 Mar 2016 19:09:12 +0100
Subject: RFR: 7153107 com/sun/jdi/InterruptHangTest.java fails in nightlies
In-Reply-To: <56F17DAE.9040803@oracle.com>
References: <597AD7AC-60FE-4A5E-8B82-81990CA61B25@oracle.com>
	<FD30E9F5-3F6E-4FD2-9893-6832E2ACE1C1@oracle.com>
	<56F17DAE.9040803@oracle.com>
Message-ID: <E5F4DB1A-FF25-4FC6-8B40-1DAFE87FBF64@oracle.com>


> On 22 mars 2016, at 18:15, serguei.spitsyn at oracle.com wrote:
> 
> Hi Staffan,
> 
> It looks good.
> One question though.
> 
> I do not see that the timeout is increased in the com/sun/jdi/InterruptHangTest.java.
> It remains 20 sec as was before.
> 
> +                    float timeoutFactor = Float.parseFloat(System.getProperty("test.timeout.factor", "1.0"));
> +                    long sleepSeconds = (long)(20 * timeoutFactor);
> 
> ...
> -                            Thread.sleep(20000);
> +                            Thread.sleep(sleepSeconds * 1000);
> Or an increase is because of the "test.timeout.factor" property?

Yes, the increase will be because outside systems will set the timeout factor.

/Staffan


> Thanks, Serguei On 3/22/16 07:14, Staffan Larsen wrote:
>> Anyone up for a review of this change?
>> 
>>> On 21 mars 2016, at 09:16, Staffan Larsen <staffan.larsen at oracle.com> <mailto:staffan.larsen at oracle.com> wrote:
>>> 
>>> Hi,
>>> 
>>> For a while we have had various timeout related problem in the JDI tests. The root cause of this seems to be the Indy String Concatenation work which makes stepping over the first string concatenation horrendously slow in debug version of the jdk. It is not ISC itself that is to blame, instead it gets the blame for the full setup of the invokedynamic framework. See JDK-8151887 for a longer discussion about this.
>>> 
>>> One of the tests that fail because of this is com/sun/jdi/InterruptHangTest.java. In this fix, I have simply increased the timeout that is used internally in the test to take the jtreg timeoutfactor into consideration. This seems to allow enough time for stepping through the indy setup code. 
>>> 
>>> I have also added timestamped logging to the TestScaffold superclass to make it easier to see what is taking a long time and how far a test has proceeded. 
>>> 
>>> webrev: http://cr.openjdk.java.net/~sla/7153107/webrev.01/ <http://cr.openjdk.java.net/~sla/7153107/webrev.01/>
>>> bug: https://bugs.openjdk.java.net/browse/JDK-7153107 <https://bugs.openjdk.java.net/browse/JDK-7153107>
>>> 
>>> Thanks,
>>> /Staffan
>>> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20160322/feba4ebe/attachment-0001.html>

From serguei.spitsyn at oracle.com  Tue Mar 22 18:10:44 2016
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Tue, 22 Mar 2016 11:10:44 -0700
Subject: RFR: 7153107 com/sun/jdi/InterruptHangTest.java fails in nightlies
In-Reply-To: <E5F4DB1A-FF25-4FC6-8B40-1DAFE87FBF64@oracle.com>
References: <597AD7AC-60FE-4A5E-8B82-81990CA61B25@oracle.com>
	<FD30E9F5-3F6E-4FD2-9893-6832E2ACE1C1@oracle.com>
	<56F17DAE.9040803@oracle.com>
	<E5F4DB1A-FF25-4FC6-8B40-1DAFE87FBF64@oracle.com>
Message-ID: <56F18AA4.5070703@oracle.com>

On 3/22/16 11:09, Staffan Larsen wrote:
>
>> On 22 mars 2016, at 18:15, serguei.spitsyn at oracle.com 
>> <mailto:serguei.spitsyn at oracle.com> wrote:
>>
>> Hi Staffan,
>>
>> It looks good.
>> One question though.
>>
>> I do not see that the timeout is increased in the 
>> com/sun/jdi/InterruptHangTest.java.
>> It remains 20 sec as was before.
>>
>> + float timeoutFactor = 
>> Float.parseFloat(System.getProperty("test.timeout.factor", "1.0"));+ 
>> long sleepSeconds = (long)(20 * timeoutFactor); ...
>> - Thread.sleep(20000);
>> + Thread.sleep(sleepSeconds * 1000);
>> Or an increase is because of the "test.timeout.factor" property?
> Yes, the increase will be because outside systems will set the timeout 
> factor.
Ok, thanks. Reviewed. Thanks, Serguei
> /Staffan
>> Thanks, Serguei On 3/22/16 07:14, Staffan Larsen wrote:
>>> Anyone up for a review of this change?
>>>
>>>> On 21 mars 2016, at 09:16, Staffan Larsen<staffan.larsen at oracle.com>  wrote:
>>>>
>>>> Hi,
>>>>
>>>> For a while we have had various timeout related problem in the JDI tests. The root cause of this seems to be the Indy String Concatenation work which makes stepping over the first string concatenation horrendously slow in debug version of the jdk. It is not ISC itself that is to blame, instead it gets the blame for the full setup of the invokedynamic framework. See JDK-8151887 for a longer discussion about this.
>>>>
>>>> One of the tests that fail because of this is com/sun/jdi/InterruptHangTest.java. In this fix, I have simply increased the timeout that is used internally in the test to take the jtreg timeoutfactor into consideration. This seems to allow enough time for stepping through the indy setup code.
>>>>
>>>> I have also added timestamped logging to the TestScaffold superclass to make it easier to see what is taking a long time and how far a test has proceeded.
>>>>
>>>> webrev:http://cr.openjdk.java.net/~sla/7153107/webrev.01/
>>>> bug:https://bugs.openjdk.java.net/browse/JDK-7153107
>>>>
>>>> Thanks,
>>>> /Staffan
>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20160322/7868a878/attachment.html>

From gerard.ziemski at oracle.com  Tue Mar 22 18:15:20 2016
From: gerard.ziemski at oracle.com (Gerard Ziemski)
Date: Tue, 22 Mar 2016 13:15:20 -0500
Subject: RFR: 8146879: Add option for handling existing log files in UL
In-Reply-To: <56EBFCCC.1080701@oracle.com>
References: <5697B7F2.50104@oracle.com> <56D578F9.6090602@oracle.com>
	<56D5A1BB.6030403@oracle.com> <56E2D478.3090202@oracle.com>
	<56EBFCCC.1080701@oracle.com>
Message-ID: <EBB590DE-C820-4D4C-9D0E-D1096B09BF54@oracle.com>

hi Marcus,

Thank you for incorporating the feedback.

The only remaining comment I have is about the ?number_of_lines_with_substring_in_file()? function. As written, it resets the entire algorithm to the beginning of the file when it can not fit the current line, when I think the intention should be only to rewind only to the beginning of that line.

May I suggest the following implementation instead:

static size_t number_of_lines_with_substring_in_file(const char* filename,
                                                         const char* substr) {
 ResourceMark rm;
 size_t ret = 0;
 FILE* fp = fopen(filename, "r");
 assert(fp, "error opening file %s: %s", filename, strerror(errno));

 int buflen = 512;
 char* buf = NEW_RESOURCE_ARRAY(char, buflen);
 long int pos = 0;

 while (fgets(buf, buflen, fp) != NULL) {
   if (buf[strlen(buf) - 1] != '\n') {
     // rewind to the beginning of the line
     fseek(fp, pos, SEEK_SET);
     // double the buffer size and try again
     buf = REALLOC_RESOURCE_ARRAY(char, buf, buflen, 2*buflen);
     buflen *= 2;
   } else {
     // get current file position
     pos = ftell(fp);

     if (strstr(buf, substr) != NULL) {
       ret++;
     }
   }
 }

 fclose(fp);
 return ret;
}


cheers


> On Mar 18, 2016, at 8:04 AM, Marcus Larsson <marcus.larsson at oracle.com> wrote:
> 
> Updated patch after feedback.
> 
> New webrev:
> http://cr.openjdk.java.net/~mlarsson/8146879/webrev.04/
> 
> Incremental:
> http://cr.openjdk.java.net/~mlarsson/8146879/webrev.03-04/
> 
> Tested with internal VM tests through RBT.
> 
> Changes:
> * Rotation filecount is now limited to 1000 files.
> * Removed loop in os::compare_file_modified_times.
> * Added a check before rotating/truncating an existing log file, and will only do so if it's a regular file.
> * Added test case to check that logging to a directory gives the intended error message.
> * Fixed test help method to handle arbitrary length log lines.
> 
> Thanks,
> Marcus
> 
> On 03/11/2016 03:21 PM, Marcus Larsson wrote:
>> Third time's the charm.
>> 
>> Webrev:
>> http://cr.openjdk.java.net/~mlarsson/8146879/webrev.03/
>> 
>> This patch makes log file rotation the default. Default thresholds are 5 rotated files with a target size of 20MiB. Truncating behavior can be achieved by setting filecount to 0 (-Xlog::myfile.log::filecount=0).
>> 
>> If a log file already exists during log file initialization it will be rotated. If any of the target file names (file.0 to file.4 in the default case) are available, that filename will be used for the existing log. If all names are taken the VM will attempt to overwrite the oldest file.
>> 
>> This should prevent unlimited log file creations and avoid accidental loss of log files from previous runs. The default thresholds (5 files, 20MiB each) is just a suggestion. If you think it should be higher/lower let me know.
>> 
>> Tested with included internal VM tests through RBT.
>> 
>> Thanks,
>> Marcus
>> 
>> On 2016-03-01 15:05, Marcus Larsson wrote:
>>> Hi,
>>> 
>>> After some offline discussions I'm withdrawing this patch. I will instead investigate if I can achieve similar behavior using log rotation as the default.
>>> 
>>> Thanks,
>>> Marcus
>>> 
>>> On 03/01/2016 12:11 PM, Marcus Larsson wrote:
>>>> Hi again,
>>>> 
>>>> Taking a different approach to this.
>>>> 
>>>> New webrev:
>>>> http://cr.openjdk.java.net/~mlarsson/8146879/webrev.01/
>>>> 
>>>> Existing files will now by default be renamed/archived with a .X suffix where X is the lowest number such that the resulting file name is available (jvm.log becomes jvm.log.0). A mode option for controlling this behavior has been added as well. It can be set to archive, append, or truncate (i.e. -Xlog::jvm.log::mode=truncate).
>>>> 
>>>> Tested with included jtreg test through JPRT.
>>>> 
>>>> Thanks,
>>>> Marcus
>>>> 
>>>> On 01/14/2016 04:00 PM, Marcus Larsson wrote:
>>>>> Hi,
>>>>> 
>>>>> Please review the following patch to make sure UL truncates existing log files before writing to them. Since files are opened in append mode, truncation isn't done automatically, so instead the patch adds an attempt to remove the log file before opening it.
>>>>> 
>>>>> Webrev:
>>>>> http://cr.openjdk.java.net/~mlarsson/8146879/webrev.00/
>>>>> 
>>>>> Issue:
>>>>> https://bugs.openjdk.java.net/browse/JDK-8146879
>>>>> 
>>>>> Testing:
>>>>> Included test through JPRT
>>>>> 
>>>>> Thanks,
>>>>> Marcus
>>>> 
>>> 
>> 
> 


From staffan.larsen at oracle.com  Tue Mar 22 18:22:41 2016
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Tue, 22 Mar 2016 19:22:41 +0100
Subject: RFR: 7153107 com/sun/jdi/InterruptHangTest.java fails in nightlies
In-Reply-To: <56F18AA4.5070703@oracle.com>
References: <597AD7AC-60FE-4A5E-8B82-81990CA61B25@oracle.com>
	<FD30E9F5-3F6E-4FD2-9893-6832E2ACE1C1@oracle.com>
	<56F17DAE.9040803@oracle.com>
	<E5F4DB1A-FF25-4FC6-8B40-1DAFE87FBF64@oracle.com>
	<56F18AA4.5070703@oracle.com>
Message-ID: <08A03ACD-1FD7-4A68-B4C5-7C9D399BFC23@oracle.com>

Thanks Serguei!

> On 22 mars 2016, at 19:10, serguei.spitsyn at oracle.com wrote:
> 
> On 3/22/16 11:09, Staffan Larsen wrote:
>> 
>>> On 22 mars 2016, at 18:15,  <mailto:serguei.spitsyn at oracle.com>serguei.spitsyn at oracle.com <mailto:serguei.spitsyn at oracle.com> wrote:
>>> 
>>> Hi Staffan,
>>> 
>>> It looks good.
>>> One question though.
>>> 
>>> I do not see that the timeout is increased in the com/sun/jdi/InterruptHangTest.java.
>>> It remains 20 sec as was before.
>>> 
>>> +                    float timeoutFactor = Float.parseFloat(System.getProperty("test.timeout.factor", "1.0"));+                    long sleepSeconds = (long)(20 * timeoutFactor);
>>> 
>>> ...
>>> -                            Thread.sleep(20000);
>>> +                            Thread.sleep(sleepSeconds * 1000);
>>> Or an increase is because of the "test.timeout.factor" property?
>> Yes, the increase will be because outside systems will set the timeout factor.
> Ok, thanks. Reviewed. Thanks, Serguei
>> 
>> /Staffan
>>> Thanks, Serguei On 3/22/16 07:14, Staffan Larsen wrote:
>>>> Anyone up for a review of this change?
>>>> 
>>>>> On 21 mars 2016, at 09:16, Staffan Larsen <staffan.larsen at oracle.com> <mailto:staffan.larsen at oracle.com> wrote:
>>>>> 
>>>>> Hi,
>>>>> 
>>>>> For a while we have had various timeout related problem in the JDI tests. The root cause of this seems to be the Indy String Concatenation work which makes stepping over the first string concatenation horrendously slow in debug version of the jdk. It is not ISC itself that is to blame, instead it gets the blame for the full setup of the invokedynamic framework. See JDK-8151887 for a longer discussion about this.
>>>>> 
>>>>> One of the tests that fail because of this is com/sun/jdi/InterruptHangTest.java. In this fix, I have simply increased the timeout that is used internally in the test to take the jtreg timeoutfactor into consideration. This seems to allow enough time for stepping through the indy setup code. 
>>>>> 
>>>>> I have also added timestamped logging to the TestScaffold superclass to make it easier to see what is taking a long time and how far a test has proceeded. 
>>>>> 
>>>>> webrev: http://cr.openjdk.java.net/~sla/7153107/webrev.01/ <http://cr.openjdk.java.net/%7Esla/7153107/webrev.01/>
>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-7153107 <https://bugs.openjdk.java.net/browse/JDK-7153107>
>>>>> 
>>>>> Thanks,
>>>>> /Staffan
>>>>> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20160322/cde58c14/attachment.html>

From yasuenag at gmail.com  Tue Mar 22 23:18:53 2016
From: yasuenag at gmail.com (Yasumasa Suenaga)
Date: Wed, 23 Mar 2016 08:18:53 +0900
Subject: RFR(S): JDK-8151444 JDP not working on some windows configurations
In-Reply-To: <56F131DA.7060205@oracle.com>
References: <56F131DA.7060205@oracle.com>
Message-ID: <56F1D2DD.9080206@gmail.com>

Hi Dmitry,

Does your change work on Linux multi-homed environment?
The code which you remove is added at JDK-8057556.

  http://mail.openjdk.java.net/pipermail/serviceability-dev/2014-September/015504.html

DiagramChannel which is used in JDPBroadcaster tries to send JDP packet
through all "UP" NICs.
However, NIC which is controlled by NetworkManager seems to be still "UP"
when ifdown command is executed.
(It seems to be removed IP address from NIC only.)

I cannot check your change because I destroyed environment for reproduce.
Did you check your change on Linux multi-homed (and NetworkManager is active)
environment?


Thanks,

Yasumasa


On 2016/03/22 20:51, Dmitry Samersoff wrote:
> Everybody,
> 
> Please review the fix:
> 
> http://cr.openjdk.java.net/~dsamersoff/JDK-8151444/webrev.01/
> 
> Removed code attempts to set IP_MULTICAST_IF to enforce sending of JDP
> packets to all available interfaces. It doesn't work on some multi-homed
> windows configurations.
> 
> Also fixed minor bug in testcase.
> 
> -Dmitry
> 
> 
> 

From marcus.larsson at oracle.com  Wed Mar 23 09:23:42 2016
From: marcus.larsson at oracle.com (Marcus Larsson)
Date: Wed, 23 Mar 2016 10:23:42 +0100
Subject: RFR: 8151438: UL instantiates duplicate tag sets
Message-ID: <56F2609E.7090201@oracle.com>

Hi,

Please review the following patch to fix the issue where duplicate 
tagsets are created for the same logical tagset.

The code that emulates the variadic template arguments assumes that 
_NO_TAG terminates the sequence of tags. If other tags (other than 
_NO_TAG) follow a terminating tag, template instances that are otherwise 
considered equal (since they share tags up until the terminating tag), 
might not be considered equal in the template sense (one of the template 
arguments can differ). This would cause another template instantiation 
for the same logical tagset and we end up with logical duplicates.

The if-statement to append the 'start' tag in 
GCTraceTimeImpl::log_start() caused such problematic template 
instantiations, so any tagset used with GCTraceTime would be duplicated. 
To fix this, the template instantiation has been forced to only be made 
once, ensuring no real tag follows the first _NO_TAG by using the 
ternary operator.

This patch also includes a test checking for invalid tagsets like these, 
and also checks for tagsets that are just permutations of other tagsets. 
Such tagsets should be avoided to prevent confusion, and to reduce 
overhead. (The test exposed one case where a different permutation was 
used, so I've fixed that as well.)

Webrev:
http://cr.openjdk.java.net/~mlarsson/8151438

Issue:
https://bugs.openjdk.java.net/browse/JDK-8151438

Testing:
New internal VM test through RBT.

Thanks,
Marcus

From stefan.karlsson at oracle.com  Wed Mar 23 10:00:32 2016
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Wed, 23 Mar 2016 11:00:32 +0100
Subject: RFR: 8151438: UL instantiates duplicate tag sets
In-Reply-To: <56F2609E.7090201@oracle.com>
References: <56F2609E.7090201@oracle.com>
Message-ID: <56F26940.5040005@oracle.com>

Hi Marcus,

On 2016-03-23 10:23, Marcus Larsson wrote:
> Hi,
>
> Please review the following patch to fix the issue where duplicate 
> tagsets are created for the same logical tagset.
>
> The code that emulates the variadic template arguments assumes that 
> _NO_TAG terminates the sequence of tags. If other tags (other than 
> _NO_TAG) follow a terminating tag, template instances that are 
> otherwise considered equal (since they share tags up until the 
> terminating tag), might not be considered equal in the template sense 
> (one of the template arguments can differ). This would cause another 
> template instantiation for the same logical tagset and we end up with 
> logical duplicates.
>
> The if-statement to append the 'start' tag in 
> GCTraceTimeImpl::log_start() caused such problematic template 
> instantiations, so any tagset used with GCTraceTime would be 
> duplicated. To fix this, the template instantiation has been forced to 
> only be made once, ensuring no real tag follows the first _NO_TAG by 
> using the ternary operator.
>
> This patch also includes a test checking for invalid tagsets like 
> these, and also checks for tagsets that are just permutations of other 
> tagsets. Such tagsets should be avoided to prevent confusion, and to 
> reduce overhead. (The test exposed one case where a different 
> permutation was used, so I've fixed that as well.)
>
> Webrev:
> http://cr.openjdk.java.net/~mlarsson/8151438

The change looks good. I have a couple of comments about the test:

http://cr.openjdk.java.net/~mlarsson/8151438/webrev.00/src/share/vm/logging/log.cpp.frames.html

191 char other_name[512];
192 other->label(other_name, sizeof(other_name), ",");
193 // Since tagsets are implemented using template arguments, using both of
194 // the (logically equivalent) tagsets (t1, t2) and (t2, t1) 
somewhere will
195 // instantiate two different LogTagSetMappings. This causes multiple
196 // tagset instances to be created for the same logical set. We want to
197 // avoid this to save time, memory and prevent any confusion around it.
198 assert(!equal, "duplicate LogTagSets found: '%s' vs '%s' "
199 "(tags must always be specified in the same order for each tagset)",
200 ts_name, other_name);


It might be good to check if (!equals) before setting up the other_name. 
Maybe:

if (!equals) {
   char other_name[512];
   other->label(other_name, sizeof(other_name), ",");
   assert(!equals /* or just false */, ...);
}


http://cr.openjdk.java.net/~mlarsson/8151438/webrev.00/src/share/vm/utilities/internalVMTests.cpp.frames.html

The test for the logging framework doesn't have a good prefix:

   70   run_unit_test(Test_log_length);
   71   run_unit_test(Test_configure_stdout);
   72   run_unit_test(Test_logconfiguration_subscribe);
    73 run_unit_test(Test_tagset_duplicates);

I think we should clean this up (in another RFE) by naming these 
functions similar to the other test functions:

   70   run_unit_test(TestLogLength_test);
   71   run_unit_test(TestLogConfigureStdout_test);
   72   run_unit_test(TestLogConfigurationSubscribe_test);
    73 run_unit_test(TestLogTagSetDuplicates_test);

I understand that there are some inconsistent names in the test list, 
but I think we should start by fixing the names for the logging tests.

Thanks,
StefanK

>
> Issue:
> https://bugs.openjdk.java.net/browse/JDK-8151438
>
> Testing:
> New internal VM test through RBT.
>
> Thanks,
> Marcus


From stefan.karlsson at oracle.com  Wed Mar 23 10:28:59 2016
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Wed, 23 Mar 2016 11:28:59 +0100
Subject: RFR: 8152538: UL doesn't inline the LogTagSet::is_level check
Message-ID: <56F26FEB.3000700@oracle.com>

Hi all,

Please, review this patch to optimize the log_is_enabled check in the 
Unified Logging framework.

http://cr.openjdk.java.net/~stefank/8152538/webrev.01/
https://bugs.openjdk.java.net/browse/JDK-8152538

The following code:
   void logLine() {
     log_debug(gc)("logLine");
   }

expands into:
(!log_is_enabled(Debug, __VA_ARGS__)) ? ... : ... )

The log_is_enabled macro further expands and inlines functions, but then 
end up calling LogTagSet::is_level.

Currently, the generated code looks like this:
(gdb) disass logLine
Dump of assembler code for function logLine():
    0x0000000000ae3bc0 <+0>: push %rbp
    0x0000000000ae3bc1 <+1>: lea 0x755fb8(%rip),%rdi # 0x1239b80 
<_ZN16LogTagSetMappingILN6LogTag4typeE22ELS1_0ELS1_0ELS1_0ELS1_0EE7_tagsetE>
    0x0000000000ae3bc8 <+8>: mov $0x2,%esi
    0x0000000000ae3bcd <+13>: mov %rsp,%rbp
    0x0000000000ae3bd0 <+16>: callq 0x969c30 
<LogTagSet::is_level(LogLevel::type) const>
    0x0000000000ae3bd5 <+21>: test %al,%al
    0x0000000000ae3bd7 <+23>: jne 0xae3be0 <logLine()+32>
    0x0000000000ae3bd9 <+25>: pop %rbp
    0x0000000000ae3bda <+26>: retq
    0x0000000000ae3bdb <+27>: nopl 0x0(%rax,%rax,1)
    0x0000000000ae3be0 <+32>: pop %rbp
    0x0000000000ae3be1 <+33>: lea 0x265133(%rip),%rdi # 0xd48d1b
    0x0000000000ae3be8 <+40>: xor %eax,%eax
    0x0000000000ae3bea <+42>:
     jmpq 0x5d9e00 <LogImpl<(LogTag::type)22, (LogTag::type)0, 
(LogTag::type)0, (LogTag::type)0, (LogTag::type)0, 
(LogTag::type)0>::write<(LogLevel::type)2>(char const*, ...)>

By making LogTagSet::is_level inlinable, we get:
(gdb) disass logLine
Dump of assembler code for function logLine():
    0x0000000000ae1690 <+0>: cmpq $0x0,0x756520(%rip) # 0x1237bb8 
<_ZN16LogTagSetMappingILN6LogTag4typeE22ELS1_0ELS1_0ELS1_0ELS1_0EE7_tagsetE+56>
    0x0000000000ae1698 <+8>: push %rbp
    0x0000000000ae1699 <+9>: mov %rsp,%rbp
    0x0000000000ae169c <+12>: je 0xae16b0 <logLine()+32>
    0x0000000000ae169e <+14>: pop %rbp
    0x0000000000ae169f <+15>: lea 0x264d75(%rip),%rdi # 0xd4641b
    0x0000000000ae16a6 <+22>: xor %eax,%eax
    0x0000000000ae16a8 <+24>:
     jmpq 0x5d8f60 <LogImpl<(LogTag::type)22, (LogTag::type)0, 
(LogTag::type)0, (LogTag::type)0, (LogTag::type)0, 
(LogTag::type)0>::write<(LogLevel::type)2>(char const*, ...)>
    0x0000000000ae16ad <+29>: nopl (%rax)
    0x0000000000ae16b0 <+32>: pop %rbp
    0x0000000000ae16b1 <+33>: retq
End of assembler dump.

Thanks,
StefanK

From marcus.larsson at oracle.com  Wed Mar 23 10:41:22 2016
From: marcus.larsson at oracle.com (Marcus Larsson)
Date: Wed, 23 Mar 2016 11:41:22 +0100
Subject: PING: Re: RFR: 8150823: UL handles disabling logs incorrectly
In-Reply-To: <56EBE5A0.5070806@oracle.com>
References: <56E2D8ED.3040204@oracle.com> <56EBE5A0.5070806@oracle.com>
Message-ID: <56F272D2.9070707@oracle.com>

On 03/18/2016 12:25 PM, Marcus Larsson wrote:
> Hi,
>
> Updated the patch after offline discussion. New patch attempts to 
> normalize the output name before searching for it or adding it. This 
> includes adding the implicit file= prefix if missing, and/or removing 
> quotes from a quoted name.
>
> Webrev:
> http://cr.openjdk.java.net/~mlarsson/8150823/webrev.01/
>
> Incremental:
> http://cr.openjdk.java.net/~mlarsson/8150823/webrev.00-01/
>
> Tested with serviceability/logging tests through RBT.
>
> Thanks,
> Marcus
>
> On 03/11/2016 03:40 PM, Marcus Larsson wrote:
>> Hi,
>>
>> Please review the following patch to fix a problem with disabling log 
>> outputs using -Xlog:disable or disable_logging() when there are 
>> multiple file outputs configured. The patch also resolves an issue 
>> with log file lookups that could cause multiple outputs to be created 
>> for the same log file.
>>
>> Log output removal now iterates backwards to not invalidate the loop 
>> index, and file outputs are always prepended with "file=" during 
>> lookups and listings.
>>
>> Webrev:
>> http://cr.openjdk.java.net/~mlarsson/8150823/webrev.00/
>>
>> Issue:
>> https://bugs.openjdk.java.net/browse/JDK-8150823
>>
>> Testing:
>> Included tests through RBT
>>
>> Thanks,
>> Marcus
>


From marcus.larsson at oracle.com  Wed Mar 23 10:43:04 2016
From: marcus.larsson at oracle.com (Marcus Larsson)
Date: Wed, 23 Mar 2016 11:43:04 +0100
Subject: RFR: 8152538: UL doesn't inline the LogTagSet::is_level check
In-Reply-To: <56F26FEB.3000700@oracle.com>
References: <56F26FEB.3000700@oracle.com>
Message-ID: <56F27338.8030005@oracle.com>

Hi Stefan,

On 03/23/2016 11:28 AM, Stefan Karlsson wrote:
> Hi all,
>
> Please, review this patch to optimize the log_is_enabled check in the 
> Unified Logging framework.
>
> http://cr.openjdk.java.net/~stefank/8152538/webrev.01/

Looks good, thanks for fixing this!

Marcus

> https://bugs.openjdk.java.net/browse/JDK-8152538
>
> The following code:
>   void logLine() {
>     log_debug(gc)("logLine");
>   }
>
> expands into:
> (!log_is_enabled(Debug, __VA_ARGS__)) ? ... : ... )
>
> The log_is_enabled macro further expands and inlines functions, but 
> then end up calling LogTagSet::is_level.
>
> Currently, the generated code looks like this:
> (gdb) disass logLine
> Dump of assembler code for function logLine():
>    0x0000000000ae3bc0 <+0>: push %rbp
>    0x0000000000ae3bc1 <+1>: lea 0x755fb8(%rip),%rdi # 0x1239b80 
> <_ZN16LogTagSetMappingILN6LogTag4typeE22ELS1_0ELS1_0ELS1_0ELS1_0EE7_tagsetE>
>    0x0000000000ae3bc8 <+8>: mov $0x2,%esi
>    0x0000000000ae3bcd <+13>: mov %rsp,%rbp
>    0x0000000000ae3bd0 <+16>: callq 0x969c30 
> <LogTagSet::is_level(LogLevel::type) const>
>    0x0000000000ae3bd5 <+21>: test %al,%al
>    0x0000000000ae3bd7 <+23>: jne 0xae3be0 <logLine()+32>
>    0x0000000000ae3bd9 <+25>: pop %rbp
>    0x0000000000ae3bda <+26>: retq
>    0x0000000000ae3bdb <+27>: nopl 0x0(%rax,%rax,1)
>    0x0000000000ae3be0 <+32>: pop %rbp
>    0x0000000000ae3be1 <+33>: lea 0x265133(%rip),%rdi # 0xd48d1b
>    0x0000000000ae3be8 <+40>: xor %eax,%eax
>    0x0000000000ae3bea <+42>:
>     jmpq 0x5d9e00 <LogImpl<(LogTag::type)22, (LogTag::type)0, 
> (LogTag::type)0, (LogTag::type)0, (LogTag::type)0, 
> (LogTag::type)0>::write<(LogLevel::type)2>(char const*, ...)>
>
> By making LogTagSet::is_level inlinable, we get:
> (gdb) disass logLine
> Dump of assembler code for function logLine():
>    0x0000000000ae1690 <+0>: cmpq $0x0,0x756520(%rip) # 0x1237bb8 
> <_ZN16LogTagSetMappingILN6LogTag4typeE22ELS1_0ELS1_0ELS1_0ELS1_0EE7_tagsetE+56>
>    0x0000000000ae1698 <+8>: push %rbp
>    0x0000000000ae1699 <+9>: mov %rsp,%rbp
>    0x0000000000ae169c <+12>: je 0xae16b0 <logLine()+32>
>    0x0000000000ae169e <+14>: pop %rbp
>    0x0000000000ae169f <+15>: lea 0x264d75(%rip),%rdi # 0xd4641b
>    0x0000000000ae16a6 <+22>: xor %eax,%eax
>    0x0000000000ae16a8 <+24>:
>     jmpq 0x5d8f60 <LogImpl<(LogTag::type)22, (LogTag::type)0, 
> (LogTag::type)0, (LogTag::type)0, (LogTag::type)0, 
> (LogTag::type)0>::write<(LogLevel::type)2>(char const*, ...)>
>    0x0000000000ae16ad <+29>: nopl (%rax)
>    0x0000000000ae16b0 <+32>: pop %rbp
>    0x0000000000ae16b1 <+33>: retq
> End of assembler dump.
>
> Thanks,
> StefanK


From marcus.larsson at oracle.com  Wed Mar 23 10:59:05 2016
From: marcus.larsson at oracle.com (Marcus Larsson)
Date: Wed, 23 Mar 2016 11:59:05 +0100
Subject: RFR: 8151438: UL instantiates duplicate tag sets
In-Reply-To: <56F26940.5040005@oracle.com>
References: <56F2609E.7090201@oracle.com> <56F26940.5040005@oracle.com>
Message-ID: <56F276F9.4010202@oracle.com>

Hi Stefan,

On 03/23/2016 11:00 AM, Stefan Karlsson wrote:
> Hi Marcus,
>
> On 2016-03-23 10:23, Marcus Larsson wrote:
>> Hi,
>>
>> Please review the following patch to fix the issue where duplicate 
>> tagsets are created for the same logical tagset.
>>
>> The code that emulates the variadic template arguments assumes that 
>> _NO_TAG terminates the sequence of tags. If other tags (other than 
>> _NO_TAG) follow a terminating tag, template instances that are 
>> otherwise considered equal (since they share tags up until the 
>> terminating tag), might not be considered equal in the template sense 
>> (one of the template arguments can differ). This would cause another 
>> template instantiation for the same logical tagset and we end up with 
>> logical duplicates.
>>
>> The if-statement to append the 'start' tag in 
>> GCTraceTimeImpl::log_start() caused such problematic template 
>> instantiations, so any tagset used with GCTraceTime would be 
>> duplicated. To fix this, the template instantiation has been forced 
>> to only be made once, ensuring no real tag follows the first _NO_TAG 
>> by using the ternary operator.
>>
>> This patch also includes a test checking for invalid tagsets like 
>> these, and also checks for tagsets that are just permutations of 
>> other tagsets. Such tagsets should be avoided to prevent confusion, 
>> and to reduce overhead. (The test exposed one case where a different 
>> permutation was used, so I've fixed that as well.)
>>
>> Webrev:
>> http://cr.openjdk.java.net/~mlarsson/8151438
>
> The change looks good. I have a couple of comments about the test:
>
> http://cr.openjdk.java.net/~mlarsson/8151438/webrev.00/src/share/vm/logging/log.cpp.frames.html 
>
>
> 191 char other_name[512];
> 192 other->label(other_name, sizeof(other_name), ",");
> 193 // Since tagsets are implemented using template arguments, using 
> both of
> 194 // the (logically equivalent) tagsets (t1, t2) and (t2, t1) 
> somewhere will
> 195 // instantiate two different LogTagSetMappings. This causes multiple
> 196 // tagset instances to be created for the same logical set. We 
> want to
> 197 // avoid this to save time, memory and prevent any confusion 
> around it.
> 198 assert(!equal, "duplicate LogTagSets found: '%s' vs '%s' "
> 199 "(tags must always be specified in the same order for each tagset)",
> 200 ts_name, other_name);
>
>
> It might be good to check if (!equals) before setting up the 
> other_name. Maybe:
>
> if (!equals) {
>   char other_name[512];
>   other->label(other_name, sizeof(other_name), ",");
>   assert(!equals /* or just false */, ...);
> }
>

Fixed.

>
> http://cr.openjdk.java.net/~mlarsson/8151438/webrev.00/src/share/vm/utilities/internalVMTests.cpp.frames.html 
>
>
> The test for the logging framework doesn't have a good prefix:
>
>   70   run_unit_test(Test_log_length);
>   71   run_unit_test(Test_configure_stdout);
>   72   run_unit_test(Test_logconfiguration_subscribe);
>    73 run_unit_test(Test_tagset_duplicates);
>
> I think we should clean this up (in another RFE) by naming these 
> functions similar to the other test functions:
>
>   70   run_unit_test(TestLogLength_test);
>   71   run_unit_test(TestLogConfigureStdout_test);
>   72   run_unit_test(TestLogConfigurationSubscribe_test);
>    73 run_unit_test(TestLogTagSetDuplicates_test);
>
> I understand that there are some inconsistent names in the test list, 
> but I think we should start by fixing the names for the logging tests.

I agree. Although I would like these tests to be ported to the unit test 
framework once that's been integrated. It will allow better organization 
and grouping of tests. Perhaps we should leave it as is until then?

For now, I renamed the test to Test_logtagset_duplicates instead of 
Test_tagset_duplicates to better indicate that it's a logging test.

New webrev:
http://cr.openjdk.java.net/~mlarsson/8151438/webrev.01/

Incremental:
http://cr.openjdk.java.net/~mlarsson/8151438/webrev.00-01/

Thanks,
Marcus

>
> Thanks,
> StefanK
>
>>
>> Issue:
>> https://bugs.openjdk.java.net/browse/JDK-8151438
>>
>> Testing:
>> New internal VM test through RBT.
>>
>> Thanks,
>> Marcus
>


From dmitry.samersoff at oracle.com  Wed Mar 23 11:51:38 2016
From: dmitry.samersoff at oracle.com (Dmitry Samersoff)
Date: Wed, 23 Mar 2016 14:51:38 +0300
Subject: RFR(S): JDK-8151444 JDP not working on some windows configurations
In-Reply-To: <56F1D2DD.9080206@gmail.com>
References: <56F131DA.7060205@oracle.com> <56F1D2DD.9080206@gmail.com>
Message-ID: <56F2834A.6080005@oracle.com>

Yasumasa,

  We have at least two problems with explicit setting of IP_MULTICAST_IF
that I can reproduce in-house.[1]

  Source address of IP packet should match the interface we are using
and network configuration can be changed while Java app is running i.e.
after the point we are setting interface flags.

  So existing code is incorrect, and I decide to remove it.

  If we need to reliably send broadcast to all available interfaces,
code have to be more complicated than just setting IP_MULTICAST_IF on
jdp start.
  We probably need to check the state of available interfaces
periodically and launch separate JdpBroadcaster for each interface.

  I'm not sure we should add such complication to Jdp.
  Sorry!

* * *
1. Below is Linux/tcpdump output in one of test configurations:
eth0 192.168.0.77 connected to LAN, wlan0 172.16.2.100 is not connected
to anything.

*Default settings:*

dooku:hs-rt#tcpdump -n -i eth0 port 7095

IP 192.168.0.77.35874 > 224.0.23.178.7095: UDP, length 262

dooku:hs-rt#tcpdump -n -i wlan0 port 7095

<no packets>

*IP_MULTICAST_IF set explicitly for both eth0 and wlan0*

dooku:hs-rt#tcpdump -n -i eth0 port 7095

IP 172.16.2.100.44921 > 224.0.23.178.7095: UDP, length 262

dooku:hs-rt#tcpdump -n -i wlan0 port 7095

IP 172.16.2.100.42919 > 224.0.23.178.7095: UDP, length 262

-Dmitry




On 2016-03-23 02:18, Yasumasa Suenaga wrote:
> Hi Dmitry,
> 
> Does your change work on Linux multi-homed environment?
> The code which you remove is added at JDK-8057556.
> 
>   http://mail.openjdk.java.net/pipermail/serviceability-dev/2014-September/015504.html
> 
> DiagramChannel which is used in JDPBroadcaster tries to send JDP packet
> through all "UP" NICs.
> However, NIC which is controlled by NetworkManager seems to be still "UP"
> when ifdown command is executed.
> (It seems to be removed IP address from NIC only.)
> 
> I cannot check your change because I destroyed environment for reproduce.
> Did you check your change on Linux multi-homed (and NetworkManager is active)
> environment?
> 
> 
> Thanks,
> 
> Yasumasa
> 
> 
> On 2016/03/22 20:51, Dmitry Samersoff wrote:
>> Everybody,
>>
>> Please review the fix:
>>
>> http://cr.openjdk.java.net/~dsamersoff/JDK-8151444/webrev.01/
>>
>> Removed code attempts to set IP_MULTICAST_IF to enforce sending of JDP
>> packets to all available interfaces. It doesn't work on some multi-homed
>> windows configurations.
>>
>> Also fixed minor bug in testcase.
>>
>> -Dmitry
>>
>>
>>


-- 
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the sources.

From bengt.rutisson at oracle.com  Wed Mar 23 12:36:36 2016
From: bengt.rutisson at oracle.com (Bengt Rutisson)
Date: Wed, 23 Mar 2016 13:36:36 +0100
Subject: RFR: 8151438: UL instantiates duplicate tag sets
In-Reply-To: <56F276F9.4010202@oracle.com>
References: <56F2609E.7090201@oracle.com> <56F26940.5040005@oracle.com>
	<56F276F9.4010202@oracle.com>
Message-ID: <56F28DD4.4080308@oracle.com>


Hi Marcus,

Looks good to me.

Thanks,
Bengt

On 2016-03-23 11:59, Marcus Larsson wrote:
> Hi Stefan,
>
> On 03/23/2016 11:00 AM, Stefan Karlsson wrote:
>> Hi Marcus,
>>
>> On 2016-03-23 10:23, Marcus Larsson wrote:
>>> Hi,
>>>
>>> Please review the following patch to fix the issue where duplicate 
>>> tagsets are created for the same logical tagset.
>>>
>>> The code that emulates the variadic template arguments assumes that 
>>> _NO_TAG terminates the sequence of tags. If other tags (other than 
>>> _NO_TAG) follow a terminating tag, template instances that are 
>>> otherwise considered equal (since they share tags up until the 
>>> terminating tag), might not be considered equal in the template 
>>> sense (one of the template arguments can differ). This would cause 
>>> another template instantiation for the same logical tagset and we 
>>> end up with logical duplicates.
>>>
>>> The if-statement to append the 'start' tag in 
>>> GCTraceTimeImpl::log_start() caused such problematic template 
>>> instantiations, so any tagset used with GCTraceTime would be 
>>> duplicated. To fix this, the template instantiation has been forced 
>>> to only be made once, ensuring no real tag follows the first _NO_TAG 
>>> by using the ternary operator.
>>>
>>> This patch also includes a test checking for invalid tagsets like 
>>> these, and also checks for tagsets that are just permutations of 
>>> other tagsets. Such tagsets should be avoided to prevent confusion, 
>>> and to reduce overhead. (The test exposed one case where a different 
>>> permutation was used, so I've fixed that as well.)
>>>
>>> Webrev:
>>> http://cr.openjdk.java.net/~mlarsson/8151438
>>
>> The change looks good. I have a couple of comments about the test:
>>
>> http://cr.openjdk.java.net/~mlarsson/8151438/webrev.00/src/share/vm/logging/log.cpp.frames.html 
>>
>>
>> 191 char other_name[512];
>> 192 other->label(other_name, sizeof(other_name), ",");
>> 193 // Since tagsets are implemented using template arguments, using 
>> both of
>> 194 // the (logically equivalent) tagsets (t1, t2) and (t2, t1) 
>> somewhere will
>> 195 // instantiate two different LogTagSetMappings. This causes multiple
>> 196 // tagset instances to be created for the same logical set. We 
>> want to
>> 197 // avoid this to save time, memory and prevent any confusion 
>> around it.
>> 198 assert(!equal, "duplicate LogTagSets found: '%s' vs '%s' "
>> 199 "(tags must always be specified in the same order for each tagset)",
>> 200 ts_name, other_name);
>>
>>
>> It might be good to check if (!equals) before setting up the 
>> other_name. Maybe:
>>
>> if (!equals) {
>>   char other_name[512];
>>   other->label(other_name, sizeof(other_name), ",");
>>   assert(!equals /* or just false */, ...);
>> }
>>
>
> Fixed.
>
>>
>> http://cr.openjdk.java.net/~mlarsson/8151438/webrev.00/src/share/vm/utilities/internalVMTests.cpp.frames.html 
>>
>>
>> The test for the logging framework doesn't have a good prefix:
>>
>>   70   run_unit_test(Test_log_length);
>>   71   run_unit_test(Test_configure_stdout);
>>   72   run_unit_test(Test_logconfiguration_subscribe);
>>    73 run_unit_test(Test_tagset_duplicates);
>>
>> I think we should clean this up (in another RFE) by naming these 
>> functions similar to the other test functions:
>>
>>   70   run_unit_test(TestLogLength_test);
>>   71   run_unit_test(TestLogConfigureStdout_test);
>>   72   run_unit_test(TestLogConfigurationSubscribe_test);
>>    73 run_unit_test(TestLogTagSetDuplicates_test);
>>
>> I understand that there are some inconsistent names in the test list, 
>> but I think we should start by fixing the names for the logging tests.
>
> I agree. Although I would like these tests to be ported to the unit 
> test framework once that's been integrated. It will allow better 
> organization and grouping of tests. Perhaps we should leave it as is 
> until then?
>
> For now, I renamed the test to Test_logtagset_duplicates instead of 
> Test_tagset_duplicates to better indicate that it's a logging test.
>
> New webrev:
> http://cr.openjdk.java.net/~mlarsson/8151438/webrev.01/
>
> Incremental:
> http://cr.openjdk.java.net/~mlarsson/8151438/webrev.00-01/
>
> Thanks,
> Marcus
>
>>
>> Thanks,
>> StefanK
>>
>>>
>>> Issue:
>>> https://bugs.openjdk.java.net/browse/JDK-8151438
>>>
>>> Testing:
>>> New internal VM test through RBT.
>>>
>>> Thanks,
>>> Marcus
>>
>


From bengt.rutisson at oracle.com  Wed Mar 23 12:37:59 2016
From: bengt.rutisson at oracle.com (Bengt Rutisson)
Date: Wed, 23 Mar 2016 13:37:59 +0100
Subject: RFR: 8152538: UL doesn't inline the LogTagSet::is_level check
In-Reply-To: <56F26FEB.3000700@oracle.com>
References: <56F26FEB.3000700@oracle.com>
Message-ID: <56F28E27.6030600@oracle.com>


Hi StefanK,

Looks good!

Bengt

On 2016-03-23 11:28, Stefan Karlsson wrote:
> Hi all,
>
> Please, review this patch to optimize the log_is_enabled check in the 
> Unified Logging framework.
>
> http://cr.openjdk.java.net/~stefank/8152538/webrev.01/
> https://bugs.openjdk.java.net/browse/JDK-8152538
>
> The following code:
>   void logLine() {
>     log_debug(gc)("logLine");
>   }
>
> expands into:
> (!log_is_enabled(Debug, __VA_ARGS__)) ? ... : ... )
>
> The log_is_enabled macro further expands and inlines functions, but 
> then end up calling LogTagSet::is_level.
>
> Currently, the generated code looks like this:
> (gdb) disass logLine
> Dump of assembler code for function logLine():
>    0x0000000000ae3bc0 <+0>: push %rbp
>    0x0000000000ae3bc1 <+1>: lea 0x755fb8(%rip),%rdi # 0x1239b80 
> <_ZN16LogTagSetMappingILN6LogTag4typeE22ELS1_0ELS1_0ELS1_0ELS1_0EE7_tagsetE>
>    0x0000000000ae3bc8 <+8>: mov $0x2,%esi
>    0x0000000000ae3bcd <+13>: mov %rsp,%rbp
>    0x0000000000ae3bd0 <+16>: callq 0x969c30 
> <LogTagSet::is_level(LogLevel::type) const>
>    0x0000000000ae3bd5 <+21>: test %al,%al
>    0x0000000000ae3bd7 <+23>: jne 0xae3be0 <logLine()+32>
>    0x0000000000ae3bd9 <+25>: pop %rbp
>    0x0000000000ae3bda <+26>: retq
>    0x0000000000ae3bdb <+27>: nopl 0x0(%rax,%rax,1)
>    0x0000000000ae3be0 <+32>: pop %rbp
>    0x0000000000ae3be1 <+33>: lea 0x265133(%rip),%rdi # 0xd48d1b
>    0x0000000000ae3be8 <+40>: xor %eax,%eax
>    0x0000000000ae3bea <+42>:
>     jmpq 0x5d9e00 <LogImpl<(LogTag::type)22, (LogTag::type)0, 
> (LogTag::type)0, (LogTag::type)0, (LogTag::type)0, 
> (LogTag::type)0>::write<(LogLevel::type)2>(char const*, ...)>
>
> By making LogTagSet::is_level inlinable, we get:
> (gdb) disass logLine
> Dump of assembler code for function logLine():
>    0x0000000000ae1690 <+0>: cmpq $0x0,0x756520(%rip) # 0x1237bb8 
> <_ZN16LogTagSetMappingILN6LogTag4typeE22ELS1_0ELS1_0ELS1_0ELS1_0EE7_tagsetE+56>
>    0x0000000000ae1698 <+8>: push %rbp
>    0x0000000000ae1699 <+9>: mov %rsp,%rbp
>    0x0000000000ae169c <+12>: je 0xae16b0 <logLine()+32>
>    0x0000000000ae169e <+14>: pop %rbp
>    0x0000000000ae169f <+15>: lea 0x264d75(%rip),%rdi # 0xd4641b
>    0x0000000000ae16a6 <+22>: xor %eax,%eax
>    0x0000000000ae16a8 <+24>:
>     jmpq 0x5d8f60 <LogImpl<(LogTag::type)22, (LogTag::type)0, 
> (LogTag::type)0, (LogTag::type)0, (LogTag::type)0, 
> (LogTag::type)0>::write<(LogLevel::type)2>(char const*, ...)>
>    0x0000000000ae16ad <+29>: nopl (%rax)
>    0x0000000000ae16b0 <+32>: pop %rbp
>    0x0000000000ae16b1 <+33>: retq
> End of assembler dump.
>
> Thanks,
> StefanK


From yasuenag at gmail.com  Wed Mar 23 13:08:19 2016
From: yasuenag at gmail.com (Yasumasa Suenaga)
Date: Wed, 23 Mar 2016 22:08:19 +0900
Subject: RFR(S): JDK-8151444 JDP not working on some windows configurations
In-Reply-To: <56F2834A.6080005@oracle.com>
References: <56F131DA.7060205@oracle.com> <56F1D2DD.9080206@gmail.com>
	<56F2834A.6080005@oracle.com>
Message-ID: <56F29543.3050105@gmail.com>

Dmitry,

Thanks, I understood.
I have no objection.


Yasumasa


On 2016/03/23 20:51, Dmitry Samersoff wrote:
> Yasumasa,
> 
>    We have at least two problems with explicit setting of IP_MULTICAST_IF
> that I can reproduce in-house.[1]
> 
>    Source address of IP packet should match the interface we are using
> and network configuration can be changed while Java app is running i.e.
> after the point we are setting interface flags.
> 
>    So existing code is incorrect, and I decide to remove it.
> 
>    If we need to reliably send broadcast to all available interfaces,
> code have to be more complicated than just setting IP_MULTICAST_IF on
> jdp start.
>    We probably need to check the state of available interfaces
> periodically and launch separate JdpBroadcaster for each interface.
> 
>    I'm not sure we should add such complication to Jdp.
>    Sorry!
> 
> * * *
> 1. Below is Linux/tcpdump output in one of test configurations:
> eth0 192.168.0.77 connected to LAN, wlan0 172.16.2.100 is not connected
> to anything.
> 
> *Default settings:*
> 
> dooku:hs-rt#tcpdump -n -i eth0 port 7095
> 
> IP 192.168.0.77.35874 > 224.0.23.178.7095: UDP, length 262
> 
> dooku:hs-rt#tcpdump -n -i wlan0 port 7095
> 
> <no packets>
> 
> *IP_MULTICAST_IF set explicitly for both eth0 and wlan0*
> 
> dooku:hs-rt#tcpdump -n -i eth0 port 7095
> 
> IP 172.16.2.100.44921 > 224.0.23.178.7095: UDP, length 262
> 
> dooku:hs-rt#tcpdump -n -i wlan0 port 7095
> 
> IP 172.16.2.100.42919 > 224.0.23.178.7095: UDP, length 262
> 
> -Dmitry
> 
> 
> 
> 
> On 2016-03-23 02:18, Yasumasa Suenaga wrote:
>> Hi Dmitry,
>>
>> Does your change work on Linux multi-homed environment?
>> The code which you remove is added at JDK-8057556.
>>
>>    http://mail.openjdk.java.net/pipermail/serviceability-dev/2014-September/015504.html
>>
>> DiagramChannel which is used in JDPBroadcaster tries to send JDP packet
>> through all "UP" NICs.
>> However, NIC which is controlled by NetworkManager seems to be still "UP"
>> when ifdown command is executed.
>> (It seems to be removed IP address from NIC only.)
>>
>> I cannot check your change because I destroyed environment for reproduce.
>> Did you check your change on Linux multi-homed (and NetworkManager is active)
>> environment?
>>
>>
>> Thanks,
>>
>> Yasumasa
>>
>>
>> On 2016/03/22 20:51, Dmitry Samersoff wrote:
>>> Everybody,
>>>
>>> Please review the fix:
>>>
>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8151444/webrev.01/
>>>
>>> Removed code attempts to set IP_MULTICAST_IF to enforce sending of JDP
>>> packets to all available interfaces. It doesn't work on some multi-homed
>>> windows configurations.
>>>
>>> Also fixed minor bug in testcase.
>>>
>>> -Dmitry
>>>
>>>
>>>
> 
> 

From yasuenag at gmail.com  Wed Mar 23 13:12:37 2016
From: yasuenag at gmail.com (Yasumasa Suenaga)
Date: Wed, 23 Mar 2016 22:12:37 +0900
Subject: PING: RFR: JDK-8151674: STW phases at Concurrent GC should count in
	PerfCounter
In-Reply-To: <56EC5AE4.4080909@oracle.com>
References: <56E242B5.1070206@gmail.com> <56E9A230.1060607@oracle.com>
	<CAGFVN2ATsvSfyzc-_AzBRXcUJMShENHog6XinvgyJiZBUMTXgQ@mail.gmail.com>
	<56EC0D54.3090907@gmail.com> <56EC5AE4.4080909@oracle.com>
Message-ID: <56F29645.80305@gmail.com>

PING:

We need one more reviewer for HotSpot changes.
Please review.


Thanks,

Yasumasa


On 2016/03/19 4:45, Jon Masamitsu wrote:
>
>
> On 3/18/2016 7:14 AM, Yasumasa Suenaga wrote:
>> Hi,
>>
>>> I added a comment to JBS about G1 initial mark.
>>> I will upload new webrev after discussing for it.
>>
>> We discussed about it on JBS, and we decided not to count initial mark on G1
>> to CGC counter. [1]
>>
>> I uploaded new webrev. Could you review it?
>
> Changes look good.   We'll need one more review of the hotspot changes.
>
> Jon
>
>>
>>   hotspot: http://cr.openjdk.java.net/~ysuenaga/JDK-8151674/webrev.01/hotspot/
>>       jdk: http://cr.openjdk.java.net/~ysuenaga/JDK-8151674/webrev.01/jdk/
>>
>> jdk part is the same with the patch which is reviewed by Staffan Larsen. [2]
>>
>>
>> Thanks,
>>
>> Yasumasa
>>
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8151674?focusedCommentId=13914167&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13914167
>> [2] http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2016-March/016911.html
>>
>>
>> On 2016/03/17 8:23, Yasumasa Suenaga wrote:
>>> Hi Jon,
>>>
>>> 2016/03/17 3:25 "Jon Masamitsu" <jon.masamitsu at oracle.com <mailto:jon.masamitsu at oracle.com>>:
>>>  >
>>>  >
>>>  >
>>>  > On 03/10/2016 07:59 PM, Yasumasa Suenaga wrote:
>>>  >>
>>>  >> Hi all,
>>>  >>
>>>  >> This review request continues from:
>>>  >> http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2016-March/016774.html
>>>  >> http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2016-March/016896.html
>>>  >>
>>>  >> I wonder that STW phases (Remark and Cleanup) at G1 are not counted in jstat FGC column.
>>>  >> For example, Initial Mark and Remark at CMS are counted as FGC.
>>>  >> We discussed on hotspot-gc-dev for this issue, and I proposed to add new PerfCounter
>>>  >> for CGC STW phases.
>>>  >>
>>>  >> I uploaded webrev. Could you review it?
>>>  >>      hotspot: http://cr.openjdk.java.net/~ysuenaga/JDK-8151674/webrev.00/hotspot/
>>>  >>          jdk: http://cr.openjdk.java.net/~ysuenaga/JDK-8151674/webrev.00/jdk/
>>>  >>
>>>  >> For compatibility, this patch works the same as the current by default.
>>>  >> If you set -XX:+EnableConcGCPerfCounter, CGC counter will work fine.
>>>  >> (I want to set +EnableConcGCPerfCounter by default)
>>>  >
>>>  >
>>>  > I would prefer not to have the flag (EnableConcGCPerfCounte)
>>>  > and just make the change for CMS.  This is a change for a major
>>>  > release and I think we can accept the incompatibility.
>>>
>>> Okay, I will remove this flag.
>>>
>>> I added a comment to JBS about G1 initial mark.
>>> I will upload new webrev after discussing for it.
>>>
>>>  > http://cr.openjdk.java.net/~ysuenaga/JDK-8151674/webrev.00/hotspot/src/share/vm/gc/g1/g1MonitoringSupport.cpp.udiff.html
>>>  >
>>>  > + // name "collector.2". In a generational collector this would be the
>>>  > + // STW phases in concurrent collection.
>>>  > + _conc_collection_counters =
>>>  > + new CollectorCounters("G1 stop-the-world phases", 2);
>>>  >
>>>  >
>>>  > Is there a hard connection between these phases and a generational
>>>  > collector (i.e., should the "In a generational collector this would be the"
>>>  > be dropped in the comment)?
>>>  >
>>>  > A comment such as
>>>  >
>>>  > // name "collector.2". STW phases as part of a concurrent collection.
>>>
>>> Thanks, I will fix.
>>>
>>>  > A set of JDK changes had been previously been reviewed (not by me). Are these
>>>  > the same?
>>>  >
>>>  > http://cr.openjdk.java.net/~ysuenaga/JDK-8151674/webrev.00/jdk/
>>>
>>> Yes, same patch.
>>>
>>> Yasumasa
>>>
>>>  > Jon
>>>  >
>>>  >
>>>  >
>>>  >>
>>>  >>
>>>  >> I cannot access JPRT.
>>>  >> So I need a sponsor.
>>>  >>
>>>  >>
>>>  >> Thanks,
>>>  >>
>>>  >> Yasumasa
>>>  >
>>>  >
>>>
>

From robbin.ehn at oracle.com  Wed Mar 23 13:50:17 2016
From: robbin.ehn at oracle.com (Robbin Ehn)
Date: Wed, 23 Mar 2016 14:50:17 +0100
Subject: RFR(xs): 8151993: Remove inclusion of inline.hpp in log.hpp (v4)
In-Reply-To: <56F02283.10908@oracle.com>
References: <56E952A5.6050708@oracle.com> <56F02283.10908@oracle.com>
Message-ID: <56F29F19.9030409@oracle.com>

Hi all,

After more input, this is the current version.
Please have a look.

Webrev: http://cr.openjdk.java.net/~rehn/8151993/v4/webrev/
Incremental: http://cr.openjdk.java.net/~rehn/8151993/v3-v4/

Thanks!

/Robbin

On 03/21/2016 05:34 PM, Robbin Ehn wrote:
> Hi all, please review this a somewhat bigger change-set.
>
> Updated with the feedback.
>
> New webrev: http://cr.openjdk.java.net/~rehn/8151993/v2/webrev/
>
> Tested with jprt hotspot and I added 2 internal vm tests.
>
> (also 2 bugs fixed, missing va_end and a potential race when calling
> prefix function twice (very unlikely))
>
> Thanks!
>
> /Robbin
>
> On 03/16/2016 01:33 PM, Robbin Ehn wrote:
>> Hi, please review this small change.
>>
>> This also change allocation methods.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8151993/
>> Webrev: http://cr.openjdk.java.net/~rehn/8151993/webrev/
>>
>> Thanks!
>>
>> /Robbin

From stefan.karlsson at oracle.com  Wed Mar 23 14:27:32 2016
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Wed, 23 Mar 2016 15:27:32 +0100
Subject: RFR(xs): 8151993: Remove inclusion of inline.hpp in log.hpp (v4)
In-Reply-To: <56F29F19.9030409@oracle.com>
References: <56E952A5.6050708@oracle.com> <56F02283.10908@oracle.com>
	<56F29F19.9030409@oracle.com>
Message-ID: <56F2A7D4.8030400@oracle.com>

Hi Robbin,

On 2016-03-23 14:50, Robbin Ehn wrote:
> Hi all,
>
> After more input, this is the current version.
> Please have a look.
>
> Webrev: http://cr.openjdk.java.net/~rehn/8151993/v4/webrev/
> Incremental: http://cr.openjdk.java.net/~rehn/8151993/v3-v4/

Looks good to me.

It's non-obvious why you change the "stderr" config below, so that might 
warrant a comment:

    LogConfiguration::disable_logging();
    assert(Test_logconfiguration_subscribe_triggered == 3, "subscription not triggered (3)");
  
- // Restore saved configuration
- LogConfiguration::parse_log_arguments("stdout", saved_config, NULL, 
NULL, log.error_stream());
- os::free(saved_config);
+ LogConfiguration::parse_log_arguments("stderr", "all=warning", NULL, 
NULL, log.error_stream());
+ assert(Test_logconfiguration_subscribe_triggered == 4, "subscription 
not triggered (3)");
  }

Thanks,
StefanK



>
> Thanks!
>
> /Robbin
>
> On 03/21/2016 05:34 PM, Robbin Ehn wrote:
>> Hi all, please review this a somewhat bigger change-set.
>>
>> Updated with the feedback.
>>
>> New webrev: http://cr.openjdk.java.net/~rehn/8151993/v2/webrev/
>>
>> Tested with jprt hotspot and I added 2 internal vm tests.
>>
>> (also 2 bugs fixed, missing va_end and a potential race when calling
>> prefix function twice (very unlikely))
>>
>> Thanks!
>>
>> /Robbin
>>
>> On 03/16/2016 01:33 PM, Robbin Ehn wrote:
>>> Hi, please review this small change.
>>>
>>> This also change allocation methods.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8151993/
>>> Webrev: http://cr.openjdk.java.net/~rehn/8151993/webrev/
>>>
>>> Thanks!
>>>
>>> /Robbin


From robbin.ehn at oracle.com  Wed Mar 23 14:35:59 2016
From: robbin.ehn at oracle.com (Robbin Ehn)
Date: Wed, 23 Mar 2016 15:35:59 +0100
Subject: RFR(xs): 8151993: Remove inclusion of inline.hpp in log.hpp (v4)
In-Reply-To: <56F2A7D4.8030400@oracle.com>
References: <56E952A5.6050708@oracle.com> <56F02283.10908@oracle.com>
	<56F29F19.9030409@oracle.com> <56F2A7D4.8030400@oracle.com>
Message-ID: <56F2A9CF.8010908@oracle.com>

Hi Stefan

On 03/23/2016 03:27 PM, Stefan Karlsson wrote:
> Hi Robbin,
>
> On 2016-03-23 14:50, Robbin Ehn wrote:
>> Hi all,
>>
>> After more input, this is the current version.
>> Please have a look.
>>
>> Webrev: http://cr.openjdk.java.net/~rehn/8151993/v4/webrev/
>> Incremental: http://cr.openjdk.java.net/~rehn/8151993/v3-v4/
>
> Looks good to me.
>
> It's non-obvious why you change the "stderr" config below, so that might
> warrant a comment:
>
>     LogConfiguration::disable_logging();
>     assert(Test_logconfiguration_subscribe_triggered == 3, "subscription
> not triggered (3)");
>
> - // Restore saved configuration
> - LogConfiguration::parse_log_arguments("stdout", saved_config, NULL,
> NULL, log.error_stream());
> - os::free(saved_config);

I'll add comment!

(The reason is that LogConfiguration::disable_logging will disable both 
stdout and stderr,
the TestLogSavedConfig will restore stdout for us but not stderr.)

Thanks Stefan!

/Robbin

> + LogConfiguration::parse_log_arguments("stderr", "all=warning", NULL,
> NULL, log.error_stream());
> + assert(Test_logconfiguration_subscribe_triggered == 4, "subscription
> not triggered (3)");
>   }
>
> Thanks,
> StefanK
>
>
>
>>
>> Thanks!
>>
>> /Robbin
>>
>> On 03/21/2016 05:34 PM, Robbin Ehn wrote:
>>> Hi all, please review this a somewhat bigger change-set.
>>>
>>> Updated with the feedback.
>>>
>>> New webrev: http://cr.openjdk.java.net/~rehn/8151993/v2/webrev/
>>>
>>> Tested with jprt hotspot and I added 2 internal vm tests.
>>>
>>> (also 2 bugs fixed, missing va_end and a potential race when calling
>>> prefix function twice (very unlikely))
>>>
>>> Thanks!
>>>
>>> /Robbin
>>>
>>> On 03/16/2016 01:33 PM, Robbin Ehn wrote:
>>>> Hi, please review this small change.
>>>>
>>>> This also change allocation methods.
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8151993/
>>>> Webrev: http://cr.openjdk.java.net/~rehn/8151993/webrev/
>>>>
>>>> Thanks!
>>>>
>>>> /Robbin
>

From marcus.larsson at oracle.com  Wed Mar 23 15:22:15 2016
From: marcus.larsson at oracle.com (Marcus Larsson)
Date: Wed, 23 Mar 2016 16:22:15 +0100
Subject: RFR: 8151438: UL instantiates duplicate tag sets
In-Reply-To: <56F28DD4.4080308@oracle.com>
References: <56F2609E.7090201@oracle.com> <56F26940.5040005@oracle.com>
	<56F276F9.4010202@oracle.com> <56F28DD4.4080308@oracle.com>
Message-ID: <56F2B4A7.10904@oracle.com>

Thanks for reviewing, Bengt!

Marcus

On 03/23/2016 01:36 PM, Bengt Rutisson wrote:
>
> Hi Marcus,
>
> Looks good to me.
>
> Thanks,
> Bengt
>
> On 2016-03-23 11:59, Marcus Larsson wrote:
>> Hi Stefan,
>>
>> On 03/23/2016 11:00 AM, Stefan Karlsson wrote:
>>> Hi Marcus,
>>>
>>> On 2016-03-23 10:23, Marcus Larsson wrote:
>>>> Hi,
>>>>
>>>> Please review the following patch to fix the issue where duplicate 
>>>> tagsets are created for the same logical tagset.
>>>>
>>>> The code that emulates the variadic template arguments assumes that 
>>>> _NO_TAG terminates the sequence of tags. If other tags (other than 
>>>> _NO_TAG) follow a terminating tag, template instances that are 
>>>> otherwise considered equal (since they share tags up until the 
>>>> terminating tag), might not be considered equal in the template 
>>>> sense (one of the template arguments can differ). This would cause 
>>>> another template instantiation for the same logical tagset and we 
>>>> end up with logical duplicates.
>>>>
>>>> The if-statement to append the 'start' tag in 
>>>> GCTraceTimeImpl::log_start() caused such problematic template 
>>>> instantiations, so any tagset used with GCTraceTime would be 
>>>> duplicated. To fix this, the template instantiation has been forced 
>>>> to only be made once, ensuring no real tag follows the first 
>>>> _NO_TAG by using the ternary operator.
>>>>
>>>> This patch also includes a test checking for invalid tagsets like 
>>>> these, and also checks for tagsets that are just permutations of 
>>>> other tagsets. Such tagsets should be avoided to prevent confusion, 
>>>> and to reduce overhead. (The test exposed one case where a 
>>>> different permutation was used, so I've fixed that as well.)
>>>>
>>>> Webrev:
>>>> http://cr.openjdk.java.net/~mlarsson/8151438
>>>
>>> The change looks good. I have a couple of comments about the test:
>>>
>>> http://cr.openjdk.java.net/~mlarsson/8151438/webrev.00/src/share/vm/logging/log.cpp.frames.html 
>>>
>>>
>>> 191 char other_name[512];
>>> 192 other->label(other_name, sizeof(other_name), ",");
>>> 193 // Since tagsets are implemented using template arguments, using 
>>> both of
>>> 194 // the (logically equivalent) tagsets (t1, t2) and (t2, t1) 
>>> somewhere will
>>> 195 // instantiate two different LogTagSetMappings. This causes 
>>> multiple
>>> 196 // tagset instances to be created for the same logical set. We 
>>> want to
>>> 197 // avoid this to save time, memory and prevent any confusion 
>>> around it.
>>> 198 assert(!equal, "duplicate LogTagSets found: '%s' vs '%s' "
>>> 199 "(tags must always be specified in the same order for each 
>>> tagset)",
>>> 200 ts_name, other_name);
>>>
>>>
>>> It might be good to check if (!equals) before setting up the 
>>> other_name. Maybe:
>>>
>>> if (!equals) {
>>>   char other_name[512];
>>>   other->label(other_name, sizeof(other_name), ",");
>>>   assert(!equals /* or just false */, ...);
>>> }
>>>
>>
>> Fixed.
>>
>>>
>>> http://cr.openjdk.java.net/~mlarsson/8151438/webrev.00/src/share/vm/utilities/internalVMTests.cpp.frames.html 
>>>
>>>
>>> The test for the logging framework doesn't have a good prefix:
>>>
>>>   70   run_unit_test(Test_log_length);
>>>   71   run_unit_test(Test_configure_stdout);
>>>   72   run_unit_test(Test_logconfiguration_subscribe);
>>>    73 run_unit_test(Test_tagset_duplicates);
>>>
>>> I think we should clean this up (in another RFE) by naming these 
>>> functions similar to the other test functions:
>>>
>>>   70   run_unit_test(TestLogLength_test);
>>>   71   run_unit_test(TestLogConfigureStdout_test);
>>>   72   run_unit_test(TestLogConfigurationSubscribe_test);
>>>    73 run_unit_test(TestLogTagSetDuplicates_test);
>>>
>>> I understand that there are some inconsistent names in the test 
>>> list, but I think we should start by fixing the names for the 
>>> logging tests.
>>
>> I agree. Although I would like these tests to be ported to the unit 
>> test framework once that's been integrated. It will allow better 
>> organization and grouping of tests. Perhaps we should leave it as is 
>> until then?
>>
>> For now, I renamed the test to Test_logtagset_duplicates instead of 
>> Test_tagset_duplicates to better indicate that it's a logging test.
>>
>> New webrev:
>> http://cr.openjdk.java.net/~mlarsson/8151438/webrev.01/
>>
>> Incremental:
>> http://cr.openjdk.java.net/~mlarsson/8151438/webrev.00-01/
>>
>> Thanks,
>> Marcus
>>
>>>
>>> Thanks,
>>> StefanK
>>>
>>>>
>>>> Issue:
>>>> https://bugs.openjdk.java.net/browse/JDK-8151438
>>>>
>>>> Testing:
>>>> New internal VM test through RBT.
>>>>
>>>> Thanks,
>>>> Marcus
>>>
>>
>


From dmitry.samersoff at oracle.com  Wed Mar 23 17:43:23 2016
From: dmitry.samersoff at oracle.com (Dmitry Samersoff)
Date: Wed, 23 Mar 2016 20:43:23 +0300
Subject: NEED REVIEWER Re: RFR(S): JDK-8151991 jvmti diagnostics commands
	requires INCLUDE_SERVICES
In-Reply-To: <56EB8726.9060101@oracle.com>
References: <56E858BD.4030401@oracle.com> <56E867C8.4070200@oracle.com>
	<56E94B3B.2060208@oracle.com> <56E96A5B.5000105@oracle.com>
	<56EB8726.9060101@oracle.com>
Message-ID: <56F2D5BB.3050809@oracle.com>

Everybody,

Webrev updated according to David's concerns.

http://cr.openjdk.java.net/~dsamersoff/JDK-8151991/webrev.02/

-Dmitry

On 2016-03-18 07:42, David Holmes wrote:
> On 17/03/2016 12:14 AM, Dmitry Samersoff wrote:
>> Everybody,
>>
>> Please, review small fix.
>>
>> http://cr.openjdk.java.net/~dsamersoff/JDK-8151991/webrev.01/
>>
>> New diagnostic command (JVMTI.agent_load) should be guarded by
>> #if INCLUDE_SERVICES and don't brake minimal VM build.
> 
> Initially I was confused as to why this was associated with
> INCLUDE_SERVICES as it seems unrelated to the all the other things
> guarded by INCLUDE_SERVICES. But now I see that the attachListener code
> is completely excluded by INCLUDE_SERVICES (excludeSrc.gmk) so it makes
> sense that the same guard is used in the diagnosticCommand sources (or
> else an independent guard introduced?).
> 
> However you would then also need the same guard in:
> 
> src/share/vm/prims/jvmtiExport.cpp
> 
> to allow INCLUDE_JVMTI to be true and INCLUDE_SERVICES to be false.
> 
> lso can you update this comment:
> 
>  64 #if INCLUDE_SERVICES // Heap dumping/inspection supported
> 
> to also refer to the JVM TI agent/attach support
> 
> Thanks,
> David
> -----
> 
> 
>> -Dmitry
>>


-- 
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the sources.

From stefan.karlsson at oracle.com  Wed Mar 23 19:34:01 2016
From: stefan.karlsson at oracle.com (Stefan Karlsson)
Date: Wed, 23 Mar 2016 20:34:01 +0100
Subject: RFR: 8151438: UL instantiates duplicate tag sets
In-Reply-To: <56F276F9.4010202@oracle.com>
References: <56F2609E.7090201@oracle.com> <56F26940.5040005@oracle.com>
	<56F276F9.4010202@oracle.com>
Message-ID: <56F2EFA9.1070504@oracle.com>

Hi Marcus,

On 23/03/16 11:59, Marcus Larsson wrote:
> Hi Stefan,
>
> On 03/23/2016 11:00 AM, Stefan Karlsson wrote:
>> Hi Marcus,
>>
>> On 2016-03-23 10:23, Marcus Larsson wrote:
>>> Hi,
>>>
>>> Please review the following patch to fix the issue where duplicate 
>>> tagsets are created for the same logical tagset.
>>>
>>> The code that emulates the variadic template arguments assumes that 
>>> _NO_TAG terminates the sequence of tags. If other tags (other than 
>>> _NO_TAG) follow a terminating tag, template instances that are 
>>> otherwise considered equal (since they share tags up until the 
>>> terminating tag), might not be considered equal in the template 
>>> sense (one of the template arguments can differ). This would cause 
>>> another template instantiation for the same logical tagset and we 
>>> end up with logical duplicates.
>>>
>>> The if-statement to append the 'start' tag in 
>>> GCTraceTimeImpl::log_start() caused such problematic template 
>>> instantiations, so any tagset used with GCTraceTime would be 
>>> duplicated. To fix this, the template instantiation has been forced 
>>> to only be made once, ensuring no real tag follows the first _NO_TAG 
>>> by using the ternary operator.
>>>
>>> This patch also includes a test checking for invalid tagsets like 
>>> these, and also checks for tagsets that are just permutations of 
>>> other tagsets. Such tagsets should be avoided to prevent confusion, 
>>> and to reduce overhead. (The test exposed one case where a different 
>>> permutation was used, so I've fixed that as well.)
>>>
>>> Webrev:
>>> http://cr.openjdk.java.net/~mlarsson/8151438
>>
>> The change looks good. I have a couple of comments about the test:
>>
>> http://cr.openjdk.java.net/~mlarsson/8151438/webrev.00/src/share/vm/logging/log.cpp.frames.html 
>>
>>
>> 191 char other_name[512];
>> 192 other->label(other_name, sizeof(other_name), ",");
>> 193 // Since tagsets are implemented using template arguments, using 
>> both of
>> 194 // the (logically equivalent) tagsets (t1, t2) and (t2, t1) 
>> somewhere will
>> 195 // instantiate two different LogTagSetMappings. This causes multiple
>> 196 // tagset instances to be created for the same logical set. We 
>> want to
>> 197 // avoid this to save time, memory and prevent any confusion 
>> around it.
>> 198 assert(!equal, "duplicate LogTagSets found: '%s' vs '%s' "
>> 199 "(tags must always be specified in the same order for each tagset)",
>> 200 ts_name, other_name);
>>
>>
>> It might be good to check if (!equals) before setting up the 
>> other_name. Maybe:
>>
>> if (!equals) {
>>   char other_name[512];
>>   other->label(other_name, sizeof(other_name), ",");
>>   assert(!equals /* or just false */, ...);
>> }
>>
>
> Fixed.
>
>>
>> http://cr.openjdk.java.net/~mlarsson/8151438/webrev.00/src/share/vm/utilities/internalVMTests.cpp.frames.html 
>>
>>
>> The test for the logging framework doesn't have a good prefix:
>>
>>   70   run_unit_test(Test_log_length);
>>   71   run_unit_test(Test_configure_stdout);
>>   72   run_unit_test(Test_logconfiguration_subscribe);
>>    73 run_unit_test(Test_tagset_duplicates);
>>
>> I think we should clean this up (in another RFE) by naming these 
>> functions similar to the other test functions:
>>
>>   70   run_unit_test(TestLogLength_test);
>>   71   run_unit_test(TestLogConfigureStdout_test);
>>   72   run_unit_test(TestLogConfigurationSubscribe_test);
>>    73 run_unit_test(TestLogTagSetDuplicates_test);
>>
>> I understand that there are some inconsistent names in the test list, 
>> but I think we should start by fixing the names for the logging tests.
>
> I agree. Although I would like these tests to be ported to the unit 
> test framework once that's been integrated. It will allow better 
> organization and grouping of tests. Perhaps we should leave it as is 
> until then?

Sounds like an OK plan to me.

>
> For now, I renamed the test to Test_logtagset_duplicates instead of 
> Test_tagset_duplicates to better indicate that it's a logging test.

OK.

>
> New webrev:
> http://cr.openjdk.java.net/~mlarsson/8151438/webrev.01/
>
> Incremental:
> http://cr.openjdk.java.net/~mlarsson/8151438/webrev.00-01/

I now see that I proposed if (!equals) but you did the right thing to 
use if (equals). :)

Looks good.

>
> Thanks,
> Marcus
>
>>
>> Thanks,
>> StefanK
>>
>>>
>>> Issue:
>>> https://bugs.openjdk.java.net/browse/JDK-8151438
>>>
>>> Testing:
>>> New internal VM test through RBT.
>>>
>>> Thanks,
>>> Marcus
>>
>


From serguei.spitsyn at oracle.com  Thu Mar 24 09:22:05 2016
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Thu, 24 Mar 2016 02:22:05 -0700
Subject: NEED REVIEWER Re: RFR(S): JDK-8151991 jvmti diagnostics commands
	requires INCLUDE_SERVICES
In-Reply-To: <56F2D5BB.3050809@oracle.com>
References: <56E858BD.4030401@oracle.com> <56E867C8.4070200@oracle.com>
	<56E94B3B.2060208@oracle.com> <56E96A5B.5000105@oracle.com>
	<56EB8726.9060101@oracle.com> <56F2D5BB.3050809@oracle.com>
Message-ID: <56F3B1BD.3070506@oracle.com>

Hi Dmitry,

-#if INCLUDE_SERVICES // Heap dumping/inspection supported
+#if INCLUDE_SERVICES
    DCmdFactory::register_DCmdFactory(new DCmdFactoryImpl<HeapDumpDCmd>(DCmd_Source_Internal | DCmd_Source_AttachAPI, true, false));
    DCmdFactory::register_DCmdFactory(new DCmdFactoryImpl<ClassHistogramDCmd>(full_export, true, false));
    DCmdFactory::register_DCmdFactory(new DCmdFactoryImpl<ClassStatsDCmd>(full_export, true, false));
    DCmdFactory::register_DCmdFactory(new DCmdFactoryImpl<ClassHierarchyDCmd>(full_export, true, false));
    DCmdFactory::register_DCmdFactory(new DCmdFactoryImpl<SymboltableDCmd>(full_export, true, false));
    DCmdFactory::register_DCmdFactory(new DCmdFactoryImpl<StringtableDCmd>(full_export, true, false));
+ DCmdFactory::register_DCmdFactory(new 
DCmdFactoryImpl<JVMTIAgentLoadDCmd>(full_export, true, false));
  #endif // INCLUDE_SERVICES
  #if INCLUDE_JVMTI
    DCmdFactory::register_DCmdFactory(new DCmdFactoryImpl<JVMTIDataDumpDCmd>(full_export, true, false));
- DCmdFactory::register_DCmdFactory(new 
DCmdFactoryImpl<JVMTIAgentLoadDCmd>(full_export, true, false));
  #endif // INCLUDE_JVMTI


The registration of theJVMTIAgentLoadDCmd  has to be guarded with the INCLUDE_JVMTI.
And now, it is not guarded.

Otherwise, the fix looks good.


Thanks,
Serguei




On 3/23/16 10:43, Dmitry Samersoff wrote:
> Everybody,
>
> Webrev updated according to David's concerns.
>
> http://cr.openjdk.java.net/~dsamersoff/JDK-8151991/webrev.02/
>
> -Dmitry
>
> On 2016-03-18 07:42, David Holmes wrote:
>> On 17/03/2016 12:14 AM, Dmitry Samersoff wrote:
>>> Everybody,
>>>
>>> Please, review small fix.
>>>
>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8151991/webrev.01/
>>>
>>> New diagnostic command (JVMTI.agent_load) should be guarded by
>>> #if INCLUDE_SERVICES and don't brake minimal VM build.
>> Initially I was confused as to why this was associated with
>> INCLUDE_SERVICES as it seems unrelated to the all the other things
>> guarded by INCLUDE_SERVICES. But now I see that the attachListener code
>> is completely excluded by INCLUDE_SERVICES (excludeSrc.gmk) so it makes
>> sense that the same guard is used in the diagnosticCommand sources (or
>> else an independent guard introduced?).
>>
>> However you would then also need the same guard in:
>>
>> src/share/vm/prims/jvmtiExport.cpp
>>
>> to allow INCLUDE_JVMTI to be true and INCLUDE_SERVICES to be false.
>>
>> lso can you update this comment:
>>
>>   64 #if INCLUDE_SERVICES // Heap dumping/inspection supported
>>
>> to also refer to the JVM TI agent/attach support
>>
>> Thanks,
>> David
>> -----
>>
>>
>>> -Dmitry
>>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20160324/ffeec303/attachment.html>

From alexander.kulyakhtin at oracle.com  Thu Mar 24 11:46:12 2016
From: alexander.kulyakhtin at oracle.com (Alexander Kulyakhtin)
Date: Thu, 24 Mar 2016 04:46:12 -0700 (PDT)
Subject: RFR: 8147987: Remove
	sun/management/jmxremote/bootstrap/JMXInterfaceBindingTest.java from
	problemList
Message-ID: <2477417d-9b02-4e7b-998e-814b58f69f7c@default>

Hi,

Could you, please, review this trivial, test-only change (enabling a previously excluded test)

Webrev: http://cr.openjdk.java.net/~akulyakh/8147987/test/ProblemList.txt.udiff.html
CR: https://bugs.openjdk.java.net/browse/JDK-8147987 "Remove sun/management/jmxremote/bootstrap/JMXInterfaceBindingTest.java from problemList"

Best regards,
Alexander





From dmitry.samersoff at oracle.com  Thu Mar 24 11:48:27 2016
From: dmitry.samersoff at oracle.com (Dmitry Samersoff)
Date: Thu, 24 Mar 2016 14:48:27 +0300
Subject: NEED REVIEWER Re: RFR(S): JDK-8151991 jvmti diagnostics commands
	requires INCLUDE_SERVICES
In-Reply-To: <56F3B1BD.3070506@oracle.com>
References: <56E858BD.4030401@oracle.com> <56E867C8.4070200@oracle.com>
	<56E94B3B.2060208@oracle.com> <56E96A5B.5000105@oracle.com>
	<56EB8726.9060101@oracle.com> <56F2D5BB.3050809@oracle.com>
	<56F3B1BD.3070506@oracle.com>
Message-ID: <56F3D40B.7050303@oracle.com>

Serguei,

Webrev updated in-place (press shift-reload):

http://cr.openjdk.java.net/~dsamersoff/JDK-8151991/webrev.02/

-Dmitry


On 2016-03-24 12:22, serguei.spitsyn at oracle.com wrote:
> Hi Dmitry,
> 
> -#if INCLUDE_SERVICES // Heap dumping/inspection supported
> +#if INCLUDE_SERVICES
>    DCmdFactory::register_DCmdFactory(new DCmdFactoryImpl<HeapDumpDCmd>(DCmd_Source_Internal | DCmd_Source_AttachAPI, true, false));
>    DCmdFactory::register_DCmdFactory(new DCmdFactoryImpl<ClassHistogramDCmd>(full_export, true, false));
>    DCmdFactory::register_DCmdFactory(new DCmdFactoryImpl<ClassStatsDCmd>(full_export, true, false));
>    DCmdFactory::register_DCmdFactory(new DCmdFactoryImpl<ClassHierarchyDCmd>(full_export, true, false));
>    DCmdFactory::register_DCmdFactory(new DCmdFactoryImpl<SymboltableDCmd>(full_export, true, false));
>    DCmdFactory::register_DCmdFactory(new DCmdFactoryImpl<StringtableDCmd>(full_export, true, false));
> + DCmdFactory::register_DCmdFactory(new
> DCmdFactoryImpl<JVMTIAgentLoadDCmd>(full_export, true, false));
>  #endif // INCLUDE_SERVICES
>  #if INCLUDE_JVMTI
>    DCmdFactory::register_DCmdFactory(new DCmdFactoryImpl<JVMTIDataDumpDCmd>(full_export, true, false));
> - DCmdFactory::register_DCmdFactory(new
> DCmdFactoryImpl<JVMTIAgentLoadDCmd>(full_export, true, false));
>  #endif // INCLUDE_JVMTI
> 
> 
> The registration of the JVMTIAgentLoadDCmd has to be guarded with the INCLUDE_JVMTI.
> And now, it is not guarded.
> 
> Otherwise, the fix looks good.
> 
> 
> Thanks,
> Serguei
> 
> 
> 
> 
> On 3/23/16 10:43, Dmitry Samersoff wrote:
>> Everybody,
>>
>> Webrev updated according to David's concerns.
>>
>> http://cr.openjdk.java.net/~dsamersoff/JDK-8151991/webrev.02/
>>
>> -Dmitry
>>
>> On 2016-03-18 07:42, David Holmes wrote:
>>> On 17/03/2016 12:14 AM, Dmitry Samersoff wrote:
>>>> Everybody,
>>>>
>>>> Please, review small fix.
>>>>
>>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8151991/webrev.01/
>>>>
>>>> New diagnostic command (JVMTI.agent_load) should be guarded by
>>>> #if INCLUDE_SERVICES and don't brake minimal VM build.
>>> Initially I was confused as to why this was associated with
>>> INCLUDE_SERVICES as it seems unrelated to the all the other things
>>> guarded by INCLUDE_SERVICES. But now I see that the attachListener code
>>> is completely excluded by INCLUDE_SERVICES (excludeSrc.gmk) so it makes
>>> sense that the same guard is used in the diagnosticCommand sources (or
>>> else an independent guard introduced?).
>>>
>>> However you would then also need the same guard in:
>>>
>>> src/share/vm/prims/jvmtiExport.cpp
>>>
>>> to allow INCLUDE_JVMTI to be true and INCLUDE_SERVICES to be false.
>>>
>>> lso can you update this comment:
>>>
>>>  64 #if INCLUDE_SERVICES // Heap dumping/inspection supported
>>>
>>> to also refer to the JVM TI agent/attach support
>>>
>>> Thanks,
>>> David
>>> -----
>>>
>>>
>>>> -Dmitry
>>>>
>>
> 


-- 
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the sources.

From serguei.spitsyn at oracle.com  Thu Mar 24 12:08:15 2016
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Thu, 24 Mar 2016 05:08:15 -0700
Subject: NEED REVIEWER Re: RFR(S): JDK-8151991 jvmti diagnostics commands
	requires INCLUDE_SERVICES
In-Reply-To: <56F3D40B.7050303@oracle.com>
References: <56E858BD.4030401@oracle.com> <56E867C8.4070200@oracle.com>
	<56E94B3B.2060208@oracle.com> <56E96A5B.5000105@oracle.com>
	<56EB8726.9060101@oracle.com> <56F2D5BB.3050809@oracle.com>
	<56F3B1BD.3070506@oracle.com> <56F3D40B.7050303@oracle.com>
Message-ID: <56F3D8AF.7010105@oracle.com>

Looks good.

Thanks!
Serguei


On 3/24/16 04:48, Dmitry Samersoff wrote:
> Serguei,
>
> Webrev updated in-place (press shift-reload):
>
> http://cr.openjdk.java.net/~dsamersoff/JDK-8151991/webrev.02/
>
> -Dmitry
>
>
> On 2016-03-24 12:22, serguei.spitsyn at oracle.com wrote:
>> Hi Dmitry,
>>
>> -#if INCLUDE_SERVICES // Heap dumping/inspection supported
>> +#if INCLUDE_SERVICES
>>     DCmdFactory::register_DCmdFactory(new DCmdFactoryImpl<HeapDumpDCmd>(DCmd_Source_Internal | DCmd_Source_AttachAPI, true, false));
>>     DCmdFactory::register_DCmdFactory(new DCmdFactoryImpl<ClassHistogramDCmd>(full_export, true, false));
>>     DCmdFactory::register_DCmdFactory(new DCmdFactoryImpl<ClassStatsDCmd>(full_export, true, false));
>>     DCmdFactory::register_DCmdFactory(new DCmdFactoryImpl<ClassHierarchyDCmd>(full_export, true, false));
>>     DCmdFactory::register_DCmdFactory(new DCmdFactoryImpl<SymboltableDCmd>(full_export, true, false));
>>     DCmdFactory::register_DCmdFactory(new DCmdFactoryImpl<StringtableDCmd>(full_export, true, false));
>> + DCmdFactory::register_DCmdFactory(new
>> DCmdFactoryImpl<JVMTIAgentLoadDCmd>(full_export, true, false));
>>   #endif // INCLUDE_SERVICES
>>   #if INCLUDE_JVMTI
>>     DCmdFactory::register_DCmdFactory(new DCmdFactoryImpl<JVMTIDataDumpDCmd>(full_export, true, false));
>> - DCmdFactory::register_DCmdFactory(new
>> DCmdFactoryImpl<JVMTIAgentLoadDCmd>(full_export, true, false));
>>   #endif // INCLUDE_JVMTI
>>
>>
>> The registration of the JVMTIAgentLoadDCmd has to be guarded with the INCLUDE_JVMTI.
>> And now, it is not guarded.
>>
>> Otherwise, the fix looks good.
>>
>>
>> Thanks,
>> Serguei
>>
>>
>>
>>
>> On 3/23/16 10:43, Dmitry Samersoff wrote:
>>> Everybody,
>>>
>>> Webrev updated according to David's concerns.
>>>
>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8151991/webrev.02/
>>>
>>> -Dmitry
>>>
>>> On 2016-03-18 07:42, David Holmes wrote:
>>>> On 17/03/2016 12:14 AM, Dmitry Samersoff wrote:
>>>>> Everybody,
>>>>>
>>>>> Please, review small fix.
>>>>>
>>>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8151991/webrev.01/
>>>>>
>>>>> New diagnostic command (JVMTI.agent_load) should be guarded by
>>>>> #if INCLUDE_SERVICES and don't brake minimal VM build.
>>>> Initially I was confused as to why this was associated with
>>>> INCLUDE_SERVICES as it seems unrelated to the all the other things
>>>> guarded by INCLUDE_SERVICES. But now I see that the attachListener code
>>>> is completely excluded by INCLUDE_SERVICES (excludeSrc.gmk) so it makes
>>>> sense that the same guard is used in the diagnosticCommand sources (or
>>>> else an independent guard introduced?).
>>>>
>>>> However you would then also need the same guard in:
>>>>
>>>> src/share/vm/prims/jvmtiExport.cpp
>>>>
>>>> to allow INCLUDE_JVMTI to be true and INCLUDE_SERVICES to be false.
>>>>
>>>> lso can you update this comment:
>>>>
>>>>   64 #if INCLUDE_SERVICES // Heap dumping/inspection supported
>>>>
>>>> to also refer to the JVM TI agent/attach support
>>>>
>>>> Thanks,
>>>> David
>>>> -----
>>>>
>>>>
>>>>> -Dmitry
>>>>>
>


From serguei.spitsyn at oracle.com  Thu Mar 24 12:11:58 2016
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Thu, 24 Mar 2016 05:11:58 -0700
Subject: RFR: 8147987: Remove
	sun/management/jmxremote/bootstrap/JMXInterfaceBindingTest.java from
	problemList
In-Reply-To: <2477417d-9b02-4e7b-998e-814b58f69f7c@default>
References: <2477417d-9b02-4e7b-998e-814b58f69f7c@default>
Message-ID: <56F3D98E.4050805@oracle.com>

Hi Alexander,

Looks good.

Thanks,
Serguei


On 3/24/16 04:46, Alexander Kulyakhtin wrote:
> Hi,
>
> Could you, please, review this trivial, test-only change (enabling a previously excluded test)
>
> Webrev: http://cr.openjdk.java.net/~akulyakh/8147987/test/ProblemList.txt.udiff.html
> CR: https://bugs.openjdk.java.net/browse/JDK-8147987 "Remove sun/management/jmxremote/bootstrap/JMXInterfaceBindingTest.java from problemList"
>
> Best regards,
> Alexander
>
>
>
>


From coleen.phillimore at oracle.com  Thu Mar 24 19:14:12 2016
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Thu, 24 Mar 2016 15:14:12 -0400
Subject: RFR (xs) 8152719: ignore com/sun/jdi/InterfaceMethodsTest.java until
	bug is fixed
Message-ID: <56F43C84.7070601@oracle.com>

open webrev at http://cr.openjdk.java.net/~coleenp/8152719/webrev
bug link https://bugs.openjdk.java.net/browse/JDK-8152719

Thanks,
Coleen

From coleen.phillimore at oracle.com  Thu Mar 24 19:53:16 2016
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Thu, 24 Mar 2016 15:53:16 -0400
Subject: RFR (xs) 8152719: ignore com/sun/jdi/InterfaceMethodsTest.java
	until bug is fixed
In-Reply-To: <56F43F53.8030400@oracle.com>
References: <56F43C84.7070601@oracle.com> <56F43DAF.1010609@oracle.com>
	<56F43F53.8030400@oracle.com>
Message-ID: <56F445AC.1010802@oracle.com>

Thanks for the reviews from Christian and Harold.  Posting to 
serviceability-dev also.
Coleen

On 3/24/16 3:26 PM, Coleen Phillimore wrote:
>
> Well, I'm told this isn't the right way to do this.  It should be 
> added to the ProblemList.txt file.
>
> open webrev at http://cr.openjdk.java.net/~coleenp/8152719.02/webrev
>
> thanks,
> Coleen
>
> On 3/24/16 3:19 PM, harold seigel wrote:
>> ignore is spelled wrong.
>>
>> Harold
>>
>> On 3/24/2016 3:14 PM, Coleen Phillimore wrote:
>>> open webrev at http://cr.openjdk.java.net/~coleenp/8152719/webrev
>>> bug link https://bugs.openjdk.java.net/browse/JDK-8152719
>>>
>>> Thanks,
>>> Coleen
>>
>


From serguei.spitsyn at oracle.com  Thu Mar 24 19:55:56 2016
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Thu, 24 Mar 2016 12:55:56 -0700
Subject: RFR (xs) 8152719: ignore com/sun/jdi/InterfaceMethodsTest.java
	until bug is fixed
In-Reply-To: <56F43C84.7070601@oracle.com>
References: <56F43C84.7070601@oracle.com>
Message-ID: <56F4464C.5020807@oracle.com>

Good.

Thanks,
Serguei

On 3/24/16 12:14, Coleen Phillimore wrote:
> open webrev at http://cr.openjdk.java.net/~coleenp/8152719/webrev
> bug link https://bugs.openjdk.java.net/browse/JDK-8152719
>
> Thanks,
> Coleen


From coleen.phillimore at oracle.com  Thu Mar 24 19:56:41 2016
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Thu, 24 Mar 2016 15:56:41 -0400
Subject: RFR (xs) 8152719: ignore com/sun/jdi/InterfaceMethodsTest.java
	until bug is fixed
In-Reply-To: <56F4464C.5020807@oracle.com>
References: <56F43C84.7070601@oracle.com> <56F4464C.5020807@oracle.com>
Message-ID: <56F44679.9090607@oracle.com>

thanks!
coleen

On 3/24/16 3:55 PM, serguei.spitsyn at oracle.com wrote:
> Good.
>
> Thanks,
> Serguei
>
> On 3/24/16 12:14, Coleen Phillimore wrote:
>> open webrev at http://cr.openjdk.java.net/~coleenp/8152719/webrev
>> bug link https://bugs.openjdk.java.net/browse/JDK-8152719
>>
>> Thanks,
>> Coleen
>


From kevin.walls at oracle.com  Thu Mar 24 20:05:49 2016
From: kevin.walls at oracle.com (Kevin Walls)
Date: Thu, 24 Mar 2016 20:05:49 +0000
Subject: RFR[9u-dev]: 8151442: jstack doesn't close quotation marks
	properly with threads' name greater than 1996 characters
In-Reply-To: <56F06670.5030802@oracle.com>
References: <556325b3-e8b2-4622-8b59-1df2ef4b1f02@default>
	<56EBC647.6020704@oracle.com>
	<0db522da-1cbe-494a-8aa3-e82ec7b7f5aa@default>
	<56EBF9CC.8000809@oracle.com> <56EC0285.9080004@oracle.com>
	<56EC7506.902@oracle.com> <56EFB351.7010707@oracle.com>
	<56F021EC.4010105@oracle.com> <56F06670.5030802@oracle.com>
Message-ID: <56F4489D.10107@oracle.com>


Hi

I didn't think of %.XXXXs when Cheleswer and I discussed this briefly.  
I'd like to have suggested that, with the idea that the 2k long thread 
name is extreme, and it's so important that we preserve the format of 
the output, and keep that closing quote, even if we lost some of the 
thread name.  We currently and probably always have truncated such 
names, the problem that triggered this was mainly that the format was 
broken.

As there are several places we pass the name to the stream and could hit 
the length limit, should we have a THREAD_NAME_FORMAT defined for such 
use instead of using %s though the actual length can't be 1996, it's 
BUFLEN minus whatever else we expect to be printed in the same print 
call.  We might guess as low as 1024?

(Retaining one st->print() also minimises any risk of concurrent prints 
jumbling up the output.)

Thanks
Kevin


On 21/03/2016 21:24, David Holmes wrote:
> On 22/03/2016 2:31 AM, Daniel D. Daugherty wrote:
>> On 3/21/16 2:39 AM, Dmitry Samersoff wrote:
>>> David,
>>>
>>>> I still see %.Ns as the simplest solution - but whatever.
>>> It spreads artificial limitation of thread name length across hotspot
>>> sources.
>>>
>>> Brief grepping[1] shows couple of other places with the same problem 
>>> and
>>> if some days we decide to change default O_BUFLEN, we have to not 
>>> forget
>>> to change .N value in couple of places as well.
>>
>> There should be a way to pass the precision value as a parameter instead
>> of hardcoding it in the format string. Something like:
>>
>>      sprintf("%.*s", precision_value, string);
>
> Yes the length limit can be passed as a variable. But I think Dmitry 
> just wants to allow for unlimited lengths. Not sure how to achieve 
> that at the lowest level though as we need to avoid complex 
> allocations etc in these print routines.
>
> David
>
>
>> Dan
>>
>>>
>>> 1.
>>> ./share/vm/prims/jni.cpp
>>> 673: "in thread \"%s\" ", thread->get_thread_name());
>>>
>>> ./share/vm/runtime/thread.cpp
>>> 1766: get_thread_profiler()->print(get_thread_name());
>>> 1974: get_thread_profiler()->print(get_thread_name());
>>> 2896: st->print("\"%s\" ", get_thread_name());
>>> 2926: st->print("%s", get_thread_name_string(buf, buflen));
>>> 2932: st->print("JavaThread \"%s\"", get_thread_name_string(buf,
>>> buflen));
>>>
>>>
>>> ./share/vm/services/threadService.cpp
>>> 882: ... st->print_cr("\"%s\":", currentThread->get_thread_name());
>>> 919: ..."%s \"%s\"", owner_desc, currentThread->get_thread_name());
>>> 932: ... st->print_cr("\"%s\":", currentThread->get_thread_name());
>>>
>>> -Dmitry
>>>
>>>
>>> On 2016-03-19 00:37, David Holmes wrote:
>>>>
>>>> On 18/03/2016 11:28 PM, Dmitry Samersoff wrote:
>>>>> David,
>>>>>
>>>>>> Ignoring Dmitry's issue it still seems simpler/cleaner to just 
>>>>>> add the
>>>>>> desired precision value to the %s than to split into two print
>>>>>> statements. Or bite the bullet now and make the length immaterial by
>>>>>> breaking the name into chunks. It's as easy to fix as to write the
>>>>>> RFE :)
>>>>> For this particular case the simplest solution is to use print_raw:
>>>>>
>>>>> print_raw("\""\"); print_raw(get_thread_name()); print_raw("\""\");
>>>> I still see %.Ns as the simplest solution - but whatever.
>>>>
>>>>> But as soon as print() finally ends up with:
>>>>>
>>>>> const int written = vsnprintf(buffer, buflen, format, ap);
>>>>> ...
>>>>> DEBUG_ONLY(warning("increase O_BUFLEN in ostream.hpp -- output
>>>>> truncated");)
>>>>>
>>>>> Complete fix should be something like:
>>>>>
>>>>> int desired_size = vsnprintf(NULL, 0, format, ap);
>>>>> if (desired_size > O_BUFLEN) {
>>>>>       malloc
>>>>>       ....
>>>>> }
>>>>>
>>>>> but it has performance penalty, so we should use some tricks to cover
>>>>> most common %s/%d/%p cases.
>>>> So you want to remove the internal limitation instead of have the
>>>> clients deal with it? Not sure it is worth the effort - IIRC that code
>>>> can be used at sensitive times hence the simple approach to buffer
>>>> management.
>>>>
>>>> David
>>>>
>>>>> -Dmitry
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 2016-03-18 15:51, David Holmes wrote:
>>>>>> On 18/03/2016 10:03 PM, Cheleswer Sahu wrote:
>>>>>>> Hi David,
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: David Holmes
>>>>>>> Sent: Friday, March 18, 2016 2:42 PM
>>>>>>> To: Cheleswer Sahu; hotspot-runtime-dev at openjdk.java.net;
>>>>>>> serviceability-dev at openjdk.java.net
>>>>>>> Subject: Re: RFR[9u-dev]: 8151442: jstack doesn't close quotation
>>>>>>> marks properly with threads' name greater than 1996 characters
>>>>>>>
>>>>>>> On 18/03/2016 5:54 PM, Cheleswer Sahu wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> Please review the code changes for
>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8151442.
>>>>>>>>
>>>>>>>> Webrev Link: http://cr.openjdk.java.net/~csahu/8151442/
>>>>>>>>
>>>>>>>> Bug Brief:
>>>>>>>>
>>>>>>>> In jstack thread dumps , thread name greater than 1996 characters
>>>>>>>> doesn't close quotation marks properly.
>>>>>>> Anyone giving a thread a name that long deserves to get a core 
>>>>>>> dump!
>>>>>>> ;-)
>>>>>>>
>>>>>>>> Problem Identified:
>>>>>>>>
>>>>>>>> Jstack is using below code to print thread name
>>>>>>>>
>>>>>>>> src/share/vm/runtime/thread.cpp
>>>>>>>>
>>>>>>>> void JavaThread::print_on(outputStream *st) const {
>>>>>>>>
>>>>>>>>       st->print("\"%s\" ", get_thread_name());
>>>>>>>>
>>>>>>>> Here "st->print()"  internally uses max buffer length as O_BUFLEN
>>>>>>>> (2000).
>>>>>>>>
>>>>>>>> void
>>>>>>>> outputStream::do_vsnprintf_and_write_with_automatic_buffer(const
>>>>>>>> char* format, va_list ap, bool add_cr) {
>>>>>>>>
>>>>>>>>       char buffer[O_BUFLEN];
>>>>>>>>
>>>>>>>> do_vsnprintf_and_write_with_automatic_buffer() finally calls
>>>>>>>>      "vsnprintf()"  which truncates the anything greater than the
>>>>>>>> max
>>>>>>>> size(2000). In this case thread's name(> 1996) along with 
>>>>>>>> quotation
>>>>>>>> marks (2)
>>>>>>>>
>>>>>>>> plus one terminating character exceeds the  max buffer size 
>>>>>>>> (2000),
>>>>>>>> therefore the closing quotation  marks gets truncated.
>>>>>>>>
>>>>>>>> Solution:
>>>>>>>>
>>>>>>>> Split the  "st->print("\"%s\" ", get_thread_name())" in two
>>>>>>>> statements
>>>>>>>>
>>>>>>>> 1.st->print("\"%s", get_thread_name());
>>>>>>>>
>>>>>>>> 2.st->print("\" ");
>>>>>>>>
>>>>>>>> This will ensure presence of closing quotation mark always.
>>>>>>> Can't we just limit the number of characters read by %s?
>>>>>>>
>>>>>>> Yes we can do it, but just one thing which I think of is, if the
>>>>>>> truncation of output inside  output stream issue get resolves as
>>>>>>> Dmritry suggested or O_BUFFLEN size gets increased in any  
>>>>>>> future fix
>>>>>>> then we have to again make changes in this code, as limiting the 
>>>>>>> no.
>>>>>>> of character read by %s will give truncated output . In such case
>>>>>>> present fix will have no effect.
>>>>>> Ignoring Dmitry's issue it still seems simpler/cleaner to just 
>>>>>> add the
>>>>>> desired precision value to the %s than to split into two print
>>>>>> statements. Or bite the bullet now and make the length immaterial by
>>>>>> breaking the name into chunks. It's as easy to fix as to write the
>>>>>> RFE :)
>>>>>>
>>>>>> David
>>>>>>
>>>>>>> David
>>>>>>>
>>>>>>>> Regards,
>>>>>>>>
>>>>>>>> Cheleswer
>>>>>>>>
>>>>>
>>>
>>


From kim.barrett at oracle.com  Thu Mar 24 20:14:11 2016
From: kim.barrett at oracle.com (Kim Barrett)
Date: Thu, 24 Mar 2016 16:14:11 -0400
Subject: RFR(xs): 8151993: Remove inclusion of inline.hpp in log.hpp (v4)
In-Reply-To: <56F29F19.9030409@oracle.com>
References: <56E952A5.6050708@oracle.com> <56F02283.10908@oracle.com>
	<56F29F19.9030409@oracle.com>
Message-ID: <67967227-F576-42EB-B122-9EB76A61A512@oracle.com>

> On Mar 23, 2016, at 9:50 AM, Robbin Ehn <robbin.ehn at oracle.com> wrote:
> 
> Hi all,
> 
> After more input, this is the current version.
> Please have a look.
> 
> Webrev: http://cr.openjdk.java.net/~rehn/8151993/v4/webrev/
> Incremental: http://cr.openjdk.java.net/~rehn/8151993/v3-v4/

This looks good.


From dmitry.samersoff at oracle.com  Mon Mar 28 18:15:00 2016
From: dmitry.samersoff at oracle.com (Dmitry Samersoff)
Date: Mon, 28 Mar 2016 21:15:00 +0300
Subject: RFR(S) JDK-8150973 Hotspot agent use of sun.boot.class.path needs to
	be updated for Jigsaw
Message-ID: <56F974A4.5080301@oracle.com>

Everybody,

Please review:

http://cr.openjdk.java.net/~dsamersoff/JDK-8150973/webrev.02/

All references to boot class path in SA code is removed.

VirtualMachineImpl.bootClassPath() is the part of
sun.com.jdi.PathSearchingVirtualMachine interface,
cleanup of this interface requires much more efforts,
so I file a separate CR for this work.

src/jdk.hotspot.agent/test/jdi/runsa.sh is part of obsoleted tests,
cleanup of this tests is in progress under a separate CR.


-Dmitry


-- 
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the sources.

From Alan.Bateman at oracle.com  Mon Mar 28 19:28:39 2016
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 28 Mar 2016 20:28:39 +0100
Subject: RFR(S) JDK-8150973 Hotspot agent use of sun.boot.class.path needs
	to be updated for Jigsaw
In-Reply-To: <56F974A4.5080301@oracle.com>
References: <56F974A4.5080301@oracle.com>
Message-ID: <56F985E7.1030309@oracle.com>



On 28/03/2016 19:15, Dmitry Samersoff wrote:
> Everybody,
>
> Please review:
>
> http://cr.openjdk.java.net/~dsamersoff/JDK-8150973/webrev.02/
>
> All references to boot class path in SA code is removed.
>
> VirtualMachineImpl.bootClassPath() is the part of
> sun.com.jdi.PathSearchingVirtualMachine interface,
> cleanup of this interface requires much more efforts,
> so I file a separate CR for this work.
>
> src/jdk.hotspot.agent/test/jdi/runsa.sh is part of obsoleted tests,
> cleanup of this tests is in progress under a separate CR.
>
Shouldn't VirtualMachineImpl.bootClassPath return emptyList() rather 
than throw an implementation specific exception?

-Alan

From dmitry.samersoff at oracle.com  Mon Mar 28 19:35:00 2016
From: dmitry.samersoff at oracle.com (Dmitry Samersoff)
Date: Mon, 28 Mar 2016 22:35:00 +0300
Subject: RFR(S) JDK-8150973 Hotspot agent use of sun.boot.class.path needs
	to be updated for Jigsaw
In-Reply-To: <56F985E7.1030309@oracle.com>
References: <56F974A4.5080301@oracle.com> <56F985E7.1030309@oracle.com>
Message-ID: <56F98764.6080108@oracle.com>

Alan,

> Shouldn't VirtualMachineImpl.bootClassPath return emptyList() rather
> than throw an implementation specific exception?

This function never used anymore. So I would prefer an exception to make
any attempt to call it fails immediately.

Would RuntimeException better?

-Dmitry

On 2016-03-28 22:28, Alan Bateman wrote:
> 
> 
> On 28/03/2016 19:15, Dmitry Samersoff wrote:
>> Everybody,
>>
>> Please review:
>>
>> http://cr.openjdk.java.net/~dsamersoff/JDK-8150973/webrev.02/
>>
>> All references to boot class path in SA code is removed.
>>
>> VirtualMachineImpl.bootClassPath() is the part of
>> sun.com.jdi.PathSearchingVirtualMachine interface,
>> cleanup of this interface requires much more efforts,
>> so I file a separate CR for this work.
>>
>> src/jdk.hotspot.agent/test/jdi/runsa.sh is part of obsoleted tests,
>> cleanup of this tests is in progress under a separate CR.
>>
> Shouldn't VirtualMachineImpl.bootClassPath return emptyList() rather
> than throw an implementation specific exception?
> 
> -Alan


-- 
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the sources.

From Alan.Bateman at oracle.com  Mon Mar 28 19:45:40 2016
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 28 Mar 2016 20:45:40 +0100
Subject: RFR(S) JDK-8150973 Hotspot agent use of sun.boot.class.path needs
	to be updated for Jigsaw
In-Reply-To: <56F98764.6080108@oracle.com>
References: <56F974A4.5080301@oracle.com> <56F985E7.1030309@oracle.com>
	<56F98764.6080108@oracle.com>
Message-ID: <56F989E4.1000406@oracle.com>



On 28/03/2016 20:35, Dmitry Samersoff wrote:
> Alan,
>
>> Shouldn't VirtualMachineImpl.bootClassPath return emptyList() rather
>> than throw an implementation specific exception?
> This function never used anymore. So I would prefer an exception to make
> any attempt to call it fails immediately.
>
> Would RuntimeException better?
>
The SA implementation implements com.sun.jdi.PathSearchingVirtualMachine 
and this method does not define any exceptions. Returning an empty List 
should be fine.

-Alan.

From dmitry.samersoff at oracle.com  Mon Mar 28 19:46:54 2016
From: dmitry.samersoff at oracle.com (Dmitry Samersoff)
Date: Mon, 28 Mar 2016 22:46:54 +0300
Subject: RFR(S) JDK-8150973 Hotspot agent use of sun.boot.class.path needs
	to be updated for Jigsaw
In-Reply-To: <56F989E4.1000406@oracle.com>
References: <56F974A4.5080301@oracle.com> <56F985E7.1030309@oracle.com>
	<56F98764.6080108@oracle.com> <56F989E4.1000406@oracle.com>
Message-ID: <56F98A2E.3020609@oracle.com>

Alan,

>  Returning an empty List should be fine.

OK. I'll change it.

-Dmitry

On 2016-03-28 22:45, Alan Bateman wrote:
> 
> 
> On 28/03/2016 20:35, Dmitry Samersoff wrote:
>> Alan,
>>
>>> Shouldn't VirtualMachineImpl.bootClassPath return emptyList() rather
>>> than throw an implementation specific exception?
>> This function never used anymore. So I would prefer an exception to make
>> any attempt to call it fails immediately.
>>
>> Would RuntimeException better?
>>
> The SA implementation implements com.sun.jdi.PathSearchingVirtualMachine
> and this method does not define any exceptions. Returning an empty List
> should be fine.
> 
> -Alan.


-- 
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the sources.

From serguei.spitsyn at oracle.com  Mon Mar 28 20:54:46 2016
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Mon, 28 Mar 2016 13:54:46 -0700
Subject: RFR(S) JDK-8150973 Hotspot agent use of sun.boot.class.path needs
	to be updated for Jigsaw
In-Reply-To: <56F974A4.5080301@oracle.com>
References: <56F974A4.5080301@oracle.com>
Message-ID: <56F99A16.5070405@oracle.com>

Hi Dmitry,

This bug is for Jigsaw M4.
Should it be fixed in the Jigsaw repository then?
My understanding is that the M4 will be integrated into the jdk9-dev the 
same was as it was for M3.

Thanks,
Serguei


On 3/28/16 11:15, Dmitry Samersoff wrote:
> Everybody,
>
> Please review:
>
> http://cr.openjdk.java.net/~dsamersoff/JDK-8150973/webrev.02/
>
> All references to boot class path in SA code is removed.
>
> VirtualMachineImpl.bootClassPath() is the part of
> sun.com.jdi.PathSearchingVirtualMachine interface,
> cleanup of this interface requires much more efforts,
> so I file a separate CR for this work.
>
> src/jdk.hotspot.agent/test/jdi/runsa.sh is part of obsoleted tests,
> cleanup of this tests is in progress under a separate CR.
>
>
> -Dmitry
>
>


From mandy.chung at oracle.com  Mon Mar 28 21:08:51 2016
From: mandy.chung at oracle.com (Mandy Chung)
Date: Mon, 28 Mar 2016 14:08:51 -0700
Subject: RFR(S) JDK-8150973 Hotspot agent use of sun.boot.class.path needs
	to be updated for Jigsaw
In-Reply-To: <56F99A16.5070405@oracle.com>
References: <56F974A4.5080301@oracle.com> <56F99A16.5070405@oracle.com>
Message-ID: <2C5825C4-E8E4-486C-8B23-E00E77D14385@oracle.com>

This fix can go in jdk9/dev as the module system has already been integrated in jdk9.  It doesn?t depend on anything in jigsaw/jake.

Mandy

> On Mar 28, 2016, at 1:54 PM, serguei.spitsyn at oracle.com wrote:
> 
> Hi Dmitry,
> 
> This bug is for Jigsaw M4.
> Should it be fixed in the Jigsaw repository then?
> My understanding is that the M4 will be integrated into the jdk9-dev the same was as it was for M3.
> 
> Thanks,
> Serguei
> 
> 
> On 3/28/16 11:15, Dmitry Samersoff wrote:
>> Everybody,
>> 
>> Please review:
>> 
>> http://cr.openjdk.java.net/~dsamersoff/JDK-8150973/webrev.02/
>> 
>> All references to boot class path in SA code is removed.
>> 
>> VirtualMachineImpl.bootClassPath() is the part of
>> sun.com.jdi.PathSearchingVirtualMachine interface,
>> cleanup of this interface requires much more efforts,
>> so I file a separate CR for this work.
>> 
>> src/jdk.hotspot.agent/test/jdi/runsa.sh is part of obsoleted tests,
>> cleanup of this tests is in progress under a separate CR.
>> 
>> 
>> -Dmitry
>> 
>> 
> 


From serguei.spitsyn at oracle.com  Mon Mar 28 21:17:05 2016
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Mon, 28 Mar 2016 14:17:05 -0700
Subject: RFR(S) JDK-8150973 Hotspot agent use of sun.boot.class.path needs
	to be updated for Jigsaw
In-Reply-To: <2C5825C4-E8E4-486C-8B23-E00E77D14385@oracle.com>
References: <56F974A4.5080301@oracle.com> <56F99A16.5070405@oracle.com>
	<2C5825C4-E8E4-486C-8B23-E00E77D14385@oracle.com>
Message-ID: <56F99F51.1010906@oracle.com>

Ok, thanks!
Serguei

On 3/28/16 14:08, Mandy Chung wrote:
> This fix can go in jdk9/dev as the module system has already been integrated in jdk9.  It doesn?t depend on anything in jigsaw/jake.
>
> Mandy
>
>> On Mar 28, 2016, at 1:54 PM, serguei.spitsyn at oracle.com wrote:
>>
>> Hi Dmitry,
>>
>> This bug is for Jigsaw M4.
>> Should it be fixed in the Jigsaw repository then?
>> My understanding is that the M4 will be integrated into the jdk9-dev the same was as it was for M3.
>>
>> Thanks,
>> Serguei
>>
>>
>> On 3/28/16 11:15, Dmitry Samersoff wrote:
>>> Everybody,
>>>
>>> Please review:
>>>
>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8150973/webrev.02/
>>>
>>> All references to boot class path in SA code is removed.
>>>
>>> VirtualMachineImpl.bootClassPath() is the part of
>>> sun.com.jdi.PathSearchingVirtualMachine interface,
>>> cleanup of this interface requires much more efforts,
>>> so I file a separate CR for this work.
>>>
>>> src/jdk.hotspot.agent/test/jdi/runsa.sh is part of obsoleted tests,
>>> cleanup of this tests is in progress under a separate CR.
>>>
>>>
>>> -Dmitry
>>>
>>>


From robbin.ehn at oracle.com  Tue Mar 29 07:22:37 2016
From: robbin.ehn at oracle.com (Robbin Ehn)
Date: Tue, 29 Mar 2016 09:22:37 +0200
Subject: RFR(xs): 8151993: Remove inclusion of inline.hpp in log.hpp (v4)
In-Reply-To: <67967227-F576-42EB-B122-9EB76A61A512@oracle.com>
References: <56E952A5.6050708@oracle.com> <56F02283.10908@oracle.com>
	<56F29F19.9030409@oracle.com>
	<67967227-F576-42EB-B122-9EB76A61A512@oracle.com>
Message-ID: <56FA2D3D.4050505@oracle.com>

Thanks Kim!

/Robbin

On 03/24/2016 09:14 PM, Kim Barrett wrote:
>> On Mar 23, 2016, at 9:50 AM, Robbin Ehn <robbin.ehn at oracle.com> wrote:
>>
>> Hi all,
>>
>> After more input, this is the current version.
>> Please have a look.
>>
>> Webrev: http://cr.openjdk.java.net/~rehn/8151993/v4/webrev/
>> Incremental: http://cr.openjdk.java.net/~rehn/8151993/v3-v4/
>
> This looks good.
>

From marcus.larsson at oracle.com  Tue Mar 29 07:32:46 2016
From: marcus.larsson at oracle.com (Marcus Larsson)
Date: Tue, 29 Mar 2016 09:32:46 +0200
Subject: RFR: 8151438: UL instantiates duplicate tag sets
In-Reply-To: <56F2EFA9.1070504@oracle.com>
References: <56F2609E.7090201@oracle.com> <56F26940.5040005@oracle.com>
	<56F276F9.4010202@oracle.com> <56F2EFA9.1070504@oracle.com>
Message-ID: <56FA2F9E.6030608@oracle.com>

Thanks for reviewing, Stefan!


On 03/23/2016 08:34 PM, Stefan Karlsson wrote:
> Hi Marcus,
>
> On 23/03/16 11:59, Marcus Larsson wrote:
>> Hi Stefan,
>>
>> On 03/23/2016 11:00 AM, Stefan Karlsson wrote:
>>> Hi Marcus,
>>>
>>> On 2016-03-23 10:23, Marcus Larsson wrote:
>>>> Hi,
>>>>
>>>> Please review the following patch to fix the issue where duplicate 
>>>> tagsets are created for the same logical tagset.
>>>>
>>>> The code that emulates the variadic template arguments assumes that 
>>>> _NO_TAG terminates the sequence of tags. If other tags (other than 
>>>> _NO_TAG) follow a terminating tag, template instances that are 
>>>> otherwise considered equal (since they share tags up until the 
>>>> terminating tag), might not be considered equal in the template 
>>>> sense (one of the template arguments can differ). This would cause 
>>>> another template instantiation for the same logical tagset and we 
>>>> end up with logical duplicates.
>>>>
>>>> The if-statement to append the 'start' tag in 
>>>> GCTraceTimeImpl::log_start() caused such problematic template 
>>>> instantiations, so any tagset used with GCTraceTime would be 
>>>> duplicated. To fix this, the template instantiation has been forced 
>>>> to only be made once, ensuring no real tag follows the first 
>>>> _NO_TAG by using the ternary operator.
>>>>
>>>> This patch also includes a test checking for invalid tagsets like 
>>>> these, and also checks for tagsets that are just permutations of 
>>>> other tagsets. Such tagsets should be avoided to prevent confusion, 
>>>> and to reduce overhead. (The test exposed one case where a 
>>>> different permutation was used, so I've fixed that as well.)
>>>>
>>>> Webrev:
>>>> http://cr.openjdk.java.net/~mlarsson/8151438
>>>
>>> The change looks good. I have a couple of comments about the test:
>>>
>>> http://cr.openjdk.java.net/~mlarsson/8151438/webrev.00/src/share/vm/logging/log.cpp.frames.html 
>>>
>>>
>>> 191 char other_name[512];
>>> 192 other->label(other_name, sizeof(other_name), ",");
>>> 193 // Since tagsets are implemented using template arguments, using 
>>> both of
>>> 194 // the (logically equivalent) tagsets (t1, t2) and (t2, t1) 
>>> somewhere will
>>> 195 // instantiate two different LogTagSetMappings. This causes 
>>> multiple
>>> 196 // tagset instances to be created for the same logical set. We 
>>> want to
>>> 197 // avoid this to save time, memory and prevent any confusion 
>>> around it.
>>> 198 assert(!equal, "duplicate LogTagSets found: '%s' vs '%s' "
>>> 199 "(tags must always be specified in the same order for each 
>>> tagset)",
>>> 200 ts_name, other_name);
>>>
>>>
>>> It might be good to check if (!equals) before setting up the 
>>> other_name. Maybe:
>>>
>>> if (!equals) {
>>>   char other_name[512];
>>>   other->label(other_name, sizeof(other_name), ",");
>>>   assert(!equals /* or just false */, ...);
>>> }
>>>
>>
>> Fixed.
>>
>>>
>>> http://cr.openjdk.java.net/~mlarsson/8151438/webrev.00/src/share/vm/utilities/internalVMTests.cpp.frames.html 
>>>
>>>
>>> The test for the logging framework doesn't have a good prefix:
>>>
>>>   70   run_unit_test(Test_log_length);
>>>   71   run_unit_test(Test_configure_stdout);
>>>   72   run_unit_test(Test_logconfiguration_subscribe);
>>>    73 run_unit_test(Test_tagset_duplicates);
>>>
>>> I think we should clean this up (in another RFE) by naming these 
>>> functions similar to the other test functions:
>>>
>>>   70   run_unit_test(TestLogLength_test);
>>>   71   run_unit_test(TestLogConfigureStdout_test);
>>>   72   run_unit_test(TestLogConfigurationSubscribe_test);
>>>    73 run_unit_test(TestLogTagSetDuplicates_test);
>>>
>>> I understand that there are some inconsistent names in the test 
>>> list, but I think we should start by fixing the names for the 
>>> logging tests.
>>
>> I agree. Although I would like these tests to be ported to the unit 
>> test framework once that's been integrated. It will allow better 
>> organization and grouping of tests. Perhaps we should leave it as is 
>> until then?
>
> Sounds like an OK plan to me.
>
>>
>> For now, I renamed the test to Test_logtagset_duplicates instead of 
>> Test_tagset_duplicates to better indicate that it's a logging test.
>
> OK.
>
>>
>> New webrev:
>> http://cr.openjdk.java.net/~mlarsson/8151438/webrev.01/
>>
>> Incremental:
>> http://cr.openjdk.java.net/~mlarsson/8151438/webrev.00-01/
>
> I now see that I proposed if (!equals) but you did the right thing to 
> use if (equals). :)
>
> Looks good.
>
>>
>> Thanks,
>> Marcus
>>
>>>
>>> Thanks,
>>> StefanK
>>>
>>>>
>>>> Issue:
>>>> https://bugs.openjdk.java.net/browse/JDK-8151438
>>>>
>>>> Testing:
>>>> New internal VM test through RBT.
>>>>
>>>> Thanks,
>>>> Marcus
>>>
>>
>


From dmitry.samersoff at oracle.com  Tue Mar 29 08:15:06 2016
From: dmitry.samersoff at oracle.com (Dmitry Samersoff)
Date: Tue, 29 Mar 2016 11:15:06 +0300
Subject: RFR(S) JDK-8150973 Hotspot agent use of sun.boot.class.path needs
	to be updated for Jigsaw
In-Reply-To: <56F974A4.5080301@oracle.com>
References: <56F974A4.5080301@oracle.com>
Message-ID: <56FA398A.3020001@oracle.com>

Everybody,

http://cr.openjdk.java.net/~dsamersoff/JDK-8150973/webrev.02/

Webrev updated (in-place, press shift-reload).

VirtualMachineImpl.bootClassPath() returns Collections.emptyList()
rather than throw an exception.

-Dmitry


On 2016-03-28 21:15, Dmitry Samersoff wrote:
> Everybody,
> 
> Please review:
> 
> http://cr.openjdk.java.net/~dsamersoff/JDK-8150973/webrev.02/
> 
> All references to boot class path in SA code is removed.
> 
> VirtualMachineImpl.bootClassPath() is the part of
> sun.com.jdi.PathSearchingVirtualMachine interface,
> cleanup of this interface requires much more efforts,
> so I file a separate CR for this work.
> 
> src/jdk.hotspot.agent/test/jdi/runsa.sh is part of obsoleted tests,
> cleanup of this tests is in progress under a separate CR.
> 
> 
> -Dmitry
> 
> 


-- 
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the sources.

From Alan.Bateman at oracle.com  Tue Mar 29 08:21:18 2016
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 29 Mar 2016 09:21:18 +0100
Subject: RFR(S) JDK-8150973 Hotspot agent use of sun.boot.class.path needs
	to be updated for Jigsaw
In-Reply-To: <56FA398A.3020001@oracle.com>
References: <56F974A4.5080301@oracle.com> <56FA398A.3020001@oracle.com>
Message-ID: <56FA3AFE.1070200@oracle.com>



On 29/03/2016 09:15, Dmitry Samersoff wrote:
> Everybody,
>
> http://cr.openjdk.java.net/~dsamersoff/JDK-8150973/webrev.02/
>
> Webrev updated (in-place, press shift-reload).
>
> VirtualMachineImpl.bootClassPath() returns Collections.emptyList()
> rather than throw an exception.
>
>
This looks okay except for the confusing comment "This function is 
required to implement com.sun.jdi.PathSearchingVirtualMachine 
interface". The class implements the interface so I think this comment 
can be removed.

For completeness then you could change the return type to List<String>.

-Alan

From dmitry.samersoff at oracle.com  Tue Mar 29 08:54:50 2016
From: dmitry.samersoff at oracle.com (Dmitry Samersoff)
Date: Tue, 29 Mar 2016 11:54:50 +0300
Subject: RFR(S) JDK-8150973 Hotspot agent use of sun.boot.class.path needs
	to be updated for Jigsaw
In-Reply-To: <56FA3AFE.1070200@oracle.com>
References: <56F974A4.5080301@oracle.com> <56FA398A.3020001@oracle.com>
	<56FA3AFE.1070200@oracle.com>
Message-ID: <56FA42DA.9070001@oracle.com>

Alan,

done (in-place)

http://cr.openjdk.java.net/~dsamersoff/JDK-8150973/webrev.02/

-Dmitry

On 2016-03-29 11:21, Alan Bateman wrote:
> 
> 
> On 29/03/2016 09:15, Dmitry Samersoff wrote:
>> Everybody,
>>
>> http://cr.openjdk.java.net/~dsamersoff/JDK-8150973/webrev.02/
>>
>> Webrev updated (in-place, press shift-reload).
>>
>> VirtualMachineImpl.bootClassPath() returns Collections.emptyList()
>> rather than throw an exception.
>>
>>
> This looks okay except for the confusing comment "This function is
> required to implement com.sun.jdi.PathSearchingVirtualMachine
> interface". The class implements the interface so I think this comment
> can be removed.
> 
> For completeness then you could change the return type to List<String>.
> 
> -Alan


-- 
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the sources.

From Alan.Bateman at oracle.com  Tue Mar 29 09:41:40 2016
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 29 Mar 2016 10:41:40 +0100
Subject: RFR(S) JDK-8150973 Hotspot agent use of sun.boot.class.path needs
	to be updated for Jigsaw
In-Reply-To: <56FA42DA.9070001@oracle.com>
References: <56F974A4.5080301@oracle.com> <56FA398A.3020001@oracle.com>
	<56FA3AFE.1070200@oracle.com> <56FA42DA.9070001@oracle.com>
Message-ID: <56FA4DD4.10506@oracle.com>



On 29/03/2016 09:54, Dmitry Samersoff wrote:
> Alan,
>
> done (in-place)
>
> http://cr.openjdk.java.net/~dsamersoff/JDK-8150973/webrev.02/
>
> -Dmitry
>
>
Looks okay to me. At some point (and nothing to do with this change) is 
that we should add type parameters to the other methods like getPath, 
classPath, etc.

-Alan

From yasuenag at gmail.com  Tue Mar 29 12:02:17 2016
From: yasuenag at gmail.com (Yasumasa Suenaga)
Date: Tue, 29 Mar 2016 21:02:17 +0900
Subject: PING: RFR: JDK-8151815: Could not parse core image with JSnap.
In-Reply-To: <CAGFVN2BkROkQnk5=xX4NaH+f19_YwoW1LzGMxu-1kksYE1BpRQ@mail.gmail.com>
References: <CAGFVN2BkROkQnk5=xX4NaH+f19_YwoW1LzGMxu-1kksYE1BpRQ@mail.gmail.com>
Message-ID: <56FA6EC9.90107@gmail.com>

PING: Could you review it?


Yasumasa


On 2016/03/22 21:24, Yasumasa Suenaga wrote:
> PING: Could you review it?
>
> Yasumasa
>
> 2016/03/14 23:39 "Yasumasa Suenaga" <yasuenag at gmail.com <mailto:yasuenag at gmail.com>>:
>
>     Hi all,
>
>     When I use `jhsdb jsnap` to get PerfCounter from core images, I encountered NPE:
>     -------------
>     Exception in thread "main" java.lang.NullPointerException
>              at sun.jvm.hotspot.tools.JSnap.run(JSnap.java:45)
>              at sun.jvm.hotspot.tools.Tool.startInternal(Tool.java:260)
>              at sun.jvm.hotspot.tools.Tool.start(Tool.java:223)
>              at sun.jvm.hotspot.tools.Tool.execute(Tool.java:118)
>              at sun.jvm.hotspot.tools.JSnap.main(JSnap.java:67)
>              at sun.jvm.hotspot.SALauncher.runJSNAP(SALauncher.java:352)
>              at sun.jvm.hotspot.SALauncher.main(SALauncher.java:404)
>     -------------
>
>     PerfMemory::destroy() clears all members which are used in JSnap.
>     Thus NPE is occurred.
>
>     I uploaded webrev for this issue.
>     Could you review it?
>
>     http://cr.openjdk.java.net/~ysuenaga/JDK-8151815/webrev.00/
>
>     I cannot access JPRT.
>     So I need a Sponsor.
>
>
>     Thanks,
>
>     Yasumasa
>

From yasuenag at gmail.com  Tue Mar 29 12:02:55 2016
From: yasuenag at gmail.com (Yasumasa Suenaga)
Date: Tue, 29 Mar 2016 21:02:55 +0900
Subject: RFR: JDK-8152435: (CL)HSDB should be started with no argument
In-Reply-To: <56F15B6C.3080102@gmail.com>
References: <56F15B6C.3080102@gmail.com>
Message-ID: <56FA6EEF.3080207@gmail.com>

PING: Could you review it?


Yasumasa


On 2016/03/22 23:49, Yasumasa Suenaga wrote:
> HI all,
> 
> After JDK-8151709, CLHSDB and HSDB cannot be started with no argument via jhsdb.
> CLHSDB and HSDB can attach process / core after starting.
> jhsdb should support it.
> 
> I uploaded webrev:
> 
>    http://cr.openjdk.java.net/~ysuenaga/JDK-8152435/webrev.00/
> 
> This patch passed jtreg test sun/tools/jhsdb in jdk repos.
> Could you review it?
> 
> I cannot access JPRT.
> So I need a sponsor.
> 
> 
> Thanks,
> 
> Yasumasa
> 

From marcus.larsson at oracle.com  Wed Mar 30 08:02:55 2016
From: marcus.larsson at oracle.com (Marcus Larsson)
Date: Wed, 30 Mar 2016 10:02:55 +0200
Subject: PING: Re: RFR: 8150823: UL handles disabling logs incorrectly
In-Reply-To: <56F272D2.9070707@oracle.com>
References: <56E2D8ED.3040204@oracle.com> <56EBE5A0.5070806@oracle.com>
	<56F272D2.9070707@oracle.com>
Message-ID: <56FB882F.4070303@oracle.com>

Need a Reviewer for this.

Thanks,
Marcus

On 03/23/2016 11:41 AM, Marcus Larsson wrote:
> On 03/18/2016 12:25 PM, Marcus Larsson wrote:
>> Hi,
>>
>> Updated the patch after offline discussion. New patch attempts to 
>> normalize the output name before searching for it or adding it. This 
>> includes adding the implicit file= prefix if missing, and/or removing 
>> quotes from a quoted name.
>>
>> Webrev:
>> http://cr.openjdk.java.net/~mlarsson/8150823/webrev.01/
>>
>> Incremental:
>> http://cr.openjdk.java.net/~mlarsson/8150823/webrev.00-01/
>>
>> Tested with serviceability/logging tests through RBT.
>>
>> Thanks,
>> Marcus
>>
>> On 03/11/2016 03:40 PM, Marcus Larsson wrote:
>>> Hi,
>>>
>>> Please review the following patch to fix a problem with disabling 
>>> log outputs using -Xlog:disable or disable_logging() when there are 
>>> multiple file outputs configured. The patch also resolves an issue 
>>> with log file lookups that could cause multiple outputs to be 
>>> created for the same log file.
>>>
>>> Log output removal now iterates backwards to not invalidate the loop 
>>> index, and file outputs are always prepended with "file=" during 
>>> lookups and listings.
>>>
>>> Webrev:
>>> http://cr.openjdk.java.net/~mlarsson/8150823/webrev.00/
>>>
>>> Issue:
>>> https://bugs.openjdk.java.net/browse/JDK-8150823
>>>
>>> Testing:
>>> Included tests through RBT
>>>
>>> Thanks,
>>> Marcus
>>
>


From serguei.spitsyn at oracle.com  Wed Mar 30 08:28:37 2016
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Wed, 30 Mar 2016 01:28:37 -0700
Subject: RFR(S) JDK-8150973 Hotspot agent use of sun.boot.class.path needs
	to be updated for Jigsaw
In-Reply-To: <56FA4DD4.10506@oracle.com>
References: <56F974A4.5080301@oracle.com> <56FA398A.3020001@oracle.com>
	<56FA3AFE.1070200@oracle.com> <56FA42DA.9070001@oracle.com>
	<56FA4DD4.10506@oracle.com>
Message-ID: <56FB8E35.6040505@oracle.com>

Hi Dmitry,

Looks good in general.

The following files in the jdk.hotspot.agent/test folder may need to be 
updated too:
   src/jdk.hotspot.agent/test/jdi/runjdb.sh
   src/jdk.hotspot.agent/test/jdi/runsa.sh

Thanks,
Serguei


On 3/29/16 02:41, Alan Bateman wrote:
>
>
> On 29/03/2016 09:54, Dmitry Samersoff wrote:
>> Alan,
>>
>> done (in-place)
>>
>> http://cr.openjdk.java.net/~dsamersoff/JDK-8150973/webrev.02/
>>
>> -Dmitry
>>
>>
> Looks okay to me. At some point (and nothing to do with this change) 
> is that we should add type parameters to the other methods like 
> getPath, classPath, etc.
>
> -Alan


From dmitry.samersoff at oracle.com  Wed Mar 30 08:50:34 2016
From: dmitry.samersoff at oracle.com (Dmitry Samersoff)
Date: Wed, 30 Mar 2016 11:50:34 +0300
Subject: RFR(S) JDK-8150973 Hotspot agent use of sun.boot.class.path needs
	to be updated for Jigsaw
In-Reply-To: <56FB8E35.6040505@oracle.com>
References: <56F974A4.5080301@oracle.com> <56FA398A.3020001@oracle.com>
	<56FA3AFE.1070200@oracle.com> <56FA42DA.9070001@oracle.com>
	<56FA4DD4.10506@oracle.com> <56FB8E35.6040505@oracle.com>
Message-ID: <56FB935A.6000600@oracle.com>

Serguei,

Thank you for review!

These tests are not part of any testing process. I plan to review and
fix/delete it as necessary under a separate CR (JDK-8146200)

-Dmitry

On 2016-03-30 11:28, serguei.spitsyn at oracle.com wrote:
> Hi Dmitry,
> 
> Looks good in general.
> 
> The following files in the jdk.hotspot.agent/test folder may need to be
> updated too:
>   src/jdk.hotspot.agent/test/jdi/runjdb.sh
>   src/jdk.hotspot.agent/test/jdi/runsa.sh
> 
> Thanks,
> Serguei
> 
> 
> On 3/29/16 02:41, Alan Bateman wrote:
>>
>>
>> On 29/03/2016 09:54, Dmitry Samersoff wrote:
>>> Alan,
>>>
>>> done (in-place)
>>>
>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8150973/webrev.02/
>>>
>>> -Dmitry
>>>
>>>
>> Looks okay to me. At some point (and nothing to do with this change)
>> is that we should add type parameters to the other methods like
>> getPath, classPath, etc.
>>
>> -Alan
> 


-- 
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the sources.

From serguei.spitsyn at oracle.com  Wed Mar 30 09:09:52 2016
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Wed, 30 Mar 2016 02:09:52 -0700
Subject: RFR(S) JDK-8150973 Hotspot agent use of sun.boot.class.path needs
	to be updated for Jigsaw
In-Reply-To: <56FB935A.6000600@oracle.com>
References: <56F974A4.5080301@oracle.com> <56FA398A.3020001@oracle.com>
	<56FA3AFE.1070200@oracle.com> <56FA42DA.9070001@oracle.com>
	<56FA4DD4.10506@oracle.com> <56FB8E35.6040505@oracle.com>
	<56FB935A.6000600@oracle.com>
Message-ID: <56FB97E0.7030507@oracle.com>

On 3/30/16 01:50, Dmitry Samersoff wrote:
> Serguei,
>
> Thank you for review!
>
> These tests are not part of any testing process. I plan to review and
> fix/delete it as necessary under a separate CR (JDK-8146200)

Ok, reviewed.


Thanks,
Serguei


>
> -Dmitry
>
> On 2016-03-30 11:28, serguei.spitsyn at oracle.com wrote:
>> Hi Dmitry,
>>
>> Looks good in general.
>>
>> The following files in the jdk.hotspot.agent/test folder may need to be
>> updated too:
>>    src/jdk.hotspot.agent/test/jdi/runjdb.sh
>>    src/jdk.hotspot.agent/test/jdi/runsa.sh
>>
>> Thanks,
>> Serguei
>>
>>
>> On 3/29/16 02:41, Alan Bateman wrote:
>>>
>>> On 29/03/2016 09:54, Dmitry Samersoff wrote:
>>>> Alan,
>>>>
>>>> done (in-place)
>>>>
>>>> http://cr.openjdk.java.net/~dsamersoff/JDK-8150973/webrev.02/
>>>>
>>>> -Dmitry
>>>>
>>>>
>>> Looks okay to me. At some point (and nothing to do with this change)
>>> is that we should add type parameters to the other methods like
>>> getPath, classPath, etc.
>>>
>>> -Alan
>


From thomas.schatzl at oracle.com  Wed Mar 30 09:37:40 2016
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Wed, 30 Mar 2016 11:37:40 +0200
Subject: RFR: JDK-8151674: STW phases at Concurrent GC should count in
	PerfCounter
In-Reply-To: <56EC5AE4.4080909@oracle.com>
References: <56E242B5.1070206@gmail.com> <56E9A230.1060607@oracle.com>
	<CAGFVN2ATsvSfyzc-_AzBRXcUJMShENHog6XinvgyJiZBUMTXgQ@mail.gmail.com>
	<56EC0D54.3090907@gmail.com> <56EC5AE4.4080909@oracle.com>
Message-ID: <1459330660.2284.35.camel@oracle.com>

Hi,

On Fri, 2016-03-18 at 12:45 -0700, Jon Masamitsu wrote:
> 
> On 3/18/2016 7:14 AM, Yasumasa Suenaga wrote:
> > Hi,
> > 
> > > I added a comment to JBS about G1 initial mark.
> > > I will upload new webrev after discussing for it.
> > 
> > We discussed about it on JBS, and we decided not to count initial
> > mark 
> > on G1
> > to CGC counter. [1]
> > 
> > I uploaded new webrev. Could you review it?
> 
> Changes look good.   We'll need one more review of the hotspot
> changes.

  Hotspot changes look good.

Thomas

From marcus.larsson at oracle.com  Wed Mar 30 14:17:05 2016
From: marcus.larsson at oracle.com (Marcus Larsson)
Date: Wed, 30 Mar 2016 16:17:05 +0200
Subject: RFR: 8146879: Add option for handling existing log files in UL
In-Reply-To: <EBB590DE-C820-4D4C-9D0E-D1096B09BF54@oracle.com>
References: <5697B7F2.50104@oracle.com> <56D578F9.6090602@oracle.com>
	<56D5A1BB.6030403@oracle.com> <56E2D478.3090202@oracle.com>
	<56EBFCCC.1080701@oracle.com>
	<EBB590DE-C820-4D4C-9D0E-D1096B09BF54@oracle.com>
Message-ID: <56FBDFE1.9040202@oracle.com>

Hi Gerard,

On 03/22/2016 07:15 PM, Gerard Ziemski wrote:
> hi Marcus,
>
> Thank you for incorporating the feedback.
>
> The only remaining comment I have is about the ?number_of_lines_with_substring_in_file()? function. As written, it resets the entire algorithm to the beginning of the file when it can not fit the current line, when I think the intention should be only to rewind only to the beginning of that line.
>
> May I suggest the following implementation instead:
>
> static size_t number_of_lines_with_substring_in_file(const char* filename,
>                                                           const char* substr) {
>   ResourceMark rm;
>   size_t ret = 0;
>   FILE* fp = fopen(filename, "r");
>   assert(fp, "error opening file %s: %s", filename, strerror(errno));
>
>   int buflen = 512;
>   char* buf = NEW_RESOURCE_ARRAY(char, buflen);
>   long int pos = 0;
>
>   while (fgets(buf, buflen, fp) != NULL) {
>     if (buf[strlen(buf) - 1] != '\n') {
>       // rewind to the beginning of the line
>       fseek(fp, pos, SEEK_SET);
>       // double the buffer size and try again
>       buf = REALLOC_RESOURCE_ARRAY(char, buf, buflen, 2*buflen);
>       buflen *= 2;
>     } else {
>       // get current file position
>       pos = ftell(fp);
>
>       if (strstr(buf, substr) != NULL) {
>         ret++;
>       }
>     }
>   }
>
>   fclose(fp);
>   return ret;
> }

Alright, fixed.

New webrev:
http://cr.openjdk.java.net/~mlarsson/8146879/webrev.05/

Incremental:
http://cr.openjdk.java.net/~mlarsson/8146879/webrev.04-05/

Also fixed some failing tests caused by this patch in the previous round 
of changes.

Thanks,
Marcus

>
> cheers
>
>
>> On Mar 18, 2016, at 8:04 AM, Marcus Larsson <marcus.larsson at oracle.com> wrote:
>>
>> Updated patch after feedback.
>>
>> New webrev:
>> http://cr.openjdk.java.net/~mlarsson/8146879/webrev.04/
>>
>> Incremental:
>> http://cr.openjdk.java.net/~mlarsson/8146879/webrev.03-04/
>>
>> Tested with internal VM tests through RBT.
>>
>> Changes:
>> * Rotation filecount is now limited to 1000 files.
>> * Removed loop in os::compare_file_modified_times.
>> * Added a check before rotating/truncating an existing log file, and will only do so if it's a regular file.
>> * Added test case to check that logging to a directory gives the intended error message.
>> * Fixed test help method to handle arbitrary length log lines.
>>
>> Thanks,
>> Marcus
>>
>> On 03/11/2016 03:21 PM, Marcus Larsson wrote:
>>> Third time's the charm.
>>>
>>> Webrev:
>>> http://cr.openjdk.java.net/~mlarsson/8146879/webrev.03/
>>>
>>> This patch makes log file rotation the default. Default thresholds are 5 rotated files with a target size of 20MiB. Truncating behavior can be achieved by setting filecount to 0 (-Xlog::myfile.log::filecount=0).
>>>
>>> If a log file already exists during log file initialization it will be rotated. If any of the target file names (file.0 to file.4 in the default case) are available, that filename will be used for the existing log. If all names are taken the VM will attempt to overwrite the oldest file.
>>>
>>> This should prevent unlimited log file creations and avoid accidental loss of log files from previous runs. The default thresholds (5 files, 20MiB each) is just a suggestion. If you think it should be higher/lower let me know.
>>>
>>> Tested with included internal VM tests through RBT.
>>>
>>> Thanks,
>>> Marcus
>>>
>>> On 2016-03-01 15:05, Marcus Larsson wrote:
>>>> Hi,
>>>>
>>>> After some offline discussions I'm withdrawing this patch. I will instead investigate if I can achieve similar behavior using log rotation as the default.
>>>>
>>>> Thanks,
>>>> Marcus
>>>>
>>>> On 03/01/2016 12:11 PM, Marcus Larsson wrote:
>>>>> Hi again,
>>>>>
>>>>> Taking a different approach to this.
>>>>>
>>>>> New webrev:
>>>>> http://cr.openjdk.java.net/~mlarsson/8146879/webrev.01/
>>>>>
>>>>> Existing files will now by default be renamed/archived with a .X suffix where X is the lowest number such that the resulting file name is available (jvm.log becomes jvm.log.0). A mode option for controlling this behavior has been added as well. It can be set to archive, append, or truncate (i.e. -Xlog::jvm.log::mode=truncate).
>>>>>
>>>>> Tested with included jtreg test through JPRT.
>>>>>
>>>>> Thanks,
>>>>> Marcus
>>>>>
>>>>> On 01/14/2016 04:00 PM, Marcus Larsson wrote:
>>>>>> Hi,
>>>>>>
>>>>>> Please review the following patch to make sure UL truncates existing log files before writing to them. Since files are opened in append mode, truncation isn't done automatically, so instead the patch adds an attempt to remove the log file before opening it.
>>>>>>
>>>>>> Webrev:
>>>>>> http://cr.openjdk.java.net/~mlarsson/8146879/webrev.00/
>>>>>>
>>>>>> Issue:
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8146879
>>>>>>
>>>>>> Testing:
>>>>>> Included test through JPRT
>>>>>>
>>>>>> Thanks,
>>>>>> Marcus


From gerard.ziemski at oracle.com  Wed Mar 30 16:16:29 2016
From: gerard.ziemski at oracle.com (Gerard Ziemski)
Date: Wed, 30 Mar 2016 11:16:29 -0500
Subject: RFR: 8146879: Add option for handling existing log files in UL
In-Reply-To: <56FBDFE1.9040202@oracle.com>
References: <5697B7F2.50104@oracle.com> <56D578F9.6090602@oracle.com>
	<56D5A1BB.6030403@oracle.com> <56E2D478.3090202@oracle.com>
	<56EBFCCC.1080701@oracle.com>
	<EBB590DE-C820-4D4C-9D0E-D1096B09BF54@oracle.com>
	<56FBDFE1.9040202@oracle.com>
Message-ID: <C2EC6E84-C551-41CF-9256-9A3FDA9D1D9C@oracle.com>

Look good.

Thank you for you patience with my review.


cheers

> On Mar 30, 2016, at 9:17 AM, Marcus Larsson <marcus.larsson at oracle.com> wrote:
> 
> Hi Gerard,
> 
> On 03/22/2016 07:15 PM, Gerard Ziemski wrote:
>> hi Marcus,
>> 
>> Thank you for incorporating the feedback.
>> 
>> The only remaining comment I have is about the ?number_of_lines_with_substring_in_file()? function. As written, it resets the entire algorithm to the beginning of the file when it can not fit the current line, when I think the intention should be only to rewind only to the beginning of that line.
>> 
>> May I suggest the following implementation instead:
>> 
>> static size_t number_of_lines_with_substring_in_file(const char* filename,
>>                                                          const char* substr) {
>>  ResourceMark rm;
>>  size_t ret = 0;
>>  FILE* fp = fopen(filename, "r");
>>  assert(fp, "error opening file %s: %s", filename, strerror(errno));
>> 
>>  int buflen = 512;
>>  char* buf = NEW_RESOURCE_ARRAY(char, buflen);
>>  long int pos = 0;
>> 
>>  while (fgets(buf, buflen, fp) != NULL) {
>>    if (buf[strlen(buf) - 1] != '\n') {
>>      // rewind to the beginning of the line
>>      fseek(fp, pos, SEEK_SET);
>>      // double the buffer size and try again
>>      buf = REALLOC_RESOURCE_ARRAY(char, buf, buflen, 2*buflen);
>>      buflen *= 2;
>>    } else {
>>      // get current file position
>>      pos = ftell(fp);
>> 
>>      if (strstr(buf, substr) != NULL) {
>>        ret++;
>>      }
>>    }
>>  }
>> 
>>  fclose(fp);
>>  return ret;
>> }
> 
> Alright, fixed.
> 
> New webrev:
> http://cr.openjdk.java.net/~mlarsson/8146879/webrev.05/
> 
> Incremental:
> http://cr.openjdk.java.net/~mlarsson/8146879/webrev.04-05/
> 
> Also fixed some failing tests caused by this patch in the previous round of changes.
> 
> Thanks,
> Marcus
> 
>> 
>> cheers
>> 
>> 
>>> On Mar 18, 2016, at 8:04 AM, Marcus Larsson <marcus.larsson at oracle.com> wrote:
>>> 
>>> Updated patch after feedback.
>>> 
>>> New webrev:
>>> http://cr.openjdk.java.net/~mlarsson/8146879/webrev.04/
>>> 
>>> Incremental:
>>> http://cr.openjdk.java.net/~mlarsson/8146879/webrev.03-04/
>>> 
>>> Tested with internal VM tests through RBT.
>>> 
>>> Changes:
>>> * Rotation filecount is now limited to 1000 files.
>>> * Removed loop in os::compare_file_modified_times.
>>> * Added a check before rotating/truncating an existing log file, and will only do so if it's a regular file.
>>> * Added test case to check that logging to a directory gives the intended error message.
>>> * Fixed test help method to handle arbitrary length log lines.
>>> 
>>> Thanks,
>>> Marcus
>>> 
>>> On 03/11/2016 03:21 PM, Marcus Larsson wrote:
>>>> Third time's the charm.
>>>> 
>>>> Webrev:
>>>> http://cr.openjdk.java.net/~mlarsson/8146879/webrev.03/
>>>> 
>>>> This patch makes log file rotation the default. Default thresholds are 5 rotated files with a target size of 20MiB. Truncating behavior can be achieved by setting filecount to 0 (-Xlog::myfile.log::filecount=0).
>>>> 
>>>> If a log file already exists during log file initialization it will be rotated. If any of the target file names (file.0 to file.4 in the default case) are available, that filename will be used for the existing log. If all names are taken the VM will attempt to overwrite the oldest file.
>>>> 
>>>> This should prevent unlimited log file creations and avoid accidental loss of log files from previous runs. The default thresholds (5 files, 20MiB each) is just a suggestion. If you think it should be higher/lower let me know.
>>>> 
>>>> Tested with included internal VM tests through RBT.
>>>> 
>>>> Thanks,
>>>> Marcus
>>>> 
>>>> On 2016-03-01 15:05, Marcus Larsson wrote:
>>>>> Hi,
>>>>> 
>>>>> After some offline discussions I'm withdrawing this patch. I will instead investigate if I can achieve similar behavior using log rotation as the default.
>>>>> 
>>>>> Thanks,
>>>>> Marcus
>>>>> 
>>>>> On 03/01/2016 12:11 PM, Marcus Larsson wrote:
>>>>>> Hi again,
>>>>>> 
>>>>>> Taking a different approach to this.
>>>>>> 
>>>>>> New webrev:
>>>>>> http://cr.openjdk.java.net/~mlarsson/8146879/webrev.01/
>>>>>> 
>>>>>> Existing files will now by default be renamed/archived with a .X suffix where X is the lowest number such that the resulting file name is available (jvm.log becomes jvm.log.0). A mode option for controlling this behavior has been added as well. It can be set to archive, append, or truncate (i.e. -Xlog::jvm.log::mode=truncate).
>>>>>> 
>>>>>> Tested with included jtreg test through JPRT.
>>>>>> 
>>>>>> Thanks,
>>>>>> Marcus
>>>>>> 
>>>>>> On 01/14/2016 04:00 PM, Marcus Larsson wrote:
>>>>>>> Hi,
>>>>>>> 
>>>>>>> Please review the following patch to make sure UL truncates existing log files before writing to them. Since files are opened in append mode, truncation isn't done automatically, so instead the patch adds an attempt to remove the log file before opening it.
>>>>>>> 
>>>>>>> Webrev:
>>>>>>> http://cr.openjdk.java.net/~mlarsson/8146879/webrev.00/
>>>>>>> 
>>>>>>> Issue:
>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8146879
>>>>>>> 
>>>>>>> Testing:
>>>>>>> Included test through JPRT
>>>>>>> 
>>>>>>> Thanks,
>>>>>>> Marcus


From mattis.castegren at oracle.com  Wed Mar 30 17:12:02 2016
From: mattis.castegren at oracle.com (Mattis Castegren)
Date: Wed, 30 Mar 2016 10:12:02 -0700 (PDT)
Subject: RFR[9u-dev]: 8151442: jstack doesn't close quotation marks
	properly with threads' name greater than 1996 characters
In-Reply-To: <56F4489D.10107@oracle.com>
References: <556325b3-e8b2-4622-8b59-1df2ef4b1f02@default>
	<56EBC647.6020704@oracle.com>
	<0db522da-1cbe-494a-8aa3-e82ec7b7f5aa@default>
	<56EBF9CC.8000809@oracle.com> <56EC0285.9080004@oracle.com>
	<56EC7506.902@oracle.com> <56EFB351.7010707@oracle.com>
	<56F021EC.4010105@oracle.com> <56F06670.5030802@oracle.com>
	<56F4489D.10107@oracle.com>
Message-ID: <e92069d4-cc45-4ce6-a71a-37798cbde525@default>

Hi

It seems there are two approaches here, either we truncate long thread names, or we make sure to print the full thread name.

I agree with Dmitry and Kirk that if the API allows these long names, the tooling should do the right thing (even though one has to wonder what these long names are).

I suggest we move ahead with the print_raw approach.

If we believe there should be a limit in the Thread name lenghts, I suggest we file a new bug for that.

Kind Regards
/Mattis

-----Original Message-----
From: Kevin Walls 
Sent: den 24 mars 2016 21:06
To: David Holmes; Daniel Daugherty; Dmitry Samersoff; Cheleswer Sahu; hotspot-runtime-dev at openjdk.java.net; serviceability-dev at openjdk.java.net
Subject: Re: RFR[9u-dev]: 8151442: jstack doesn't close quotation marks properly with threads' name greater than 1996 characters


Hi

I didn't think of %.XXXXs when Cheleswer and I discussed this briefly.  
I'd like to have suggested that, with the idea that the 2k long thread name is extreme, and it's so important that we preserve the format of the output, and keep that closing quote, even if we lost some of the thread name.  We currently and probably always have truncated such names, the problem that triggered this was mainly that the format was broken.

As there are several places we pass the name to the stream and could hit the length limit, should we have a THREAD_NAME_FORMAT defined for such use instead of using %s though the actual length can't be 1996, it's BUFLEN minus whatever else we expect to be printed in the same print call.  We might guess as low as 1024?

(Retaining one st->print() also minimises any risk of concurrent prints jumbling up the output.)

Thanks
Kevin


On 21/03/2016 21:24, David Holmes wrote:
> On 22/03/2016 2:31 AM, Daniel D. Daugherty wrote:
>> On 3/21/16 2:39 AM, Dmitry Samersoff wrote:
>>> David,
>>>
>>>> I still see %.Ns as the simplest solution - but whatever.
>>> It spreads artificial limitation of thread name length across 
>>> hotspot sources.
>>>
>>> Brief grepping[1] shows couple of other places with the same problem 
>>> and if some days we decide to change default O_BUFLEN, we have to 
>>> not forget to change .N value in couple of places as well.
>>
>> There should be a way to pass the precision value as a parameter 
>> instead of hardcoding it in the format string. Something like:
>>
>>      sprintf("%.*s", precision_value, string);
>
> Yes the length limit can be passed as a variable. But I think Dmitry 
> just wants to allow for unlimited lengths. Not sure how to achieve 
> that at the lowest level though as we need to avoid complex 
> allocations etc in these print routines.
>
> David
>
>
>> Dan
>>
>>>
>>> 1.
>>> ./share/vm/prims/jni.cpp
>>> 673: "in thread \"%s\" ", thread->get_thread_name());
>>>
>>> ./share/vm/runtime/thread.cpp
>>> 1766: get_thread_profiler()->print(get_thread_name());
>>> 1974: get_thread_profiler()->print(get_thread_name());
>>> 2896: st->print("\"%s\" ", get_thread_name());
>>> 2926: st->print("%s", get_thread_name_string(buf, buflen));
>>> 2932: st->print("JavaThread \"%s\"", get_thread_name_string(buf, 
>>> buflen));
>>>
>>>
>>> ./share/vm/services/threadService.cpp
>>> 882: ... st->print_cr("\"%s\":", currentThread->get_thread_name());
>>> 919: ..."%s \"%s\"", owner_desc, currentThread->get_thread_name());
>>> 932: ... st->print_cr("\"%s\":", currentThread->get_thread_name());
>>>
>>> -Dmitry
>>>
>>>
>>> On 2016-03-19 00:37, David Holmes wrote:
>>>>
>>>> On 18/03/2016 11:28 PM, Dmitry Samersoff wrote:
>>>>> David,
>>>>>
>>>>>> Ignoring Dmitry's issue it still seems simpler/cleaner to just 
>>>>>> add the desired precision value to the %s than to split into two 
>>>>>> print statements. Or bite the bullet now and make the length 
>>>>>> immaterial by breaking the name into chunks. It's as easy to fix 
>>>>>> as to write the RFE :)
>>>>> For this particular case the simplest solution is to use print_raw:
>>>>>
>>>>> print_raw("\""\"); print_raw(get_thread_name()); 
>>>>> print_raw("\""\");
>>>> I still see %.Ns as the simplest solution - but whatever.
>>>>
>>>>> But as soon as print() finally ends up with:
>>>>>
>>>>> const int written = vsnprintf(buffer, buflen, format, ap); ...
>>>>> DEBUG_ONLY(warning("increase O_BUFLEN in ostream.hpp -- output
>>>>> truncated");)
>>>>>
>>>>> Complete fix should be something like:
>>>>>
>>>>> int desired_size = vsnprintf(NULL, 0, format, ap); if 
>>>>> (desired_size > O_BUFLEN) {
>>>>>       malloc
>>>>>       ....
>>>>> }
>>>>>
>>>>> but it has performance penalty, so we should use some tricks to 
>>>>> cover most common %s/%d/%p cases.
>>>> So you want to remove the internal limitation instead of have the 
>>>> clients deal with it? Not sure it is worth the effort - IIRC that 
>>>> code can be used at sensitive times hence the simple approach to 
>>>> buffer management.
>>>>
>>>> David
>>>>
>>>>> -Dmitry
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 2016-03-18 15:51, David Holmes wrote:
>>>>>> On 18/03/2016 10:03 PM, Cheleswer Sahu wrote:
>>>>>>> Hi David,
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: David Holmes
>>>>>>> Sent: Friday, March 18, 2016 2:42 PM
>>>>>>> To: Cheleswer Sahu; hotspot-runtime-dev at openjdk.java.net;
>>>>>>> serviceability-dev at openjdk.java.net
>>>>>>> Subject: Re: RFR[9u-dev]: 8151442: jstack doesn't close 
>>>>>>> quotation marks properly with threads' name greater than 1996 
>>>>>>> characters
>>>>>>>
>>>>>>> On 18/03/2016 5:54 PM, Cheleswer Sahu wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> Please review the code changes for 
>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8151442.
>>>>>>>>
>>>>>>>> Webrev Link: http://cr.openjdk.java.net/~csahu/8151442/
>>>>>>>>
>>>>>>>> Bug Brief:
>>>>>>>>
>>>>>>>> In jstack thread dumps , thread name greater than 1996 
>>>>>>>> characters doesn't close quotation marks properly.
>>>>>>> Anyone giving a thread a name that long deserves to get a core 
>>>>>>> dump!
>>>>>>> ;-)
>>>>>>>
>>>>>>>> Problem Identified:
>>>>>>>>
>>>>>>>> Jstack is using below code to print thread name
>>>>>>>>
>>>>>>>> src/share/vm/runtime/thread.cpp
>>>>>>>>
>>>>>>>> void JavaThread::print_on(outputStream *st) const {
>>>>>>>>
>>>>>>>>       st->print("\"%s\" ", get_thread_name());
>>>>>>>>
>>>>>>>> Here "st->print()"  internally uses max buffer length as 
>>>>>>>> O_BUFLEN (2000).
>>>>>>>>
>>>>>>>> void
>>>>>>>> outputStream::do_vsnprintf_and_write_with_automatic_buffer(cons
>>>>>>>> t
>>>>>>>> char* format, va_list ap, bool add_cr) {
>>>>>>>>
>>>>>>>>       char buffer[O_BUFLEN];
>>>>>>>>
>>>>>>>> do_vsnprintf_and_write_with_automatic_buffer() finally calls
>>>>>>>>      "vsnprintf()"  which truncates the anything greater than 
>>>>>>>> the max size(2000). In this case thread's name(> 1996) along 
>>>>>>>> with quotation marks (2)
>>>>>>>>
>>>>>>>> plus one terminating character exceeds the  max buffer size 
>>>>>>>> (2000), therefore the closing quotation  marks gets truncated.
>>>>>>>>
>>>>>>>> Solution:
>>>>>>>>
>>>>>>>> Split the  "st->print("\"%s\" ", get_thread_name())" in two 
>>>>>>>> statements
>>>>>>>>
>>>>>>>> 1.st->print("\"%s", get_thread_name());
>>>>>>>>
>>>>>>>> 2.st->print("\" ");
>>>>>>>>
>>>>>>>> This will ensure presence of closing quotation mark always.
>>>>>>> Can't we just limit the number of characters read by %s?
>>>>>>>
>>>>>>> Yes we can do it, but just one thing which I think of is, if the 
>>>>>>> truncation of output inside  output stream issue get resolves as 
>>>>>>> Dmritry suggested or O_BUFFLEN size gets increased in any future 
>>>>>>> fix then we have to again make changes in this code, as limiting 
>>>>>>> the no.
>>>>>>> of character read by %s will give truncated output . In such 
>>>>>>> case present fix will have no effect.
>>>>>> Ignoring Dmitry's issue it still seems simpler/cleaner to just 
>>>>>> add the desired precision value to the %s than to split into two 
>>>>>> print statements. Or bite the bullet now and make the length 
>>>>>> immaterial by breaking the name into chunks. It's as easy to fix 
>>>>>> as to write the RFE :)
>>>>>>
>>>>>> David
>>>>>>
>>>>>>> David
>>>>>>>
>>>>>>>> Regards,
>>>>>>>>
>>>>>>>> Cheleswer
>>>>>>>>
>>>>>
>>>
>>


From staffan.larsen at oracle.com  Wed Mar 30 19:23:17 2016
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Wed, 30 Mar 2016 21:23:17 +0200
Subject: javaone 2012 presentation on Diagnosing Your Application on the
	JVM : Question on attach on Windows
In-Reply-To: <F53B76A14E75764283B3CFF6D24B9DCD0FDA6445@G4W3205.americas.hpqcorp.net>
References: <F53B76A14E75764283B3CFF6D24B9DCD0FDA6445@G4W3205.americas.hpqcorp.net>
Message-ID: <223DA7C2-0B53-4798-BF9B-894AEF89159F@oracle.com>


> On 30 mars 2016, at 09:40, Bacchu, Anjan <anjan.bacchu at hpe.com> wrote:
> 
> Hi Staffan,
>  
>       I just now saw the presentation slides at http://www.slideshare.net/stalar/diagnosing-your-application-on-the-jvm <http://www.slideshare.net/stalar/diagnosing-your-application-on-the-jvm>.
>  
> On Slide 16 of the presentation, you show the details of the ?HotSpot Dynamic Attach Mechanism? for Windows.
>  
> 1)  You talk about Remote process injecting code into the JVM using combination of VirtualAllocEx and
> 2)  WriteProcessMemory. Further it goes ahead and creates a Remote thread in the JVM to call above code.
>  
>  
> Do you have some sample code which does this, to say, dump the heap ?

If you want to dump the heap, take a look at ?jcmd <pid> GC.heap_dump?: 

----------
Generate a HPROF format dump of the Java heap.

Impact: High: Depends on Java heap size and content. Request a full GC unless the '-all' option is specified.

Permission: java.lang.management.ManagementPermission(monitor)

Syntax : GC.heap_dump [options] <filename>

Arguments:
	filename :  Name of the dump file (STRING, no default value)

Options: (options must be specified using the <key> or <key>=<value> syntax)
	-all : [optional] Dump all objects, including unreachable objects (BOOLEAN, false)
----------

You can also use ?jmap -dump <pid>.

>  
> I used to develop windows application long ago and just from the slide #16 andhttp://openjdk.java.net/groups/hotspot/docs/Serviceability.html#battach <http://openjdk.java.net/groups/hotspot/docs/Serviceability.html#battach>, I?m unable to proceed further.

The source code is in the VirtualMachineImpl.c file for windows: http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/1565a0efe6f0/src/jdk.attach/windows/native/libattach/VirtualMachineImpl.c <http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/1565a0efe6f0/src/jdk.attach/windows/native/libattach/VirtualMachineImpl.c>



>  
> All help will be useful.
>  
> Thank you very much,
>  
> BR,
> ~A

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20160330/63c08244/attachment.html>

From chris.plummer at oracle.com  Thu Mar 31 06:20:41 2016
From: chris.plummer at oracle.com (Chris Plummer)
Date: Wed, 30 Mar 2016 23:20:41 -0700
Subject: RFR(M): 8148195: Some InstanceKlass and MethodCounters fields can be
	excluded when JVMTI is not supported
Message-ID: <56FCC1B9.3060007@oracle.com>

Please review the following for removing some fields that are not needed 
when not supporting JVMTI.

https://bugs.openjdk.java.net/browse/JDK-8148195
http://cr.openjdk.java.net/~cjplummer/8148195/webrev.02/webrev.hotspot/

I had passed a preliminary review around a month or so ago. The webrev 
is here:

http://cr.openjdk.java.net/~cjplummer/8148195/webrev.01/webrev.hotspot/

I made a number of changes since then. I tried to reduce the number of 
#ifdefs, but at the same time include less unnecessary code in the 
INCLUDE_JVMTI=0 build. For example, BreakpointInfo is now completely 
gone when not including JVMTI. I didn't really succeed at the former 
since #ifdefs seem to have just moved around, but there is a lot more 
code conditionally compiled out now, and I think it's cleaner this way.

Also since the previous webrev, I added some fixes for SA, although 
these aren't possible to test right now. Currently the minimal VM is the 
only one that supports excluding JVMTI, but it also excludes SA, so that 
makes it hard to test conditionally removing some JVMTI support from SA. 
I tried doing a client VM build without JVMTI, but that's currently 
broken (can't build with INCLUDE_JVMTI=0 and INCLUDE_SERVICES=1). It's a 
known issue that's already being worked on.

Testing I've done:

  - jprt -testset hotspot
  - jck vm tests with minimal vm on linux-x86
  - hotspot/test/:compact2_minimal with minimal vm on linux-x86
  - all the serviceability tests I could find supported by RBT. Ran with 
client vm
     on linux-x86 and server vm on linux-x64.

I'm going to try to do more minimal VM testing. I need to figure out 
more test suites I can run with minimal and not get a ton of errors due 
to the tests using excluded functionality.

thanks,

Chris

From marcus.larsson at oracle.com  Thu Mar 31 07:26:02 2016
From: marcus.larsson at oracle.com (Marcus Larsson)
Date: Thu, 31 Mar 2016 09:26:02 +0200
Subject: RFR: 8146879: Add option for handling existing log files in UL
In-Reply-To: <C2EC6E84-C551-41CF-9256-9A3FDA9D1D9C@oracle.com>
References: <5697B7F2.50104@oracle.com> <56D578F9.6090602@oracle.com>
	<56D5A1BB.6030403@oracle.com> <56E2D478.3090202@oracle.com>
	<56EBFCCC.1080701@oracle.com>
	<EBB590DE-C820-4D4C-9D0E-D1096B09BF54@oracle.com>
	<56FBDFE1.9040202@oracle.com>
	<C2EC6E84-C551-41CF-9256-9A3FDA9D1D9C@oracle.com>
Message-ID: <56FCD10A.6050200@oracle.com>

Thanks for reviewing!

Marcus

On 03/30/2016 06:16 PM, Gerard Ziemski wrote:
> Look good.
>
> Thank you for you patience with my review.
>
>
> cheers
>
>> On Mar 30, 2016, at 9:17 AM, Marcus Larsson <marcus.larsson at oracle.com> wrote:
>>
>> Hi Gerard,
>>
>> On 03/22/2016 07:15 PM, Gerard Ziemski wrote:
>>> hi Marcus,
>>>
>>> Thank you for incorporating the feedback.
>>>
>>> The only remaining comment I have is about the ?number_of_lines_with_substring_in_file()? function. As written, it resets the entire algorithm to the beginning of the file when it can not fit the current line, when I think the intention should be only to rewind only to the beginning of that line.
>>>
>>> May I suggest the following implementation instead:
>>>
>>> static size_t number_of_lines_with_substring_in_file(const char* filename,
>>>                                                           const char* substr) {
>>>   ResourceMark rm;
>>>   size_t ret = 0;
>>>   FILE* fp = fopen(filename, "r");
>>>   assert(fp, "error opening file %s: %s", filename, strerror(errno));
>>>
>>>   int buflen = 512;
>>>   char* buf = NEW_RESOURCE_ARRAY(char, buflen);
>>>   long int pos = 0;
>>>
>>>   while (fgets(buf, buflen, fp) != NULL) {
>>>     if (buf[strlen(buf) - 1] != '\n') {
>>>       // rewind to the beginning of the line
>>>       fseek(fp, pos, SEEK_SET);
>>>       // double the buffer size and try again
>>>       buf = REALLOC_RESOURCE_ARRAY(char, buf, buflen, 2*buflen);
>>>       buflen *= 2;
>>>     } else {
>>>       // get current file position
>>>       pos = ftell(fp);
>>>
>>>       if (strstr(buf, substr) != NULL) {
>>>         ret++;
>>>       }
>>>     }
>>>   }
>>>
>>>   fclose(fp);
>>>   return ret;
>>> }
>> Alright, fixed.
>>
>> New webrev:
>> http://cr.openjdk.java.net/~mlarsson/8146879/webrev.05/
>>
>> Incremental:
>> http://cr.openjdk.java.net/~mlarsson/8146879/webrev.04-05/
>>
>> Also fixed some failing tests caused by this patch in the previous round of changes.
>>
>> Thanks,
>> Marcus
>>
>>> cheers
>>>
>>>
>>>> On Mar 18, 2016, at 8:04 AM, Marcus Larsson <marcus.larsson at oracle.com> wrote:
>>>>
>>>> Updated patch after feedback.
>>>>
>>>> New webrev:
>>>> http://cr.openjdk.java.net/~mlarsson/8146879/webrev.04/
>>>>
>>>> Incremental:
>>>> http://cr.openjdk.java.net/~mlarsson/8146879/webrev.03-04/
>>>>
>>>> Tested with internal VM tests through RBT.
>>>>
>>>> Changes:
>>>> * Rotation filecount is now limited to 1000 files.
>>>> * Removed loop in os::compare_file_modified_times.
>>>> * Added a check before rotating/truncating an existing log file, and will only do so if it's a regular file.
>>>> * Added test case to check that logging to a directory gives the intended error message.
>>>> * Fixed test help method to handle arbitrary length log lines.
>>>>
>>>> Thanks,
>>>> Marcus
>>>>
>>>> On 03/11/2016 03:21 PM, Marcus Larsson wrote:
>>>>> Third time's the charm.
>>>>>
>>>>> Webrev:
>>>>> http://cr.openjdk.java.net/~mlarsson/8146879/webrev.03/
>>>>>
>>>>> This patch makes log file rotation the default. Default thresholds are 5 rotated files with a target size of 20MiB. Truncating behavior can be achieved by setting filecount to 0 (-Xlog::myfile.log::filecount=0).
>>>>>
>>>>> If a log file already exists during log file initialization it will be rotated. If any of the target file names (file.0 to file.4 in the default case) are available, that filename will be used for the existing log. If all names are taken the VM will attempt to overwrite the oldest file.
>>>>>
>>>>> This should prevent unlimited log file creations and avoid accidental loss of log files from previous runs. The default thresholds (5 files, 20MiB each) is just a suggestion. If you think it should be higher/lower let me know.
>>>>>
>>>>> Tested with included internal VM tests through RBT.
>>>>>
>>>>> Thanks,
>>>>> Marcus
>>>>>
>>>>> On 2016-03-01 15:05, Marcus Larsson wrote:
>>>>>> Hi,
>>>>>>
>>>>>> After some offline discussions I'm withdrawing this patch. I will instead investigate if I can achieve similar behavior using log rotation as the default.
>>>>>>
>>>>>> Thanks,
>>>>>> Marcus
>>>>>>
>>>>>> On 03/01/2016 12:11 PM, Marcus Larsson wrote:
>>>>>>> Hi again,
>>>>>>>
>>>>>>> Taking a different approach to this.
>>>>>>>
>>>>>>> New webrev:
>>>>>>> http://cr.openjdk.java.net/~mlarsson/8146879/webrev.01/
>>>>>>>
>>>>>>> Existing files will now by default be renamed/archived with a .X suffix where X is the lowest number such that the resulting file name is available (jvm.log becomes jvm.log.0). A mode option for controlling this behavior has been added as well. It can be set to archive, append, or truncate (i.e. -Xlog::jvm.log::mode=truncate).
>>>>>>>
>>>>>>> Tested with included jtreg test through JPRT.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Marcus
>>>>>>>
>>>>>>> On 01/14/2016 04:00 PM, Marcus Larsson wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> Please review the following patch to make sure UL truncates existing log files before writing to them. Since files are opened in append mode, truncation isn't done automatically, so instead the patch adds an attempt to remove the log file before opening it.
>>>>>>>>
>>>>>>>> Webrev:
>>>>>>>> http://cr.openjdk.java.net/~mlarsson/8146879/webrev.00/
>>>>>>>>
>>>>>>>> Issue:
>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8146879
>>>>>>>>
>>>>>>>> Testing:
>>>>>>>> Included test through JPRT
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Marcus


From serguei.spitsyn at oracle.com  Thu Mar 31 07:38:44 2016
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Thu, 31 Mar 2016 00:38:44 -0700
Subject: RFR(M): 8148195: Some InstanceKlass and MethodCounters fields can
	be excluded when JVMTI is not supported
In-Reply-To: <56FCC1B9.3060007@oracle.com>
References: <56FCC1B9.3060007@oracle.com>
Message-ID: <56FCD404.8030601@oracle.com>

Hi Chris,


It looks pretty good, thanks!

Just some minor comments below.

src/share/vm/ci/ciMethod.cpp

   The only file with old Copyright year.

src/share/vm/oops/instanceKlass.hpp

  907   // Breakpoint support (see methods on Method* for details)
908 #if INCLUDE_JVMTI
  909   BreakpointInfo* breakpoints() const       { return _breakpoints; };
  910   void set_breakpoints(BreakpointInfo* bps) { _breakpoints = bps; };
911 #endif

  Better to move the comment at the L907 inside the ifdef block.

1280   // RedefineClasses support
1281 #if INCLUDE_JVMTI
1282   void link_previous_versions(InstanceKlass* pv) { _previous_versions = pv; }
1283   void mark_newly_obsolete_methods(Array<Method*>* old_methods, int emcp_method_count);
1284 #endif

  Better to move the comment at the L1280 inside the ifdef block.


src/share/vm/oops/method.hpp

1041 /// Fast Breakpoints.
1042
1043 // If this structure gets more complicated (because bpts get numerous),
1044 // move it into its own header.
1045
1046 // There is presently no provision for concurrent access
1047 // to breakpoint lists, which is only OK for JVMTI because
1048 // breakpoints are written only at safepoints, and are read
1049 // concurrently only outside of safepoints.
1050
1051 #if INCLUDE_JVMTI

  Better to move the comments at the L1041-1949 inside the ifdef block.

Consider it reviewed, I do not need to see another webrev.


Thanks,
Serguei


On 3/30/16 23:20, Chris Plummer wrote:
> Please review the following for removing some fields that are not 
> needed when not supporting JVMTI.
>
> https://bugs.openjdk.java.net/browse/JDK-8148195
> http://cr.openjdk.java.net/~cjplummer/8148195/webrev.02/webrev.hotspot/
>
> I had passed a preliminary review around a month or so ago. The webrev 
> is here:
>
> http://cr.openjdk.java.net/~cjplummer/8148195/webrev.01/webrev.hotspot/
>
> I made a number of changes since then. I tried to reduce the number of 
> #ifdefs, but at the same time include less unnecessary code in the 
> INCLUDE_JVMTI=0 build. For example, BreakpointInfo is now completely 
> gone when not including JVMTI. I didn't really succeed at the former 
> since #ifdefs seem to have just moved around, but there is a lot more 
> code conditionally compiled out now, and I think it's cleaner this way.
>
> Also since the previous webrev, I added some fixes for SA, although 
> these aren't possible to test right now. Currently the minimal VM is 
> the only one that supports excluding JVMTI, but it also excludes SA, 
> so that makes it hard to test conditionally removing some JVMTI 
> support from SA. I tried doing a client VM build without JVMTI, but 
> that's currently broken (can't build with INCLUDE_JVMTI=0 and 
> INCLUDE_SERVICES=1). It's a known issue that's already being worked on.
>
> Testing I've done:
>
>  - jprt -testset hotspot
>  - jck vm tests with minimal vm on linux-x86
>  - hotspot/test/:compact2_minimal with minimal vm on linux-x86
>  - all the serviceability tests I could find supported by RBT. Ran 
> with client vm
>     on linux-x86 and server vm on linux-x64.
>
> I'm going to try to do more minimal VM testing. I need to figure out 
> more test suites I can run with minimal and not get a ton of errors 
> due to the tests using excluded functionality.
>
> thanks,
>
> Chris

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20160331/065710ec/attachment-0001.html>

From cheleswer.sahu at oracle.com  Thu Mar 31 09:46:55 2016
From: cheleswer.sahu at oracle.com (Cheleswer Sahu)
Date: Thu, 31 Mar 2016 02:46:55 -0700 (PDT)
Subject: RFR[9u-dev]: 8151442: jstack doesn't close quotation marks
	properly with threads' name greater than 1996 characters
In-Reply-To: <e92069d4-cc45-4ce6-a71a-37798cbde525@default>
References: <556325b3-e8b2-4622-8b59-1df2ef4b1f02@default>
	<56EBC647.6020704@oracle.com>
	<0db522da-1cbe-494a-8aa3-e82ec7b7f5aa@default>
	<56EBF9CC.8000809@oracle.com> <56EC0285.9080004@oracle.com>
	<56EC7506.902@oracle.com> <56EFB351.7010707@oracle.com>
	<56F021EC.4010105@oracle.com> <56F06670.5030802@oracle.com>
	<56F4489D.10107@oracle.com>
	<e92069d4-cc45-4ce6-a71a-37798cbde525@default>
Message-ID: <e1d739b6-b0a5-4a50-a4e4-811de8016147@default>

Hi ,

I would like to go with the "print_raw()" option as this can print any length of thread name. I have modified the code and written a test case also for this bug. Please review the code changes from the below link 

http://cr.openjdk.java.net/~csahu/8151442/webrev.01/ 

Regards,
Cheleswer

-----Original Message-----
From: Mattis Castegren 
Sent: Wednesday, March 30, 2016 10:42 PM
To: Kevin Walls; David Holmes; Daniel Daugherty; Dmitry Samersoff; Cheleswer Sahu; hotspot-runtime-dev at openjdk.java.net; serviceability-dev at openjdk.java.net
Cc: Mattis Castegren
Subject: RE: RFR[9u-dev]: 8151442: jstack doesn't close quotation marks properly with threads' name greater than 1996 characters

Hi

It seems there are two approaches here, either we truncate long thread names, or we make sure to print the full thread name.

I agree with Dmitry and Kirk that if the API allows these long names, the tooling should do the right thing (even though one has to wonder what these long names are).

I suggest we move ahead with the print_raw approach.

If we believe there should be a limit in the Thread name lenghts, I suggest we file a new bug for that.

Kind Regards
/Mattis

-----Original Message-----
From: Kevin Walls 
Sent: den 24 mars 2016 21:06
To: David Holmes; Daniel Daugherty; Dmitry Samersoff; Cheleswer Sahu; hotspot-runtime-dev at openjdk.java.net; serviceability-dev at openjdk.java.net
Subject: Re: RFR[9u-dev]: 8151442: jstack doesn't close quotation marks properly with threads' name greater than 1996 characters


Hi

I didn't think of %.XXXXs when Cheleswer and I discussed this briefly.  
I'd like to have suggested that, with the idea that the 2k long thread name is extreme, and it's so important that we preserve the format of the output, and keep that closing quote, even if we lost some of the thread name.  We currently and probably always have truncated such names, the problem that triggered this was mainly that the format was broken.

As there are several places we pass the name to the stream and could hit the length limit, should we have a THREAD_NAME_FORMAT defined for such use instead of using %s though the actual length can't be 1996, it's BUFLEN minus whatever else we expect to be printed in the same print call.  We might guess as low as 1024?

(Retaining one st->print() also minimises any risk of concurrent prints jumbling up the output.)

Thanks
Kevin


On 21/03/2016 21:24, David Holmes wrote:
> On 22/03/2016 2:31 AM, Daniel D. Daugherty wrote:
>> On 3/21/16 2:39 AM, Dmitry Samersoff wrote:
>>> David,
>>>
>>>> I still see %.Ns as the simplest solution - but whatever.
>>> It spreads artificial limitation of thread name length across 
>>> hotspot sources.
>>>
>>> Brief grepping[1] shows couple of other places with the same problem 
>>> and if some days we decide to change default O_BUFLEN, we have to 
>>> not forget to change .N value in couple of places as well.
>>
>> There should be a way to pass the precision value as a parameter 
>> instead of hardcoding it in the format string. Something like:
>>
>>      sprintf("%.*s", precision_value, string);
>
> Yes the length limit can be passed as a variable. But I think Dmitry 
> just wants to allow for unlimited lengths. Not sure how to achieve 
> that at the lowest level though as we need to avoid complex 
> allocations etc in these print routines.
>
> David
>
>
>> Dan
>>
>>>
>>> 1.
>>> ./share/vm/prims/jni.cpp
>>> 673: "in thread \"%s\" ", thread->get_thread_name());
>>>
>>> ./share/vm/runtime/thread.cpp
>>> 1766: get_thread_profiler()->print(get_thread_name());
>>> 1974: get_thread_profiler()->print(get_thread_name());
>>> 2896: st->print("\"%s\" ", get_thread_name());
>>> 2926: st->print("%s", get_thread_name_string(buf, buflen));
>>> 2932: st->print("JavaThread \"%s\"", get_thread_name_string(buf, 
>>> buflen));
>>>
>>>
>>> ./share/vm/services/threadService.cpp
>>> 882: ... st->print_cr("\"%s\":", currentThread->get_thread_name());
>>> 919: ..."%s \"%s\"", owner_desc, currentThread->get_thread_name());
>>> 932: ... st->print_cr("\"%s\":", currentThread->get_thread_name());
>>>
>>> -Dmitry
>>>
>>>
>>> On 2016-03-19 00:37, David Holmes wrote:
>>>>
>>>> On 18/03/2016 11:28 PM, Dmitry Samersoff wrote:
>>>>> David,
>>>>>
>>>>>> Ignoring Dmitry's issue it still seems simpler/cleaner to just 
>>>>>> add the desired precision value to the %s than to split into two 
>>>>>> print statements. Or bite the bullet now and make the length 
>>>>>> immaterial by breaking the name into chunks. It's as easy to fix 
>>>>>> as to write the RFE :)
>>>>> For this particular case the simplest solution is to use print_raw:
>>>>>
>>>>> print_raw("\""\"); print_raw(get_thread_name()); 
>>>>> print_raw("\""\");
>>>> I still see %.Ns as the simplest solution - but whatever.
>>>>
>>>>> But as soon as print() finally ends up with:
>>>>>
>>>>> const int written = vsnprintf(buffer, buflen, format, ap); ...
>>>>> DEBUG_ONLY(warning("increase O_BUFLEN in ostream.hpp -- output
>>>>> truncated");)
>>>>>
>>>>> Complete fix should be something like:
>>>>>
>>>>> int desired_size = vsnprintf(NULL, 0, format, ap); if 
>>>>> (desired_size > O_BUFLEN) {
>>>>>       malloc
>>>>>       ....
>>>>> }
>>>>>
>>>>> but it has performance penalty, so we should use some tricks to 
>>>>> cover most common %s/%d/%p cases.
>>>> So you want to remove the internal limitation instead of have the 
>>>> clients deal with it? Not sure it is worth the effort - IIRC that 
>>>> code can be used at sensitive times hence the simple approach to 
>>>> buffer management.
>>>>
>>>> David
>>>>
>>>>> -Dmitry
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 2016-03-18 15:51, David Holmes wrote:
>>>>>> On 18/03/2016 10:03 PM, Cheleswer Sahu wrote:
>>>>>>> Hi David,
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: David Holmes
>>>>>>> Sent: Friday, March 18, 2016 2:42 PM
>>>>>>> To: Cheleswer Sahu; hotspot-runtime-dev at openjdk.java.net;
>>>>>>> serviceability-dev at openjdk.java.net
>>>>>>> Subject: Re: RFR[9u-dev]: 8151442: jstack doesn't close 
>>>>>>> quotation marks properly with threads' name greater than 1996 
>>>>>>> characters
>>>>>>>
>>>>>>> On 18/03/2016 5:54 PM, Cheleswer Sahu wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> Please review the code changes for 
>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8151442.
>>>>>>>>
>>>>>>>> Webrev Link: http://cr.openjdk.java.net/~csahu/8151442/
>>>>>>>>
>>>>>>>> Bug Brief:
>>>>>>>>
>>>>>>>> In jstack thread dumps , thread name greater than 1996 
>>>>>>>> characters doesn't close quotation marks properly.
>>>>>>> Anyone giving a thread a name that long deserves to get a core 
>>>>>>> dump!
>>>>>>> ;-)
>>>>>>>
>>>>>>>> Problem Identified:
>>>>>>>>
>>>>>>>> Jstack is using below code to print thread name
>>>>>>>>
>>>>>>>> src/share/vm/runtime/thread.cpp
>>>>>>>>
>>>>>>>> void JavaThread::print_on(outputStream *st) const {
>>>>>>>>
>>>>>>>>       st->print("\"%s\" ", get_thread_name());
>>>>>>>>
>>>>>>>> Here "st->print()"  internally uses max buffer length as 
>>>>>>>> O_BUFLEN (2000).
>>>>>>>>
>>>>>>>> void
>>>>>>>> outputStream::do_vsnprintf_and_write_with_automatic_buffer(cons
>>>>>>>> t
>>>>>>>> char* format, va_list ap, bool add_cr) {
>>>>>>>>
>>>>>>>>       char buffer[O_BUFLEN];
>>>>>>>>
>>>>>>>> do_vsnprintf_and_write_with_automatic_buffer() finally calls
>>>>>>>>      "vsnprintf()"  which truncates the anything greater than 
>>>>>>>> the max size(2000). In this case thread's name(> 1996) along 
>>>>>>>> with quotation marks (2)
>>>>>>>>
>>>>>>>> plus one terminating character exceeds the  max buffer size 
>>>>>>>> (2000), therefore the closing quotation  marks gets truncated.
>>>>>>>>
>>>>>>>> Solution:
>>>>>>>>
>>>>>>>> Split the  "st->print("\"%s\" ", get_thread_name())" in two 
>>>>>>>> statements
>>>>>>>>
>>>>>>>> 1.st->print("\"%s", get_thread_name());
>>>>>>>>
>>>>>>>> 2.st->print("\" ");
>>>>>>>>
>>>>>>>> This will ensure presence of closing quotation mark always.
>>>>>>> Can't we just limit the number of characters read by %s?
>>>>>>>
>>>>>>> Yes we can do it, but just one thing which I think of is, if the 
>>>>>>> truncation of output inside  output stream issue get resolves as 
>>>>>>> Dmritry suggested or O_BUFFLEN size gets increased in any future 
>>>>>>> fix then we have to again make changes in this code, as limiting 
>>>>>>> the no.
>>>>>>> of character read by %s will give truncated output . In such 
>>>>>>> case present fix will have no effect.
>>>>>> Ignoring Dmitry's issue it still seems simpler/cleaner to just 
>>>>>> add the desired precision value to the %s than to split into two 
>>>>>> print statements. Or bite the bullet now and make the length 
>>>>>> immaterial by breaking the name into chunks. It's as easy to fix 
>>>>>> as to write the RFE :)
>>>>>>
>>>>>> David
>>>>>>
>>>>>>> David
>>>>>>>
>>>>>>>> Regards,
>>>>>>>>
>>>>>>>> Cheleswer
>>>>>>>>
>>>>>
>>>
>>


From marcus.larsson at oracle.com  Thu Mar 31 10:40:27 2016
From: marcus.larsson at oracle.com (Marcus Larsson)
Date: Thu, 31 Mar 2016 12:40:27 +0200
Subject: RFR (S): 8153174: Remove trailing comma from log configuration
	listings
Message-ID: <56FCFE9B.80509@oracle.com>

Hi,

Please review the following small patch to avoid adding a trailing comma 
in the tagset and level listings in the configuration string for log 
outputs. Removing this comma allows the string to be used without 
modification when configuring logging (with -Xlog or similar).

Webrev:
http://cr.openjdk.java.net/~mlarsson/8153174/webrev.00/

Issue:
https://bugs.openjdk.java.net/browse/JDK-8153174

Thanks,
Marcus

From yasuenag at gmail.com  Thu Mar 31 13:33:44 2016
From: yasuenag at gmail.com (Yasumasa Suenaga)
Date: Thu, 31 Mar 2016 22:33:44 +0900
Subject: RFR: JDK-8153073: UL: Set filesize option with k/m/g
In-Reply-To: <56FCECDA.3070204@gmail.com>
References: <56FBDE02.2030900@gmail.com> <56FCD642.3000107@oracle.com>
	<56FCECDA.3070204@gmail.com>
Message-ID: <56FD2738.8050500@gmail.com>

CC'ed to serviceability-dev.

Could you review it?

>    http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.01/


Thanks,

Yasumasa


On 2016/03/31 18:24, Yasumasa Suenaga wrote:
> Hi Marcus,
> 
>> You're missing an include of arguments.hpp in logFileOutput.cpp.
> 
> arguments.hpp is included in precompiled.hpp . So build was succeeded.
> However, it should be included in logFileOutput.cpp .
> 
> I uploaded a new webrev. Could you review again?
> 
>    http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.01/
> 
> 
> Thanks,
> 
> Yasumasa
> 
> 
> On 2016/03/31 16:48, Marcus Larsson wrote:
>> Hi,
>>
>> On 03/30/2016 04:09 PM, Yasumasa Suenaga wrote:
>>> Hi all,
>>>
>>> This request review is related to [1].
>>>
>>> I want to set filesize option with k/m/g as below:
>>>              -Xlog:gc=trace:file=gc.log:time:filecount=5,filesize=10m
>>>
>>> Memory size option (e.g. -Xmx) can be set with k/m/g .
>>> I think we can use option parser in arguments.cpp .
>>>
>>> I uploaded webrev. Could you review it?
>>>
>>>     http://cr.openjdk.java.net/~ysuenaga/JDK-8153073/webrev.00/
>>
>> You're missing an include of arguments.hpp in logFileOutput.cpp.
>>
>> Apart from that, this looks good to me.
>>
>> Thanks,
>> Marcus
>>
>>>
>>>
>>> I cannot access JPRT. So I need a sponsor.
>>>
>>>
>>> Thanks,
>>>
>>> Yasumasa
>>>
>>>
>>> [1] http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-March/018704.html
>>>
>>

From yasuenag at gmail.com  Thu Mar 31 13:35:02 2016
From: yasuenag at gmail.com (Yasumasa Suenaga)
Date: Thu, 31 Mar 2016 22:35:02 +0900
Subject: RFR: JDK-8153074: UL: Show output option in VM.log jcmd
In-Reply-To: <56FBDE2F.60701@gmail.com>
References: <56FBDE2F.60701@gmail.com>
Message-ID: <56FD2786.9020102@gmail.com>

CC'ed to serviceability-dev.

Could you review it?

>    http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.00/


Thanks,

Yasumasa


On 2016/03/30 23:09, Yasumasa Suenaga wrote:
> Hi all,
> 
> This request review is related to [1].
> 
> I want to see output option (filecount, filesize) in VM.log jcmd.
> 
>   Output sample:
>       #2: gc.log gc=trace, filecount=5,filesize=1048576 time,level,
> 
> I uploaded webrev. Could you review it?
> 
>    http://cr.openjdk.java.net/~ysuenaga/JDK-8153074/webrev.00/
> 
> 
> I cannot access JPRT. So I need a sponsor.
> 
> 
> Thanks,
> 
> Yasumasa
> 
> 
> [1] http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-March/018704.html
> 
> 

From anjan.bacchu at hpe.com  Wed Mar 30 07:40:34 2016
From: anjan.bacchu at hpe.com (Bacchu, Anjan)
Date: Wed, 30 Mar 2016 07:40:34 +0000
Subject: javaone 2012 presentation on Diagnosing Your Application on the JVM
	: Question on attach on Windows
Message-ID: <F53B76A14E75764283B3CFF6D24B9DCD0FDA6445@G4W3205.americas.hpqcorp.net>

Hi Staffan,

      I just now saw the presentation slides at http://www.slideshare.net/stalar/diagnosing-your-application-on-the-jvm.

On Slide 16 of the presentation, you show the details of the "HotSpot Dynamic Attach Mechanism" for Windows.


1)  You talk about Remote process injecting code into the JVM using combination of VirtualAllocEx and

2)  WriteProcessMemory. Further it goes ahead and creates a Remote thread in the JVM to call above code.


Do you have some sample code which does this, to say, dump the heap ?

I used to develop windows application long ago and just from the slide #16 and http://openjdk.java.net/groups/hotspot/docs/Serviceability.html#battach, I'm unable to proceed further.

All help will be useful.

Thank you very much,

BR,
~A

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20160330/7d871c4d/attachment-0001.html>

From anjan.bacchu at hpe.com  Thu Mar 31 11:30:39 2016
From: anjan.bacchu at hpe.com (Bacchu, Anjan)
Date: Thu, 31 Mar 2016 11:30:39 +0000
Subject: javaone 2012 presentation on Diagnosing Your Application on the
	JVM : Question on attach on Windows
In-Reply-To: <223DA7C2-0B53-4798-BF9B-894AEF89159F@oracle.com>
References: <F53B76A14E75764283B3CFF6D24B9DCD0FDA6445@G4W3205.americas.hpqcorp.net>
	<223DA7C2-0B53-4798-BF9B-894AEF89159F@oracle.com>
Message-ID: <F53B76A14E75764283B3CFF6D24B9DCD0FDA672C@G4W3205.americas.hpqcorp.net>

Hi Staffan,

      Thank you very much for the presentation and the quick response.

      Jcmd/jmap : Unfortunately, we ship only the Client JRE with our product. Customer doesn?t have access to jcmd/jmap. That?s why I was looking for an outside solution.

Then I came across https://github.com/apangin/jattach ? however this is only for linux/bsd. I wanted to use ?HotSpot Dynamic Attach Mechanism? to dump the heap on Windows by writing a similar utility for windows.

Thanks again,

BR,
~A




From: Staffan Larsen [mailto:staffan.larsen at oracle.com]
Sent: Thursday, March 31, 2016 12:53 AM
To: Bacchu, Anjan <anjan.bacchu at hpe.com>
Cc: serviceability-dev at openjdk.java.net
Subject: Re: javaone 2012 presentation on Diagnosing Your Application on the JVM : Question on attach on Windows


On 30 mars 2016, at 09:40, Bacchu, Anjan <anjan.bacchu at hpe.com<mailto:anjan.bacchu at hpe.com>> wrote:

Hi Staffan,

      I just now saw the presentation slides at http://www.slideshare.net/stalar/diagnosing-your-application-on-the-jvm.

On Slide 16 of the presentation, you show the details of the ?HotSpot Dynamic Attach Mechanism? for Windows.

1)  You talk about Remote process injecting code into the JVM using combination of VirtualAllocEx and
2)  WriteProcessMemory. Further it goes ahead and creates a Remote thread in the JVM to call above code.


Do you have some sample code which does this, to say, dump the heap ?

If you want to dump the heap, take a look at ?jcmd <pid> GC.heap_dump?:

----------
Generate a HPROF format dump of the Java heap.

Impact: High: Depends on Java heap size and content. Request a full GC unless the '-all' option is specified.

Permission: java.lang.management.ManagementPermission(monitor)

Syntax : GC.heap_dump [options] <filename>

Arguments:
            filename :  Name of the dump file (STRING, no default value)

Options: (options must be specified using the <key> or <key>=<value> syntax)
            -all : [optional] Dump all objects, including unreachable objects (BOOLEAN, false)
----------

You can also use ?jmap -dump <pid>.



I used to develop windows application long ago and just from the slide #16 andhttp://openjdk.java.net/groups/hotspot/docs/Serviceability.html#battach, I?m unable to proceed further.

The source code is in the VirtualMachineImpl.c file for windows: http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/1565a0efe6f0/src/jdk.attach/windows/native/libattach/VirtualMachineImpl.c





All help will be useful.

Thank you very much,

BR,
~A

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20160331/9b1ff3b5/attachment.html>

From chris.plummer at oracle.com  Thu Mar 31 16:31:01 2016
From: chris.plummer at oracle.com (Chris Plummer)
Date: Thu, 31 Mar 2016 09:31:01 -0700
Subject: RFR(M): 8148195: Some InstanceKlass and MethodCounters fields can
	be excluded when JVMTI is not supported
In-Reply-To: <56FCD404.8030601@oracle.com>
References: <56FCC1B9.3060007@oracle.com> <56FCD404.8030601@oracle.com>
Message-ID: <56FD50C5.4020303@oracle.com>

An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20160331/c309fbb0/attachment-0001.html>

From dmitry.samersoff at oracle.com  Thu Mar 31 18:54:51 2016
From: dmitry.samersoff at oracle.com (Dmitry Samersoff)
Date: Thu, 31 Mar 2016 21:54:51 +0300
Subject: RFR[9u-dev]: 8151442: jstack doesn't close quotation marks
	properly with threads' name greater than 1996 characters
In-Reply-To: <e1d739b6-b0a5-4a50-a4e4-811de8016147@default>
References: <556325b3-e8b2-4622-8b59-1df2ef4b1f02@default>
	<56EBC647.6020704@oracle.com>
	<0db522da-1cbe-494a-8aa3-e82ec7b7f5aa@default>
	<56EBF9CC.8000809@oracle.com> <56EC0285.9080004@oracle.com>
	<56EC7506.902@oracle.com> <56EFB351.7010707@oracle.com>
	<56F021EC.4010105@oracle.com> <56F06670.5030802@oracle.com>
	<56F4489D.10107@oracle.com>
	<e92069d4-cc45-4ce6-a71a-37798cbde525@default>
	<e1d739b6-b0a5-4a50-a4e4-811de8016147@default>
Message-ID: <56FD727B.1000209@oracle.com>

Cheleswer,

Looks good for me! (R)

-Dmitry


On 2016-03-31 12:46, Cheleswer Sahu wrote:
> Hi ,
> 
> I would like to go with the "print_raw()" option as this can print any length of thread name. I have modified the code and written a test case also for this bug. Please review the code changes from the below link 
> 
> http://cr.openjdk.java.net/~csahu/8151442/webrev.01/ 
> 
> Regards,
> Cheleswer
> 
> -----Original Message-----
> From: Mattis Castegren 
> Sent: Wednesday, March 30, 2016 10:42 PM
> To: Kevin Walls; David Holmes; Daniel Daugherty; Dmitry Samersoff; Cheleswer Sahu; hotspot-runtime-dev at openjdk.java.net; serviceability-dev at openjdk.java.net
> Cc: Mattis Castegren
> Subject: RE: RFR[9u-dev]: 8151442: jstack doesn't close quotation marks properly with threads' name greater than 1996 characters
> 
> Hi
> 
> It seems there are two approaches here, either we truncate long thread names, or we make sure to print the full thread name.
> 
> I agree with Dmitry and Kirk that if the API allows these long names, the tooling should do the right thing (even though one has to wonder what these long names are).
> 
> I suggest we move ahead with the print_raw approach.
> 
> If we believe there should be a limit in the Thread name lenghts, I suggest we file a new bug for that.
> 
> Kind Regards
> /Mattis
> 
> -----Original Message-----
> From: Kevin Walls 
> Sent: den 24 mars 2016 21:06
> To: David Holmes; Daniel Daugherty; Dmitry Samersoff; Cheleswer Sahu; hotspot-runtime-dev at openjdk.java.net; serviceability-dev at openjdk.java.net
> Subject: Re: RFR[9u-dev]: 8151442: jstack doesn't close quotation marks properly with threads' name greater than 1996 characters
> 
> 
> Hi
> 
> I didn't think of %.XXXXs when Cheleswer and I discussed this briefly.  
> I'd like to have suggested that, with the idea that the 2k long thread name is extreme, and it's so important that we preserve the format of the output, and keep that closing quote, even if we lost some of the thread name.  We currently and probably always have truncated such names, the problem that triggered this was mainly that the format was broken.
> 
> As there are several places we pass the name to the stream and could hit the length limit, should we have a THREAD_NAME_FORMAT defined for such use instead of using %s though the actual length can't be 1996, it's BUFLEN minus whatever else we expect to be printed in the same print call.  We might guess as low as 1024?
> 
> (Retaining one st->print() also minimises any risk of concurrent prints jumbling up the output.)
> 
> Thanks
> Kevin
> 
> 
> On 21/03/2016 21:24, David Holmes wrote:
>> On 22/03/2016 2:31 AM, Daniel D. Daugherty wrote:
>>> On 3/21/16 2:39 AM, Dmitry Samersoff wrote:
>>>> David,
>>>>
>>>>> I still see %.Ns as the simplest solution - but whatever.
>>>> It spreads artificial limitation of thread name length across 
>>>> hotspot sources.
>>>>
>>>> Brief grepping[1] shows couple of other places with the same problem 
>>>> and if some days we decide to change default O_BUFLEN, we have to 
>>>> not forget to change .N value in couple of places as well.
>>>
>>> There should be a way to pass the precision value as a parameter 
>>> instead of hardcoding it in the format string. Something like:
>>>
>>>      sprintf("%.*s", precision_value, string);
>>
>> Yes the length limit can be passed as a variable. But I think Dmitry 
>> just wants to allow for unlimited lengths. Not sure how to achieve 
>> that at the lowest level though as we need to avoid complex 
>> allocations etc in these print routines.
>>
>> David
>>
>>
>>> Dan
>>>
>>>>
>>>> 1.
>>>> ./share/vm/prims/jni.cpp
>>>> 673: "in thread \"%s\" ", thread->get_thread_name());
>>>>
>>>> ./share/vm/runtime/thread.cpp
>>>> 1766: get_thread_profiler()->print(get_thread_name());
>>>> 1974: get_thread_profiler()->print(get_thread_name());
>>>> 2896: st->print("\"%s\" ", get_thread_name());
>>>> 2926: st->print("%s", get_thread_name_string(buf, buflen));
>>>> 2932: st->print("JavaThread \"%s\"", get_thread_name_string(buf, 
>>>> buflen));
>>>>
>>>>
>>>> ./share/vm/services/threadService.cpp
>>>> 882: ... st->print_cr("\"%s\":", currentThread->get_thread_name());
>>>> 919: ..."%s \"%s\"", owner_desc, currentThread->get_thread_name());
>>>> 932: ... st->print_cr("\"%s\":", currentThread->get_thread_name());
>>>>
>>>> -Dmitry
>>>>
>>>>
>>>> On 2016-03-19 00:37, David Holmes wrote:
>>>>>
>>>>> On 18/03/2016 11:28 PM, Dmitry Samersoff wrote:
>>>>>> David,
>>>>>>
>>>>>>> Ignoring Dmitry's issue it still seems simpler/cleaner to just 
>>>>>>> add the desired precision value to the %s than to split into two 
>>>>>>> print statements. Or bite the bullet now and make the length 
>>>>>>> immaterial by breaking the name into chunks. It's as easy to fix 
>>>>>>> as to write the RFE :)
>>>>>> For this particular case the simplest solution is to use print_raw:
>>>>>>
>>>>>> print_raw("\""\"); print_raw(get_thread_name()); 
>>>>>> print_raw("\""\");
>>>>> I still see %.Ns as the simplest solution - but whatever.
>>>>>
>>>>>> But as soon as print() finally ends up with:
>>>>>>
>>>>>> const int written = vsnprintf(buffer, buflen, format, ap); ...
>>>>>> DEBUG_ONLY(warning("increase O_BUFLEN in ostream.hpp -- output
>>>>>> truncated");)
>>>>>>
>>>>>> Complete fix should be something like:
>>>>>>
>>>>>> int desired_size = vsnprintf(NULL, 0, format, ap); if 
>>>>>> (desired_size > O_BUFLEN) {
>>>>>>       malloc
>>>>>>       ....
>>>>>> }
>>>>>>
>>>>>> but it has performance penalty, so we should use some tricks to 
>>>>>> cover most common %s/%d/%p cases.
>>>>> So you want to remove the internal limitation instead of have the 
>>>>> clients deal with it? Not sure it is worth the effort - IIRC that 
>>>>> code can be used at sensitive times hence the simple approach to 
>>>>> buffer management.
>>>>>
>>>>> David
>>>>>
>>>>>> -Dmitry
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 2016-03-18 15:51, David Holmes wrote:
>>>>>>> On 18/03/2016 10:03 PM, Cheleswer Sahu wrote:
>>>>>>>> Hi David,
>>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: David Holmes
>>>>>>>> Sent: Friday, March 18, 2016 2:42 PM
>>>>>>>> To: Cheleswer Sahu; hotspot-runtime-dev at openjdk.java.net;
>>>>>>>> serviceability-dev at openjdk.java.net
>>>>>>>> Subject: Re: RFR[9u-dev]: 8151442: jstack doesn't close 
>>>>>>>> quotation marks properly with threads' name greater than 1996 
>>>>>>>> characters
>>>>>>>>
>>>>>>>> On 18/03/2016 5:54 PM, Cheleswer Sahu wrote:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> Please review the code changes for 
>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8151442.
>>>>>>>>>
>>>>>>>>> Webrev Link: http://cr.openjdk.java.net/~csahu/8151442/
>>>>>>>>>
>>>>>>>>> Bug Brief:
>>>>>>>>>
>>>>>>>>> In jstack thread dumps , thread name greater than 1996 
>>>>>>>>> characters doesn't close quotation marks properly.
>>>>>>>> Anyone giving a thread a name that long deserves to get a core 
>>>>>>>> dump!
>>>>>>>> ;-)
>>>>>>>>
>>>>>>>>> Problem Identified:
>>>>>>>>>
>>>>>>>>> Jstack is using below code to print thread name
>>>>>>>>>
>>>>>>>>> src/share/vm/runtime/thread.cpp
>>>>>>>>>
>>>>>>>>> void JavaThread::print_on(outputStream *st) const {
>>>>>>>>>
>>>>>>>>>       st->print("\"%s\" ", get_thread_name());
>>>>>>>>>
>>>>>>>>> Here "st->print()"  internally uses max buffer length as 
>>>>>>>>> O_BUFLEN (2000).
>>>>>>>>>
>>>>>>>>> void
>>>>>>>>> outputStream::do_vsnprintf_and_write_with_automatic_buffer(cons
>>>>>>>>> t
>>>>>>>>> char* format, va_list ap, bool add_cr) {
>>>>>>>>>
>>>>>>>>>       char buffer[O_BUFLEN];
>>>>>>>>>
>>>>>>>>> do_vsnprintf_and_write_with_automatic_buffer() finally calls
>>>>>>>>>      "vsnprintf()"  which truncates the anything greater than 
>>>>>>>>> the max size(2000). In this case thread's name(> 1996) along 
>>>>>>>>> with quotation marks (2)
>>>>>>>>>
>>>>>>>>> plus one terminating character exceeds the  max buffer size 
>>>>>>>>> (2000), therefore the closing quotation  marks gets truncated.
>>>>>>>>>
>>>>>>>>> Solution:
>>>>>>>>>
>>>>>>>>> Split the  "st->print("\"%s\" ", get_thread_name())" in two 
>>>>>>>>> statements
>>>>>>>>>
>>>>>>>>> 1.st->print("\"%s", get_thread_name());
>>>>>>>>>
>>>>>>>>> 2.st->print("\" ");
>>>>>>>>>
>>>>>>>>> This will ensure presence of closing quotation mark always.
>>>>>>>> Can't we just limit the number of characters read by %s?
>>>>>>>>
>>>>>>>> Yes we can do it, but just one thing which I think of is, if the 
>>>>>>>> truncation of output inside  output stream issue get resolves as 
>>>>>>>> Dmritry suggested or O_BUFFLEN size gets increased in any future 
>>>>>>>> fix then we have to again make changes in this code, as limiting 
>>>>>>>> the no.
>>>>>>>> of character read by %s will give truncated output . In such 
>>>>>>>> case present fix will have no effect.
>>>>>>> Ignoring Dmitry's issue it still seems simpler/cleaner to just 
>>>>>>> add the desired precision value to the %s than to split into two 
>>>>>>> print statements. Or bite the bullet now and make the length 
>>>>>>> immaterial by breaking the name into chunks. It's as easy to fix 
>>>>>>> as to write the RFE :)
>>>>>>>
>>>>>>> David
>>>>>>>
>>>>>>>> David
>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>>
>>>>>>>>> Cheleswer
>>>>>>>>>
>>>>>>
>>>>
>>>
> 


-- 
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the sources.

From kevin.walls at oracle.com  Thu Mar 31 19:32:00 2016
From: kevin.walls at oracle.com (Kevin Walls)
Date: Thu, 31 Mar 2016 20:32:00 +0100
Subject: RFR[9u-dev]: 8151442: jstack doesn't close quotation marks
	properly with threads' name greater than 1996 characters
In-Reply-To: <56FD727B.1000209@oracle.com>
References: <556325b3-e8b2-4622-8b59-1df2ef4b1f02@default>
	<56EBC647.6020704@oracle.com>
	<0db522da-1cbe-494a-8aa3-e82ec7b7f5aa@default>
	<56EBF9CC.8000809@oracle.com> <56EC0285.9080004@oracle.com>
	<56EC7506.902@oracle.com> <56EFB351.7010707@oracle.com>
	<56F021EC.4010105@oracle.com> <56F06670.5030802@oracle.com>
	<56F4489D.10107@oracle.com>
	<e92069d4-cc45-4ce6-a71a-37798cbde525@default>
	<e1d739b6-b0a5-4a50-a4e4-811de8016147@default>
	<56FD727B.1000209@oracle.com>
Message-ID: <56FD7B30.8020105@oracle.com>

Yes, looks good. 8-)


On 31/03/2016 19:54, Dmitry Samersoff wrote:
> Cheleswer,
>
> Looks good for me! (R)
>
> -Dmitry
>
>
> On 2016-03-31 12:46, Cheleswer Sahu wrote:
>> Hi ,
>>
>> I would like to go with the "print_raw()" option as this can print any length of thread name. I have modified the code and written a test case also for this bug. Please review the code changes from the below link
>>
>> http://cr.openjdk.java.net/~csahu/8151442/webrev.01/
>>
>> Regards,
>> Cheleswer
>>
>> -----Original Message-----
>> From: Mattis Castegren
>> Sent: Wednesday, March 30, 2016 10:42 PM
>> To: Kevin Walls; David Holmes; Daniel Daugherty; Dmitry Samersoff; Cheleswer Sahu; hotspot-runtime-dev at openjdk.java.net; serviceability-dev at openjdk.java.net
>> Cc: Mattis Castegren
>> Subject: RE: RFR[9u-dev]: 8151442: jstack doesn't close quotation marks properly with threads' name greater than 1996 characters
>>
>> Hi
>>
>> It seems there are two approaches here, either we truncate long thread names, or we make sure to print the full thread name.
>>
>> I agree with Dmitry and Kirk that if the API allows these long names, the tooling should do the right thing (even though one has to wonder what these long names are).
>>
>> I suggest we move ahead with the print_raw approach.
>>
>> If we believe there should be a limit in the Thread name lenghts, I suggest we file a new bug for that.
>>
>> Kind Regards
>> /Mattis
>>
>> -----Original Message-----
>> From: Kevin Walls
>> Sent: den 24 mars 2016 21:06
>> To: David Holmes; Daniel Daugherty; Dmitry Samersoff; Cheleswer Sahu; hotspot-runtime-dev at openjdk.java.net; serviceability-dev at openjdk.java.net
>> Subject: Re: RFR[9u-dev]: 8151442: jstack doesn't close quotation marks properly with threads' name greater than 1996 characters
>>
>>
>> Hi
>>
>> I didn't think of %.XXXXs when Cheleswer and I discussed this briefly.
>> I'd like to have suggested that, with the idea that the 2k long thread name is extreme, and it's so important that we preserve the format of the output, and keep that closing quote, even if we lost some of the thread name.  We currently and probably always have truncated such names, the problem that triggered this was mainly that the format was broken.
>>
>> As there are several places we pass the name to the stream and could hit the length limit, should we have a THREAD_NAME_FORMAT defined for such use instead of using %s though the actual length can't be 1996, it's BUFLEN minus whatever else we expect to be printed in the same print call.  We might guess as low as 1024?
>>
>> (Retaining one st->print() also minimises any risk of concurrent prints jumbling up the output.)
>>
>> Thanks
>> Kevin
>>
>>
>> On 21/03/2016 21:24, David Holmes wrote:
>>> On 22/03/2016 2:31 AM, Daniel D. Daugherty wrote:
>>>> On 3/21/16 2:39 AM, Dmitry Samersoff wrote:
>>>>> David,
>>>>>
>>>>>> I still see %.Ns as the simplest solution - but whatever.
>>>>> It spreads artificial limitation of thread name length across
>>>>> hotspot sources.
>>>>>
>>>>> Brief grepping[1] shows couple of other places with the same problem
>>>>> and if some days we decide to change default O_BUFLEN, we have to
>>>>> not forget to change .N value in couple of places as well.
>>>> There should be a way to pass the precision value as a parameter
>>>> instead of hardcoding it in the format string. Something like:
>>>>
>>>>       sprintf("%.*s", precision_value, string);
>>> Yes the length limit can be passed as a variable. But I think Dmitry
>>> just wants to allow for unlimited lengths. Not sure how to achieve
>>> that at the lowest level though as we need to avoid complex
>>> allocations etc in these print routines.
>>>
>>> David
>>>
>>>
>>>> Dan
>>>>
>>>>> 1.
>>>>> ./share/vm/prims/jni.cpp
>>>>> 673: "in thread \"%s\" ", thread->get_thread_name());
>>>>>
>>>>> ./share/vm/runtime/thread.cpp
>>>>> 1766: get_thread_profiler()->print(get_thread_name());
>>>>> 1974: get_thread_profiler()->print(get_thread_name());
>>>>> 2896: st->print("\"%s\" ", get_thread_name());
>>>>> 2926: st->print("%s", get_thread_name_string(buf, buflen));
>>>>> 2932: st->print("JavaThread \"%s\"", get_thread_name_string(buf,
>>>>> buflen));
>>>>>
>>>>>
>>>>> ./share/vm/services/threadService.cpp
>>>>> 882: ... st->print_cr("\"%s\":", currentThread->get_thread_name());
>>>>> 919: ..."%s \"%s\"", owner_desc, currentThread->get_thread_name());
>>>>> 932: ... st->print_cr("\"%s\":", currentThread->get_thread_name());
>>>>>
>>>>> -Dmitry
>>>>>
>>>>>
>>>>> On 2016-03-19 00:37, David Holmes wrote:
>>>>>> On 18/03/2016 11:28 PM, Dmitry Samersoff wrote:
>>>>>>> David,
>>>>>>>
>>>>>>>> Ignoring Dmitry's issue it still seems simpler/cleaner to just
>>>>>>>> add the desired precision value to the %s than to split into two
>>>>>>>> print statements. Or bite the bullet now and make the length
>>>>>>>> immaterial by breaking the name into chunks. It's as easy to fix
>>>>>>>> as to write the RFE :)
>>>>>>> For this particular case the simplest solution is to use print_raw:
>>>>>>>
>>>>>>> print_raw("\""\"); print_raw(get_thread_name());
>>>>>>> print_raw("\""\");
>>>>>> I still see %.Ns as the simplest solution - but whatever.
>>>>>>
>>>>>>> But as soon as print() finally ends up with:
>>>>>>>
>>>>>>> const int written = vsnprintf(buffer, buflen, format, ap); ...
>>>>>>> DEBUG_ONLY(warning("increase O_BUFLEN in ostream.hpp -- output
>>>>>>> truncated");)
>>>>>>>
>>>>>>> Complete fix should be something like:
>>>>>>>
>>>>>>> int desired_size = vsnprintf(NULL, 0, format, ap); if
>>>>>>> (desired_size > O_BUFLEN) {
>>>>>>>        malloc
>>>>>>>        ....
>>>>>>> }
>>>>>>>
>>>>>>> but it has performance penalty, so we should use some tricks to
>>>>>>> cover most common %s/%d/%p cases.
>>>>>> So you want to remove the internal limitation instead of have the
>>>>>> clients deal with it? Not sure it is worth the effort - IIRC that
>>>>>> code can be used at sensitive times hence the simple approach to
>>>>>> buffer management.
>>>>>>
>>>>>> David
>>>>>>
>>>>>>> -Dmitry
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 2016-03-18 15:51, David Holmes wrote:
>>>>>>>> On 18/03/2016 10:03 PM, Cheleswer Sahu wrote:
>>>>>>>>> Hi David,
>>>>>>>>>
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: David Holmes
>>>>>>>>> Sent: Friday, March 18, 2016 2:42 PM
>>>>>>>>> To: Cheleswer Sahu; hotspot-runtime-dev at openjdk.java.net;
>>>>>>>>> serviceability-dev at openjdk.java.net
>>>>>>>>> Subject: Re: RFR[9u-dev]: 8151442: jstack doesn't close
>>>>>>>>> quotation marks properly with threads' name greater than 1996
>>>>>>>>> characters
>>>>>>>>>
>>>>>>>>> On 18/03/2016 5:54 PM, Cheleswer Sahu wrote:
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> Please review the code changes for
>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8151442.
>>>>>>>>>>
>>>>>>>>>> Webrev Link: http://cr.openjdk.java.net/~csahu/8151442/
>>>>>>>>>>
>>>>>>>>>> Bug Brief:
>>>>>>>>>>
>>>>>>>>>> In jstack thread dumps , thread name greater than 1996
>>>>>>>>>> characters doesn't close quotation marks properly.
>>>>>>>>> Anyone giving a thread a name that long deserves to get a core
>>>>>>>>> dump!
>>>>>>>>> ;-)
>>>>>>>>>
>>>>>>>>>> Problem Identified:
>>>>>>>>>>
>>>>>>>>>> Jstack is using below code to print thread name
>>>>>>>>>>
>>>>>>>>>> src/share/vm/runtime/thread.cpp
>>>>>>>>>>
>>>>>>>>>> void JavaThread::print_on(outputStream *st) const {
>>>>>>>>>>
>>>>>>>>>>        st->print("\"%s\" ", get_thread_name());
>>>>>>>>>>
>>>>>>>>>> Here "st->print()"  internally uses max buffer length as
>>>>>>>>>> O_BUFLEN (2000).
>>>>>>>>>>
>>>>>>>>>> void
>>>>>>>>>> outputStream::do_vsnprintf_and_write_with_automatic_buffer(cons
>>>>>>>>>> t
>>>>>>>>>> char* format, va_list ap, bool add_cr) {
>>>>>>>>>>
>>>>>>>>>>        char buffer[O_BUFLEN];
>>>>>>>>>>
>>>>>>>>>> do_vsnprintf_and_write_with_automatic_buffer() finally calls
>>>>>>>>>>       "vsnprintf()"  which truncates the anything greater than
>>>>>>>>>> the max size(2000). In this case thread's name(> 1996) along
>>>>>>>>>> with quotation marks (2)
>>>>>>>>>>
>>>>>>>>>> plus one terminating character exceeds the  max buffer size
>>>>>>>>>> (2000), therefore the closing quotation  marks gets truncated.
>>>>>>>>>>
>>>>>>>>>> Solution:
>>>>>>>>>>
>>>>>>>>>> Split the  "st->print("\"%s\" ", get_thread_name())" in two
>>>>>>>>>> statements
>>>>>>>>>>
>>>>>>>>>> 1.st->print("\"%s", get_thread_name());
>>>>>>>>>>
>>>>>>>>>> 2.st->print("\" ");
>>>>>>>>>>
>>>>>>>>>> This will ensure presence of closing quotation mark always.
>>>>>>>>> Can't we just limit the number of characters read by %s?
>>>>>>>>>
>>>>>>>>> Yes we can do it, but just one thing which I think of is, if the
>>>>>>>>> truncation of output inside  output stream issue get resolves as
>>>>>>>>> Dmritry suggested or O_BUFFLEN size gets increased in any future
>>>>>>>>> fix then we have to again make changes in this code, as limiting
>>>>>>>>> the no.
>>>>>>>>> of character read by %s will give truncated output . In such
>>>>>>>>> case present fix will have no effect.
>>>>>>>> Ignoring Dmitry's issue it still seems simpler/cleaner to just
>>>>>>>> add the desired precision value to the %s than to split into two
>>>>>>>> print statements. Or bite the bullet now and make the length
>>>>>>>> immaterial by breaking the name into chunks. It's as easy to fix
>>>>>>>> as to write the RFE :)
>>>>>>>>
>>>>>>>> David
>>>>>>>>
>>>>>>>>> David
>>>>>>>>>
>>>>>>>>>> Regards,
>>>>>>>>>>
>>>>>>>>>> Cheleswer
>>>>>>>>>>
>