From guangyu.zgy at alibaba-inc.com  Mon Dec  3 02:34:37 2018
From: guangyu.zgy at alibaba-inc.com (=?UTF-8?B?Z3Vhbmd5dShncmVnKSB6aHU=?=)
Date: Mon, 03 Dec 2018 10:34:37 +0800
Subject: =?UTF-8?B?5Zue5aSN77yaW1BBVENIXSBKRlIgdGhyZWFkIHNhbXBsaW5nIGlzc3Vl?=
In-Reply-To: <4168442c-b232-4cd9-a4c2-e467e5bd0ac0@default>
References: <CAC+6wjph3KF4Bc_jkTqZe9hGoF6CgbpPtx_usW7TWCfCwo6Tzw@mail.gmail.com>,
 <4168442c-b232-4cd9-a4c2-e467e5bd0ac0@default>
Message-ID: <366a3ebd-290e-4272-a49f-586b982cca45.guangyu.zgy@alibaba-inc.com>

It's nice the question is addressed. I ever met the same problem. My application has ~700 java threads, most of them run in native state, so there is little chance for threads in java state can be sampled in an interval. Then I tried a similar solution as Milan's - If the 5 attempts all failed, continue trying until one sample succeed. Then there is at least one successful java sample in each 10ms interval. 

The solution looks good, but the overhead increased significantly. So I added an switch to enable/disable native samples, and usually disabled the native samples to leave more cpu for java samples. 

Besides the solution above, there are also other workarounds. In most situation, we can run JFR in a longer time to increase java samples; we can also reduce the sampling interval to increase sampling rate as Erik mentioned.

Thanks,
Guangyu


------------------------------------------------------------------
????Markus Gronlund <markus.gronlund at oracle.com>
?????2018?11?30?(???) 22:23
????Milan Mimica <milan.mimica at gmail.com>
????hotspot-jfr-dev <hotspot-jfr-dev at openjdk.java.net>
????RE: [PATCH] JFR thread sampling issue

Hi Milan,

Thanks for pointing to this and providing a patch suggestion.

Overall it looks reasonable, but I need to take a closer look in regards to how longer sample sessions interplays with the thread smr list - we should ensure that an attempt does not wrap around the thread list.

Sorry for the delay on this issue - your overall suggestion will be incorporated in some form, but we need to be careful that it does not have hidden side effects. I will get back to you on this.

Thanks again
Markus 

-----Original Message-----
From: Milan Mimica <milan.mimica at gmail.com> 
Sent: den 19 november 2018 13:42
To: hotspot-jfr-dev at openjdk.java.net
Subject: [PATCH] JFR thread sampling issue

Hello

I was regularly using JFR to profile my service and thread sampling results have been very useful. Unfortunately, when I have switched to Java 9 and afterwards, it stopped working. The recording would catch too few samples for the results to be useful. My service has about 500 threads, most of them being on some blocked state.

With the release of Java 11, I have started digging into the JFR source code and I think I have found the problem. I think JfrThreadSampler::task_stacktrace is supposed to find at most 5 threads that are in state _thread_in_Java, or at most 1 thread that is in _thread_in_native, but instead it just picks next 5 (or 1) threads and then ignores them of they are not in right state. Without the insight into code change prior to JDK 11 I can just guess, but there are some clues that lead me to think that's how it was supposed to work. One of the clues is that sample_task.do_sample_thread returns a result that is otherwise unused.

I'm attaching a patch.
Tested test-jdk_jfr_sanity on fastdebug, and in my production.

I'm waiting for my Author status approval so I'll be able to create a proper changeset. I believe I also need a ticket for this.


--
Milan Mimica

From aazores at redhat.com  Tue Dec  4 14:04:26 2018
From: aazores at redhat.com (Andrew Azores)
Date: Tue, 4 Dec 2018 09:04:26 -0500
Subject: JFR Event for Full GCs
Message-ID: <fcd660e2-3a99-4f2d-6efc-5792942392bc@redhat.com>

Hi all,

I'm looking into a JMC bug report [0] for adding a JFR rule to detect 
Full GC events. From what I could tell playing around with JMC and then 
by reading through the JFR and JDK GC sources, there does not seem to be 
an existing Full GC event, not any event that corresponds 1:1 with a 
full collection. There is the jdk.GarbageCollection event, but I don't 
see that any of its properties can be used to reliably indicate Full GC 
vs otherwise for all collectors (or at least both G1 and CMS as 
specified in the bug report). If this assumption is wrong please let me 
know and point me in the right direction.

If a JFR event does need to be added or modified to enable tracking full 
collection occurrences, would the preferred approach be to modify the 
jdk.GarbageCollection event with a field to denote the collection type, 
or to emit an entirely new event flagging a full collection? My personal 
leaning would be toward a new event marked experimental, but I defer to 
the experts.

Once I have guidance on the questions above I would be glad to prepare 
and submit a patch for your approval.

Thanks,

[0] https://bugs.openjdk.java.net/browse/JMC-5596

-- 
Andrew Azores
Software Engineer, OpenJDK Team
Red Hat

From erik.gahlin at oracle.com  Tue Dec  4 15:26:51 2018
From: erik.gahlin at oracle.com (Erik Gahlin)
Date: Tue, 4 Dec 2018 16:26:51 +0100
Subject: JFR Event for Full GCs
In-Reply-To: <fcd660e2-3a99-4f2d-6efc-5792942392bc@redhat.com>
References: <fcd660e2-3a99-4f2d-6efc-5792942392bc@redhat.com>
Message-ID: <E76E15C6-A602-446C-AB32-9C2F96EDF610@oracle.com>

There is an OldCollection event which is typically triggered during a full collection, but is perhaps not sufficient for your use case?

Erik

> On 4 Dec 2018, at 15:04, Andrew Azores <aazores at redhat.com> wrote:
> 
> Hi all,
> 
> I'm looking into a JMC bug report [0] for adding a JFR rule to detect Full GC events. From what I could tell playing around with JMC and then by reading through the JFR and JDK GC sources, there does not seem to be an existing Full GC event, not any event that corresponds 1:1 with a full collection. There is the jdk.GarbageCollection event, but I don't see that any of its properties can be used to reliably indicate Full GC vs otherwise for all collectors (or at least both G1 and CMS as specified in the bug report). If this assumption is wrong please let me know and point me in the right direction.
> 
> If a JFR event does need to be added or modified to enable tracking full collection occurrences, would the preferred approach be to modify the jdk.GarbageCollection event with a field to denote the collection type, or to emit an entirely new event flagging a full collection? My personal leaning would be toward a new event marked experimental, but I defer to the experts.
> 
> Once I have guidance on the questions above I would be glad to prepare and submit a patch for your approval.
> 
> Thanks,
> 
> [0] https://bugs.openjdk.java.net/browse/JMC-5596
> 
> -- 
> Andrew Azores
> Software Engineer, OpenJDK Team
> Red Hat


From marcus.hirt at oracle.com  Tue Dec  4 16:56:11 2018
From: marcus.hirt at oracle.com (Marcus Hirt)
Date: Tue, 4 Dec 2018 17:56:11 +0100
Subject: JFR Event for Full GCs
In-Reply-To: <E76E15C6-A602-446C-AB32-9C2F96EDF610@oracle.com>
References: <fcd660e2-3a99-4f2d-6efc-5792942392bc@redhat.com>
 <E76E15C6-A602-446C-AB32-9C2F96EDF610@oracle.com>
Message-ID: <2954FEC8-0EF8-40FC-B2AF-31A8FCA4FC3D@oracle.com>

On a related note, it would be nice to have events (with stack traces) for System.gc() calls:
https://bugs.openjdk.java.net/browse/JDK-8003216

/M

- Excuse me if terse; sent from my phone.

> On 4 Dec 2018, at 16:26, Erik Gahlin <erik.gahlin at oracle.com> wrote:
> 
> There is an OldCollection event which is typically triggered during a full collection, but is perhaps not sufficient for your use case?
> 
> Erik
> 
>> On 4 Dec 2018, at 15:04, Andrew Azores <aazores at redhat.com> wrote:
>> 
>> Hi all,
>> 
>> I'm looking into a JMC bug report [0] for adding a JFR rule to detect Full GC events. From what I could tell playing around with JMC and then by reading through the JFR and JDK GC sources, there does not seem to be an existing Full GC event, not any event that corresponds 1:1 with a full collection. There is the jdk.GarbageCollection event, but I don't see that any of its properties can be used to reliably indicate Full GC vs otherwise for all collectors (or at least both G1 and CMS as specified in the bug report). If this assumption is wrong please let me know and point me in the right direction.
>> 
>> If a JFR event does need to be added or modified to enable tracking full collection occurrences, would the preferred approach be to modify the jdk.GarbageCollection event with a field to denote the collection type, or to emit an entirely new event flagging a full collection? My personal leaning would be toward a new event marked experimental, but I defer to the experts.
>> 
>> Once I have guidance on the questions above I would be glad to prepare and submit a patch for your approval.
>> 
>> Thanks,
>> 
>> [0] https://bugs.openjdk.java.net/browse/JMC-5596
>> 
>> -- 
>> Andrew Azores
>> Software Engineer, OpenJDK Team
>> Red Hat
> 

From erik.gahlin at oracle.com  Tue Dec  4 18:01:05 2018
From: erik.gahlin at oracle.com (Erik Gahlin)
Date: Tue, 4 Dec 2018 19:01:05 +0100
Subject: JFR Event for Full GCs
In-Reply-To: <2954FEC8-0EF8-40FC-B2AF-31A8FCA4FC3D@oracle.com>
References: <fcd660e2-3a99-4f2d-6efc-5792942392bc@redhat.com>
 <E76E15C6-A602-446C-AB32-9C2F96EDF610@oracle.com>
 <2954FEC8-0EF8-40FC-B2AF-31A8FCA4FC3D@oracle.com>
Message-ID: <5C06C0E1.4040207@oracle.com>

Should Runtime::gc(), DiagnosticCommandMBean::gcRun() and 
MemoryMXBean::gc() also be included?

> On a related note, it would be nice to have events (with stack traces) 
> for System.gc() calls:
> https://bugs.openjdk.java.net/browse/JDK-8003216
>
> /M
>
> - Excuse me if terse; sent from my phone.
>
> On 4 Dec 2018, at 16:26, Erik Gahlin <erik.gahlin at oracle.com 
> <mailto:erik.gahlin at oracle.com>> wrote:
>
>> There is an OldCollection event which is typically triggered during a 
>> full collection, but is perhaps not sufficient for your use case?
>>
>> Erik
>>
>>> On 4 Dec 2018, at 15:04, Andrew Azores <aazores at redhat.com 
>>> <mailto:aazores at redhat.com>> wrote:
>>>
>>> Hi all,
>>>
>>> I'm looking into a JMC bug report [0] for adding a JFR rule to 
>>> detect Full GC events. From what I could tell playing around with 
>>> JMC and then by reading through the JFR and JDK GC sources, there 
>>> does not seem to be an existing Full GC event, not any event that 
>>> corresponds 1:1 with a full collection. There is the 
>>> jdk.GarbageCollection event, but I don't see that any of its 
>>> properties can be used to reliably indicate Full GC vs otherwise for 
>>> all collectors (or at least both G1 and CMS as specified in the bug 
>>> report). If this assumption is wrong please let me know and point me 
>>> in the right direction.
>>>
>>> If a JFR event does need to be added or modified to enable tracking 
>>> full collection occurrences, would the preferred approach be to 
>>> modify the jdk.GarbageCollection event with a field to denote the 
>>> collection type, or to emit an entirely new event flagging a full 
>>> collection? My personal leaning would be toward a new event marked 
>>> experimental, but I defer to the experts.
>>>
>>> Once I have guidance on the questions above I would be glad to 
>>> prepare and submit a patch for your approval.
>>>
>>> Thanks,
>>>
>>> [0] https://bugs.openjdk.java.net/browse/JMC-5596
>>>
>>> -- 
>>> Andrew Azores
>>> Software Engineer, OpenJDK Team
>>> Red Hat
>>


From marcus at hirt.se  Tue Dec  4 18:10:17 2018
From: marcus at hirt.se (Marcus Hirt)
Date: Tue, 4 Dec 2018 19:10:17 +0100
Subject: SV: JFR Event for Full GCs
In-Reply-To: <5C06C0E1.4040207@oracle.com>
References: <fcd660e2-3a99-4f2d-6efc-5792942392bc@redhat.com>
 <E76E15C6-A602-446C-AB32-9C2F96EDF610@oracle.com>
 <2954FEC8-0EF8-40FC-B2AF-31A8FCA4FC3D@oracle.com>
 <5C06C0E1.4040207@oracle.com>
Message-ID: <4b2001d48bfc$9c909ed0$d5b1dc70$@hirt.se>

Aye, every user call that attempts to trigger a gc (regardless if it succeeds 
or not). The stack trace would show how the attempt was made.

/M
-----Ursprungligt meddelande-----
Fr?n: hotspot-jfr-dev <hotspot-jfr-dev-bounces at openjdk.java.net> F?r Erik Gahlin
Skickat: den 4 december 2018 19:01
Till: Marcus Hirt <marcus.hirt at oracle.com>
Kopia: hotspot-jfr-dev at openjdk.java.net
?mne: Re: JFR Event for Full GCs

Should Runtime::gc(), DiagnosticCommandMBean::gcRun() and
MemoryMXBean::gc() also be included?

> On a related note, it would be nice to have events (with stack traces) 
> for System.gc() calls:
> https://bugs.openjdk.java.net/browse/JDK-8003216
>
> /M
>
> - Excuse me if terse; sent from my phone.
>
> On 4 Dec 2018, at 16:26, Erik Gahlin <erik.gahlin at oracle.com 
> <mailto:erik.gahlin at oracle.com>> wrote:
>
>> There is an OldCollection event which is typically triggered during a 
>> full collection, but is perhaps not sufficient for your use case?
>>
>> Erik
>>
>>> On 4 Dec 2018, at 15:04, Andrew Azores <aazores at redhat.com 
>>> <mailto:aazores at redhat.com>> wrote:
>>>
>>> Hi all,
>>>
>>> I'm looking into a JMC bug report [0] for adding a JFR rule to 
>>> detect Full GC events. From what I could tell playing around with 
>>> JMC and then by reading through the JFR and JDK GC sources, there 
>>> does not seem to be an existing Full GC event, not any event that 
>>> corresponds 1:1 with a full collection. There is the 
>>> jdk.GarbageCollection event, but I don't see that any of its 
>>> properties can be used to reliably indicate Full GC vs otherwise for 
>>> all collectors (or at least both G1 and CMS as specified in the bug 
>>> report). If this assumption is wrong please let me know and point me 
>>> in the right direction.
>>>
>>> If a JFR event does need to be added or modified to enable tracking 
>>> full collection occurrences, would the preferred approach be to 
>>> modify the jdk.GarbageCollection event with a field to denote the 
>>> collection type, or to emit an entirely new event flagging a full 
>>> collection? My personal leaning would be toward a new event marked 
>>> experimental, but I defer to the experts.
>>>
>>> Once I have guidance on the questions above I would be glad to 
>>> prepare and submit a patch for your approval.
>>>
>>> Thanks,
>>>
>>> [0] https://bugs.openjdk.java.net/browse/JMC-5596
>>>
>>> --
>>> Andrew Azores
>>> Software Engineer, OpenJDK Team
>>> Red Hat
>>



From erik.gahlin at oracle.com  Wed Dec  5 17:02:54 2018
From: erik.gahlin at oracle.com (Erik Gahlin)
Date: Wed, 5 Dec 2018 18:02:54 +0100
Subject: [URGENT] 8214896: JFR Tool left files behind
Message-ID: <5C0804BE.2070605@oracle.com>

Hi,

Could I have a review of that fixes a compilation error due to old files 
being left behind.

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

Webrev:
http://cr.openjdk.java.net/~egahlin/8214896/

Thanks
Erik

From markus.gronlund at oracle.com  Wed Dec  5 17:10:23 2018
From: markus.gronlund at oracle.com (Markus Gronlund)
Date: Wed, 5 Dec 2018 09:10:23 -0800 (PST)
Subject: [URGENT] 8214896: JFR Tool left files behind
In-Reply-To: <5C0804BE.2070605@oracle.com>
References: <5C0804BE.2070605@oracle.com>
Message-ID: <bc090e06-5b9a-4e7f-9d86-4f173bb469bc@default>

This is building again with the patch.

Looks good.

Markus

-----Original Message-----
From: Erik Gahlin 
Sent: den 5 december 2018 18:03
To: hotspot-jfr-dev at openjdk.java.net
Subject: [URGENT] 8214896: JFR Tool left files behind

Hi,

Could I have a review of that fixes a compilation error due to old files being left behind.

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

Webrev:
http://cr.openjdk.java.net/~egahlin/8214896/

Thanks
Erik

From aazores at redhat.com  Wed Dec  5 17:23:04 2018
From: aazores at redhat.com (Andrew Azores)
Date: Wed, 5 Dec 2018 12:23:04 -0500
Subject: JFR Event for Full GCs
In-Reply-To: <E76E15C6-A602-446C-AB32-9C2F96EDF610@oracle.com>
References: <fcd660e2-3a99-4f2d-6efc-5792942392bc@redhat.com>
 <E76E15C6-A602-446C-AB32-9C2F96EDF610@oracle.com>
Message-ID: <8684d5d4-c751-3c8b-723e-3cb345109287@redhat.com>

Hmm. It's along the right lines (and I had overlooked it before) but I 
don't think this event meets the requirement. I modified my JMC testing 
rule to look for those events while running my reproducer applet with 
-XX:+UseG1GC -XX:+PrintGCDetails. My run saw one OldGarbageCollection 
event emitted but the GC log output does not show any Full GC events. I 
also tried reading through the JFR and GC sources again to trace the 
execution path where this event is emitted, and although I wasn't 100% 
confident, it didn't look to me like this event is 1:1 with Full 
collections - perhaps a Full collection implies this event emission but 
not vice-versa? From my limited understanding of the GC phases and 
generations this would seem to make sense.

On 2018-12-04 10:26 a.m., Erik Gahlin wrote:
> There is an OldCollection event which is typically triggered during a full collection, but is perhaps not sufficient for your use case?
> 
> Erik
> 
>> On 4 Dec 2018, at 15:04, Andrew Azores <aazores at redhat.com> wrote:
>>
>> Hi all,
>>
>> I'm looking into a JMC bug report [0] for adding a JFR rule to detect Full GC events. From what I could tell playing around with JMC and then by reading through the JFR and JDK GC sources, there does not seem to be an existing Full GC event, not any event that corresponds 1:1 with a full collection. There is the jdk.GarbageCollection event, but I don't see that any of its properties can be used to reliably indicate Full GC vs otherwise for all collectors (or at least both G1 and CMS as specified in the bug report). If this assumption is wrong please let me know and point me in the right direction.
>>
>> If a JFR event does need to be added or modified to enable tracking full collection occurrences, would the preferred approach be to modify the jdk.GarbageCollection event with a field to denote the collection type, or to emit an entirely new event flagging a full collection? My personal leaning would be toward a new event marked experimental, but I defer to the experts.
>>
>> Once I have guidance on the questions above I would be glad to prepare and submit a patch for your approval.
>>
>> Thanks,
>>
>> [0] https://bugs.openjdk.java.net/browse/JMC-5596
>>
>> -- 
>> Andrew Azores
>> Software Engineer, OpenJDK Team
>> Red Hat
> 


-- 
Andrew Azores
Software Engineer, OpenJDK Team
Red Hat

From thomas.schatzl at oracle.com  Wed Dec  5 21:54:42 2018
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Wed, 05 Dec 2018 22:54:42 +0100
Subject: JFR Event for Full GCs
In-Reply-To: <8684d5d4-c751-3c8b-723e-3cb345109287@redhat.com>
References: <fcd660e2-3a99-4f2d-6efc-5792942392bc@redhat.com>
 <E76E15C6-A602-446C-AB32-9C2F96EDF610@oracle.com>
 <8684d5d4-c751-3c8b-723e-3cb345109287@redhat.com>
Message-ID: <19484af89d0f8659a97e0ea69962cadebd9c26a2.camel@oracle.com>

Hi,

On Wed, 2018-12-05 at 12:23 -0500, Andrew Azores wrote:
> Hmm. It's along the right lines (and I had overlooked it before) but
> I don't think this event meets the requirement. I modified my JMC
> testing rule to look for those events while running my reproducer
> applet with -XX:+UseG1GC -XX:+PrintGCDetails. My run saw one
> OldGarbageCollection event emitted but the GC log output does not
> show any Full GC events. I also tried reading through the JFR and GC
> sources again to trace the execution path where this event is
> emitted, and although I wasn't 100% confident, it didn't look to me
> like this event is 1:1 with Full collections - perhaps a Full
> collection implies this event emission but not vice-versa? From my
> limited understanding of the GC phases and generations this would
> seem to make sense.

  iirc a completed marking cycle also counts as "full" collection in
some cases as it completely considers the old generation too.
PrintGCDetails should show them. 

(Young collections may actually also reclaim space in old gen but does
not send this event - so actually this OldGarbageCollection event may
actually be considered as some kind of backwards compatibility hack for
G1 in any case)

Thanks,
  Thomas



From mikhailo.seledtsov at oracle.com  Wed Dec  5 22:21:42 2018
From: mikhailo.seledtsov at oracle.com (Mikhailo Seledtsov)
Date: Wed, 05 Dec 2018 14:21:42 -0800
Subject: RFR(XS): 8214906: [TESTBUG] jfr/event/sampling/TestNative.java fails
 with UnsatisfiedLinkError
Message-ID: <5C084F76.8020108@oracle.com>

Please review this one-liner fix, renaming the native method to reflect 
the new package path:

========== Diff:
         --- a/test/jdk/jdk/jfr/event/sampling/libTestNative.c
         +++ b/test/jdk/jdk/jfr/event/sampling/libTestNative.c
         @@ -30,7 +30,7 @@
         #include <unistd.h>
         #endif

         -JNIEXPORT void JNICALL 
Java_com_oracle_jfr_event_sampling_TestNative_longTime
         +JNIEXPORT void JNICALL 
Java_jdk_jfr_event_sampling_TestNative_longTime

========= Testing
Locally (Linux-x64): ran the affected test
    - via 'jtreg -nativepath: " commands - PASS
    - via "make test": PASS
Lab:
   - ran automatically on multiple platforms - PASS


Thank you,
Misha

From markus.gronlund at oracle.com  Wed Dec  5 23:48:31 2018
From: markus.gronlund at oracle.com (Markus Gronlund)
Date: Wed, 5 Dec 2018 15:48:31 -0800 (PST)
Subject: RFR(XS): 8214906: [TESTBUG] jfr/event/sampling/TestNative.java
 fails with UnsatisfiedLinkError
In-Reply-To: <5C084F76.8020108@oracle.com>
References: <5C084F76.8020108@oracle.com>
Message-ID: <f0ce23fd-4ad4-4274-84ab-cdb654fde631@default>

Hi Misha,

Looks good, thanks for fixing.

Markus

-----Original Message-----
From: Mikhailo Seledtsov 
Sent: den 5 december 2018 23:22
To: hotspot-jfr-dev at openjdk.java.net
Subject: RFR(XS): 8214906: [TESTBUG] jfr/event/sampling/TestNative.java fails with UnsatisfiedLinkError

Please review this one-liner fix, renaming the native method to reflect the new package path:

========== Diff:
         --- a/test/jdk/jdk/jfr/event/sampling/libTestNative.c
         +++ b/test/jdk/jdk/jfr/event/sampling/libTestNative.c
         @@ -30,7 +30,7 @@
         #include <unistd.h>
         #endif

         -JNIEXPORT void JNICALL
Java_com_oracle_jfr_event_sampling_TestNative_longTime
         +JNIEXPORT void JNICALL
Java_jdk_jfr_event_sampling_TestNative_longTime

========= Testing
Locally (Linux-x64): ran the affected test
    - via 'jtreg -nativepath: " commands - PASS
    - via "make test": PASS
Lab:
   - ran automatically on multiple platforms - PASS


Thank you,
Misha

From mikhailo.seledtsov at oracle.com  Thu Dec  6 01:32:36 2018
From: mikhailo.seledtsov at oracle.com (Mikhailo Seledtsov)
Date: Wed, 05 Dec 2018 17:32:36 -0800
Subject: RFR(XS): 8214906: [TESTBUG] jfr/event/sampling/TestNative.java
 fails with UnsatisfiedLinkError
In-Reply-To: <f0ce23fd-4ad4-4274-84ab-cdb654fde631@default>
References: <5C084F76.8020108@oracle.com>
 <f0ce23fd-4ad4-4274-84ab-cdb654fde631@default>
Message-ID: <5C087C34.7080701@oracle.com>

Thank you,

Misha

On 12/5/18, 3:48 PM, Markus Gronlund wrote:
> Hi Misha,
>
> Looks good, thanks for fixing.
>
> Markus
>
> -----Original Message-----
> From: Mikhailo Seledtsov
> Sent: den 5 december 2018 23:22
> To: hotspot-jfr-dev at openjdk.java.net
> Subject: RFR(XS): 8214906: [TESTBUG] jfr/event/sampling/TestNative.java fails with UnsatisfiedLinkError
>
> Please review this one-liner fix, renaming the native method to reflect the new package path:
>
> ========== Diff:
>           --- a/test/jdk/jdk/jfr/event/sampling/libTestNative.c
>           +++ b/test/jdk/jdk/jfr/event/sampling/libTestNative.c
>           @@ -30,7 +30,7 @@
>           #include<unistd.h>
>           #endif
>
>           -JNIEXPORT void JNICALL
> Java_com_oracle_jfr_event_sampling_TestNative_longTime
>           +JNIEXPORT void JNICALL
> Java_jdk_jfr_event_sampling_TestNative_longTime
>
> ========= Testing
> Locally (Linux-x64): ran the affected test
>      - via 'jtreg -nativepath: " commands - PASS
>      - via "make test": PASS
> Lab:
>     - ran automatically on multiple platforms - PASS
>
>
> Thank you,
> Misha

From erik.gahlin at oracle.com  Thu Dec  6 15:25:11 2018
From: erik.gahlin at oracle.com (Erik Gahlin)
Date: Thu, 6 Dec 2018 16:25:11 +0100
Subject: RFR: 8214925: JFR tool fails to execute
Message-ID: <5C093F57.4050303@oracle.com>

Hi,

Could I have a review of a fix of a test bug that prevents the 
JDK_HOME/bin/jfr tool to launch on Mac OS X and Linux.

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

Webrev:
http://cr.openjdk.java.net/~egahlin/8214925/

Testing:
tier1, tier2, tier5

Thanks
Erik

From markus.gronlund at oracle.com  Thu Dec  6 16:56:06 2018
From: markus.gronlund at oracle.com (Markus Gronlund)
Date: Thu, 6 Dec 2018 08:56:06 -0800 (PST)
Subject: RFR: 8214925: JFR tool fails to execute
In-Reply-To: <5C093F57.4050303@oracle.com>
References: <5C093F57.4050303@oracle.com>
Message-ID: <dda13392-3ded-4da1-949a-6867f5019dae@default>

Hi Erik,

Looks good.

Markus

-----Original Message-----
From: Erik Gahlin 
Sent: den 6 december 2018 16:25
To: hotspot-jfr-dev at openjdk.java.net
Subject: RFR: 8214925: JFR tool fails to execute

Hi,

Could I have a review of a fix of a test bug that prevents the JDK_HOME/bin/jfr tool to launch on Mac OS X and Linux.

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

Webrev:
http://cr.openjdk.java.net/~egahlin/8214925/

Testing:
tier1, tier2, tier5

Thanks
Erik

From mikhailo.seledtsov at oracle.com  Thu Dec  6 19:28:16 2018
From: mikhailo.seledtsov at oracle.com (Mikhailo Seledtsov)
Date: Thu, 06 Dec 2018 11:28:16 -0800
Subject: RFR: 8214925: JFR tool fails to execute
In-Reply-To: <dda13392-3ded-4da1-949a-6867f5019dae@default>
References: <5C093F57.4050303@oracle.com>
 <dda13392-3ded-4da1-949a-6867f5019dae@default>
Message-ID: <5C097850.3030106@oracle.com>

+1

Misha

On 12/6/18, 8:56 AM, Markus Gronlund wrote:
> Hi Erik,
>
> Looks good.
>
> Markus
>
> -----Original Message-----
> From: Erik Gahlin
> Sent: den 6 december 2018 16:25
> To: hotspot-jfr-dev at openjdk.java.net
> Subject: RFR: 8214925: JFR tool fails to execute
>
> Hi,
>
> Could I have a review of a fix of a test bug that prevents the JDK_HOME/bin/jfr tool to launch on Mac OS X and Linux.
>
> Bug:
> https://bugs.openjdk.java.net/browse/JDK-8214925
>
> Webrev:
> http://cr.openjdk.java.net/~egahlin/8214925/
>
> Testing:
> tier1, tier2, tier5
>
> Thanks
> Erik

From aazores at redhat.com  Fri Dec  7 14:11:28 2018
From: aazores at redhat.com (Andrew Azores)
Date: Fri, 7 Dec 2018 09:11:28 -0500
Subject: JFR Event for Full GCs
In-Reply-To: <19484af89d0f8659a97e0ea69962cadebd9c26a2.camel@oracle.com>
References: <fcd660e2-3a99-4f2d-6efc-5792942392bc@redhat.com>
 <E76E15C6-A602-446C-AB32-9C2F96EDF610@oracle.com>
 <8684d5d4-c751-3c8b-723e-3cb345109287@redhat.com>
 <19484af89d0f8659a97e0ea69962cadebd9c26a2.camel@oracle.com>
Message-ID: <2c28b84b-25c8-9080-8efa-4983242d2601@redhat.com>

Hi,

On 2018-12-05 4:54 p.m., Thomas Schatzl wrote:
> Hi,
> 
> On Wed, 2018-12-05 at 12:23 -0500, Andrew Azores wrote:
>> Hmm. It's along the right lines (and I had overlooked it before) but
>> I don't think this event meets the requirement. I modified my JMC
>> testing rule to look for those events while running my reproducer
>> applet with -XX:+UseG1GC -XX:+PrintGCDetails. My run saw one
>> OldGarbageCollection event emitted but the GC log output does not
>> show any Full GC events. I also tried reading through the JFR and GC
>> sources again to trace the execution path where this event is
>> emitted, and although I wasn't 100% confident, it didn't look to me
>> like this event is 1:1 with Full collections - perhaps a Full
>> collection implies this event emission but not vice-versa? From my
>> limited understanding of the GC phases and generations this would
>> seem to make sense.
> 
>    iirc a completed marking cycle also counts as "full" collection in
> some cases as it completely considers the old generation too.
> PrintGCDetails should show them.
> 
> (Young collections may actually also reclaim space in old gen but does
> not send this event - so actually this OldGarbageCollection event may
> actually be considered as some kind of backwards compatibility hack for
> G1 in any case)
> 
> Thanks,
>    Thomas
> 
> 

Sorry, I'm not sure I've fully understood. Are you saying that the 
OldGarbageCollection event really should signify that a full collection 
has occurred? I don't think I saw any instances of a marking cycle 
showing as a full collection in the logs, but maybe it was there and I 
just didn't know what I was looking for.

The GarbageCollection event's gcName field seems that it may actually do 
the trick for G1, since G1 has distinct gcNames for G1New/G1Old/*G1Full* 
which are tagged on by the various GCTracers. Testing a JMC rule that 
looks for those and comparing its results to PrintGCDetails looks like 
it is working as expected, with one event seen for each "Pause Full" in 
the logs. Should OldGarbageCollection be a CMS analog to these events?

-- 
Andrew Azores
Software Engineer, OpenJDK Team
Red Hat

From thomas.schatzl at oracle.com  Fri Dec  7 14:51:41 2018
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Fri, 07 Dec 2018 15:51:41 +0100
Subject: JFR Event for Full GCs
In-Reply-To: <2c28b84b-25c8-9080-8efa-4983242d2601@redhat.com>
References: <fcd660e2-3a99-4f2d-6efc-5792942392bc@redhat.com>
 <E76E15C6-A602-446C-AB32-9C2F96EDF610@oracle.com>
 <8684d5d4-c751-3c8b-723e-3cb345109287@redhat.com>
 <19484af89d0f8659a97e0ea69962cadebd9c26a2.camel@oracle.com>
 <2c28b84b-25c8-9080-8efa-4983242d2601@redhat.com>
Message-ID: <b5dd5c0b85378ba6f2ee5ed9d295178a5f650d89.camel@oracle.com>

Hi,

On Fri, 2018-12-07 at 09:11 -0500, Andrew Azores wrote:
> Hi,
> 
> On 2018-12-05 4:54 p.m., Thomas Schatzl wrote:
> > Hi,
> > 
> > On Wed, 2018-12-05 at 12:23 -0500, Andrew Azores wrote:
> > > Hmm. It's along the right lines (and I had overlooked it before)
> > > but I don't think this event meets the requirement. I modified my
> > > JMC testing rule to look for those events while running my
> > > reproducer applet with -XX:+UseG1GC -XX:+PrintGCDetails. My run
> > > saw one OldGarbageCollection event emitted but the GC log output
> > > does not show any Full GC events. I also tried reading through
> > > the JFR and GC sources again to trace the execution path where
> > > this event is emitted, and although I wasn't 100% confident, it
> > > didn't look to me like this event is 1:1 with Full collections -
> > > perhaps a Full collection implies this event emission but not
> > > vice-versa? From my limited understanding of the GC phases and
> > > generations this would seem to make sense.
> > 
> >    iirc a completed marking cycle also counts as "full" collection
> > in some cases as it completely considers the old generation too.
> > PrintGCDetails should show them.
> > 
> > (Young collections may actually also reclaim space in old gen but
> > does not send this event - so actually this OldGarbageCollection
> > event may actually be considered as some kind of backwards
> > compatibility hack for G1 in any case)
> > 
> > Thanks,
> >    Thomas
> > 
> 
> Sorry, I'm not sure I've fully understood. Are you saying that the 
> OldGarbageCollection event really should signify that a full
> collection has occurred? I don't think I saw any instances of a
> marking cycle showing as a full collection in the logs, but maybe it
> was there and I just didn't know what I was looking for.

Since the OldGarbageCollection event is not well defined, it seems
purely incidental that it works (or not) depending on what you believe
it indicates.

The situation gets worse because particularly with G1 it is a bit
unclear (to me) what an OldGarbageCollection event actually indicates.

Since G1 may always collect the old generation with any GC, does this
mean it should always send that event or not (or only if it also
collects parts of the old gen; should G1 also send the event during the
remark phase where it also collects completely empty old gen regions
instead of the end of concurrent mark)?

Or is it reserved for the typically more time consuming events like stw
full gc, and eventually concurrent cycle for backwards compatibility to
Serial and Parallel where the situation is relatively clear?

>From very briefly looking at jdk11 sources, it should trigger for both
concurrent cycle end and regular Full GC in G1. Not so sure whether
latest JDK8u also triggers it at concurrent cycle end from looking
there even more briefly.

For CMS (which should not have changed since jdk8u, so assuming the
code is the same), it looks like it is sent at both concurrent cycle
end and stw old generation compaction.

> The GarbageCollection event's gcName field seems that it may actually
> do the trick for G1, since G1 has distinct gcNames for
> G1New/G1Old/*G1Full* which are tagged on by the various GCTracers.  

I wonder what "G1Old" means - probably Mixed GC?

> Testing a JMC rule that looks for those and comparing its results to
> PrintGCDetails looks like it is working as expected, with one event
> seen for each "Pause Full" in  the logs. Should OldGarbageCollection
> be a CMS analog to these events?

I recommend using this event and the gcname field for CMS too as it
seems to work currently. As mentioned, CMS should send
OldGarbageCollection both for stw full gc and end of concurrent cycle
afaict (without testing).

Hth,
  Thomas



From stooke at redhat.com  Mon Dec 10 15:25:20 2018
From: stooke at redhat.com (Simon Tooke)
Date: Mon, 10 Dec 2018 10:25:20 -0500
Subject: RFR: 8214776: Avoid GCC 8.X strncpy() errors in JFR code
Message-ID: <995483f8-a9d8-6b58-45ba-7ce15725a586@redhat.com>

This small patch fixes some simple warnings in JFR code, found by GCC 8.1
Essentially, any code sequence of the pattern

    int l = strlen(somestring)
    char* buffer = malloc(l + 1)
    strncpy(buffer, somestring, l)
    buffer[l] = 0

is replaced by

    int len = strlen(somestring)
    char* buffer = malloc(len + 1)
    strncpy(buffer, somestring, len + 1)

Bug: https://bugs.openjdk.java.net/browse/JDK-8214776
Webrev:
http://cr.openjdk.java.net/~sgehwolf/webrevs/stooke/JDK-8214776/02/webrev/

From markus.gronlund at oracle.com  Mon Dec 10 15:31:35 2018
From: markus.gronlund at oracle.com (Markus Gronlund)
Date: Mon, 10 Dec 2018 07:31:35 -0800 (PST)
Subject: RFR: 8214776: Avoid GCC 8.X strncpy() errors in JFR code
In-Reply-To: <995483f8-a9d8-6b58-45ba-7ce15725a586@redhat.com>
References: <995483f8-a9d8-6b58-45ba-7ce15725a586@redhat.com>
Message-ID: <0d8373c4-756f-4422-8bb9-1d5be3de3c60@default>

Hi Simon,

Looks good, thanks for fixing.

Markus

-----Original Message-----
From: Simon Tooke <stooke at redhat.com> 
Sent: den 10 december 2018 16:25
To: hotspot-jfr-dev at openjdk.java.net
Subject: RFR: 8214776: Avoid GCC 8.X strncpy() errors in JFR code

This small patch fixes some simple warnings in JFR code, found by GCC 8.1 Essentially, any code sequence of the pattern

    int l = strlen(somestring)
    char* buffer = malloc(l + 1)
    strncpy(buffer, somestring, l)
    buffer[l] = 0

is replaced by

    int len = strlen(somestring)
    char* buffer = malloc(len + 1)
    strncpy(buffer, somestring, len + 1)

Bug: https://bugs.openjdk.java.net/browse/JDK-8214776
Webrev:
http://cr.openjdk.java.net/~sgehwolf/webrevs/stooke/JDK-8214776/02/webrev/

From erik.gahlin at oracle.com  Mon Dec 10 20:42:18 2018
From: erik.gahlin at oracle.com (Erik Gahlin)
Date: Mon, 10 Dec 2018 21:42:18 +0100
Subject: RFR: 8165675: Trace event for thread park has incorrect unit for
 timeout
Message-ID: <5C0ECFAA.4090204@oracle.com>

Hi,

Could I have a fix of a bug in the ThreadPark event.

The field "timeout" was incorrectly used for both 
LockSupport.parkNanos(nanos) and LockSupport.parkUntil(epochMillis). Fix 
is to use two fields, "timeout" and "until", with different content 
types. I also improved the unit test so it verifies the contents of the 
fields. To make it work,  I also had to update test framework and the 
print command of the jfr tool to handle missing values.

For some reason, the test TestEnoughPermission started to fail because 
it tried to access a class in a restricted package 
(sun.util.locale.provider). Fix was to not use String.format in the 
test. Not sure why it happened, but perhaps due to class initialization 
now happening in a different order.

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

Webrev:
http://cr.openjdk.java.net/~egahlin/8165675/

Thanks
Erik

From erik.gahlin at oracle.com  Mon Dec 10 21:30:54 2018
From: erik.gahlin at oracle.com (Erik Gahlin)
Date: Mon, 10 Dec 2018 22:30:54 +0100
Subject: RFR: 8214750: Unnecessary <p> tags in jfr classes
Message-ID: <5C0EDB0E.20104@oracle.com>

Hi,

Could I have a review of this docs fix that removes unnecessary <p> ?

Webrev:
http://cr.openjdk.java.net/~egahlin/8214750/

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

Thanks
Erik

From markus.gronlund at oracle.com  Mon Dec 10 21:36:17 2018
From: markus.gronlund at oracle.com (Markus Gronlund)
Date: Mon, 10 Dec 2018 13:36:17 -0800 (PST)
Subject: RFR: 8214750: Unnecessary <p> tags in jfr classes
In-Reply-To: <5C0EDB0E.20104@oracle.com>
References: <5C0EDB0E.20104@oracle.com>
Message-ID: <6cd4d32a-660e-478a-b20c-6b1e59be92ab@default>

Looks good.

Markus


-----Original Message-----
From: Erik Gahlin 
Sent: den 10 december 2018 22:31
To: hotspot-jfr-dev at openjdk.java.net
Subject: RFR: 8214750: Unnecessary <p> tags in jfr classes

Hi,

Could I have a review of this docs fix that removes unnecessary <p> ?

Webrev:
http://cr.openjdk.java.net/~egahlin/8214750/

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

Thanks
Erik

From sgehwolf at redhat.com  Tue Dec 11 11:01:18 2018
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Tue, 11 Dec 2018 12:01:18 +0100
Subject: RFR: 8214776: Avoid GCC 8.X strncpy() errors in JFR code
In-Reply-To: <0d8373c4-756f-4422-8bb9-1d5be3de3c60@default>
References: <995483f8-a9d8-6b58-45ba-7ce15725a586@redhat.com>
 <0d8373c4-756f-4422-8bb9-1d5be3de3c60@default>
Message-ID: <9aa4f95f7b03455082df573afd8a62f18d81dcea.camel@redhat.com>

Hi Simon,

I'll sponsor this for you.

Thanks,
Severin

On Mon, 2018-12-10 at 07:31 -0800, Markus Gronlund wrote:
> Hi Simon,
> 
> Looks good, thanks for fixing.
> 
> Markus
> 
> -----Original Message-----
> From: Simon Tooke <stooke at redhat.com> 
> Sent: den 10 december 2018 16:25
> To: hotspot-jfr-dev at openjdk.java.net
> Subject: RFR: 8214776: Avoid GCC 8.X strncpy() errors in JFR code
> 
> This small patch fixes some simple warnings in JFR code, found by GCC 8.1 Essentially, any code sequence of the pattern
> 
>     int l = strlen(somestring)
>     char* buffer = malloc(l + 1)
>     strncpy(buffer, somestring, l)
>     buffer[l] = 0
> 
> is replaced by
> 
>     int len = strlen(somestring)
>     char* buffer = malloc(len + 1)
>     strncpy(buffer, somestring, len + 1)
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8214776
> Webrev:
> http://cr.openjdk.java.net/~sgehwolf/webrevs/stooke/JDK-8214776/02/webrev/


From markus.gronlund at oracle.com  Tue Dec 11 13:26:13 2018
From: markus.gronlund at oracle.com (Markus Gronlund)
Date: Tue, 11 Dec 2018 05:26:13 -0800 (PST)
Subject: RFR: 8165675: Trace event for thread park has incorrect unit for
 timeout
In-Reply-To: <5C0ECFAA.4090204@oracle.com>
References: <5C0ECFAA.4090204@oracle.com>
Message-ID: <f73957f7-dd87-4d76-9841-11ea01d4d095@default>

Hi Erik,

Looks good, thanks for fixing this.

Markus

-----Original Message-----
From: Erik Gahlin 
Sent: den 10 december 2018 21:42
To: hotspot-jfr-dev at openjdk.java.net
Subject: RFR: 8165675: Trace event for thread park has incorrect unit for timeout

Hi,

Could I have a fix of a bug in the ThreadPark event.

The field "timeout" was incorrectly used for both
LockSupport.parkNanos(nanos) and LockSupport.parkUntil(epochMillis). Fix is to use two fields, "timeout" and "until", with different content types. I also improved the unit test so it verifies the contents of the fields. To make it work,  I also had to update test framework and the print command of the jfr tool to handle missing values.

For some reason, the test TestEnoughPermission started to fail because it tried to access a class in a restricted package (sun.util.locale.provider). Fix was to not use String.format in the test. Not sure why it happened, but perhaps due to class initialization now happening in a different order.

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

Webrev:
http://cr.openjdk.java.net/~egahlin/8165675/

Thanks
Erik

From sgehwolf at redhat.com  Tue Dec 11 13:47:09 2018
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Tue, 11 Dec 2018 14:47:09 +0100
Subject: RFR: 8214776: Avoid GCC 8.X strncpy() errors in JFR code
In-Reply-To: <995483f8-a9d8-6b58-45ba-7ce15725a586@redhat.com>
References: <995483f8-a9d8-6b58-45ba-7ce15725a586@redhat.com>
Message-ID: <da7b54ef2b02cb7ee4b30c795eca7e7cfc85e485.camel@redhat.com>

Hi Simon,

On Mon, 2018-12-10 at 10:25 -0500, Simon Tooke wrote:
> This small patch fixes some simple warnings in JFR code, found by GCC 8.1
> Essentially, any code sequence of the pattern
> 
>     int l = strlen(somestring)
>     char* buffer = malloc(l + 1)
>     strncpy(buffer, somestring, l)
>     buffer[l] = 0
> 
> is replaced by
> 
>     int len = strlen(somestring)
>     char* buffer = malloc(len + 1)
>     strncpy(buffer, somestring, len + 1)
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8214776
> Webrev:
> http://cr.openjdk.java.net/~sgehwolf/webrevs/stooke/JDK-8214776/02/webrev/

Shouldn't these:

@@ -332,7 +331,7 @@
     if (NULL == emergency_dump_path) {
       return NULL;
     }
-    strncpy(emergency_dump_path, buffer, emergency_filename_length);
+    strncpy(emergency_dump_path, buffer, emergency_filename_length + 1);
     emergency_dump_path[emergency_filename_length] = '\0';
   }
   return emergency_dump_path;
@@ -407,7 +406,7 @@
   if (_path == NULL) {
     return false;
   }
-  strncpy(_path, path, path_len);
+  strncpy(_path, path, path_len + 1);
   _path[path_len] = '\0';

Be this instead?

@@ -332,8 +331,7 @@
     if (NULL == emergency_dump_path) {
       return NULL;
     }
-    strncpy(emergency_dump_path, buffer, emergency_filename_length);
-    emergency_dump_path[emergency_filename_length] = '\0';
+    strncpy(emergency_dump_path, buffer, emergency_filename_length + 1);
   }
   return emergency_dump_path;
 }
@@ -407,8 +405,7 @@
   if (_path == NULL) {
     return false;
   }
-  strncpy(_path, path, path_len);
-  _path[path_len] = '\0';
+  strncpy(_path, path, path_len + 1);

Thanks,
Severin


From stooke at redhat.com  Tue Dec 11 16:06:46 2018
From: stooke at redhat.com (Simon Tooke)
Date: Tue, 11 Dec 2018 11:06:46 -0500
Subject: RFR: 8214776: Avoid GCC 8.X strncpy() errors in JFR code
In-Reply-To: <da7b54ef2b02cb7ee4b30c795eca7e7cfc85e485.camel@redhat.com>
References: <995483f8-a9d8-6b58-45ba-7ce15725a586@redhat.com>
 <da7b54ef2b02cb7ee4b30c795eca7e7cfc85e485.camel@redhat.com>
Message-ID: <cf130384-c41b-5de2-028e-127d9317212f@redhat.com>

On 2018-12-11 8:47 a.m., Severin Gehwolf wrote:
> Hi Simon,
>
> On Mon, 2018-12-10 at 10:25 -0500, Simon Tooke wrote:
>> This small patch fixes some simple warnings in JFR code, found by GCC 8.1
>> Essentially, any code sequence of the pattern
>>
>>     int l = strlen(somestring)
>>     char* buffer = malloc(l + 1)
>>     strncpy(buffer, somestring, l)
>>     buffer[l] = 0
>>
>> is replaced by
>>
>>     int len = strlen(somestring)
>>     char* buffer = malloc(len + 1)
>>     strncpy(buffer, somestring, len + 1)
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8214776
>> Webrev:
>> http://cr.openjdk.java.net/~sgehwolf/webrevs/stooke/JDK-8214776/02/webrev/
> Shouldn't these:
>
> @@ -332,7 +331,7 @@
>      if (NULL == emergency_dump_path) {
>        return NULL;
>      }
> -    strncpy(emergency_dump_path, buffer, emergency_filename_length);
> +    strncpy(emergency_dump_path, buffer, emergency_filename_length + 1);
>      emergency_dump_path[emergency_filename_length] = '\0';
>    }
>    return emergency_dump_path;
> @@ -407,7 +406,7 @@
>    if (_path == NULL) {
>      return false;
>    }
> -  strncpy(_path, path, path_len);
> +  strncpy(_path, path, path_len + 1);
>    _path[path_len] = '\0';
>
> Be this instead?
>
> @@ -332,8 +331,7 @@
>      if (NULL == emergency_dump_path) {
>        return NULL;
>      }
> -    strncpy(emergency_dump_path, buffer, emergency_filename_length);
> -    emergency_dump_path[emergency_filename_length] = '\0';
> +    strncpy(emergency_dump_path, buffer, emergency_filename_length + 1);
>    }
>    return emergency_dump_path;
>  }
> @@ -407,8 +405,7 @@
>    if (_path == NULL) {
>      return false;
>    }
> -  strncpy(_path, path, path_len);
> -  _path[path_len] = '\0';
> +  strncpy(_path, path, path_len + 1);
Yes, you're absolutely right - the null terminator is now set in the
line before.
I can produce a new webrev.

>
> Thanks,
> Severin
>
Thank you,
-Simon



From stooke at redhat.com  Tue Dec 11 16:29:29 2018
From: stooke at redhat.com (Simon Tooke)
Date: Tue, 11 Dec 2018 11:29:29 -0500
Subject: RFR: 8214776: Avoid GCC 8.X strncpy() errors in JFR code
In-Reply-To: <cf130384-c41b-5de2-028e-127d9317212f@redhat.com>
References: <995483f8-a9d8-6b58-45ba-7ce15725a586@redhat.com>
 <da7b54ef2b02cb7ee4b30c795eca7e7cfc85e485.camel@redhat.com>
 <cf130384-c41b-5de2-028e-127d9317212f@redhat.com>
Message-ID: <a7874939-64ab-c5a0-9ac6-a3b6474001e6@redhat.com>

On 2018-12-11 11:06 a.m., Simon Tooke wrote:
> On 2018-12-11 8:47 a.m., Severin Gehwolf wrote:
>> Hi Simon,
>>
>> On Mon, 2018-12-10 at 10:25 -0500, Simon Tooke wrote:
>>> This small patch fixes some simple warnings in JFR code, found by GCC 8.1
>>> Essentially, any code sequence of the pattern
>>>
>>>     int l = strlen(somestring)
>>>     char* buffer = malloc(l + 1)
>>>     strncpy(buffer, somestring, l)
>>>     buffer[l] = 0
>>>
>>> is replaced by
>>>
>>>     int len = strlen(somestring)
>>>     char* buffer = malloc(len + 1)
>>>     strncpy(buffer, somestring, len + 1)
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8214776
>>> Webrev:
>>> http://cr.openjdk.java.net/~sgehwolf/webrevs/stooke/JDK-8214776/02/webrev/

Revised webrev:

http://cr.openjdk.java.net/~sgehwolf/webrevs/stooke/JDK-8214776/03/webrev/

Thanks again to Severin


>> Shouldn't these:
>>
>> @@ -332,7 +331,7 @@
>>      if (NULL == emergency_dump_path) {
>>        return NULL;
>>      }
>> -    strncpy(emergency_dump_path, buffer, emergency_filename_length);
>> +    strncpy(emergency_dump_path, buffer, emergency_filename_length + 1);
>>      emergency_dump_path[emergency_filename_length] = '\0';
>>    }
>>    return emergency_dump_path;
>> @@ -407,7 +406,7 @@
>>    if (_path == NULL) {
>>      return false;
>>    }
>> -  strncpy(_path, path, path_len);
>> +  strncpy(_path, path, path_len + 1);
>>    _path[path_len] = '\0';
>>
>> Be this instead?
>>
>> @@ -332,8 +331,7 @@
>>      if (NULL == emergency_dump_path) {
>>        return NULL;
>>      }
>> -    strncpy(emergency_dump_path, buffer, emergency_filename_length);
>> -    emergency_dump_path[emergency_filename_length] = '\0';
>> +    strncpy(emergency_dump_path, buffer, emergency_filename_length + 1);
>>    }
>>    return emergency_dump_path;
>>  }
>> @@ -407,8 +405,7 @@
>>    if (_path == NULL) {
>>      return false;
>>    }
>> -  strncpy(_path, path, path_len);
>> -  _path[path_len] = '\0';
>> +  strncpy(_path, path, path_len + 1);
> Yes, you're absolutely right - the null terminator is now set in the
> line before.
> I can produce a new webrev.
>
>> Thanks,
>> Severin
>>
> Thank you,
> -Simon
>
>


From sgehwolf at redhat.com  Tue Dec 11 16:38:18 2018
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Tue, 11 Dec 2018 17:38:18 +0100
Subject: RFR: 8214776: Avoid GCC 8.X strncpy() errors in JFR code
In-Reply-To: <a7874939-64ab-c5a0-9ac6-a3b6474001e6@redhat.com>
References: <995483f8-a9d8-6b58-45ba-7ce15725a586@redhat.com>
 <da7b54ef2b02cb7ee4b30c795eca7e7cfc85e485.camel@redhat.com>
 <cf130384-c41b-5de2-028e-127d9317212f@redhat.com>
 <a7874939-64ab-c5a0-9ac6-a3b6474001e6@redhat.com>
Message-ID: <4561d94806dc16eedcd8f37c1e9c95e161aa7cab.camel@redhat.com>

On Tue, 2018-12-11 at 11:29 -0500, Simon Tooke wrote:
> On 2018-12-11 11:06 a.m., Simon Tooke wrote:
> > On 2018-12-11 8:47 a.m., Severin Gehwolf wrote:
> > > Hi Simon,
> > > 
> > > On Mon, 2018-12-10 at 10:25 -0500, Simon Tooke wrote:
> > > > This small patch fixes some simple warnings in JFR code, found by GCC 8.1
> > > > Essentially, any code sequence of the pattern
> > > > 
> > > >     int l = strlen(somestring)
> > > >     char* buffer = malloc(l + 1)
> > > >     strncpy(buffer, somestring, l)
> > > >     buffer[l] = 0
> > > > 
> > > > is replaced by
> > > > 
> > > >     int len = strlen(somestring)
> > > >     char* buffer = malloc(len + 1)
> > > >     strncpy(buffer, somestring, len + 1)
> > > > 
> > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8214776
> > > > Webrev:
> > > > http://cr.openjdk.java.net/~sgehwolf/webrevs/stooke/JDK-8214776/02/webrev/
> 
> Revised webrev:
> 
> http://cr.openjdk.java.net/~sgehwolf/webrevs/stooke/JDK-8214776/03/webrev/

This looks good to me.

Thanks,
Severin


From kustos at gmx.net  Tue Dec 11 21:33:28 2018
From: kustos at gmx.net (Philippe Marschall)
Date: Tue, 11 Dec 2018 22:33:28 +0100
Subject: jdk.jfr.Recording javadoc does not compile
Message-ID: <e8feabc2-79f4-b4ad-06d5-7e4fe9c11813@gmx.net>

Hello

I don't know where to report this. The class Javadoc of 
jdk.jfr.Recording contains the following code which does not compile:

Configuration c = Configuration.getConfiguration("default");
Recording r = new Recording(c);
r.start();
System.gc();
Thread.sleep(5000);
r.stop();
r.copyTo(Files.createTempFile("my-recording", ".jfr"));

The issue is that Recording has no #copyTo(Path) method. Probably the 
#dump(Path) method was intended.

Cheers
Philippe

From erik.gahlin at oracle.com  Tue Dec 11 22:16:05 2018
From: erik.gahlin at oracle.com (Erik Gahlin)
Date: Tue, 11 Dec 2018 23:16:05 +0100
Subject: jdk.jfr.Recording javadoc does not compile
In-Reply-To: <e8feabc2-79f4-b4ad-06d5-7e4fe9c11813@gmx.net>
References: <e8feabc2-79f4-b4ad-06d5-7e4fe9c11813@gmx.net>
Message-ID: <5C103725.3020704@oracle.com>

Hello Philippe,

Thanks for reporting this! I created a bug to track it:

https://bugs.openjdk.java.net/browse/JDK-8215237

Cheers
Erik

> Hello
>
> I don't know where to report this. The class Javadoc of 
> jdk.jfr.Recording contains the following code which does not compile:
>
> Configuration c = Configuration.getConfiguration("default");
> Recording r = new Recording(c);
> r.start();
> System.gc();
> Thread.sleep(5000);
> r.stop();
> r.copyTo(Files.createTempFile("my-recording", ".jfr"));
>
> The issue is that Recording has no #copyTo(Path) method. Probably the 
> #dump(Path) method was intended.
>
> Cheers
> Philippe


From erik.gahlin at oracle.com  Wed Dec 12 09:46:43 2018
From: erik.gahlin at oracle.com (Erik Gahlin)
Date: Wed, 12 Dec 2018 10:46:43 +0100
Subject: RFR: 8215175: Inconsistencies in JFR event metadata
Message-ID: <5C10D903.80303@oracle.com>

Hi,

Could I have review of this fix to the event metadata.

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

Webrev:
http://cr.openjdk.java.net/~egahlin/8215175/

Thanks
Erik


From markus.gronlund at oracle.com  Wed Dec 12 22:51:39 2018
From: markus.gronlund at oracle.com (Markus Gronlund)
Date: Wed, 12 Dec 2018 14:51:39 -0800 (PST)
Subject: RFR(S): 8215284: Reduce noise induced by periodic task getFileSize()
Message-ID: <d4fa521f-846e-46cb-8211-eb3768d815ea@default>

Greetings,

Can I get a review for the following:

Bug: https://bugs.openjdk.java.net/browse/JDK-8215284 
Webrev: http://cr.openjdk.java.net/~mgronlun/8215284/webrev01/ 

Summary: The periodic task operation runs in Java checking the file size of the current chunk. This produces unnecessary exposure and noise by the JFR framework itself. It is especially interesting that the path to check the size of a file produces a memory allocation trace....most likely some effect of autoboxing and lambda constructions...

We can avoid this by diving into the VM instead to test for the rotateDisk condition since the amount written to the current chunk is already tracked there.

Testing: jdk_jfr

Thanks
Markus

From markus.gronlund at oracle.com  Thu Dec 13 12:17:34 2018
From: markus.gronlund at oracle.com (Markus Gronlund)
Date: Thu, 13 Dec 2018 04:17:34 -0800 (PST)
Subject: RFR: 8215175: Inconsistencies in JFR event metadata
In-Reply-To: <5C10D903.80303@oracle.com>
References: <5C10D903.80303@oracle.com>
Message-ID: <eef27810-62d3-4728-99d3-abe173de1e58@default>

Hi Erik,

Looks good, thanks for fixing.

Markus

-----Original Message-----
From: Erik Gahlin 
Sent: den 12 december 2018 10:47
To: hotspot-jfr-dev at openjdk.java.net
Subject: RFR: 8215175: Inconsistencies in JFR event metadata

Hi,

Could I have review of this fix to the event metadata.

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

Webrev:
http://cr.openjdk.java.net/~egahlin/8215175/

Thanks
Erik


From erik.gahlin at oracle.com  Thu Dec 13 14:24:49 2018
From: erik.gahlin at oracle.com (Erik Gahlin)
Date: Thu, 13 Dec 2018 15:24:49 +0100
Subject: RFR: 8215237: jdk.jfr.Recording javadoc does not compile
Message-ID: <5C126BB1.8000203@oracle.com>

Hi,

Could i have review of this docs fix that updates the example code so it 
compiles.

- It updates an incorrect method name in the Recording class.

- It rewrites the example in the consumer package so it uses the streams 
API. This makes the code tighter and avoids the use at literal in the 
javadoc comment.

Webrev:
http://cr.openjdk.java.net/~egahlin/8215237/

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

Thanks
Erik

From markus.gronlund at oracle.com  Thu Dec 13 14:35:34 2018
From: markus.gronlund at oracle.com (Markus Gronlund)
Date: Thu, 13 Dec 2018 06:35:34 -0800 (PST)
Subject: RFR: 8215237: jdk.jfr.Recording javadoc does not compile
In-Reply-To: <5C126BB1.8000203@oracle.com>
References: <5C126BB1.8000203@oracle.com>
Message-ID: <eb2751ef-c1a9-4e33-8cd2-3fe8b478b4a5@default>

Looks good.

Markus

-----Original Message-----
From: Erik Gahlin 
Sent: den 13 december 2018 15:25
To: hotspot-jfr-dev at openjdk.java.net
Subject: RFR: 8215237: jdk.jfr.Recording javadoc does not compile

Hi,

Could i have review of this docs fix that updates the example code so it compiles.

- It updates an incorrect method name in the Recording class.

- It rewrites the example in the consumer package so it uses the streams API. This makes the code tighter and avoids the use at literal in the javadoc comment.

Webrev:
http://cr.openjdk.java.net/~egahlin/8215237/

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

Thanks
Erik

From erik.gahlin at oracle.com  Thu Dec 13 19:00:01 2018
From: erik.gahlin at oracle.com (Erik Gahlin)
Date: Thu, 13 Dec 2018 20:00:01 +0100
Subject: RFR: 8215362: JFR GTest JfrTestNetworkUtilization fails
Message-ID: <5C12AC31.3040604@oracle.com>

Hi,

Could I have a review of a test fix.

The unit was changed from bytes to bits (multiplied by 8), but the 
native test was not updated.

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

Webrev:
http://cr.openjdk.java.net/~egahlin/8215362/

Testing:
tier1 + test/jdk/jdk/jfr/*

Thanks
Erik

From jesper.wilhelmsson at oracle.com  Thu Dec 13 19:09:49 2018
From: jesper.wilhelmsson at oracle.com (jesper.wilhelmsson at oracle.com)
Date: Thu, 13 Dec 2018 20:09:49 +0100
Subject: RFR: 8215362: JFR GTest JfrTestNetworkUtilization fails
In-Reply-To: <5C12AC31.3040604@oracle.com>
References: <5C12AC31.3040604@oracle.com>
Message-ID: <1A46338F-3874-4D33-80AE-6F3B8F49D129@oracle.com>

Looks good!
I consider this a trivial change.
/Jesper

> On 13 Dec 2018, at 20:00, Erik Gahlin <erik.gahlin at oracle.com> wrote:
> 
> Hi,
> 
> Could I have a review of a test fix.
> 
> The unit was changed from bytes to bits (multiplied by 8), but the native test was not updated.
> 
> Bug:
> https://bugs.openjdk.java.net/browse/JDK-8215362
> 
> Webrev:
> http://cr.openjdk.java.net/~egahlin/8215362/
> 
> Testing:
> tier1 + test/jdk/jdk/jfr/*
> 
> Thanks
> Erik


From markus.gronlund at oracle.com  Thu Dec 13 21:41:42 2018
From: markus.gronlund at oracle.com (Markus Gronlund)
Date: Thu, 13 Dec 2018 13:41:42 -0800 (PST)
Subject: RFR: 8215362: JFR GTest JfrTestNetworkUtilization fails
In-Reply-To: <5C12AC31.3040604@oracle.com>
References: <5C12AC31.3040604@oracle.com>
Message-ID: <4bf3af85-a3e3-4371-a5e3-3298902abff9@default>

Hi Erik,

Looks good.

Markus

-----Original Message-----
From: Erik Gahlin 
Sent: den 13 december 2018 20:00
To: hotspot-jfr-dev at openjdk.java.net
Cc: Jesper Wilhelmsson <jesper.wilhelmsson at oracle.com>; Markus Gr?nlund <markus.gronlund at oracle.com>
Subject: RFR: 8215362: JFR GTest JfrTestNetworkUtilization fails

Hi,

Could I have a review of a test fix.

The unit was changed from bytes to bits (multiplied by 8), but the native test was not updated.

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

Webrev:
http://cr.openjdk.java.net/~egahlin/8215362/

Testing:
tier1 + test/jdk/jdk/jfr/*

Thanks
Erik

From erik.gahlin at oracle.com  Fri Dec 14 20:47:16 2018
From: erik.gahlin at oracle.com (Erik Gahlin)
Date: Fri, 14 Dec 2018 21:47:16 +0100
Subject: RFR: 8205651: TestLargeRootSet fails with exception: Could not find
 root object
Message-ID: <5C1416D4.30106@oracle.com>

Hi,

Could I have a review of a test that has failed intermittently. By 
increasing the size of the StackObject array the likelihood of the 
object sampler finding it increases.

I also added logging, so it is possible to see if the code path for a 
very large root set is taken. This is not the case, before or after the 
proposed change. It's hard to trigger that path. To start with, the heap 
must be at least 640 MB (32 MB/ 5%). I did however test with a modified 
JVM where the code path was triggered more easily and the test passed.

For now, I'm only making the test more stable and adding logging, so it 
easier to write a better test in the future.

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

Webrev:
http://cr.openjdk.java.net/~egahlin/8205651/

Thanks
Erik

From mikhailo.seledtsov at oracle.com  Fri Dec 14 21:48:46 2018
From: mikhailo.seledtsov at oracle.com (Mikhailo Seledtsov)
Date: Fri, 14 Dec 2018 13:48:46 -0800
Subject: RFR: 8205651: TestLargeRootSet fails with exception: Could not
 find root object
In-Reply-To: <5C1416D4.30106@oracle.com>
References: <5C1416D4.30106@oracle.com>
Message-ID: <5C14253E.8030000@oracle.com>

Changes look good to me from SQE/test point of view,

Misha

On 12/14/18, 12:47 PM, Erik Gahlin wrote:
> Hi,
>
> Could I have a review of a test that has failed intermittently. By 
> increasing the size of the StackObject array the likelihood of the 
> object sampler finding it increases.
>
> I also added logging, so it is possible to see if the code path for a 
> very large root set is taken. This is not the case, before or after 
> the proposed change. It's hard to trigger that path. To start with, 
> the heap must be at least 640 MB (32 MB/ 5%). I did however test with 
> a modified JVM where the code path was triggered more easily and the 
> test passed.
>
> For now, I'm only making the test more stable and adding logging, so 
> it easier to write a better test in the future.
>
> Bug:
> https://bugs.openjdk.java.net/browse/JDK-8205651
>
> Webrev:
> http://cr.openjdk.java.net/~egahlin/8205651/
>
> Thanks
> Erik

From milan.mimica at gmail.com  Thu Dec 20 11:50:48 2018
From: milan.mimica at gmail.com (Milan Mimica)
Date: Thu, 20 Dec 2018 12:50:48 +0100
Subject: [PATCH] JFR thread sampling issue
In-Reply-To: <4168442c-b232-4cd9-a4c2-e467e5bd0ac0@default>
References: <CAC+6wjph3KF4Bc_jkTqZe9hGoF6CgbpPtx_usW7TWCfCwo6Tzw@mail.gmail.com>
 <4168442c-b232-4cd9-a4c2-e467e5bd0ac0@default>
Message-ID: <CAC+6wjqWHndQBym+e2Up_xBAOvy94GZL8qLs6nfX=i0Cwzjo_Q@mail.gmail.com>

Hi Markus

I'm gonna try to resurrect thins (once again).

Did you get a chance to check in more details? At a glance, the code takes
care not to wrap around the thread list.



On Fri, 30 Nov 2018 at 15:21, Markus Gronlund <markus.gronlund at oracle.com>
wrote:

> Hi Milan,
>
> Thanks for pointing to this and providing a patch suggestion.
>
> Overall it looks reasonable, but I need to take a closer look in regards
> to how longer sample sessions interplays with the thread smr list - we
> should ensure that an attempt does not wrap around the thread list.
>
> Sorry for the delay on this issue - your overall suggestion will be
> incorporated in some form, but we need to be careful that it does not have
> hidden side effects. I will get back to you on this.
>
> Thanks again
> Markus
>
> -----Original Message-----
> From: Milan Mimica <milan.mimica at gmail.com>
> Sent: den 19 november 2018 13:42
> To: hotspot-jfr-dev at openjdk.java.net
> Subject: [PATCH] JFR thread sampling issue
>
> Hello
>
> I was regularly using JFR to profile my service and thread sampling
> results have been very useful. Unfortunately, when I have switched to Java
> 9 and afterwards, it stopped working. The recording would catch too few
> samples for the results to be useful. My service has about 500 threads,
> most of them being on some blocked state.
>
> With the release of Java 11, I have started digging into the JFR source
> code and I think I have found the problem. I think
> JfrThreadSampler::task_stacktrace is supposed to find at most 5 threads
> that are in state _thread_in_Java, or at most 1 thread that is in
> _thread_in_native, but instead it just picks next 5 (or 1) threads and then
> ignores them of they are not in right state. Without the insight into code
> change prior to JDK 11 I can just guess, but there are some clues that lead
> me to think that's how it was supposed to work. One of the clues is that
> sample_task.do_sample_thread returns a result that is otherwise unused.
>
> I'm attaching a patch.
> Tested test-jdk_jfr_sanity on fastdebug, and in my production.
>
> I'm waiting for my Author status approval so I'll be able to create a
> proper changeset. I believe I also need a ticket for this.
>
>
> --
> Milan Mimica
>


-- 
Milan Mimica

From markus.gronlund at oracle.com  Thu Dec 20 17:45:14 2018
From: markus.gronlund at oracle.com (Markus Gronlund)
Date: Thu, 20 Dec 2018 09:45:14 -0800 (PST)
Subject: [PATCH] JFR thread sampling issue
In-Reply-To: <CAC+6wjqWHndQBym+e2Up_xBAOvy94GZL8qLs6nfX=i0Cwzjo_Q@mail.gmail.com>
References: <CAC+6wjph3KF4Bc_jkTqZe9hGoF6CgbpPtx_usW7TWCfCwo6Tzw@mail.gmail.com>
 <4168442c-b232-4cd9-a4c2-e467e5bd0ac0@default>
 <CAC+6wjqWHndQBym+e2Up_xBAOvy94GZL8qLs6nfX=i0Cwzjo_Q@mail.gmail.com>
Message-ID: <648c0724-2128-4f88-bf6a-8ed34695f913@default>

Hi again Milan,

?

Sorry for the delay on this. After some investigation I think your patch is good as-is.

?

I was concerned with the loop not having a terminating condition when the number of samples is less than sample_limit.

?

Re-checking on next_thread(?) however, it actually provides this condition as part of:

?

return next != first_sampled ? next : NULL;

?

With this will restore the previous sampling behavior for Java threads that is part of 8 and early 9 ? thank you.

I will shepherd and sponsor this change for you.

?

Thanks again

Markus

?

From: Milan Mimica <milan.mimica at gmail.com> 
Sent: den 20 december 2018 12:51
To: Markus Gronlund <markus.gronlund at oracle.com>
Cc: hotspot-jfr-dev at openjdk.java.net
Subject: Re: [PATCH] JFR thread sampling issue

?

Hi Markus

?

I'm gonna try to resurrect thins (once again).

?

Did you get a chance to check in more details? At a glance, the code takes care not to wrap around the thread list.

?

?

?

On Fri, 30 Nov 2018 at 15:21, Markus Gronlund <HYPERLINK "mailto:markus.gronlund at oracle.com"markus.gronlund at oracle.com> wrote:

Hi Milan,

Thanks for pointing to this and providing a patch suggestion.

Overall it looks reasonable, but I need to take a closer look in regards to how longer sample sessions interplays with the thread smr list - we should ensure that an attempt does not wrap around the thread list.

Sorry for the delay on this issue - your overall suggestion will be incorporated in some form, but we need to be careful that it does not have hidden side effects. I will get back to you on this.

Thanks again
Markus 

-----Original Message-----
From: Milan Mimica <HYPERLINK "mailto:milan.mimica at gmail.com"milan.mimica at gmail.com> 
Sent: den 19 november 2018 13:42
To: HYPERLINK "mailto:hotspot-jfr-dev at openjdk.java.net"hotspot-jfr-dev at openjdk.java.net
Subject: [PATCH] JFR thread sampling issue

Hello

I was regularly using JFR to profile my service and thread sampling results have been very useful. Unfortunately, when I have switched to Java 9 and afterwards, it stopped working. The recording would catch too few samples for the results to be useful. My service has about 500 threads, most of them being on some blocked state.

With the release of Java 11, I have started digging into the JFR source code and I think I have found the problem. I think JfrThreadSampler::task_stacktrace is supposed to find at most 5 threads that are in state _thread_in_Java, or at most 1 thread that is in _thread_in_native, but instead it just picks next 5 (or 1) threads and then ignores them of they are not in right state. Without the insight into code change prior to JDK 11 I can just guess, but there are some clues that lead me to think that's how it was supposed to work. One of the clues is that sample_task.do_sample_thread returns a result that is otherwise unused.

I'm attaching a patch.
Tested test-jdk_jfr_sanity on fastdebug, and in my production.

I'm waiting for my Author status approval so I'll be able to create a proper changeset. I believe I also need a ticket for this.


--
Milan Mimica



-- 

Milan Mimica

From markus.gronlund at oracle.com  Fri Dec 21 14:54:09 2018
From: markus.gronlund at oracle.com (Markus Gronlund)
Date: Fri, 21 Dec 2018 06:54:09 -0800 (PST)
Subject: RFR(XS): 8215727: Restore JFR thread sampler loop to old / previous
 behavior (was: [PATCH] JFR thread sampling issue)
Message-ID: <69adbbce-2be3-4e57-a28b-62e1d810e641@default>

Greetings,

I am sending this RFR on behalf of Milan Mimica to formalize the patch he submitted to address this issue.

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

Tests: jdk_jfr

I am a Reviewer for this change.

Thanks a lot Milan for your contribution and patience.

Thanks
Markus

-----Original Message-----
From: Milan Mimica <milan.mimica at gmail.com> 
Sent: den 19 november 2018 13:42
To: hotspot-jfr-dev at openjdk.java.net
Subject: [PATCH] JFR thread sampling issue

Hello

I was regularly using JFR to profile my service and thread sampling results have been very useful. Unfortunately, when I have switched to Java 9 and afterwards, it stopped working. The recording would catch too few samples for the results to be useful. My service has about 500 threads, most of them being on some blocked state.

With the release of Java 11, I have started digging into the JFR source code and I think I have found the problem. I think JfrThreadSampler::task_stacktrace is supposed to find at most 5 threads that are in state _thread_in_Java, or at most 1 thread that is in _thread_in_native, but instead it just picks next 5 (or 1) threads and then ignores them of they are not in right state. Without the insight into code change prior to JDK 11 I can just guess, but there are some clues that lead me to think that's how it was supposed to work. One of the clues is that sample_task.do_sample_thread returns a result that is otherwise unused.

I'm attaching a patch.
Tested test-jdk_jfr_sanity on fastdebug, and in my production.

I'm waiting for my Author status approval so I'll be able to create a proper changeset. I believe I also need a ticket for this.


--
Milan Mimica

From erik.gahlin at oracle.com  Fri Dec 21 15:19:12 2018
From: erik.gahlin at oracle.com (Erik Gahlin)
Date: Fri, 21 Dec 2018 16:19:12 +0100
Subject: RFR(XS): 8215727: Restore JFR thread sampler loop to old /
 previous behavior (was: [PATCH] JFR thread sampling issue)
In-Reply-To: <69adbbce-2be3-4e57-a28b-62e1d810e641@default>
References: <69adbbce-2be3-4e57-a28b-62e1d810e641@default>
Message-ID: <5C1D0470.7040309@oracle.com>

Looks good.

Erik

> Greetings,
>
> I am sending this RFR on behalf of Milan Mimica to formalize the patch he submitted to address this issue.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8215727
> Webrev: http://cr.openjdk.java.net/~mgronlun/8215727/webrev/
>
> Tests: jdk_jfr
>
> I am a Reviewer for this change.
>
> Thanks a lot Milan for your contribution and patience.
>
> Thanks
> Markus
>
> -----Original Message-----
> From: Milan Mimica <milan.mimica at gmail.com>
> Sent: den 19 november 2018 13:42
> To: hotspot-jfr-dev at openjdk.java.net
> Subject: [PATCH] JFR thread sampling issue
>
> Hello
>
> I was regularly using JFR to profile my service and thread sampling results have been very useful. Unfortunately, when I have switched to Java 9 and afterwards, it stopped working. The recording would catch too few samples for the results to be useful. My service has about 500 threads, most of them being on some blocked state.
>
> With the release of Java 11, I have started digging into the JFR source code and I think I have found the problem. I think JfrThreadSampler::task_stacktrace is supposed to find at most 5 threads that are in state _thread_in_Java, or at most 1 thread that is in _thread_in_native, but instead it just picks next 5 (or 1) threads and then ignores them of they are not in right state. Without the insight into code change prior to JDK 11 I can just guess, but there are some clues that lead me to think that's how it was supposed to work. One of the clues is that sample_task.do_sample_thread returns a result that is otherwise unused.
>
> I'm attaching a patch.
> Tested test-jdk_jfr_sanity on fastdebug, and in my production.
>
> I'm waiting for my Author status approval so I'll be able to create a proper changeset. I believe I also need a ticket for this.
>
>
> --
> Milan Mimica


From markus.gronlund at oracle.com  Fri Dec 21 17:14:36 2018
From: markus.gronlund at oracle.com (Markus Gronlund)
Date: Fri, 21 Dec 2018 09:14:36 -0800 (PST)
Subject: RFR: 8205651: TestLargeRootSet fails with exception: Could not
 find root object
In-Reply-To: <5C1416D4.30106@oracle.com>
References: <5C1416D4.30106@oracle.com>
Message-ID: <f573a552-e545-45a4-88ea-ba0740960177@default>

Looks good.

Markus

-----Original Message-----
From: Erik Gahlin 
Sent: den 14 december 2018 21:47
To: hotspot-jfr-dev at openjdk.java.net
Subject: RFR: 8205651: TestLargeRootSet fails with exception: Could not find root object

Hi,

Could I have a review of a test that has failed intermittently. By increasing the size of the StackObject array the likelihood of the object sampler finding it increases.

I also added logging, so it is possible to see if the code path for a very large root set is taken. This is not the case, before or after the proposed change. It's hard to trigger that path. To start with, the heap must be at least 640 MB (32 MB/ 5%). I did however test with a modified JVM where the code path was triggered more easily and the test passed.

For now, I'm only making the test more stable and adding logging, so it easier to write a better test in the future.

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

Webrev:
http://cr.openjdk.java.net/~egahlin/8205651/

Thanks
Erik