RFR: 8338768: Introduce runtime lookup to check for static builds [v2]

Magnus Ihse Bursie ihse at openjdk.org
Tue Aug 27 13:50:03 UTC 2024


On Mon, 26 Aug 2024 09:39:28 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> I understand the cost overhead experienced by any individual Java run may be lost in the noise, but it still impacts every single Java run just to save some time/resources for the handful of builders of statically linked VMs. I am not a fan.
>
>> but it still impacts every single Java run just to save some time/resources for the handful of builders of statically linked VMs.
> 
> Seriously? I challenge you do prove there is any effect at all. :-/
> 
> Also, there is not a "handful" of builders of static libraries. Our internal CI system builds static libraries all the time, and I for one would be glad to use these resources on more productive stuff than building all object files twice. 
> 
> Also, the intention is to enable static builds by default on GHA, once the entire process of making static builds "dirt cheap" is finished, to avoid regressions.

> Hi @magicus, perhaps the answer is both yes and no. [...] Since the mainline doesn't have the needed build changes to have the ability to link a javastatic binary, from that point of view all the static cases in the PR cannot be tested yet. 

I don't think that is correct. This PR just modifies the existing places where static and dynamic libraries are handled differently. These have been put in place by prior users of static libraries (mobile, graal), and do not require the Hermetic Java "javastatic" launcher to test.

I honestly thought this part was going to be a no-brainer, a simple preparation for future things to come. I'm surprised that it seems to be so controversial.

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

PR Comment: https://git.openjdk.org/jdk/pull/20666#issuecomment-2312613235


More information about the core-libs-dev mailing list