RFR 8187305: Add logging for shared library loads/unloads

[Thomas Stüfe]

On Wed, Feb 19, 2020 at 2:57 PM Langer, Christoph <christoph.langer at sap.com>
wrote:

> 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.
>
>
It's closed and marked as resolved.

..Thomas


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