RFR: 8166189: Fix for Bug 8165524 breaks AIX build
erik.joelsson at oracle.com
Thu Sep 29 09:06:02 UTC 2016
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.
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>
>>> On Wed, Sep 28, 2016 at 9:33 AM, Volker Simonis <volker.simonis at gmail.com>
>>>> 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:
>>> 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
>>> has the same problem, one often resorts to copy-paste as the most
>>> way to get code reuse. In part, the mercurial repo organization
>>> 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
>> 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?
>>> One code sharing mechanism that does get used is seen in
>>> where code from the jdk repo is packaged into a shared object and invoked
>>> from hotspot, dynamically.
More information about the core-libs-dev