RFR: 8276563: Undefined Behaviour in class Assembler

[Jorn Vernee]

On Mon, 8 Nov 2021 14:17:15 GMT, Andrew Haley <aph at openjdk.org> wrote:

> > > In other words: in the current scheme we pass around an integer disguised as a pointer, and then have to cast it to an integer to use it. That seems silly. Let's just pass around the integer instead, wrapped in a value-object, which the compiler should treat the same as if it were just the integer.
> > 
> > 
> > That's worth exploring, but I'm reluctant to start overloading `->`. I'll have a look.
> 
> So I had a good look, and I think this idea is not going to fly without substantial changes elsewhere. The trickiest problem I've found so far is `GrowableArray<Register>`, which assumes that `Register` is a pointer type. None of these problems is insurmountable, of course, but it does mean that a change like this spills into many more places in shared code.

I ran into problems before where GrowableArray::print was assuming the values it held were pointer sized. Is that what you're talking about as well? I think a long term fix there might be to implement some kind of `print_on` template function with specializations for different types, which GrowableArray then uses instead of trying to cast each element to an `intptr_t`.

> Oh, the other problem is that variables of type `Register` may be assigned, which means that the field containing the encoding can no longer be `const`, and there are `const` problems elsewhere too.

Okay, I'd assume not having the encoding be `const` would be fine, as long as `Register` is passed around by-value. i.e. only some code's private copy of a `Register` instance would be overwritten (same as if it was a pointer).

---

Any ways, thanks for trying this out! If the required changes are too much (making backporting harder as well) I think going with a more focused fix is the way to go, as well. Maybe we can come back for a broader refactoring another day.

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

PR: https://git.openjdk.java.net/jdk/pull/6280