RFR: 8166189: Fix for Bug 8165524 breaks AIX build

[Volker Simonis]

On Wed, Sep 28, 2016 at 8:54 PM, Chris Bensen <chris.bensen at oracle.com> wrote:
>
> On Sep 28, 2016, at 11:50 AM, Thomas Stüfe <thomas.stuefe at gmail.com> wrote:
>
>
>
> On Wed, Sep 28, 2016 at 7:33 PM, Martin Buchholz <martinrb at google.com>
> wrote:
>>
>> On Wed, Sep 28, 2016 at 9:33 AM, Volker Simonis <volker.simonis at gmail.com>
>> wrote:
>>
>> >
>> > I don't think this can be easily done with the current build system.
>> > Remember for example that even such a sensitive part like jni.h is
>> > still duplicated between the hotspot and the jdk repository:
>> >
>> > hotspot/src/share/vm/prims/jni.h
>> > jdk/src/java.base/share/native/include/jni.h
>> >
>>
>> It's one of the frustrating aspects of openjdk development that it's hard
>> to share C level infrastructure among different components.  Components
>> sometimes grow their own local C infrastructure, but when another
>> component
>> has the same problem, one often resorts to copy-paste as the most
>> expedient
>> way to get code reuse.  In part, the mercurial repo organization
>> reinforces
>> this - there is one top-level repo with fan-out, but there is nothing at
>> the bottom with fan-in.
>
>
> At SAP, we often solve this by moving code to the hotspot and exporting it
> from there, the hotspot being the central part which (almost) has to be
> loaded from the very beginning. I think we did this for dladdr() too.
>

As I said before, this obviously can't work for libjli which is used
to dynamically load the libjvm.

> But that is an ugly hack too, because it bloats the hotspot and forces us to
> add -ljvm to a lot of makefiles or to resolve those functions dynamically.
>
> Another solution for us on AIX could be to put this stuff into an own
> library and provide it independently from the OpenJDK build system, just
> declare it to be a build dependency, similar to Apples JavaRuntimeServices.
>
> As we need dladdr() in both hotspot and JDK, maybe that would be the best
> option.
>
>
> That sounds like a reasonable solution to me.
>

Sorry, but that doesn't sound like a solution to me at all. I think we
should keep the OpenJDK sources self-contained. I don't want to depend
on yet another non-standard, third party library which doesn't even
exist now.

The solution proposed by Martin could work, but it is not great from a
software engineering perspective either because it doesn't allow
sharing of header files.

What would be actually needed would be a new top-level
repository/directory (call it 'base' or 'porting' or whatsoever) which
should be organized like for example jdk/java.base/src (i.e. have
'share/', 'unix/', 'windows/', etc. subdirectories.

The artifacts from this new directory would be build as the very first
step of the build process (if necessary) and the results, as well as
the source directories themselves would have to be made available to
all the other build steps (in particular to. hotspot and jdk). In fact
I had implemented a similar solution for the jdk repository in order
to stay with a single copy of dladdr on AIX  (i.e.
jdk/src/aix/porting). But this solution had to go away when the
sources were modularized because the new schema doesn't allow sharing
of files between modules anymore :(

However, I'm not sure if we want to start such a project right now?

> Chris
>
>
>
>
>>
>> One code sharing mechanism that does get used is seen in
>> ClassLoader::load_zip_library()
>> where code from the jdk repo is packaged into a shared object and invoked
>> from hotspot, dynamically.
>
>
>