Opensource, Community, Governance

[Bob McWhirter]

On Wed, May 1, 2019 at 1:31 PM Christian Wimmer <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.


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


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

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.


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

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

-Bob


>
> -Christian
>
>