On Wed, Sep 28, 2016 at 8:54 PM, Chris Bensen <chris.ben...@oracle.com> wrote: > > 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> > wrote: >> >> On Wed, Sep 28, 2016 at 9:33 AM, Volker Simonis <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. >
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. > > >
