Re: RFR: 8166189: Fix for Bug 8165524 breaks AIX build

[Kumar Srinivasan]

Hi Volker,


Hi Volker et. al.,

Was a bug opened to track this ? I still see these files around
http://hg.openjdk.java.net/jdk9/dev/jdk/file/ff45c582ca8a/src/java.base/aix/native/libjli


Hi Kumar,

no, as far as I know there's no bug for this issue until now.


Have created a bug for you:
https://bugs.openjdk.java.net/browse/JDK-8170635


The current situation is not ideal, but it works and it doesn't impact
any other platform except AIX.


Yes there are  2 or more instances of this in the JDK repo, this poses a 
greater

problem to maintain the integrity of this function.


So there's no reason for us to address this with high priority and
surely not within the jdk9 time frame.

I think ideally, this could be addressed the next time we see a
similar problem, otherwise it is probably always too much at the
bottom of the priority list :)


It may not be high priority, but it needs to be fixed, for this reason
I have created a JDK10 bug, but at the very least we need to track it.

Thanks
Kumar



Thank you and best regards,
Volker


Would you like me to create a bug for you ?

Thanks
Kumar


On 9/29/2016 9:59 AM, Volker Simonis wrote:

On Thu, Sep 29, 2016 at 5:25 PM, Erik Joelsson 
wrote:


On 2016-09-29 16:54, Alan Burlison wrote:

On 29/09/2016 08:03, Volker Simonis wrote:


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.


Unless I'm completely misunderstanding, that's not what is being
proposed.
What is being proposed is refactoring code that's currently duplicated
across the JVM & JDK into a common library. Such a library would be a
standard Java component, not non-standard and not third-party. I can't
see
what the problem is, to be honest.


Volker's comment above was directed at the suggestion of taking the
problematic AIX specific code out of the OpenJDK repositories and create
a
separate library with a separate lifecycle somewhere else that OpenJDK
for
AIX would then need to depend on. Volker was instead proposing what you
describe.


Thanks Erik, this is exactly what I meant :)

And I think the solution you ssketched in your previous mail is the
right way to address this problem.

Regards,
Volker



/Erik

Re: RFR: 8166189: Fix for Bug 8165524 breaks AIX build

[Volker Simonis]

On Wed, Nov 30, 2016 at 6:18 AM, Kumar Srinivasan
 wrote:
> Hi Volker et. al.,
>
> Was a bug opened to track this ? I still see these files around
> http://hg.openjdk.java.net/jdk9/dev/jdk/file/ff45c582ca8a/src/java.base/aix/native/libjli
>

Hi Kumar,

no, as far as I know there's no bug for this issue until now.
The current situation is not ideal, but it works and it doesn't impact
any other platform except AIX.
So there's no reason for us to address this with high priority and
surely not within the jdk9 time frame.

I think ideally, this could be addressed the next time we see a
similar problem, otherwise it is probably always too much at the
bottom of the priority list :)

Thank you and best regards,
Volker

> Would you like me to create a bug for you ?
>
> Thanks
> Kumar
>
>
> On 9/29/2016 9:59 AM, Volker Simonis wrote:
>>
>> On Thu, Sep 29, 2016 at 5:25 PM, Erik Joelsson 
>> wrote:
>>>
>>>
>>> On 2016-09-29 16:54, Alan Burlison wrote:

 On 29/09/2016 08:03, Volker Simonis wrote:

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


 Unless I'm completely misunderstanding, that's not what is being
 proposed.
 What is being proposed is refactoring code that's currently duplicated
 across the JVM & JDK into a common library. Such a library would be a
 standard Java component, not non-standard and not third-party. I can't
 see
 what the problem is, to be honest.

>>> Volker's comment above was directed at the suggestion of taking the
>>> problematic AIX specific code out of the OpenJDK repositories and create
>>> a
>>> separate library with a separate lifecycle somewhere else that OpenJDK
>>> for
>>> AIX would then need to depend on. Volker was instead proposing what you
>>> describe.
>>>
>> Thanks Erik, this is exactly what I meant :)
>>
>> And I think the solution you ssketched in your previous mail is the
>> right way to address this problem.
>>
>> Regards,
>> Volker
>>
>>
>>> /Erik
>
>

Re: RFR: 8166189: Fix for Bug 8165524 breaks AIX build

[Kumar Srinivasan]

Hi Volker et. al.,

Was a bug opened to track this ? I still see these files around
http://hg.openjdk.java.net/jdk9/dev/jdk/file/ff45c582ca8a/src/java.base/aix/native/libjli

Would you like me to create a bug for you ?

Thanks
Kumar

On 9/29/2016 9:59 AM, Volker Simonis wrote:

On Thu, Sep 29, 2016 at 5:25 PM, Erik Joelsson  wrote:


On 2016-09-29 16:54, Alan Burlison wrote:

On 29/09/2016 08:03, Volker Simonis wrote:


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.


Unless I'm completely misunderstanding, that's not what is being proposed.
What is being proposed is refactoring code that's currently duplicated
across the JVM & JDK into a common library. Such a library would be a
standard Java component, not non-standard and not third-party. I can't see
what the problem is, to be honest.


Volker's comment above was directed at the suggestion of taking the
problematic AIX specific code out of the OpenJDK repositories and create a
separate library with a separate lifecycle somewhere else that OpenJDK for
AIX would then need to depend on. Volker was instead proposing what you
describe.


Thanks Erik, this is exactly what I meant :)

And I think the solution you ssketched in your previous mail is the
right way to address this problem.

Regards,
Volker



/Erik

Re: RFR: 8166189: Fix for Bug 8165524 breaks AIX build

[Kumar Srinivasan]

+1.

Kumar


On 29/09/2016 16:25, Erik Joelsson wrote:


Volker's comment above was directed at the suggestion of taking the
problematic AIX specific code out of the OpenJDK repositories and create
a separate library with a separate lifecycle somewhere else that OpenJDK
for AIX would then need to depend on. Volker was instead proposing what
you describe.


Ah right, in which case we are in violent agreement ;-)

Re: RFR: 8166189: Fix for Bug 8165524 breaks AIX build

[Alan Burlison]

On 29/09/2016 16:25, Erik Joelsson wrote:


Volker's comment above was directed at the suggestion of taking the
problematic AIX specific code out of the OpenJDK repositories and create
a separate library with a separate lifecycle somewhere else that OpenJDK
for AIX would then need to depend on. Volker was instead proposing what
you describe.


Ah right, in which case we are in violent agreement ;-)

--
Alan Burlison
--

Re: RFR: 8166189: Fix for Bug 8165524 breaks AIX build

[Volker Simonis]

On Thu, Sep 29, 2016 at 5:25 PM, Erik Joelsson  wrote:
>
>
> On 2016-09-29 16:54, Alan Burlison wrote:
>>
>> On 29/09/2016 08:03, Volker Simonis wrote:
>>
>>> 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.
>>
>>
>> Unless I'm completely misunderstanding, that's not what is being proposed.
>> What is being proposed is refactoring code that's currently duplicated
>> across the JVM & JDK into a common library. Such a library would be a
>> standard Java component, not non-standard and not third-party. I can't see
>> what the problem is, to be honest.
>>
> Volker's comment above was directed at the suggestion of taking the
> problematic AIX specific code out of the OpenJDK repositories and create a
> separate library with a separate lifecycle somewhere else that OpenJDK for
> AIX would then need to depend on. Volker was instead proposing what you
> describe.
>

Thanks Erik, this is exactly what I meant :)

And I think the solution you ssketched in your previous mail is the
right way to address this problem.

Regards,
Volker


> /Erik

Re: RFR: 8166189: Fix for Bug 8165524 breaks AIX build

[Chris Bensen]

A lot of ideas have been thrown around so solve the problem of duplicated code 
in this situation. And there are other cases that are nearly identical so we 
need a general solution. The fact is this code should be moved to a common 
location. Since OpenJDK depends on Posix, Windows API and a few other non 
standard things that are mostly standard such as dladdr, it has been suggested 
by me and others that a library that doesn’t depend on anything else be created 
containing these methods to backfill the API that OpenJDK depends on if that 
API is not present on that platform. If that is a library outside OpenJDK or 
inside I’m not sure if that matters. Fact is there should be a library that 
contains method such as dladdr in cases such as AIX that do not have that 
method. Personally I’m not sure if the hack implementation of dladdr for AIX 
should be located in OpenJDK.

Chris


> On Sep 29, 2016, at 8:25 AM, Erik Joelsson  wrote:
> 
> 
> 
> On 2016-09-29 16:54, Alan Burlison wrote:
>> On 29/09/2016 08:03, Volker Simonis wrote:
>> 
>>> 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.
>> 
>> Unless I'm completely misunderstanding, that's not what is being proposed. 
>> What is being proposed is refactoring code that's currently duplicated 
>> across the JVM & JDK into a common library. Such a library would be a 
>> standard Java component, not non-standard and not third-party. I can't see 
>> what the problem is, to be honest.
>> 
> Volker's comment above was directed at the suggestion of taking the 
> problematic AIX specific code out of the OpenJDK repositories and create a 
> separate library with a separate lifecycle somewhere else that OpenJDK for 
> AIX would then need to depend on. Volker was instead proposing what you 
> describe.
> 
> /Erik

Re: RFR: 8166189: Fix for Bug 8165524 breaks AIX build

[Erik Joelsson]

On 2016-09-29 16:54, Alan Burlison wrote:

On 29/09/2016 08:03, Volker Simonis wrote:


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.


Unless I'm completely misunderstanding, that's not what is being 
proposed. What is being proposed is refactoring code that's currently 
duplicated across the JVM & JDK into a common library. Such a library 
would be a standard Java component, not non-standard and not 
third-party. I can't see what the problem is, to be honest.


Volker's comment above was directed at the suggestion of taking the 
problematic AIX specific code out of the OpenJDK repositories and create 
a separate library with a separate lifecycle somewhere else that OpenJDK 
for AIX would then need to depend on. Volker was instead proposing what 
you describe.


/Erik

Re: RFR: 8166189: Fix for Bug 8165524 breaks AIX build

[Alan Burlison]

On 29/09/2016 08:03, Volker Simonis wrote:


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.


Unless I'm completely misunderstanding, that's not what is being 
proposed. What is being proposed is refactoring code that's currently 
duplicated across the JVM & JDK into a common library. Such a library 
would be a standard Java component, not non-standard and not 
third-party. I can't see what the problem is, to be honest.


--
Alan Burlison
--

Re: RFR: 8166189: Fix for Bug 8165524 breaks AIX build

[Erik Joelsson]

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 /make that 
builds this, create a new top level target in /make/Main.gmk that 
calls it. Build it into /support/native/. 
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  wrote:

On Sep 28, 2016, at 11:50 AM, Thomas Stüfe  wrote:



On Wed, Sep 28, 2016 at 7:33 PM, Martin Buchholz 
wrote:

On Wed, Sep 28, 2016 at 9:33 AM, Volker Simonis 
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.

Re: RFR: 8166189: Fix for Bug 8165524 breaks AIX build

[Volker Simonis]

On Wed, Sep 28, 2016 at 8:54 PM, Chris Bensen  wrote:
>
> On Sep 28, 2016, at 11:50 AM, Thomas Stüfe  wrote:
>
>
>
> On Wed, Sep 28, 2016 at 7:33 PM, Martin Buchholz 
> wrote:
>>
>> On Wed, Sep 28, 2016 at 9:33 AM, Volker Simonis 
>> 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.
>
>
>

Re: RFR: 8166189: Fix for Bug 8165524 breaks AIX build

[Thomas Stüfe]

Hi Kumar,

On Wed, Sep 28, 2016 at 3:03 PM, Kumar Srinivasan <
kumar.x.sriniva...@oracle.com> wrote:

>
> Hello Thomas, Volker,
>
>
> Hi Kumar,
>
>
>> On 9/16/2016 10:34 AM, Volker Simonis wrote:
>>
>>> Hi Christoph,
>>>
>>> I think your change is fine as a quick-fix to fix the build. But
>>> you're completely right that this should be reworked in the long term.
>>> I hate to see that we now have the third version of these routines in
>>> the OpenJDK. Unfortunately a clean solution is not trivial.
>>>
>>> libjli is not linked against libjvm because libjli is actually used to
>>> load libjvm. So we can not put the dladdr routines for AIX there. But
>>> I think we should at least consolidate the two versions which will be
>>> in the class library after your change. Initially I intentionally put
>>> porting_aix.{c,h} into jdk/aix/porting with the intent to make it
>>> available to ALL jdk native libraries.
>>>
>>> Unfortunately, with the source code reorganization due to the modular
>>> changes, the common, top-level aix repository had to go away and the
>>> code was moved to src/java.desktop/aix/native/libawt/porting_aix.c.
>>> With the reorganized, modularized source code layout and build system
>>> it is not possible to share code between modules. We somehow have to
>>> fix this although I currently don't know how. IF somebody has an idea,
>>> please let me know :)
>>>
>>
>> Why doesn't AIX support a Standard C API that most other
>> *nix based OS'es support ?
>>
>>
> dladdr() is not Posix, hence it should not be used in code that wants to
> be portable across Unix systems. Afaik dladdr() is a propietary Solaris API
> that was adapted by the glibc and slowly spread over to some other Unices,
> but by no means all of them.
>
> dladdr makes a number of assumptions about the architecture: e.g. that a C
> function pointer points into the text segment of the binary instead of e.g.
> a PLT, or that a loaded binary is placed continuously in memory (we only
> have one dli_fbase in DL_info). So imho  it makes sense to not make this a
> standard Posix API.
>
> We (SAP) implemented dladdr atop of loadquery(), and this kind of works,
> although we had to add some hacks to handle both real code addresses and C
> function pointers. So the code is there, it is "just" a question of where
> to place it.
>
>
> I understand your desire to keep AIX pristine and clean, similarly,
> we should also keep  OpenJDK sources clean, having 3 identical
> dladdr implementation, spread across the OpenJDK does not
> bode well.
>
>
I'm not IBM :) and have therefore no strong emotions about keeping AIX
pristine. I only did argue that dladdr() is not POSIX and therefore that it
would have been nice if OpenJDK would have refrained from using this API
(so much).

Kind Regards, Thomas

So, is it possible to park the sources in hotspot repo, and create a
> shared shared object, that can be suitably linked to the launchers,
> awt and hotspot to this library/object ?
>
> Thanks
> Kumar
>
>
>
>
> Kind Regards, Thomas
>
> Thanks
>>
>> Kumar
>>
>>
>>
>>> Regarding your change:
>>>
>>> - can you please move
>>>
>>> +#if defined(_AIX)
>>> +#include "java_md_aix.h"
>>> +#endif
>>> +
>>>
>>> from java_md_common.c to the end of
>>> java.base/unix/native/libjli/java_md.h. It will then be automatically
>>> included into java_md_common.c trough java.h which includes java_md.h
>>>
>>> Also, this version of dladdr is inherently not thread safe. I don't
>>> think that's a problem here, but it would be nice if you could quickly
>>> check if that's indeed true.
>>>
>>> Besides that, looks good.
>>>
>>> Thanks for fixing,
>>> Volker
>>>
>>>
>>>
>>>
>>> On Fri, Sep 16, 2016 at 11:58 AM, Langer, Christoph
>>>  wrote:
>>>
 Hi,

 the fix for https://bugs.openjdk.java.net/browse/JDK-8165524 breaks
 the AIX build as function dladdr is not available on AIX.

 There already exist ports of that API in hotspot and awt. With the
 proposed change I duplicate the awt port to libjli. This is maybe only a
 quick fix - eventually we should think about consolidating and using the
 hotspot port in all places by exporting it from libjvm.so for AIX.

 Bug: https://bugs.openjdk.java.net/browse/JDK-8166189
 Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8166189.0/

 Thanks
 Christoph


 -Original Message-
> From: core-libs-dev [mailto:core-libs-dev-boun...@openjdk.java.net]
> On Behalf
> Of Kumar Srinivasan
> Sent: Montag, 12. September 2016 22:57
> To: core-libs-dev ; Mandy Chung
> ; Chris Bensen 
> Subject: RFR: 8165524: Better detect JRE that Linux JLI will be using
>
> Hello,
>
> I am sponsoring this changeset for Chris Bensen of the java packager
> team, please review  fix for the launcher to  better locate java.home.
>
> http://cr.openjdk.java.net/~ksrini/8165524/
>
> Thanks
> Kumar
>

>>
>
>

Re: RFR: 8166189: Fix for Bug 8165524 breaks AIX build

[Chris Bensen]

> On Sep 28, 2016, at 11:50 AM, Thomas Stüfe  wrote:
> 
> 
> 
> On Wed, Sep 28, 2016 at 7:33 PM, Martin Buchholz  > wrote:
> On Wed, Sep 28, 2016 at 9:33 AM, Volker Simonis  >
> 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.
> 

Re: RFR: 8166189: Fix for Bug 8165524 breaks AIX build

[Thomas Stüfe]

On Wed, Sep 28, 2016 at 7:33 PM, Martin Buchholz 
wrote:

> On Wed, Sep 28, 2016 at 9:33 AM, Volker Simonis 
> 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.
>

Re: RFR: 8166189: Fix for Bug 8165524 breaks AIX build

[Martin Buchholz]

On Wed, Sep 28, 2016 at 9:33 AM, Volker Simonis 
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.

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.

Re: RFR: 8166189: Fix for Bug 8165524 breaks AIX build

[Kumar Srinivasan]

One thing I missed to mention,  the fix for  8165524
is primarily to assist the packager tool, which deploys client
side/JavaFX based applications.

If this tool is not relevant and does not exist on AIX. Then at
a minimum the dladdr  call can either be dynamically located/invoked
using dlsym, or  simply have the AIX version of dladdr return JNI_FALSE
always, only for the launcher of course.

Thanks
Kumar




Hello Thomas, Volker,



Hi Kumar,


On 9/16/2016 10:34 AM, Volker Simonis wrote:

Hi Christoph,

I think your change is fine as a quick-fix to fix the build. But
you're completely right that this should be reworked in the
long term.
I hate to see that we now have the third version of these
routines in
the OpenJDK. Unfortunately a clean solution is not trivial.

libjli is not linked against libjvm because libjli is actually
used to
load libjvm. So we can not put the dladdr routines for AIX
there. But
I think we should at least consolidate the two versions which
will be
in the class library after your change. Initially I
intentionally put
porting_aix.{c,h} into jdk/aix/porting with the intent to 
make it

available to ALL jdk native libraries.

Unfortunately, with the source code reorganization due to the
modular
changes, the common, top-level aix repository had to go away
and the
code was moved to
src/java.desktop/aix/native/libawt/porting_aix.c.
With the reorganized, modularized source code layout and build
system
it is not possible to share code between modules. We somehow
have to
fix this although I currently don't know how. IF somebody has
an idea,
please let me know :)


Why doesn't AIX support a Standard C API that most other
*nix based OS'es support ?


dladdr() is not Posix, hence it should not be used in code that wants 
to be portable across Unix systems. Afaik dladdr() is a propietary 
Solaris API that was adapted by the glibc and slowly spread over to 
some other Unices, but by no means all of them.
dladdr makes a number of assumptions about the architecture: e.g. 
that a C function pointer points into the text segment of the binary 
instead of e.g. a PLT, or that a loaded binary is placed continuously 
in memory (we only have one dli_fbase in DL_info). So imho  it makes 
sense to not make this a standard Posix API.


We (SAP) implemented dladdr atop of loadquery(), and this kind of 
works, although we had to add some hacks to handle both real code 
addresses and C function pointers. So the code is there, it is "just" 
a question of where to place it.


I understand your desire to keep AIX pristine and clean, similarly,
we should also keep  OpenJDK sources clean, having 3 identical
dladdr implementation, spread across the OpenJDK does not
bode well.

So, is it possible to park the sources in hotspot repo, and create a
shared shared object, that can be suitably linked to the launchers,
awt and hotspot to this library/object ?

Thanks
Kumar




Kind Regards, Thomas

Thanks

Kumar



Regarding your change:

- can you please move

+#if defined(_AIX)
+#include "java_md_aix.h"
+#endif
+

from java_md_common.c to the end of
java.base/unix/native/libjli/java_md.h. It will then be
automatically
included into java_md_common.c trough java.h which includes
java_md.h

Also, this version of dladdr is inherently not thread safe. I
don't
think that's a problem here, but it would be nice if you could
quickly
check if that's indeed true.

Besides that, looks good.

Thanks for fixing,
Volker




On Fri, Sep 16, 2016 at 11:58 AM, Langer, Christoph
mailto:christoph.lan...@sap.com>>
wrote:

Hi,

the fix for
https://bugs.openjdk.java.net/browse/JDK-8165524
 breaks
the AIX build as function dladdr is not available on AIX.

There already exist ports of that API in hotspot and awt.
With the proposed change I duplicate the awt port to
libjli. This is maybe only a quick fix - eventually we
should think about consolidating and using the hotspot
port in all places by exporting it from libjvm.so for AIX.

Bug: https://bugs.openjdk.java.net/browse/JDK-8166189

Webrev:
http://cr.openjdk.java.net/~clanger/webrevs/8166189.0/


Thanks
Christoph


-Original Message-
From: core-libs-dev
[mailto:core-libs-dev-boun...@openjdk.java.net
<

Re: RFR: 8166189: Fix for Bug 8165524 breaks AIX build

[Volker Simonis]

On Wed, Sep 28, 2016 at 3:03 PM, Kumar Srinivasan
 wrote:
>
> Hello Thomas, Volker,
>
>
> Hi Kumar,
>
>>
>> On 9/16/2016 10:34 AM, Volker Simonis wrote:
>>>
>>> Hi Christoph,
>>>
>>> I think your change is fine as a quick-fix to fix the build. But
>>> you're completely right that this should be reworked in the long term.
>>> I hate to see that we now have the third version of these routines in
>>> the OpenJDK. Unfortunately a clean solution is not trivial.
>>>
>>> libjli is not linked against libjvm because libjli is actually used to
>>> load libjvm. So we can not put the dladdr routines for AIX there. But
>>> I think we should at least consolidate the two versions which will be
>>> in the class library after your change. Initially I intentionally put
>>> porting_aix.{c,h} into jdk/aix/porting with the intent to make it
>>> available to ALL jdk native libraries.
>>>
>>> Unfortunately, with the source code reorganization due to the modular
>>> changes, the common, top-level aix repository had to go away and the
>>> code was moved to src/java.desktop/aix/native/libawt/porting_aix.c.
>>> With the reorganized, modularized source code layout and build system
>>> it is not possible to share code between modules. We somehow have to
>>> fix this although I currently don't know how. IF somebody has an idea,
>>> please let me know :)
>>
>>
>> Why doesn't AIX support a Standard C API that most other
>> *nix based OS'es support ?
>>
>
> dladdr() is not Posix, hence it should not be used in code that wants to be
> portable across Unix systems. Afaik dladdr() is a propietary Solaris API
> that was adapted by the glibc and slowly spread over to some other Unices,
> but by no means all of them.
>
> dladdr makes a number of assumptions about the architecture: e.g. that a C
> function pointer points into the text segment of the binary instead of e.g.
> a PLT, or that a loaded binary is placed continuously in memory (we only
> have one dli_fbase in DL_info). So imho  it makes sense to not make this a
> standard Posix API.
>
> We (SAP) implemented dladdr atop of loadquery(), and this kind of works,
> although we had to add some hacks to handle both real code addresses and C
> function pointers. So the code is there, it is "just" a question of where to
> place it.
>
>
> I understand your desire to keep AIX pristine and clean, similarly,
> we should also keep  OpenJDK sources clean, having 3 identical
> dladdr implementation, spread across the OpenJDK does not
> bode well.
>
> So, is it possible to park the sources in hotspot repo, and create a
> shared shared object, that can be suitably linked to the launchers,
> awt and hotspot to this library/object ?

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

So before we envision a solution for the various dladdr
implementations for AIX we should really come up with a general way to
share code between hotspot and jdk. I've cc'ed build-dev because I
think this is to a big part a build/infrastructure issue. If somebody
has a good idea, please let me know :)

Regards,
Volker

>
> Thanks
> Kumar
>
>
>
>
> Kind Regards, Thomas
>
>> Thanks
>>
>> Kumar
>>
>>
>>>
>>> Regarding your change:
>>>
>>> - can you please move
>>>
>>> +#if defined(_AIX)
>>> +#include "java_md_aix.h"
>>> +#endif
>>> +
>>>
>>> from java_md_common.c to the end of
>>> java.base/unix/native/libjli/java_md.h. It will then be automatically
>>> included into java_md_common.c trough java.h which includes java_md.h
>>>
>>> Also, this version of dladdr is inherently not thread safe. I don't
>>> think that's a problem here, but it would be nice if you could quickly
>>> check if that's indeed true.
>>>
>>> Besides that, looks good.
>>>
>>> Thanks for fixing,
>>> Volker
>>>
>>>
>>>
>>>
>>> On Fri, Sep 16, 2016 at 11:58 AM, Langer, Christoph
>>>  wrote:

 Hi,

 the fix for https://bugs.openjdk.java.net/browse/JDK-8165524 breaks the
 AIX build as function dladdr is not available on AIX.

 There already exist ports of that API in hotspot and awt. With the
 proposed change I duplicate the awt port to libjli. This is maybe only a
 quick fix - eventually we should think about consolidating and using the
 hotspot port in all places by exporting it from libjvm.so for AIX.

 Bug: https://bugs.openjdk.java.net/browse/JDK-8166189
 Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8166189.0/

 Thanks
 Christoph


> -Original Message-
> From: core-libs-dev [mailto:core-libs-dev-boun...@openjdk.java.net] On
> Behalf
> Of Kumar Srinivasan
> Sent: Montag, 12. September 2016 22:57
> To: core-libs-dev ; Mandy Chung
> ; Chris Bensen 
> Subject: RFR: 8165524: Better detect JRE that Linux JLI will be using
>

Re: RFR: 8166189: Fix for Bug 8165524 breaks AIX build

[Kumar Srinivasan]

Hello Thomas, Volker,



Hi Kumar,


On 9/16/2016 10:34 AM, Volker Simonis wrote:

Hi Christoph,

I think your change is fine as a quick-fix to fix the build. But
you're completely right that this should be reworked in the
long term.
I hate to see that we now have the third version of these
routines in
the OpenJDK. Unfortunately a clean solution is not trivial.

libjli is not linked against libjvm because libjli is actually
used to
load libjvm. So we can not put the dladdr routines for AIX
there. But
I think we should at least consolidate the two versions which
will be
in the class library after your change. Initially I
intentionally put
porting_aix.{c,h} into jdk/aix/porting with the intent to make it
available to ALL jdk native libraries.

Unfortunately, with the source code reorganization due to the
modular
changes, the common, top-level aix repository had to go away
and the
code was moved to
src/java.desktop/aix/native/libawt/porting_aix.c.
With the reorganized, modularized source code layout and build
system
it is not possible to share code between modules. We somehow
have to
fix this although I currently don't know how. IF somebody has
an idea,
please let me know :)


Why doesn't AIX support a Standard C API that most other
*nix based OS'es support ?


dladdr() is not Posix, hence it should not be used in code that wants 
to be portable across Unix systems. Afaik dladdr() is a propietary 
Solaris API that was adapted by the glibc and slowly spread over to 
some other Unices, but by no means all of them.
dladdr makes a number of assumptions about the architecture: e.g. that 
a C function pointer points into the text segment of the binary 
instead of e.g. a PLT, or that a loaded binary is placed continuously 
in memory (we only have one dli_fbase in DL_info). So imho  it makes 
sense to not make this a standard Posix API.


We (SAP) implemented dladdr atop of loadquery(), and this kind of 
works, although we had to add some hacks to handle both real code 
addresses and C function pointers. So the code is there, it is "just" 
a question of where to place it.


I understand your desire to keep AIX pristine and clean, similarly,
we should also keep  OpenJDK sources clean, having 3 identical
dladdr implementation, spread across the OpenJDK does not
bode well.

So, is it possible to park the sources in hotspot repo, and create a
shared shared object, that can be suitably linked to the launchers,
awt and hotspot to this library/object ?

Thanks
Kumar




Kind Regards, Thomas

Thanks

Kumar



Regarding your change:

- can you please move

+#if defined(_AIX)
+#include "java_md_aix.h"
+#endif
+

from java_md_common.c to the end of
java.base/unix/native/libjli/java_md.h. It will then be
automatically
included into java_md_common.c trough java.h which includes
java_md.h

Also, this version of dladdr is inherently not thread safe. I
don't
think that's a problem here, but it would be nice if you could
quickly
check if that's indeed true.

Besides that, looks good.

Thanks for fixing,
Volker




On Fri, Sep 16, 2016 at 11:58 AM, Langer, Christoph
mailto:christoph.lan...@sap.com>>
wrote:

Hi,

the fix for
https://bugs.openjdk.java.net/browse/JDK-8165524
 breaks
the AIX build as function dladdr is not available on AIX.

There already exist ports of that API in hotspot and awt.
With the proposed change I duplicate the awt port to
libjli. This is maybe only a quick fix - eventually we
should think about consolidating and using the hotspot
port in all places by exporting it from libjvm.so for AIX.

Bug: https://bugs.openjdk.java.net/browse/JDK-8166189

Webrev:
http://cr.openjdk.java.net/~clanger/webrevs/8166189.0/


Thanks
Christoph


-Original Message-
From: core-libs-dev
[mailto:core-libs-dev-boun...@openjdk.java.net
] On Behalf
Of Kumar Srinivasan
Sent: Montag, 12. September 2016 22:57
To: core-libs-dev mailto:core-libs-dev@openjdk.java.net>>; Mandy Chung
mailto:mandy.ch...@oracle.com>>; Chris Bensen
mailto:chris.ben...@oracle.com>>

Re: RFR: 8166189: Fix for Bug 8165524 breaks AIX build

[Thomas Stüfe]

Hi Kumar,


> On 9/16/2016 10:34 AM, Volker Simonis wrote:
>
>> Hi Christoph,
>>
>> I think your change is fine as a quick-fix to fix the build. But
>> you're completely right that this should be reworked in the long term.
>> I hate to see that we now have the third version of these routines in
>> the OpenJDK. Unfortunately a clean solution is not trivial.
>>
>> libjli is not linked against libjvm because libjli is actually used to
>> load libjvm. So we can not put the dladdr routines for AIX there. But
>> I think we should at least consolidate the two versions which will be
>> in the class library after your change. Initially I intentionally put
>> porting_aix.{c,h} into jdk/aix/porting with the intent to make it
>> available to ALL jdk native libraries.
>>
>> Unfortunately, with the source code reorganization due to the modular
>> changes, the common, top-level aix repository had to go away and the
>> code was moved to src/java.desktop/aix/native/libawt/porting_aix.c.
>> With the reorganized, modularized source code layout and build system
>> it is not possible to share code between modules. We somehow have to
>> fix this although I currently don't know how. IF somebody has an idea,
>> please let me know :)
>>
>
> Why doesn't AIX support a Standard C API that most other
> *nix based OS'es support ?
>
>
dladdr() is not Posix, hence it should not be used in code that wants to be
portable across Unix systems. Afaik dladdr() is a propietary Solaris API
that was adapted by the glibc and slowly spread over to some other Unices,
but by no means all of them.

dladdr makes a number of assumptions about the architecture: e.g. that a C
function pointer points into the text segment of the binary instead of e.g.
a PLT, or that a loaded binary is placed continuously in memory (we only
have one dli_fbase in DL_info). So imho  it makes sense to not make this a
standard Posix API.

We (SAP) implemented dladdr atop of loadquery(), and this kind of works,
although we had to add some hacks to handle both real code addresses and C
function pointers. So the code is there, it is "just" a question of where
to place it.

Kind Regards, Thomas

Thanks
>
> Kumar
>
>
>
>> Regarding your change:
>>
>> - can you please move
>>
>> +#if defined(_AIX)
>> +#include "java_md_aix.h"
>> +#endif
>> +
>>
>> from java_md_common.c to the end of
>> java.base/unix/native/libjli/java_md.h. It will then be automatically
>> included into java_md_common.c trough java.h which includes java_md.h
>>
>> Also, this version of dladdr is inherently not thread safe. I don't
>> think that's a problem here, but it would be nice if you could quickly
>> check if that's indeed true.
>>
>> Besides that, looks good.
>>
>> Thanks for fixing,
>> Volker
>>
>>
>>
>>
>> On Fri, Sep 16, 2016 at 11:58 AM, Langer, Christoph
>>  wrote:
>>
>>> Hi,
>>>
>>> the fix for https://bugs.openjdk.java.net/browse/JDK-8165524 breaks the
>>> AIX build as function dladdr is not available on AIX.
>>>
>>> There already exist ports of that API in hotspot and awt. With the
>>> proposed change I duplicate the awt port to libjli. This is maybe only a
>>> quick fix - eventually we should think about consolidating and using the
>>> hotspot port in all places by exporting it from libjvm.so for AIX.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8166189
>>> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8166189.0/
>>>
>>> Thanks
>>> Christoph
>>>
>>>
>>> -Original Message-
 From: core-libs-dev [mailto:core-libs-dev-boun...@openjdk.java.net] On
 Behalf
 Of Kumar Srinivasan
 Sent: Montag, 12. September 2016 22:57
 To: core-libs-dev ; Mandy Chung
 ; Chris Bensen 
 Subject: RFR: 8165524: Better detect JRE that Linux JLI will be using

 Hello,

 I am sponsoring this changeset for Chris Bensen of the java packager
 team, please review  fix for the launcher to  better locate java.home.

 http://cr.openjdk.java.net/~ksrini/8165524/

 Thanks
 Kumar

>>>
>

Re: RFR: 8166189: Fix for Bug 8165524 breaks AIX build

[Chris Bensen]

> On Sep 21, 2016, at 6:38 AM, Kumar Srinivasan  
> wrote:
> 
> 
> On 9/16/2016 10:34 AM, Volker Simonis wrote:
>> Hi Christoph,
>> 
>> I think your change is fine as a quick-fix to fix the build. But
>> you're completely right that this should be reworked in the long term.
>> I hate to see that we now have the third version of these routines in
>> the OpenJDK. Unfortunately a clean solution is not trivial.
>> 
>> libjli is not linked against libjvm because libjli is actually used to
>> load libjvm. So we can not put the dladdr routines for AIX there. But
>> I think we should at least consolidate the two versions which will be
>> in the class library after your change. Initially I intentionally put
>> porting_aix.{c,h} into jdk/aix/porting with the intent to make it
>> available to ALL jdk native libraries.
>> 
>> Unfortunately, with the source code reorganization due to the modular
>> changes, the common, top-level aix repository had to go away and the
>> code was moved to src/java.desktop/aix/native/libawt/porting_aix.c.
>> With the reorganized, modularized source code layout and build system
>> it is not possible to share code between modules. We somehow have to
>> fix this although I currently don't know how. IF somebody has an idea,
>> please let me know :)
> 
> Why doesn't AIX support a Standard C API that most other
> *nix based OS'es support ?

I was wondering the same thing.

Chris


> 
> Thanks
> 
> Kumar
> 
>> 
>> Regarding your change:
>> 
>> - can you please move
>> 
>> +#if defined(_AIX)
>> +#include "java_md_aix.h"
>> +#endif
>> +
>> 
>> from java_md_common.c to the end of
>> java.base/unix/native/libjli/java_md.h. It will then be automatically
>> included into java_md_common.c trough java.h which includes java_md.h
>> 
>> Also, this version of dladdr is inherently not thread safe. I don't
>> think that's a problem here, but it would be nice if you could quickly
>> check if that's indeed true.
>> 
>> Besides that, looks good.
>> 
>> Thanks for fixing,
>> Volker
>> 
>> 
>> 
>> 
>> On Fri, Sep 16, 2016 at 11:58 AM, Langer, Christoph
>>  wrote:
>>> Hi,
>>> 
>>> the fix for https://bugs.openjdk.java.net/browse/JDK-8165524 breaks the AIX 
>>> build as function dladdr is not available on AIX.
>>> 
>>> There already exist ports of that API in hotspot and awt. With the proposed 
>>> change I duplicate the awt port to libjli. This is maybe only a quick fix - 
>>> eventually we should think about consolidating and using the hotspot port 
>>> in all places by exporting it from libjvm.so for AIX.
>>> 
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8166189
>>> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8166189.0/
>>> 
>>> Thanks
>>> Christoph
>>> 
>>> 
 -Original Message-
 From: core-libs-dev [mailto:core-libs-dev-boun...@openjdk.java.net] On 
 Behalf
 Of Kumar Srinivasan
 Sent: Montag, 12. September 2016 22:57
 To: core-libs-dev ; Mandy Chung
 ; Chris Bensen 
 Subject: RFR: 8165524: Better detect JRE that Linux JLI will be using
 
 Hello,
 
 I am sponsoring this changeset for Chris Bensen of the java packager
 team, please review  fix for the launcher to  better locate java.home.
 
 http://cr.openjdk.java.net/~ksrini/8165524/
 
 Thanks
 Kumar
> 

Re: RFR: 8166189: Fix for Bug 8165524 breaks AIX build

[Kumar Srinivasan]

On 9/16/2016 10:34 AM, Volker Simonis wrote:

Hi Christoph,

I think your change is fine as a quick-fix to fix the build. But
you're completely right that this should be reworked in the long term.
I hate to see that we now have the third version of these routines in
the OpenJDK. Unfortunately a clean solution is not trivial.

libjli is not linked against libjvm because libjli is actually used to
load libjvm. So we can not put the dladdr routines for AIX there. But
I think we should at least consolidate the two versions which will be
in the class library after your change. Initially I intentionally put
porting_aix.{c,h} into jdk/aix/porting with the intent to make it
available to ALL jdk native libraries.

Unfortunately, with the source code reorganization due to the modular
changes, the common, top-level aix repository had to go away and the
code was moved to src/java.desktop/aix/native/libawt/porting_aix.c.
With the reorganized, modularized source code layout and build system
it is not possible to share code between modules. We somehow have to
fix this although I currently don't know how. IF somebody has an idea,
please let me know :)


Why doesn't AIX support a Standard C API that most other
*nix based OS'es support ?

Thanks

Kumar



Regarding your change:

- can you please move

+#if defined(_AIX)
+#include "java_md_aix.h"
+#endif
+

from java_md_common.c to the end of
java.base/unix/native/libjli/java_md.h. It will then be automatically
included into java_md_common.c trough java.h which includes java_md.h

Also, this version of dladdr is inherently not thread safe. I don't
think that's a problem here, but it would be nice if you could quickly
check if that's indeed true.

Besides that, looks good.

Thanks for fixing,
Volker




On Fri, Sep 16, 2016 at 11:58 AM, Langer, Christoph
 wrote:

Hi,

the fix for https://bugs.openjdk.java.net/browse/JDK-8165524 breaks the AIX 
build as function dladdr is not available on AIX.

There already exist ports of that API in hotspot and awt. With the proposed 
change I duplicate the awt port to libjli. This is maybe only a quick fix - 
eventually we should think about consolidating and using the hotspot port in 
all places by exporting it from libjvm.so for AIX.

Bug: https://bugs.openjdk.java.net/browse/JDK-8166189
Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8166189.0/

Thanks
Christoph



-Original Message-
From: core-libs-dev [mailto:core-libs-dev-boun...@openjdk.java.net] On Behalf
Of Kumar Srinivasan
Sent: Montag, 12. September 2016 22:57
To: core-libs-dev ; Mandy Chung
; Chris Bensen 
Subject: RFR: 8165524: Better detect JRE that Linux JLI will be using

Hello,

I am sponsoring this changeset for Chris Bensen of the java packager
team, please review  fix for the launcher to  better locate java.home.

http://cr.openjdk.java.net/~ksrini/8165524/

Thanks
Kumar

RE: RFR: 8166189: Fix for Bug 8165524 breaks AIX build

[Langer, Christoph]

Hi all,

hearing no objections and having the final ok from Goetz, I pushed the fix:
http://hg.openjdk.java.net/jdk9/dev/jdk/rev/c709e74ffcf6

Best regards
Christoph

> -Original Message-
> From: Lindenmaier, Goetz
> Sent: Montag, 19. September 2016 11:10
> To: Langer, Christoph ; Volker Simonis
> 
> Cc: Kumar Srinivasan ; Mandy Chung
> ; Chris Bensen ; core-
> libs-dev ; ppc-aix-port-...@openjdk.java.net;
> Dmitry Samersoff 
> Subject: RE: RFR: 8166189: Fix for Bug 8165524 breaks AIX build
> 
> Hi Christoph,
> 
> This looks good now.  Please adapt the copyright year in java_md.h.
> I would appreciate this getting pushed to get our builds going again.
> 
> Best regards,
>   Goetz.
> 
> 
> 
> 
> > -Original Message-
> > From: Langer, Christoph
> > Sent: Montag, 19. September 2016 10:45
> > To: Volker Simonis 
> > Cc: Kumar Srinivasan ; Mandy Chung
> > ; Chris Bensen ;
> > Lindenmaier, Goetz ; core-libs-dev  > d...@openjdk.java.net>; ppc-aix-port-...@openjdk.java.net; Dmitry
> > Samersoff 
> > Subject: RE: RFR: 8166189: Fix for Bug 8165524 breaks AIX build
> >
> > Hi all,
> >
> > thanks for your valuable input.
> >
> > So, since libjli.so can't use libjvm.so and its dladdr() port, there's no 
> > way
> > around the libjli.so specific version of it. However, in libjli.so it is 
> > only used for
> > resolving pathnames of the program, so the code can be very lean. Hence I
> > completely reduced it to delivering the pathname of a module. And this code
> > is not thread safe, as Volker mentioned. I would think/hope that a launcher
> > would do its resolving work all in one thread and this should not be an 
> > issue.
> > Maybe someone of the jli experts can confirm this or object against it. For
> > now I would not spend more efforts in making this multi thread capable.
> >
> > As for the libawt version of dladdr(), this one should be removed and
> > redirected to hotspot. I'll have a look at this when I find time.
> >
> > Please find a new webrev where I have addressed all findings and concerns
> > - corrected spaces and indentation
> > - removed the printf output in favor of handling the return code
> > - only fill the info->dli_fname field
> > - move conditional include to src/java.base/unix/native/libjli/java_md.h
> >
> > http://cr.openjdk.java.net/~clanger/webrevs/8166189.1/
> >
> > Best regards
> > Christoph
> >
> > > -Original Message-
> > > From: Volker Simonis [mailto:volker.simo...@gmail.com]
> > > Sent: Freitag, 16. September 2016 19:34
> > > To: Langer, Christoph 
> > > Cc: Kumar Srinivasan ; Mandy Chung
> > > ; Chris Bensen ;
> > > Thomas Stüfe ; Lindenmaier, Goetz
> > > ; core-libs-dev  > > d...@openjdk.java.net>; ppc-aix-port-...@openjdk.java.net
> > > Subject: Re: RFR: 8166189: Fix for Bug 8165524 breaks AIX build
> > >
> > > Hi Christoph,
> > >
> > > I think your change is fine as a quick-fix to fix the build. But
> > > you're completely right that this should be reworked in the long term.
> > > I hate to see that we now have the third version of these routines in
> > > the OpenJDK. Unfortunately a clean solution is not trivial.
> > >
> > > libjli is not linked against libjvm because libjli is actually used to
> > > load libjvm. So we can not put the dladdr routines for AIX there. But
> > > I think we should at least consolidate the two versions which will be
> > > in the class library after your change. Initially I intentionally put
> > > porting_aix.{c,h} into jdk/aix/porting with the intent to make it
> > > available to ALL jdk native libraries.
> > >
> > > Unfortunately, with the source code reorganization due to the modular
> > > changes, the common, top-level aix repository had to go away and the
> > > code was moved to src/java.desktop/aix/native/libawt/porting_aix.c.
> > > With the reorganized, modularized source code layout and build system
> > > it is not possible to share code between modules. We somehow have to
> > > fix this although I currently don't know how. IF somebody has an idea,
> > > please let me know :)
> > >
> > > Regarding your change:
> > >
> > > - can you please move
> > >
> > > +#if defined(_AIX)
> > > +#include "java_md_aix.h"
> > > +#endif
> > > +
> > >
> > > from java_md_common.c to the end of
> > > java.b

RE: RFR: 8166189: Fix for Bug 8165524 breaks AIX build

[Lindenmaier, Goetz]

Hi Christoph, 

This looks good now.  Please adapt the copyright year in java_md.h.
I would appreciate this getting pushed to get our builds going again.

Best regards,
  Goetz.




> -Original Message-
> From: Langer, Christoph
> Sent: Montag, 19. September 2016 10:45
> To: Volker Simonis 
> Cc: Kumar Srinivasan ; Mandy Chung
> ; Chris Bensen ;
> Lindenmaier, Goetz ; core-libs-dev  d...@openjdk.java.net>; ppc-aix-port-...@openjdk.java.net; Dmitry
> Samersoff 
> Subject: RE: RFR: 8166189: Fix for Bug 8165524 breaks AIX build
> 
> Hi all,
> 
> thanks for your valuable input.
> 
> So, since libjli.so can't use libjvm.so and its dladdr() port, there's no way
> around the libjli.so specific version of it. However, in libjli.so it is only 
> used for
> resolving pathnames of the program, so the code can be very lean. Hence I
> completely reduced it to delivering the pathname of a module. And this code
> is not thread safe, as Volker mentioned. I would think/hope that a launcher
> would do its resolving work all in one thread and this should not be an issue.
> Maybe someone of the jli experts can confirm this or object against it. For
> now I would not spend more efforts in making this multi thread capable.
> 
> As for the libawt version of dladdr(), this one should be removed and
> redirected to hotspot. I'll have a look at this when I find time.
> 
> Please find a new webrev where I have addressed all findings and concerns
> - corrected spaces and indentation
> - removed the printf output in favor of handling the return code
> - only fill the info->dli_fname field
> - move conditional include to src/java.base/unix/native/libjli/java_md.h
> 
> http://cr.openjdk.java.net/~clanger/webrevs/8166189.1/
> 
> Best regards
> Christoph
> 
> > -Original Message-
> > From: Volker Simonis [mailto:volker.simo...@gmail.com]
> > Sent: Freitag, 16. September 2016 19:34
> > To: Langer, Christoph 
> > Cc: Kumar Srinivasan ; Mandy Chung
> > ; Chris Bensen ;
> > Thomas Stüfe ; Lindenmaier, Goetz
> > ; core-libs-dev  > d...@openjdk.java.net>; ppc-aix-port-...@openjdk.java.net
> > Subject: Re: RFR: 8166189: Fix for Bug 8165524 breaks AIX build
> >
> > Hi Christoph,
> >
> > I think your change is fine as a quick-fix to fix the build. But
> > you're completely right that this should be reworked in the long term.
> > I hate to see that we now have the third version of these routines in
> > the OpenJDK. Unfortunately a clean solution is not trivial.
> >
> > libjli is not linked against libjvm because libjli is actually used to
> > load libjvm. So we can not put the dladdr routines for AIX there. But
> > I think we should at least consolidate the two versions which will be
> > in the class library after your change. Initially I intentionally put
> > porting_aix.{c,h} into jdk/aix/porting with the intent to make it
> > available to ALL jdk native libraries.
> >
> > Unfortunately, with the source code reorganization due to the modular
> > changes, the common, top-level aix repository had to go away and the
> > code was moved to src/java.desktop/aix/native/libawt/porting_aix.c.
> > With the reorganized, modularized source code layout and build system
> > it is not possible to share code between modules. We somehow have to
> > fix this although I currently don't know how. IF somebody has an idea,
> > please let me know :)
> >
> > Regarding your change:
> >
> > - can you please move
> >
> > +#if defined(_AIX)
> > +#include "java_md_aix.h"
> > +#endif
> > +
> >
> > from java_md_common.c to the end of
> > java.base/unix/native/libjli/java_md.h. It will then be automatically
> > included into java_md_common.c trough java.h which includes java_md.h
> >
> > Also, this version of dladdr is inherently not thread safe. I don't
> > think that's a problem here, but it would be nice if you could quickly
> > check if that's indeed true.
> >
> > Besides that, looks good.
> >
> > Thanks for fixing,
> > Volker
> >
> >
> >
> >
> > On Fri, Sep 16, 2016 at 11:58 AM, Langer, Christoph
> >  wrote:
> > > Hi,
> > >
> > > the fix for https://bugs.openjdk.java.net/browse/JDK-8165524 breaks
> the AIX
> > build as function dladdr is not available on AIX.
> > >
> > > There already exist ports of that API in hotspot and awt. With the
> proposed
> > change I duplicate the awt port to libjli. This is maybe only a quick fix -
> > eventually we should think about cons

RE: RFR: 8166189: Fix for Bug 8165524 breaks AIX build

[Langer, Christoph]

Hi all,

thanks for your valuable input.

So, since libjli.so can't use libjvm.so and its dladdr() port, there's no way 
around the libjli.so specific version of it. However, in libjli.so it is only 
used for resolving pathnames of the program, so the code can be very lean. 
Hence I completely reduced it to delivering the pathname of a module. And this 
code is not thread safe, as Volker mentioned. I would think/hope that a 
launcher would do its resolving work all in one thread and this should not be 
an issue. Maybe someone of the jli experts can confirm this or object against 
it. For now I would not spend more efforts in making this multi thread capable.

As for the libawt version of dladdr(), this one should be removed and 
redirected to hotspot. I'll have a look at this when I find time.

Please find a new webrev where I have addressed all findings and concerns
- corrected spaces and indentation
- removed the printf output in favor of handling the return code
- only fill the info->dli_fname field
- move conditional include to src/java.base/unix/native/libjli/java_md.h

http://cr.openjdk.java.net/~clanger/webrevs/8166189.1/

Best regards
Christoph

> -Original Message-
> From: Volker Simonis [mailto:volker.simo...@gmail.com]
> Sent: Freitag, 16. September 2016 19:34
> To: Langer, Christoph 
> Cc: Kumar Srinivasan ; Mandy Chung
> ; Chris Bensen ;
> Thomas Stüfe ; Lindenmaier, Goetz
> ; core-libs-dev  d...@openjdk.java.net>; ppc-aix-port-...@openjdk.java.net
> Subject: Re: RFR: 8166189: Fix for Bug 8165524 breaks AIX build
> 
> Hi Christoph,
> 
> I think your change is fine as a quick-fix to fix the build. But
> you're completely right that this should be reworked in the long term.
> I hate to see that we now have the third version of these routines in
> the OpenJDK. Unfortunately a clean solution is not trivial.
> 
> libjli is not linked against libjvm because libjli is actually used to
> load libjvm. So we can not put the dladdr routines for AIX there. But
> I think we should at least consolidate the two versions which will be
> in the class library after your change. Initially I intentionally put
> porting_aix.{c,h} into jdk/aix/porting with the intent to make it
> available to ALL jdk native libraries.
> 
> Unfortunately, with the source code reorganization due to the modular
> changes, the common, top-level aix repository had to go away and the
> code was moved to src/java.desktop/aix/native/libawt/porting_aix.c.
> With the reorganized, modularized source code layout and build system
> it is not possible to share code between modules. We somehow have to
> fix this although I currently don't know how. IF somebody has an idea,
> please let me know :)
> 
> Regarding your change:
> 
> - can you please move
> 
> +#if defined(_AIX)
> +#include "java_md_aix.h"
> +#endif
> +
> 
> from java_md_common.c to the end of
> java.base/unix/native/libjli/java_md.h. It will then be automatically
> included into java_md_common.c trough java.h which includes java_md.h
> 
> Also, this version of dladdr is inherently not thread safe. I don't
> think that's a problem here, but it would be nice if you could quickly
> check if that's indeed true.
> 
> Besides that, looks good.
> 
> Thanks for fixing,
> Volker
> 
> 
> 
> 
> On Fri, Sep 16, 2016 at 11:58 AM, Langer, Christoph
>  wrote:
> > Hi,
> >
> > the fix for https://bugs.openjdk.java.net/browse/JDK-8165524 breaks the AIX
> build as function dladdr is not available on AIX.
> >
> > There already exist ports of that API in hotspot and awt. With the proposed
> change I duplicate the awt port to libjli. This is maybe only a quick fix -
> eventually we should think about consolidating and using the hotspot port in 
> all
> places by exporting it from libjvm.so for AIX.
> >
> > Bug: https://bugs.openjdk.java.net/browse/JDK-8166189
> > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8166189.0/
> >
> > Thanks
> > Christoph
> >
> >
> >> -Original Message-
> >> From: core-libs-dev [mailto:core-libs-dev-boun...@openjdk.java.net] On
> Behalf
> >> Of Kumar Srinivasan
> >> Sent: Montag, 12. September 2016 22:57
> >> To: core-libs-dev ; Mandy Chung
> >> ; Chris Bensen 
> >> Subject: RFR: 8165524: Better detect JRE that Linux JLI will be using
> >>
> >> Hello,
> >>
> >> I am sponsoring this changeset for Chris Bensen of the java packager
> >> team, please review  fix for the launcher to  better locate java.home.
> >>
> >> http://cr.openjdk.java.net/~ksrini/8165524/
> >>
> >> Thanks
> >> Kumar
> >

Re: RFR: 8166189: Fix for Bug 8165524 breaks AIX build

[Dmitry Samersoff]

Christoph,

java_md_aix.c

32: missed comma after L_GETINFO

Should you return an error from fill_dll_info rather than print it to
stderr?

-Dmitry



On 2016-09-16 12:58, Langer, Christoph wrote:
> Hi,
> 
> the fix for https://bugs.openjdk.java.net/browse/JDK-8165524 breaks the AIX 
> build as function dladdr is not available on AIX.
> 
> There already exist ports of that API in hotspot and awt. With the proposed 
> change I duplicate the awt port to libjli. This is maybe only a quick fix - 
> eventually we should think about consolidating and using the hotspot port in 
> all places by exporting it from libjvm.so for AIX.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8166189
> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8166189.0/
> 
> Thanks
> Christoph
> 
> 
>> -Original Message-
>> From: core-libs-dev [mailto:core-libs-dev-boun...@openjdk.java.net] On Behalf
>> Of Kumar Srinivasan
>> Sent: Montag, 12. September 2016 22:57
>> To: core-libs-dev ; Mandy Chung
>> ; Chris Bensen 
>> Subject: RFR: 8165524: Better detect JRE that Linux JLI will be using
>>
>> Hello,
>>
>> I am sponsoring this changeset for Chris Bensen of the java packager
>> team, please review  fix for the launcher to  better locate java.home.
>>
>> http://cr.openjdk.java.net/~ksrini/8165524/
>>
>> Thanks
>> Kumar
> 


-- 
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the sources.

Re: RFR: 8166189: Fix for Bug 8165524 breaks AIX build

[Volker Simonis]

Not sure if that's a good idea. You can have a custom launcher which
doesn't use libjli.so and I don't think we want to make libjvm.so
dependent on libjli.so.


On Fri, Sep 16, 2016 at 7:47 PM, Chris Bensen  wrote:
> I assume libjvm.so has access to dlopen and dlsym? Can the AIX
> implementation of dladdr live in libjli.so and libjvm.so load it from there?
>
> Chris
>
>
> On Sep 16, 2016, at 10:34 AM, Volker Simonis 
> wrote:
>
> Hi Christoph,
>
> I think your change is fine as a quick-fix to fix the build. But
> you're completely right that this should be reworked in the long term.
> I hate to see that we now have the third version of these routines in
> the OpenJDK. Unfortunately a clean solution is not trivial.
>
> libjli is not linked against libjvm because libjli is actually used to
> load libjvm. So we can not put the dladdr routines for AIX there. But
> I think we should at least consolidate the two versions which will be
> in the class library after your change. Initially I intentionally put
> porting_aix.{c,h} into jdk/aix/porting with the intent to make it
> available to ALL jdk native libraries.
>
> Unfortunately, with the source code reorganization due to the modular
> changes, the common, top-level aix repository had to go away and the
> code was moved to src/java.desktop/aix/native/libawt/porting_aix.c.
> With the reorganized, modularized source code layout and build system
> it is not possible to share code between modules. We somehow have to
> fix this although I currently don't know how. IF somebody has an idea,
> please let me know :)
>
> Regarding your change:
>
> - can you please move
>
> +#if defined(_AIX)
> +#include "java_md_aix.h"
> +#endif
> +
>
> from java_md_common.c to the end of
> java.base/unix/native/libjli/java_md.h. It will then be automatically
> included into java_md_common.c trough java.h which includes java_md.h
>
> Also, this version of dladdr is inherently not thread safe. I don't
> think that's a problem here, but it would be nice if you could quickly
> check if that's indeed true.
>
> Besides that, looks good.
>
> Thanks for fixing,
> Volker
>
>
>
>
> On Fri, Sep 16, 2016 at 11:58 AM, Langer, Christoph
>  wrote:
>
> Hi,
>
> the fix for https://bugs.openjdk.java.net/browse/JDK-8165524 breaks the AIX
> build as function dladdr is not available on AIX.
>
> There already exist ports of that API in hotspot and awt. With the proposed
> change I duplicate the awt port to libjli. This is maybe only a quick fix -
> eventually we should think about consolidating and using the hotspot port in
> all places by exporting it from libjvm.so for AIX.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8166189
> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8166189.0/
>
> Thanks
> Christoph
>
>
> -Original Message-
> From: core-libs-dev [mailto:core-libs-dev-boun...@openjdk.java.net] On
> Behalf
> Of Kumar Srinivasan
> Sent: Montag, 12. September 2016 22:57
> To: core-libs-dev ; Mandy Chung
> ; Chris Bensen 
> Subject: RFR: 8165524: Better detect JRE that Linux JLI will be using
>
> Hello,
>
> I am sponsoring this changeset for Chris Bensen of the java packager
> team, please review  fix for the launcher to  better locate java.home.
>
> http://cr.openjdk.java.net/~ksrini/8165524/
>
> Thanks
> Kumar
>
>
>

Re: RFR: 8166189: Fix for Bug 8165524 breaks AIX build

[Chris Bensen]

I assume libjvm.so has access to dlopen and dlsym? Can the AIX implementation 
of dladdr live in libjli.so and libjvm.so load it from there?

Chris


> On Sep 16, 2016, at 10:34 AM, Volker Simonis  wrote:
> 
> Hi Christoph,
> 
> I think your change is fine as a quick-fix to fix the build. But
> you're completely right that this should be reworked in the long term.
> I hate to see that we now have the third version of these routines in
> the OpenJDK. Unfortunately a clean solution is not trivial.
> 
> libjli is not linked against libjvm because libjli is actually used to
> load libjvm. So we can not put the dladdr routines for AIX there. But
> I think we should at least consolidate the two versions which will be
> in the class library after your change. Initially I intentionally put
> porting_aix.{c,h} into jdk/aix/porting with the intent to make it
> available to ALL jdk native libraries.
> 
> Unfortunately, with the source code reorganization due to the modular
> changes, the common, top-level aix repository had to go away and the
> code was moved to src/java.desktop/aix/native/libawt/porting_aix.c.
> With the reorganized, modularized source code layout and build system
> it is not possible to share code between modules. We somehow have to
> fix this although I currently don't know how. IF somebody has an idea,
> please let me know :)
> 
> Regarding your change:
> 
> - can you please move
> 
> +#if defined(_AIX)
> +#include "java_md_aix.h"
> +#endif
> +
> 
> from java_md_common.c to the end of
> java.base/unix/native/libjli/java_md.h. It will then be automatically
> included into java_md_common.c trough java.h which includes java_md.h
> 
> Also, this version of dladdr is inherently not thread safe. I don't
> think that's a problem here, but it would be nice if you could quickly
> check if that's indeed true.
> 
> Besides that, looks good.
> 
> Thanks for fixing,
> Volker
> 
> 
> 
> 
> On Fri, Sep 16, 2016 at 11:58 AM, Langer, Christoph
>  wrote:
>> Hi,
>> 
>> the fix for https://bugs.openjdk.java.net/browse/JDK-8165524 breaks the AIX 
>> build as function dladdr is not available on AIX.
>> 
>> There already exist ports of that API in hotspot and awt. With the proposed 
>> change I duplicate the awt port to libjli. This is maybe only a quick fix - 
>> eventually we should think about consolidating and using the hotspot port in 
>> all places by exporting it from libjvm.so for AIX.
>> 
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8166189
>> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8166189.0/
>> 
>> Thanks
>> Christoph
>> 
>> 
>>> -Original Message-
>>> From: core-libs-dev [mailto:core-libs-dev-boun...@openjdk.java.net] On 
>>> Behalf
>>> Of Kumar Srinivasan
>>> Sent: Montag, 12. September 2016 22:57
>>> To: core-libs-dev ; Mandy Chung
>>> ; Chris Bensen 
>>> Subject: RFR: 8165524: Better detect JRE that Linux JLI will be using
>>> 
>>> Hello,
>>> 
>>> I am sponsoring this changeset for Chris Bensen of the java packager
>>> team, please review  fix for the launcher to  better locate java.home.
>>> 
>>> http://cr.openjdk.java.net/~ksrini/8165524/
>>> 
>>> Thanks
>>> Kumar
>> 

Re: RFR: 8166189: Fix for Bug 8165524 breaks AIX build

[Volker Simonis]

Hi Christoph,

I think your change is fine as a quick-fix to fix the build. But
you're completely right that this should be reworked in the long term.
I hate to see that we now have the third version of these routines in
the OpenJDK. Unfortunately a clean solution is not trivial.

libjli is not linked against libjvm because libjli is actually used to
load libjvm. So we can not put the dladdr routines for AIX there. But
I think we should at least consolidate the two versions which will be
in the class library after your change. Initially I intentionally put
porting_aix.{c,h} into jdk/aix/porting with the intent to make it
available to ALL jdk native libraries.

Unfortunately, with the source code reorganization due to the modular
changes, the common, top-level aix repository had to go away and the
code was moved to src/java.desktop/aix/native/libawt/porting_aix.c.
With the reorganized, modularized source code layout and build system
it is not possible to share code between modules. We somehow have to
fix this although I currently don't know how. IF somebody has an idea,
please let me know :)

Regarding your change:

- can you please move

+#if defined(_AIX)
+#include "java_md_aix.h"
+#endif
+

from java_md_common.c to the end of
java.base/unix/native/libjli/java_md.h. It will then be automatically
included into java_md_common.c trough java.h which includes java_md.h

Also, this version of dladdr is inherently not thread safe. I don't
think that's a problem here, but it would be nice if you could quickly
check if that's indeed true.

Besides that, looks good.

Thanks for fixing,
Volker




On Fri, Sep 16, 2016 at 11:58 AM, Langer, Christoph
 wrote:
> Hi,
>
> the fix for https://bugs.openjdk.java.net/browse/JDK-8165524 breaks the AIX 
> build as function dladdr is not available on AIX.
>
> There already exist ports of that API in hotspot and awt. With the proposed 
> change I duplicate the awt port to libjli. This is maybe only a quick fix - 
> eventually we should think about consolidating and using the hotspot port in 
> all places by exporting it from libjvm.so for AIX.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8166189
> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8166189.0/
>
> Thanks
> Christoph
>
>
>> -Original Message-
>> From: core-libs-dev [mailto:core-libs-dev-boun...@openjdk.java.net] On Behalf
>> Of Kumar Srinivasan
>> Sent: Montag, 12. September 2016 22:57
>> To: core-libs-dev ; Mandy Chung
>> ; Chris Bensen 
>> Subject: RFR: 8165524: Better detect JRE that Linux JLI will be using
>>
>> Hello,
>>
>> I am sponsoring this changeset for Chris Bensen of the java packager
>> team, please review  fix for the launcher to  better locate java.home.
>>
>> http://cr.openjdk.java.net/~ksrini/8165524/
>>
>> Thanks
>> Kumar
>

Re: RFR: 8166189: Fix for Bug 8165524 breaks AIX build

[Mandy Chung]

> On Sep 16, 2016, at 2:58 AM, Langer, Christoph  
> wrote:
> 
> Hi,
> 
> the fix for https://bugs.openjdk.java.net/browse/JDK-8165524 breaks the AIX 
> build as function dladdr is not available on AIX.
> 
> There already exist ports of that API in hotspot and awt. With the proposed 
> change I duplicate the awt port to libjli. This is maybe only a quick fix - 
> eventually we should think about consolidating and using the hotspot port in 
> all places by exporting it from libjvm.so for AIX.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8166189
> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8166189.0/

This looks okay.   It’d be good to consolidate the hotspot and awt code as a 
JVM entry point.  But launcher would need to carry this copy since dladdr is 
called before libjvm.so is loaded.

formatting nit: not align with lines above (4-space indentation)

  55   }
  56   return 0;

Mandy