Opensource, Community, Governance

[Christian Wimmer]

On 5/1/19 10:39, Bob McWhirter wrote:
> 
> 
> On Wed, May 1, 2019 at 1:31 PM Christian Wimmer 
> <christian.wimmer at oracle.com <mailto:christian.wimmer at oracle.com>> wrote:
> 
>     Hi Bob,
> 
>     Some answers to your Native Image related technical points:
> 
>      >     - JNI over the C-ish "porting" of the JDK (removes DCE
>     opportunities)
> 
>     We see this as the only feasible way to have a maintainable and stable
>     Native Image code base that works across multiple platforms (Linux,
>     MacOS, Windows) and JDK versions (8, 11, latest).
> 
>     We also think that it is not going to impact the startup time and
>     memory
>     footprint of native images, but implementation is not complete enough
>     yet to show this.
> 
> 
> Implicitly libjava.so will be included in its entirety, yes, since DCE 
> can't see beyond the C calls and eliminate from there.

Probably. That is only 230 KByte. Note that we still have DCE on the 
Java side, i.e., Java methods accessed from native code are only going 
to be included when they are necessary.

>      >     - The fallback mode of native-image for Helidon
> 
>     The fallback mode is not implemented for technical reasons, but only
>     for
>     legal reasons. Especially, it has nothing to do with Helidon (or any
>     other concrete application that supports Native Image).
> 
> 
> I dunno that I understand "legal" reasons. Would you mind elaborating?

Sorry, I cannot comment more on this.

>      >     - The tight intertwinglyness of compressed pointers and isolates
> 
>     This is a technical necessity: compressed pointers can only be used
>     when
>     references within the image heap are relative to the heap base - which
>     is exactly what isolates provide. The support for isolates is a
>     (positive) side effect of compressed pointers.
> 
> 
> Compressed pointers could also be useful without multiple isolates, 
> though, no?

Yes. But compressed pointers requires pointers that are relative to the 
image heap. So you should see things the other way round: compressed 
pointers provide the basis for multiple isolates, i.e., support for 
multiple isolates is just a small extension of all the code that was 
necessary for compressed pointers.

> I know Jason Greene was submitted some heap-copying optimizations which 
> could've been used with compressed pointers, but without isolates.
> 
> For our serverless or microservice or high-density-containers-on-a-pod 
> use-cases, multiple isolates seems... un-needed.
> 
> But having compressed pointers is still desirable.
> 
> 
>      >     - The lazy class initiatialization changes
> 
>     Based on our experience and feedback from early adopters (and all the
>     effort you did for Quarkus was an important feedback for us too), it
>     became clear that the default needs to be "initialize classes at run
>     time". This is what Java developers are used to, and no application
>     will
>     work out-of-the-box if you change this. A lot of libraries and
>     frameworks of course want to take advantage of class initialization at
>     build time. We envision that libraries will ship with the appropriate
>     configuration, i.e., that Quarkus will ship with the configuration that
>     most classes are initialized at build time.
> 
>     I'm sorry that we rushed out these changes, but we felt that the time
>     window for a change like that was closing rapidly.
> 
> 
> Sure, but open discussion would've been beneficial prior to the action 
> being taken.

Yes, I hope we can improve that in the future.

>      >     - the LLVM effort
> 
>     I don't understand your concern here. What can be negative about
>     supporting more platforms via LLVM?
> 
> 
> I'm not *opposed* to the LLVM effort, don't get me wrong. But as I'm 
> working on vanilla AArch64, I'm left wondering if the path I'm taking 
> will end up being orphaned in favor of the LLVM strategy. Am I wasting 
> my time? Should I be working with Johan on the LLVM stuff?I have no idea.

No, native AArch64 support is still necessary for GraalVM. LLVM 
complicates the build process, greatly increases compile times, and will 
most likely never reach the peak performance of a native backend. All of 
that is acceptable if you want to quickly support a new architecture, or 
if you have company requirements that applications must ship with LLVM 
bitcode (Apple has such requirements for their app store).

-Christian


> It all boils back down to open communication and project governance, of 
> which I'm still not feeling super re-assured about.
> 
> -Bob
> 
> 
>     -Christian
>