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