RFR: 8252921: NMT overwrite memory type for region assert when building dynamic archive [v3]

[Ioi Lam]

On Tue, 15 Sep 2020 20:15:52 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

>> Thanks for the fix. I've done some testing on the patch. It passed tier1 and also passed running the
>> appcds/dynamicArchive/methodHandles/MethodHandlesAsCollectorTest.java test 30 times on Windows and linux. One question
>> : why the JavaThread::post_run doesn't need to set the following?
>>    set_stack_base(NULL);
>>    set_stack_size(0);
>
>> Thanks for the fix. I've done some testing on the patch. It passed tier1 and also passed running the
>> appcds/dynamicArchive/methodHandles/MethodHandlesAsCollectorTest.java test 30 times on Windows and linux. One question
>> : why the JavaThread::post_run doesn't need to set the following? set_stack_base(NULL);
>> set_stack_size(0);
> 
> Thanks for reviewing, Calvin.
> 
> The last statement of JavaThread::post_run() deletes 'thread' object, so there is no point to reset its states here.
> While NonJavaThread object lives pass lifespan of actual thread, its state does matter, I believe.

This code in
[virtualMemoryTracker.cpp](https://github.com/openjdk/jdk/blob/9a7dcdcdbad34e061a8988287fe691abfd4df305/src/hotspot/share/services/virtualMemoryTracker.cpp#L350)
still looks buggy to me:
    if (reserved_rgn->same_region(base_addr, size)) {
      reserved_rgn->set_call_stack(stack);
      reserved_rgn->set_flag(flag);
      return true;
    } else {
      assert(reserved_rgn->overlap_region(base_addr, size), "Must be");

      // Overlapped reservation.
      // It can happen when the regions are thread stacks, as JNI
      // thread does not detach from VM before exits, and leads to
      // leak JavaThread object
      if (reserved_rgn->flag() == mtThreadStack) {
        guarantee(!CheckJNICalls, "Attached JNI thread exited without being detached");
        // Overwrite with new region
Why is the "Overlapped reservation" fix not done when the two regions are exactly the same?

If a JNI thread has exited without detaching, and its stack happens to be picked for a future memory reservation of the
exact size, I think we will get the same assert as in this bug report.

-------------

PR: https://git.openjdk.java.net/jdk/pull/185