On Apr 17, 2015, at 11:29 AM, Fredrik Arvidsson
wrote:
> Hi
> Ill try to reply in-line below.
>
> On 2015-04-17 10:27, Mattis Castegren wrote:
>> Ok. One risk I see would be that you would forget "base tags". For example,
>> if you write a lot of code in g1, it would be easy to log something
Hi All,
I’m very happy for a digital solution. As for solving problems in JFR.. great
but that is a commercial solution and thus doesn’t work for OpenJDK. Remember?
Plus, with all due respect for JFR, not all of us agree that this is the best
way to sort out performance issues ;-)
Regards,
Kir
On 4/16/15 10:01 AM, Daniel D. Daugherty wrote:
>
http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8073705-JVMTI-redefscale2.1/
src/share/vm/classfile/javaClasses.hpp
No comments.
src/share/vm/classfile/javaClasses.cpp
No comments.
src/share/vm/oops/cpCache.hpp
No comme
Thanks for the reviews, Vladimir, Dmitry and Staffan.
Roland.
I guess it would be a possible later enhancement request to add a new logging
tag ”gc_compressed” for example that prints gc output in some easy to parse
format. It could be one line of comma separated values per GC for example that
you could import to other tools.
But I agree with Fredrik,
Hi Martijn, and the others :)
I'm glad you like what we do. We also think the tag based logging is
something good, and that it will make the logging in the JVM easier to
implement, configure and consume.
Regarding 'binary / compressed' log format. We are not planning to add
any structured lo
Hi Fredrik,
Thanks from us (jClarity and some other orgs) for considering the tag based
system, we're really glad you've gone in this direction. One quick bit of
feedback.
Is it possible to add a binary / compressed logging format or an interface/
API to plug one in for high performance Logging?
Hi
Ill try to reply in-line below.
On 2015-04-17 10:27, Mattis Castegren wrote:
Ok. One risk I see would be that you would forget "base tags". For example, if you write a lot of code in g1,
it would be easy to log something as only "g1", not including the "gc" tag. For us in Sustaining,
that c
Ok. One risk I see would be that you would forget "base tags". For example, if
you write a lot of code in g1, it would be easy to log something as only "g1",
not including the "gc" tag. For us in Sustaining, that could lead to us having
to use long verbose lines in order to get everything. This
Hi Mattis
The hierarchical structure is gone. Each log line in the code should
contain all tags related to the message logged.
In your example below the line would be printed just like before since
the log call contains the gc tag.
All tags will be defined in a single source file. The availab
Hi
Is the hierarchical thought completely gone, or can one tag be a "sub set" of
another? Previously, you had the example of a logging module gc_g1_init. If you
add some "g1" logging, would that also be printed is someone runs with
Xverbose:gc? Or would the log message need to include all tags,
Hi
We are planning to release an updated version of JEP-158 very soon. The
work to update this JEP has been going on for some time and we now feel
we are ready to present it to a wider audience.
The JEP for JVM Unified Logging was created back in February 2012. The
requirements for the API a
12 matches
Mail list logo
