RFR: 8166189: Fix for Bug 8165524 breaks AIX build

Thomas Stüfe thomas.stuefe at gmail.com
Wed Sep 28 18:50:24 UTC 2016

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

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

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

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

More information about the core-libs-dev mailing list