On Tue, 31 Mar 2026 09:18:25 GMT, Maurizio Cimadamore <[email protected]> wrote:
>> I agree with excluding `Linker` from this PR - I've felt `Linker` does not >> need to be value-based TBH. In addition `FunctionDescriptor` does not need >> to be value based because we would not use `==` for it. >> >> So I think it should do first to exclude `Linker` and `FunctionDescriptor` >> from value based class (I think it needs CSR). Then we can go ahead this PR. >> What do you think? > >> I agree with excluding `Linker` from this PR - I've felt `Linker` does not >> need to be value-based TBH. In addition `FunctionDescriptor` does not need >> to be value based because we would not use `==` for it. >> >> So I think it should do first to exclude `Linker` and `FunctionDescriptor` >> from value based class (I think it needs CSR). Then we can go ahead this PR. >> What do you think? > > In my mind, FunctionDescriptor and MemoryLayout are very close, as the former > is just an aggregate of the latter. For instance, the Linker uses FD as keys > in maps -- and I suspect others might want to do so as well. That said, I > agree that, given the fact that FD contains collections/arrays, we can't > really recommend people to use `==` for it. But still, it feels like a value > class to me (in spirit). @mcimadamore I said the same thing in https://github.com/openjdk/jdk/pull/30481#issuecomment-4148814551 > I think `FunctionDescriptor` can be kept `@ValueBased` since it represents a > tuple of `(Optional<MemoryLayout> resLayout, List<MemoryLayout> argLayouts)` > describing the signature of a foreign function; similar to what `MethodType` > and `MethodTypeDesc` do for **Java** methods, the former of which is interned > and used with `==`. ------------- PR Comment: https://git.openjdk.org/jdk/pull/30443#issuecomment-4162988673
