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

David Holmes david.holmes at oracle.com
Thu Sep 17 00:59:30 UTC 2020


Hi Zhengyu,

On 16/09/2020 9:28 pm, Zhengyu Gu wrote:
> On Wed, 16 Sep 2020 02:49:45 GMT, David Holmes <dholmes at openjdk.org> wrote:
> 
>>> Thread stack is currently unregistered with NMT in Thread's destructor. Apparently, only Java thread invokes destructor
>>> before thread exits.  For NonJavaThread, e.g. ConcurrentGCThread, thread may exit while its "Thread" object continues
>>> alive, therefore, its thread stack is still "alive" from NMT perspective. Once thread exits, the virtual memory for the
>>> thread stack can be reserved again, that confused NMT.  The solution is to move thread stack unregistration code to
>>> post_run() method.
>>
>> src/hotspot/share/runtime/thread.hpp line 762:
>>
>>> 760:  public:
>>> 761:   // Stack overflow support
>>> 762:   address stack_base() const           { return _stack_base; }
>>
>> Why did you remove the assertion? We want the assertion in general to ensure there are no improper uses of stack_base().
> 
> We now reset NonJavaThread's stack base and size,  so _stack_base == NULL is possible, e.g. when generating hs_err
> report, as we should now see empty stack for "G1 Main Marker" thread in original bug report.

Resetting the stack base and size seems pointless given we follow that 
immediately with

Thread::clear_thread_current();

And once there is no thread-current for this thread its base and size 
can never be queried, so I don't think this change, or the change to the 
assertion in stack_base() is needed.

> You do have a valid point for the assertion. I think following assertion is more precise:
> 
> assert(_stack_base != NULL || Thread::current() != NULL, "Sanity check");
> 
> What you think?

That assertion doesn't make sense to me as the stack_base() being 
queried doesn't have to belong to the current thread.

Thanks,
David
-----

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


More information about the hotspot-runtime-dev mailing list