Request For Comment: Asynchronous Logging

[Thomas Stüfe]

>
>
>
> >     - What are your preferences on the configuration of the intermediate
> >     data structure? Should it be configured based on the maximum number
> of
> >     log messages it can store or rather on the total size of the stored
> >     log messages? I think that for normal runs this distinction probably
> >     won't make a big difference because the size of log messages will
> >     probably be the same on average so "number of log messages" should
> >     always be proportional to "total size of log mesages".
> >
> >
> > I prefer the configuration of the intermediate buffer to be as a memory
> size, not "number of entries". The latter does not carry any information
> (what entries? how large are they?). It also, again, exposes implementation
> details - in this case that there is a vector of entries.
> >


Maybe our perspective differs from yours.

We provide long term support for customers who use the JDK in a large
variety of situations, and on a wide number of platforms. Any combination
of flags, regardless how odd and exotic, will be used by a small subset of
our users in the years to come. So it has to work reliably and has to be
tested. I would like to keep long term maintainability of the JDK, and that
includes being careful with rolling out new features.

I personally think that UL is already too complex. IMHO exposing the
ability to log to different log files was a bad choice. I have never seen a
situation where this feature was useful, let alone vital. But it is there
and can never be undone and its complexity causes technical debt. Just as
one example of how this already impacts us, I am currently changing NMT to
be late-initializable (see JDK-8256844), and that includes revamping early
dynamic C++ initialization. UL is by far the most complex early
initialization in that stage, with a surprising number of os::malloc calls.
All to initialize what basically is just a constant static structure, which
should have been static-initialized as a number of constants. But revamping
that is very difficult because we chose to expose features like this.

Every feature increases complexity. If the feature is useful, fine. But
aesthetics alone are not a good reason.

Please let's have this design discussion before pushing patches. The right
way to do things is to build consent first, then to write code. Every added
feature increases maintenance effort for *all* maintainers.

Thanks, Thomas