JDK-8247249 : [aarch64] assert((flag() == mtNone || flag() == f)) failed: Overwrite memory type
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 15
  • Priority: P3
  • Status: Resolved
  • Resolution: Duplicate
  • OS: linux
  • CPU: aarch64
  • Submitted: 2020-06-09
  • Updated: 2020-06-10
  • Resolved: 2020-06-10
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 15
15Resolved
Related Reports
Duplicate :  
JDK-8243535 - NMT may show wrong numbers for CDS and CCS
Relates :  
JDK-8243392 - Remodel CDS/Metaspace storage reservation
Description
open/test/hotspot/jtreg/runtime/cds/SharedBaseAddress.java

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (/opt/mach5/mesos/work_dir/slaves/63712a43-4eaa-429c-95b4-483ac8241123-S780/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/fa451e47-1a50-4f50-a2d0-fc729e54fa2c/runs/fa8133f1-9a07-45df-9aac-e1dd79ec797a/workspace/open/src/hotspot/share/services/virtualMemoryTracker.cpp:291), pid=15711, tid=15714
#  assert((flag() == mtNone || flag() == f)) failed: Overwrite memory type
#
# JRE version:  (15.0) (fastdebug build )
# Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 15-internal+0-2020-06-09-1047468.patric.hedlin.jdk, mixed mode, sharing, tiered, compressed oops, g1 gc, linux-aarch64)
# Problematic frame:
# V  [libjvm.so+0x146e51c]  ReservedMemoryRegion::set_flag(MemoryType)+0x154
#
Comments
This error was caused by 8243392: Remodel CDS/Metaspace storage reservation and fixed as a side effect of 8243535: NMT may show wrong numbers for CDS and CCS
10-06-2020
Confirming that another (tier4) run does not manifest the issue. (revision: 6b87c49162fd9f20e7cac0a6d0a4cb45308d3bd7)
10-06-2020
Analysis: This error has been introduced with "8243392: Remodel CDS/Metaspace storage reservation". The sequence of events: 1) We attempt to generate a CDS archive whose base address is 0xFFFFFFFF. This is an invalid address for mapping on aarch64, and we fall back to 0x100000000 (4G). So, the generated archive' base address is 0x100000000. 2) We call VM with -XShare:on -XX:ArchiveRelocationMode=1 and that archive. (also UseCompressedClassPointers=1 by default). 3) We reserve space for cds+ccs at at archive base address 0x100000000. This is then split into two reserved regions, but NMT does not know this and still treats this as one region. 4) We map the archives into the cds address space. As a side effect the whole region in NMT (cds+ccs) gets painted with the "mtClassShared" flag since NMT treats both as a single unit. 5) ArchiveRelocation=1 -> we simulate a mapping error 5.1) -> so we unmap all archives again, which is specifically ignored in NMT, 5.2) -> and we release archive space and class space separately. But here the problem is that NMT only knows both as one unit, so it enters this special condition in virtualMemoryTracker.cpp 463ff: if (reserved_rgn->flag() == mtClassShared && reserved_rgn->contain_region(addr, size) && !reserved_rgn->same_region(addr, size)) { // This is an unmapped CDS region, which is part of the reserved shared // memory region. // See special handling in VirtualMemoryTracker::add_reserved_region also. return true; } which is actually meant to prevent the unmappings of the archive files in step (5.1) from changing NMT state. But here, it means we just do not remove the reserved region for cds+ccs at all. The result is that after releasing the memory, NMT still has the cds+ccs mapping. 6) Now we re-attempt to map the archives. We reserve space for cds+ccs at any arbitrary address. However, on aarch64, we get the same address as before, 0x100000000. 7) When attempting to reserve space at that location, NMT complains because it still has its old mapping at that location. So we assert. ------- TL;DR This happens whenever we re-try to reserve space for cds and ccs after the first attempt failed, and that second attempt uses the same base address as the first attempt. This can only happen in test mode when ArchiveRelocationMode=1 and is very improbable any OS other than linux aarch64 since only there we roll our own optimized ccs placement (see Metaspace::reserve_address_space_for_compressed_classes). The underlying reason for all this is the hackish way we treat CDS mappings in NMT. We should improve this, this is way to hard. -------- The good news is that this is already fixed as a side effect of "JDK-8243535 NMT may show wrong numbers for CDS and CCS". So, these crashes should not happen anymore after 8243535.
10-06-2020
Okay if b87b8ca419cba7e502d65ec531bf038fa34223fd ( 8246729: MappedByteBuffer.force() throws IndexOutOfBoundsException) is the first revision this error showed up, it could not have been caused by JDK-8243535 since that came later. I'll continue to look for a bit.
10-06-2020
Yes, I see a related problem where that might be uploaded more suitably. Will file a new bug shortly.
10-06-2020
First seen on Aarch64 in (private) Tier4 run on 2020-06-09. Since Aarch64 is not part of regular Tier4 testing yet, there is no history. (revision: b87b8ca419cba7e502d65ec531bf038fa34223fd)
10-06-2020
The 278 .jtr-files in the test run seem to include some other oddities as well. Uploaded additional (JhsdbThreadInfoTest.jtr). JhsdbThreadInfoTest.jtr includes this line (but reports as passed): Java HotSpot(TM) 64-Bit Server VM warning: Native Memory Tracking did not setup properly, using wrong launcher?
10-06-2020
Since when do these errors occur? Only aarch64?
10-06-2020
Could you please attach JTwork/runtime/cds/SharedBaseAddress.jtr? Or is this issue about a different test?
10-06-2020
Possibly, I'll take a look. Since I cannot reproduce this locally, could you please attach the jtr?
10-06-2020
[~stuefe] Thomas, is this caused by your recent change for NMT ? "JDK-8243535 NMT may show wrong numbers for CDS and CCS "
09-06-2020
ILW = HLM = P3
09-06-2020