Hi Chris, I too am bothered by the jumbled lines. However I don’t think that we need strict ordering. However I don’t believe it’s up to the logging framework to enforce order. If order is needed it should be up to the producer or the consumer of messages to deal with the issue of order. However I do believe these requirements should be struck from the document
Logging is performed at different levels: error, warning, info, debug, trace Logging messages are in human-readable plain text Messages can be “decorated” with level, component, thread id, timestamp Enable/disable individual log messages by message id (for example by using__FILE__ / __LINE__) IMHO, that is proposal specifies a taxonomy that is hierarchal and devoid of context in the domains in which it will be working is very limiting and over reaching. As I have stated in past discussion, feel that the mention of levels should be dropped. It it my view that at it’s core, logging is a messaging problem and there are many lessons that we should be taking from messaging that seem to be missing from this proposal. Even lessons or ideas learned from social media messaging (Twitter messages???) is missing from the proposal. The goals that I pointed to all specify all work against the flexibility of allowing non-hieracrchal taxonomies. In other words, allow users of the framework to define categories that the makers of the framework cannot not possibly conjure up and then allow those categories to be collected or acted upon independent of other categories. This scheme does not nor should not preclude one from using a hierarchal logging system. However it does not limit one to a hierarchical scheme when that scheme does not make sense. If we take GC logging into consideration. The current system of flags allow me to understand what it is I’m getting as I turn on each flag. I can turn on combinations of flags to get different bits of information as the need arises. Unfortunately the newer code is translating these flags to Fine, Finer, and Finest which means some developer is not deciding what categories of logging goes into each of these limited number of categories which may.. or may not be an appropriate mix. My experience with logging in the field is that everything sooner or later degenerates into the lowest common denominator… which is why I get called in as the logging becomes the primary bottleneck in the application. To let you know how much of a problem this it now represents about 30-40% of all rescue tuning that I’m involved in. Now I know you guys are all very clever and you don’t think that you’d be susceptible to making the same type of mistake… however I should caution that a number of the teams that locked themselves into the logging/bottleneck problem were also very clever. This is just something that happens organically… over time without anyone really taking notice.. much like the frog in the pot or stone soup story. I completely agree with this statement; "It is outside the scope of this JEP to add the actual logging calls from all JVM components. This JEP will only provide the infrastructure to do the logging.” I’d add to this that the implementation should not over reach in that defining categories is not within the scope of the framework Finally, the statement "It is also outside the scope of the JEP to enforce a logging format, apart from the format of the decorations and the use of human-readable plain text” is also objectionable as it precludes logging binary formats. This IMHO is a huge over-reach based on the dogma that logs should be in human readable form. The last time I checked ASCII was not human readable in that I need a program to view it in a meaningful format on a screen. Please, lets not let the problems found in the current set of logging frameworks that Java developers have had been forced to use leak into the JVM. Lets reconsider this JEP in it’s current form before moving to an implementation. Kind regards, Kirk Pepperdine On May 17, 2014, at 9:47 AM, Chris Newland <cnewl...@chrisnewland.com> wrote: > Hi Fredrik, > > The discussion I had with David Holmes and John Rose on hotspot-dev back > in February might be relevant to this JEP: > http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-February/012718.html > > I'm the author of a JITWatch[1], a JIT compiler log analysis tool which > relies on -XX:+TraceClassLoading -XX:+LogCompilation -XX:+PrintAssembly > all being present in hotspot.log > > Occasionally the lack of thread safety in the VM logging presents me with > jumbled output: > > [Entry Point] > [Constants] > # {method} 'ind > <writer thread='3340'/> > [Loaded sun.nio.cs.ThreadLocalCoders from C:\Program > Files\Java\jre7\lib\rt.jar] > <writer thread='2660'/> > exOf' '(II)I' in 'java/lang/String' > # this: ecx = 'java/lang/String' > # parm0: edx = int > # parm1: [sp+0x20] = int (sp of caller) > 0x009e07e0: nop > > The JEP goal of no interleaving would fix this problem but if the locking > adds too much cost/complexity then John's suggestion of tagging partial > lines would be a great help to log tool writers. > > Otherwise my only comment is that the goals look like a massive > improvement to current VM logging but for post-execution log tool writers > it is also useful for end users to be able to easily locate and load a > single log file. > > Kind regards, > > Chris > > [1] https://github.com/AdoptOpenJDK/jitwatch > >>>> ---------- Forwarded message ---------- >>>> From: Fredrik Arvidsson <fredrik.arvids...@oracle.com> >>>> Date: 16 May 2014 09:47 >>>> Subject: Need comments on JEP-158: Unified JVM Logging >>>> To: "serviceability-dev@openjdk.java.net >>>> serviceability-dev@openjdk.java.net" >>>> <serviceability-dev@openjdk.java.net>, >>>> hotspot-...@openjdk.java.net >>>> >>>> >>>> Hi all >>>> Please help me review this updated version of the JEP-158 Unified JVM >>>> Logging that was pushed today to the JEP repository. >>>> >>>> Since the service posting the JEPs to http://openjdk.java.net/jeps/ >>>> site >>>> seems to be non working at the moment I am linking directly to the HG >>>> repository instead. >>>> >>>> The updated JEP can be found here in raw markdown format: >>>> http://hg.openjdk.java.net/jep/jeps/file/b04a394c4df4/jep-158.md >>>> >>>> Primarily I would like to have feedback on the overall functionality >>>> scope, the logging API and the command line argument format. All type >>>> of >>>> comments are of course welcome, but I would like to stay away from any >>>> implementation specifics at this point. >>>> >>>> I have a POC implementation which is nearly feature complete up and >>>> running and it looks good so far. >>>> >>>> /Fredrik >>>> >>>> >
