RFR: 8199067 [REDO] NMT: Enhance thread stack tracking

[Thomas Stüfe]

Hi Zhengyu,

sorry for the late response!

I looked the windows changes over.

The capping of the size may not work correctly if the committed range
overlaps the end of the region but starts in the middle:

+    // current region may go beyond the limit, trim to the limit
+    committed_size = MIN2(committed_size, size);

should it not be rather:

+    committed_size = MIN2(committed_size, top - committed_start);

?

The code also assumes that the input range starts at the begin of a
region. Not sure if this is always the case. So, I would test if
MEMORY_BASIC_INFORMATION.BaseAddress lays below the input start
address, in which case I would only add the overlapping part to the
committed size.

Best Regards, Thomas






On Mon, Mar 19, 2018 at 5:10 PM, Zhengyu Gu <zgu at redhat.com> wrote:
>
> Ping!
>
> submit-hs test still good.
>
> Mach5 mach5-one-zgu-JDK-8199067-20180319-1419-14981: Builds PASSED. Testing SUCCESSFUL.
>
> Thanks,
>
> -Zhengyu
>
>
> On 03/08/2018 09:08 AM, Zhengyu Gu wrote:
>>
>> The early change failed on some fast machine with many processors running Linux OS. It reveals that there can be holes in thread's stack, which throws off binary search for finding stack bottom.
>>
>> Besides, some threads (ConcurrentGCThread and WatcherThread, etc.) do exit without notifying NMT, which can trip over NMT final reporting, as their stacks became unmapped.
>>
>> This patch addresses above issues by searching whole address range for committed regions. If the address range becomes invalid, simply reports as not committed.
>>
>> GTest also updated.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8199067
>> Webrev: http://cr.openjdk.java.net/~zgu/8199067/webrev.00/index.html
>>
>>
>> Test:
>>    hotspot tier1 on Linux 64 and Windows x64.
>>
>>    Submit repo test came back clean.
>>    Mach5 mach5-one-zgu-JDK-8199067-20180308-1218-13719: Builds PASSED. Testing SUCCESSFUL.
>>
>>
>> Thanks,
>>
>> -Zhengyu
>>