RFR: 8166189: Fix for Bug 8165524 breaks AIX build

Chris Bensen chris.bensen at oracle.com
Wed Sep 28 18:54:17 UTC 2016


> 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 <mailto:martinrb at google.com>> wrote:
> On Wed, Sep 28, 2016 at 9:33 AM, Volker Simonis <volker.simonis at gmail.com <mailto: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 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.

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




More information about the build-dev mailing list