[8u] RFR: JDK-8164041: support old pre-c++11 toolchains and ucLibc

[Andrey Petushkov]

Dear Ed,

>> Hi Ed,
>> 
>> Thank you for response! It’s though not quite clear to me if it’s possible to use generated code there since these functions are inline, so having them as generated incur indirect call, which likely alleviates any performance gain (so for universal binary it’s easier to just build against the lowest supported CPU anyway)
> 
> 
> Yes, of course, the fact that it cannot inline the dynamic calls leads
> to a performance hit.
> 
> Two possible solutions to this
> 
> 1) Do a static test.
> 
>    if (has_ldrexd()) do_ldrexd; else do_somethingelse;
> 
> This can then be inlined and reduces the cost to a single static test
> and a predicted branch.
Well, that is right. However we have found that making even a simple check against the global variable is really expensive in such places. You can see by “UseMembar” change in the c1 patch. We have observed that eliminating the check and effectively executing barrier instruction even when unnecessary is still faster compared to checking the variable and not executing the barrier.. So it takes to play and measure a bit..
> 
> 2) Generate 2 versions of libjvm.so (say libjvm.so and
> libjvm_ldrexd.so) and have the loader select the correct version in a
> similar way to the way it selects the client ot server vm.
> 
> This would have no performance overhead, but is considerably more
> complex and would require a JEP if it were to be accepted upstream.
Fully agree. Less maintainable in addition
> 
> I do think there is value in having a single image which works across
> all variants of ARMs.
Yes, I do think the same. Although the deeper to go the more it takes to support it. Do you have any feeling of what is the lowest/oldest ARM version it makes sense to support in the aarch32 port?

Thank you,
Andrey
> 
> All the best,
> Ed.
>