> On Sep 28, 2016, at 11:50 AM, Thomas Stüfe <thomas.stu...@gmail.com> wrote: > > > > On Wed, Sep 28, 2016 at 7:33 PM, Martin Buchholz <marti...@google.com > <mailto:marti...@google.com>> wrote: > On Wed, Sep 28, 2016 at 9:33 AM, Volker Simonis <volker.simo...@gmail.com > <mailto:volker.simo...@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. >
