RFR: 8343531: Improve print_location for invalid heap pointers [v2]

[Volker Simonis]

On Mon, 4 Nov 2024 15:52:59 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Oh, OK. Compressed pointers make this whole thing a bit messy. I think current code is not handling the case of compressed interior pointers all that well; IDK if we even have those in Hotspot.
> 

Yes, that's true. I first thought about calling  `BlockLocationPrinter<CollectedHeapT>::print_location()` recursively for the compressed oops case to avoid code duplication and get the same handling for regular and compressed oops, but that would have been a much larger change.
I think we can have compressed oops in registers, e.g. when GC iterates the heap or when compiled code loads a field but the cases are probably more rare than regular oops.

> I think there is an ambiguity between compressed pointers and regular pointers at this level, which we cannot reasonably resolve. E.g. if we have zero-based compressed oops with 2-bit shift and 16 GB heap, passing `0x1000000` as the `addr` here cannot distinguish between cases of "regular pointer, points to `0x1000000`" and "compressed pointer, decodes as `0x4000000`". I guess we would like to print both interpretations. But this is way beyond the scope for this PR.

That's also true, but remember that  `is_valid_obj()` does quite some checks. So in your example, in order to make it really ambiguous, it would require that at address `0x1000000 + 8` as well as at address `0x4000000 + 8` we have properly aligned,  valid (possibly compressed) pointers into MetaSpace pointing to a valid `Klass` object (which is probably not so common for most adresses). 

> This version would do meanwhile.

Thanks for the review.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21870#discussion_r1828017494