I don’t recall coming across much that was architecture-dependent in my travels, my somewhat superficial impression is of a good portability job. The reporting is completely different on no-MMU platforms so there’s no scope for confusion there.
VmExe could in principle be binary-format-dependent (since that’s where startcode/endcode are filled in) but I think it would be a bug if it was; to the extent that it means anything it means that your executable is that big. The reason I say it’s meaningless is that you could just look at the executable; it’s not like it changes.
I suppose the points about JIT compilers adding to some of the figures is false on platforms too obscure for anyone to have ported their JIT to them l-)
Good point about thread stacks inflating vsize, and one I should have thought of as I’ve had a correspondent be confused by it in the past.
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
(no subject)
Date: 2012-01-28 08:13 pm (UTC)I don’t recall coming across much that was architecture-dependent in my travels, my somewhat superficial impression is of a good portability job. The reporting is completely different on no-MMU platforms so there’s no scope for confusion there.
VmExe could in principle be binary-format-dependent (since that’s where startcode/endcode are filled in) but I think it would be a bug if it was; to the extent that it means anything it means that your executable is that big. The reason I say it’s meaningless is that you could just look at the executable; it’s not like it changes.
I suppose the points about JIT compilers adding to some of the figures is false on platforms too obscure for anyone to have ported their JIT to them l-)
Good point about thread stacks inflating vsize, and one I should have thought of as I’ve had a correspondent be confused by it in the past.