RFR 8187305: Add logging for shared library loads/unloads

[Langer, Christoph]

Hi,

+1 for unifying.

I think we should use the new category "library" but probably move all the logging into the os specific code - at least where necessary (because we might have more information at hand).

But why use a follow up issue? JDK-8187305 is just good for that.

Cheers
Christoph

> -----Original Message-----
> From: hotspot-runtime-dev <hotspot-runtime-dev-
> bounces at openjdk.java.net> On Behalf Of Thomas Stüfe
> Sent: Dienstag, 18. Februar 2020 21:32
> To: Harold Seigel <harold.seigel at oracle.com>
> Cc: hotspot-runtime-dev at openjdk.java.net; Baesken, Matthias
> <matthias.baesken at sap.com>
> Subject: Re: RFR 8187305: Add logging for shared library loads/unloads
> 
> Hi Harold,
> 
> I think it makes sense to unify both approaches. We can do this in a follow
> up issue. I'll open a bug when I am back in the office, or if you do it
> just put it on my name.
> 
> Cheers, Thomas
> 
> On Tue, Feb 18, 2020 at 9:27 PM Harold Seigel <harold.seigel at oracle.com>
> wrote:
> 
> > Hi Thomas,
> >
> > Thanks for pointing this out.
> >
> > The fix for JDK-8187305 <https://bugs.openjdk.java.net/browse/JDK-
> 8187305>
> > also includes logging for JVM_UnloadLibrary() and JVM_FindLibraryEntry().
> > So the two fixes do not completely overlap.  Is it confusing to keep both
> > sets of logging?  Or, should the JVM_UnloadLibrary() and
> > JVM_FindLibraryEntry() be moved into platform dependent code?
> >
> > Thanks,  Harold
> > On 2/18/2020 3:04 PM, Thomas Stüfe wrote:
> >
> > Hi Harold,
> >
> > First off, thanks a lot for doing this!
> >
> > Unfortunately, our wires got crossed with this. Matthias already added
> > tracing for shared library loading with "8228902: add os::dll_load to the
> > unified logging os category". He did not know about this issue and
> > therefore did not update it.
> >
> > So arguably this issue is a duplicate of 8229802 and should have been
> > closed when 8229802 was pushed.
> >
> > His solution is somewhat more complete since he also reports errors and
> > error details when a library could not be loaded. Since he does tracing in
> > platform dependent code he has more information to trace.
> >
> > But he did not add tests, and I like your tests and it would be nice to
> > have them.
> >
> > Just a proposal, but one possibility would be to remove your tracing from
> > jvm.cpp and change the category of the existing tracing Matthias did to
> > your new category "library". And use the tests to test the existing
> > tracing. What do you think?
> >
> > Sorry again for the confusion and the redundant work!
> >
> > Cheers, Thomas
> >
> >
> >
> >
> >
> >
> > On Fri, Feb 14, 2020 at 2:37 PM Harold Seigel <harold.seigel at oracle.com>
> > wrote:
> >
> >> Thanks David!
> >>
> >> I'll use "driver" mode the next time I write a logging test.
> >>
> >> Harold
> >>
> >> On 2/13/2020 5:26 PM, David Holmes wrote:
> >> > Hi Harold,
> >> >
> >> > Looks good.
> >> >
> >> > Minor nit, in the test you could use "driver" mode.
> >> >
> >> > Thanks,
> >> > David
> >> >
> >> > On 14/02/2020 7:22 am, Harold Seigel wrote:
> >> >> Hi,
> >> >>
> >> >> Please review this small fix to add logging to loading, unloading,
> >> >> and finding entries in shared libraries.
> >> >>
> >> >> Open Webrev:
> >> >> http://cr.openjdk.java.net/~hseigel/bug_8187305/webrev/index.html
> >> >>
> >> >> JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8187305
> >> >>
> >> >> The fix was regression tested by running Mach5 tiers 1 and 2 tests
> >> >> and builds on Linux-x64, Solaris, Windows, and Mac OS X, by running
> >> >> Mach5 tiers 3-5 tests on Linux-x64, and JCK lang and VM tests on
> >> >> Linux-x64.
> >> >>
> >> >> Thanks, Harold
> >> >>
> >>
> >