[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-hotspot-runtime-dev
Subject:    Question about CompressedKlassPointers::range
From:       Thomas_Stüfe <thomas.stuefe () gmail ! com>
Date:       2020-04-21 14:31:08
Message-ID: CAA-vtUyGhP38Sz13Nz_E2+PSGK21Z0GfqGq24Axfz1i7A42_eg () mail ! gmail ! com
[Download RAW message or body]

Hi,

this is a followup question, mainly for aarch64, to
https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-April/008757.html
 .

CompressedKlassPointers has a range field, only used by aarch64 afaics,
introduced with "8193266: AArch64: TestOptionsWithRanges.java SIGSEGV".

I read its bug description and the patch. If I understand the problem,
before CDS the assumption was that CompressedClassSpaceSize is synonymous
with the range of values narrow Klass pointers could have; which seems
logical, but that assumption was broken since CDS and now the encoding
range must span both the ccs and the cds archives.

The range is used inside MacroAssembler::klass_decode_mode() to decide
whether to use the OR mode.

I see this being set in three places:
1) at cds dumptime, to 4G
2) at cds runtime, to CompressedClassSpaceSize, and
3) if cds is disabled it keeps its default value of 4G.

I may miss something here. Would (2) not be too small? Should that size not
include the size of the archives? We map first the archives, lets say they
are 300MB, after that ccs, lets say 1G default, would that not mean any
Klass residing toward the end of the ccs - if it were to fill up, which it
almost never does - would have an offset larger than the initially assumed
range and hence not correctly OR-able with the base anymore?

And I'm not sure (3) is correct either since the range we could encode in
theory is 32G with shift=3. In practice this is today no problem. Today
CompressedClassSpaceSize is artificially capped at 3G. If that were ever to
change, and someone would set it to >4G, this should cause problems too, no?

If my assumption about (2) is correct, it could be the error is just well
hidden either because MacroAssembler::_klass_decode_mode is already
initialized, using the default value (3). Or because it is difficult to
allocate so many classes to trigger this error.

--

As a more general question: CompressedKlassPointers::range(), as in "the
expected range of narrow Klass pointer values", I guess it makes sense to
keep it as small as possible, right? Instead of, say hard-coding it to 32G?
Since the smaller the expected range of narrow pointers is, the more
probable we could choose the OR mode?

Oh, and on aarch64, how "good" is that OR mode compared with the "movk"
mode on aarch64? Since it seems to be preferred?

Thanks a lot, again,

Thomas
[prev in list] [next in list] [prev in thread] [next in thread]