Hello,
From my point of view, now that I better understand what aix/porting
actually was/is, I would say go for it. Put something together the way
you would like it. I doubt there will ever be much code needed in this
new entity so it can go in the top level repo without problems. There is
already a common/src you can sort it into. I assume you will want to
build a static lib that is easily picked up by other libraries and
provide an include directory. Put a new makefile in <top>/make that
builds this, create a new top level target in <top>/make/Main.gmk that
calls it. Build it into <outputdir>/support/native/<somesuitablename>.
Since this is only for AIX now, surround it with proper ifeqs. Doesn't
really seem that complicated to me. :)
Neither hotspot nor JDK is buildable on their own now, so there is no
problem putting dependencies on either at the top level.
/Erik
On 2016-09-29 09:03, Volker Simonis wrote:
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.
