Assert poisoning initialization before os memory subsystem

Thomas Stüfe thomas.stuefe at gmail.com
Mon Jan 14 14:29:25 UTC 2019


Hi Thomas

yes, that is ugly and unnecessary. I think in the original version I
used raw mmap/VirtualAlloc and later switched to os::reserve_memory()
because of reuse-guilt, but forgot to think about init dependencies.

Initialization can happen at a later point. If an assert happens
before the poison page is initialized nothing bad happens, we just
won't see register values which is no big deal.

I opened https://bugs.openjdk.java.net/browse/JDK-8216982

Cheers, Thomas :)

On Mon, Jan 14, 2019 at 10:49 AM Thomas Schatzl
<thomas.schatzl at oracle.com> wrote:
>
> Hi Thomas,
>
>   the change "JDK-8191101: Show register content in hs-err file on
> assert" added some code that initializes some memory page for
> retrieving the register context on assert failure.
>
> This reserves, commits and mprotects a single VM page.
>
> The problem is that this occurs before the os subsystem completely
> initialized itself, causing issues if not guarded against in the commit
> code - i.e. if UseNUMA is enabled, the VM did not get a chance to
> initialize the NUMA subsystem (even if it just disables it).
>
> Obviously all os implementations guard already against this (because
> they do not crash; during review of JDK-8213827 we temporarily removed
> this guard and hence noticed this), and from a functionality pov NUMA
> initialization is not needed for this feature.
>
> However I was wondering whether it is really necessary to do this
> assert poisoning setup before the os::init_2 call. Do you have any
> recollection why the poisoining (needs to?) occurs that early?
>
> It looks like a bit of an ugly wart to use the os component without
> having it completely initialized.
>
> Thanks,
>   Thomas :P
>


More information about the hotspot-dev mailing list