On Tue, 28 Feb 2023 20:45:38 GMT, Phil Race <p...@openjdk.org> wrote:
>> I think you have read more about the differences between -fpic and -fPIC >> than I have, so nothing I can add here. >> >> Making this option only on aarch64 seems like a reasonable idea if that's >> where we see the effect. > >> I dont think -fPIC is implied by -fpic. @erikj79 please clarify. > > That isn't what I said. > I said they they do very similar things, based on the references I read > with just a specific difference is that lower case "fpic" can be limited in > size. > > which is why I wrote >> So far as I can tell the -fpic are using just limits the size of the global >> offset table that -fPIC will generate. > > My comment >> Since we had an unlimited offset table before, then -fpic won't change >> anything. > > I was trying to point out that if your eval + fix is explained by saying we > no longer > have "-fpic" then that's wrong. We never had -fpic. > We didn't change compiler options, but clearly performance changed > > > The man page you just linked does explain how the mechanism -fpic uses > which limits size could result in better performance > > " When generating code for shared libraries, -fpic implies > -msmall-data and -fPIC implies -mlarge-data." > > "When -msmall-data is used, > objects 8 bytes long or smaller are placed in a small data > area (the ".sdata" and ".sbss" sections) and are accessed via > 16-bit relocations off of the $gp register." > > So on some architectures it can be faster. > > BUT since we were using -fPIC for a long time, I am not seeing how you've > explained WHY we now need to explicitly use -fpic to get the performance back > ? > In other words "we mysteriously lost performance, but I've found an option > that helps". > > So possibly, if you applied -fpic to the JDK before the regression it would > get even faster ... Thanks @prrace. I will analyse further why -fpic is causing change in behaviour in our case. ------------- PR: https://git.openjdk.org/jdk/pull/12761
