Opensource, Community, Governance

[Bob McWhirter]

On Wed, May 1, 2019 at 2:13 PM Christian Wimmer <christian.wimmer at oracle.com>
wrote:

>
> 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.
>

I think that's the primary crux of the matter. There's obviously style and
other gate checks on the code. A process, if you will. There's not just
hope that the code is well-formatted and non-buggy.

Is the GraalVM project willing to go beyond "hope" for improved
communication and actually instill a governance process that is open and
transparent?

We are downstream, so decisions made without involvement somewhat remove
control of our own destiny from us. Which is discomforting.

Right or wrong, there's feelings that while there are N things we feel
non-involved with, there are N*M more that we're not even aware of that
will probably ultimately affect us (and all other downstream consumers).
And we don't want to be caught unawares.  Particularly since we are
contributing both upstream and to the general ecosystem, we feel we have at
least some standing in being concerned.



>
> >      >     - 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).
>

Thanks, that's good to know.

-Bob


>
> -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
> >
>