RFR: 8166189: Fix for Bug 8165524 breaks AIX build

[Erik Joelsson]

Hello,

 From my point of view, now that I better understand what aix/porting 
actually was/is, I would say go for it. Put something together the way 
you would like it. I doubt there will ever be much code needed in this 
new entity so it can go in the top level repo without problems. There is 
already a common/src you can sort it into. I assume you will want to 
build a static lib that is easily picked up by other libraries and 
provide an include directory. Put a new makefile in <top>/make that 
builds this, create a new top level target in <top>/make/Main.gmk that 
calls it. Build it into <outputdir>/support/native/<somesuitablename>. 
Since this is only for AIX now, surround it with proper ifeqs. Doesn't 
really seem that complicated to me. :)

Neither hotspot nor JDK is buildable on their own now, so there is no 
problem putting dependencies on either at the top level.

/Erik

On 2016-09-29 09:03, Volker Simonis wrote:
> 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.
>>
>>