On Tuesday 03 Apr 2012 02:26:03 Zlatin Balevsky wrote:
> On Mon, Apr 2, 2012 at 6:04 PM, Matthew Toseland
> wrote:
> > On Saturday 31 Mar 2012 04:03:10 Zlatin Balevsky wrote:
> >> >>
> >> >> In 'log.info("Random message: %s", obj.toString())' evaluating
> >> >> 'obj.toString()' was what caused is
On Tuesday 03 Apr 2012 02:26:03 Zlatin Balevsky wrote:
> On Mon, Apr 2, 2012 at 6:04 PM, Matthew Toseland
> wrote:
> > On Saturday 31 Mar 2012 04:03:10 Zlatin Balevsky wrote:
> >> >>
> >> >> In 'log.info("Random message: %s", obj.toString())' evaluating
> >> >> 'obj.toString()' was what caused is
On Saturday 31 Mar 2012 04:03:10 Zlatin Balevsky wrote:
> >>
> >> In 'log.info("Random message: %s", obj.toString())' evaluating
> >> 'obj.toString()' was what caused issues, not recycling it, or so I believe
> >> to remember.
> >
> > You don't need to call obj.toString() before calling log() - j
On Mon, Apr 2, 2012 at 6:04 PM, Matthew Toseland
wrote:
> On Saturday 31 Mar 2012 04:03:10 Zlatin Balevsky wrote:
>> >>
>> >> In 'log.info("Random message: %s", obj.toString())' evaluating
>> >> 'obj.toString()' was what caused issues, not recycling it, or so I
>> >> believe to remember.
>> >
>>
On Mon, Apr 2, 2012 at 6:04 PM, Matthew Toseland
wrote:
> On Saturday 31 Mar 2012 04:03:10 Zlatin Balevsky wrote:
>> >>
>> >> In 'log.info("Random message: %s", obj.toString())' evaluating
>> >> 'obj.toString()' was what caused issues, not recycling it, or so I
>> >> believe to remember.
>> >
>>
On Saturday 31 Mar 2012 04:03:10 Zlatin Balevsky wrote:
> >>
> >> In 'log.info("Random message: %s", obj.toString())' evaluating
> >> 'obj.toString()' was what caused issues, not recycling it, or so I believe
> >> to remember.
> >
> > You don't need to call obj.toString() before calling log() - j
>>
>> In 'log.info("Random message: %s", obj.toString())' evaluating
>> 'obj.toString()' was what caused issues, not recycling it, or so I believe
>> to remember.
>
> You don't need to call obj.toString() before calling log() - just pass the
> object itself. Then the only overheads are:
> 1) Cal
>>
>> In 'log.info("Random message: %s", obj.toString())' evaluating
>> 'obj.toString()' was what caused issues, not recycling it, or so I believe
>> to remember.
>
> You don't need to call obj.toString() before calling log() - just pass the
> object itself. Then the only overheads are:
> 1) Cal
On Wednesday 28 Mar 2012 19:56:19 postwall-freenet at yahoo.de wrote:
> If I remember right then the main issue with debug logging wasn't GC but that
> generating some of the log string arguments in freenet was simply very
> resource intensive in itself.
I'm not sure. I do remember it greatly i
On Wednesday 28 Mar 2012 19:56:19 postwall-free...@yahoo.de wrote:
> If I remember right then the main issue with debug logging wasn't GC but that
> generating some of the log string arguments in freenet was simply very
> resource intensive in itself.
I'm not sure. I do remember it greatly incr
e of the former.
Speeking out of memory as a non Java-dev here, so ignore if applicable. :P
Von: Ximin Luo
An: devl at freenetproject.org
Gesendet: 4:33 Samstag, 24.M?rz 2012
Betreff: Re: [freenet-dev] Logging in Fred
I see.
Actually we didn't even
e of the former.
Speeking out of memory as a non Java-dev here, so ignore if applicable. :P
Von: Ximin Luo
An: devl@freenetproject.org
Gesendet: 4:33 Samstag, 24.März 2012
Betreff: Re: [freenet-dev] Logging in Fred
I see.
Actually we didn't even
On 24-03-2012 09:26, Marco Schulze wrote:
> I finally got freenet.jar compiled and profiled. First, size-related
> numbers:
>
> Number of lines removed: ~5000
> freenet.jar shrink: ~200k
>
> And profiling data (see below for details):
>
> freenet.support.FileLoggerHook$WriterThread.run: 8,35% (3)
On 24-03-2012 09:26, Marco Schulze wrote:
I finally got freenet.jar compiled and profiled. First, size-related
numbers:
Number of lines removed: ~5000
freenet.jar shrink: ~200k
And profiling data (see below for details):
freenet.support.FileLoggerHook$WriterThread.run: 8,35% (3)
Oops. Most of
I finally got freenet.jar compiled and profiled. First, size-related
numbers:
Number of lines removed: ~5000
freenet.jar shrink: ~200k
And profiling data (see below for details):
freenet.support.FileLoggerHook$WriterThread.run: 8,35% (3)
freenet.support.Log.isLoggable: 0.09% (17)
freenet.suppo
I finally got freenet.jar compiled and profiled. First, size-related
numbers:
Number of lines removed: ~5000
freenet.jar shrink: ~200k
And profiling data (see below for details):
freenet.support.FileLoggerHook$WriterThread.run: 8,35% (3)
freenet.support.Log.isLoggable: 0.09% (17)
freenet.supp
I see.
Actually we didn't even need the side effects thing - I did notice that your
example stopped doing GC when setting "shouldLog = false" always, so I tried to
introduce your "if (shouldLog) { shouldLog = false; }" into my example, but was
still unable to reproduce GC. Then changing
- System.
On 24/03/12 02:44, Zlatin Balevsky wrote:
> Wrong. Extracting the log statement into its own method and calling
> that method inside the while loop still creates garbage. Stack frames
> are different.
>
How do you explain the results obtained from running my test code, then? Turn
on -verbose:gc
On 24/03/12 01:56, Zlatin Balevsky wrote:
> Not really. Here, I'll change my call to allocate everything on one level:
>
> while (true) {
> log(" list size is {1} ",
> new Integer(listToLog.size()));
> }
>
> I don't see how using this you can log primiti
Sorry, bad typing. "inside its own" not "inside its only".
On 24/03/12 01:33, Ximin Luo wrote:
> That is because in your example you're allocating all those new Object()s in
> the same stack frame, so the allocator runs out of space on the stack.
>
> If you put the call to log(x, new Object()) in
That is because in your example you're allocating all those new Object()s in
the same stack frame, so the allocator runs out of space on the stack.
If you put the call to log(x, new Object()) inside its only function call, each
Object will be destroyed once that call exits, and no GC occurs.
Exam
It doesn't look like a big deal but if all of Fred was using lazy
evaluation for logging it would make one common use case very
annoying:
Say I'm working on a specific class and need to run that class with
debug logging enabled. This would have the side effect of changing
the compiled LOG.debug(
As to why it still creates garbage even if you do not touch the
arguments in the testWithout method, I would guess that different
inlining rules apply to large methods, small methods and methods that
are already inlined within other methods.
To give definitive answer I'll have to look through the
Your test has nothing to do with stack allocation because you never
use the objects that you pass to the log_info method so JIT removes
them. Apply the following patch and see yourself create garbage in
both testWith and testWithout.
--- Test2.java 2012-03-23 23:01:05.540475497 -0400
+++ Test.ja
Wrong. Extracting the log statement into its own method and calling
that method inside the while loop still creates garbage. Stack frames
are different.
Read again exactly how Escape Analysis works. The objects it prevents
from creating do not appear in heap histograms. Take a "jmap -histo
" a
The only bug-vector I see in the current predicate approach is that
when used incorrectly it cause the size of methods to explode. There
are some hard-coded thresholds for the method size in bytecodes that
turn off some or all JIT optimizations; there are also a whole host of
compilation parameter
Not really. Here, I'll change my call to allocate everything on one level:
while (true) {
log(" list size is {1} ",
new Integer(listToLog.size()));
}
I don't see how using this you can log primitive values without garbage.
On Fri, Mar 23, 2012 at 9:33 P
You're right, the example you gave will put the arguments on the
stack. I wanted to clarify Escape Analysis in its current form works
only if a new object doesn't exit the stack frame where it's created.
Because of that, the moment you do something slightly more complicated
you will create garbage
It doesn't look like a big deal but if all of Fred was using lazy
evaluation for logging it would make one common use case very
annoying:
Say I'm working on a specific class and need to run that class with
debug logging enabled. This would have the side effect of changing
the compiled LOG.debug(
I see.
Actually we didn't even need the side effects thing - I did notice that your
example stopped doing GC when setting "shouldLog = false" always, so I tried to
introduce your "if (shouldLog) { shouldLog = false; }" into my example, but was
still unable to reproduce GC. Then changing
- System.
As to why it still creates garbage even if you do not touch the
arguments in the testWithout method, I would guess that different
inlining rules apply to large methods, small methods and methods that
are already inlined within other methods.
To give definitive answer I'll have to look through the
Your test has nothing to do with stack allocation because you never
use the objects that you pass to the log_info method so JIT removes
them. Apply the following patch and see yourself create garbage in
both testWith and testWithout.
--- Test2.java 2012-03-23 23:01:05.540475497 -0400
+++ Test.ja
On 24/03/12 02:44, Zlatin Balevsky wrote:
> Wrong. Extracting the log statement into its own method and calling
> that method inside the while loop still creates garbage. Stack frames
> are different.
>
How do you explain the results obtained from running my test code, then? Turn
on -verbose:gc
Wrong. Extracting the log statement into its own method and calling
that method inside the while loop still creates garbage. Stack frames
are different.
Read again exactly how Escape Analysis works. The objects it prevents
from creating do not appear in heap histograms. Take a "jmap -histo
" a
On 24/03/12 01:56, Zlatin Balevsky wrote:
> Not really. Here, I'll change my call to allocate everything on one level:
>
> while (true) {
> log(" list size is {1} ",
> new Integer(listToLog.size()));
> }
>
> I don't see how using this you can log primiti
The only bug-vector I see in the current predicate approach is that
when used incorrectly it cause the size of methods to explode. There
are some hard-coded thresholds for the method size in bytecodes that
turn off some or all JIT optimizations; there are also a whole host of
compilation parameter
Not really. Here, I'll change my call to allocate everything on one level:
while (true) {
log(" list size is {1} ",
new Integer(listToLog.size()));
}
I don't see how using this you can log primitive values without garbage.
On Fri, Mar 23, 2012 at 9:33 P
Sorry, bad typing. "inside its own" not "inside its only".
On 24/03/12 01:33, Ximin Luo wrote:
> That is because in your example you're allocating all those new Object()s in
> the same stack frame, so the allocator runs out of space on the stack.
>
> If you put the call to log(x, new Object()) in
That is because in your example you're allocating all those new Object()s in
the same stack frame, so the allocator runs out of space on the stack.
If you put the call to log(x, new Object()) inside its only function call, each
Object will be destroyed once that call exits, and no GC occurs.
Exam
You're right, the example you gave will put the arguments on the
stack. I wanted to clarify Escape Analysis in its current form works
only if a new object doesn't exit the stack frame where it's created.
Because of that, the moment you do something slightly more complicated
you will create garbage
On Friday 23 Mar 2012 16:00:15 Marco Schulze wrote:
> Yes, and yes.
>
> On 23-03-2012 12:43, Matthew Toseland wrote:
> > On Friday 23 Mar 2012 15:29:44 you wrote:
> >> Right now, the map is only used to list class thresholds which are
> >> different from the global threshold, which means it is emp
On Friday 23 Mar 2012 15:29:44 you wrote:
> Right now, the map is only used to list class thresholds which are
> different from the global threshold, which means it is empty 99% of the
> time. This is the simplest solution, but it also means that the
> possibility of lock contention is way highe
On Friday 23 Mar 2012 00:18:02 Marco Schulze wrote:
> I already have all but log rotation and async ready, and haven't yet
> found a single benchmark supporting the use of a branch as the
> performance holy grail. For example (outputting to /dev/null):
>
> public static void main (String[] args)
On Friday 23 Mar 2012 11:35:44 Ximin Luo wrote:
> lol, OK.
>
> I am just annoyed with everyone that keeps arguing "we need to implement our
> own generic X framework because of minor issue Y whose importance I am
> over-inflating, even though countless other projects with similar requirements
> ge
Sure. Since the class name lookups will only be used for debugging, they
can be as generic as necessary, as long it doesn't add any requirements
to users. Match-on-load and match-on-demand are both fine.
On 23-03-2012 13:19, Matthew Toseland wrote:
> On Friday 23 Mar 2012 16:00:15 Marco Schulze
Yes, and yes.
On 23-03-2012 12:43, Matthew Toseland wrote:
> On Friday 23 Mar 2012 15:29:44 you wrote:
>> Right now, the map is only used to list class thresholds which are
>> different from the global threshold, which means it is empty 99% of the
>> time. This is the simplest solution, but it als
Right now, the map is only used to list class thresholds which are
different from the global threshold, which means it is empty 99% of the
time. This is the simplest solution, but it also means that the
possibility of lock contention is way higher. However, unless this
proves to be very bad in
lol, OK.
I am just annoyed with everyone that keeps arguing "we need to implement our
own generic X framework because of minor issue Y whose importance I am
over-inflating, even though countless other projects with similar requirements
get around these adequately".
To anyone doing refactoring wor
Sure. Since the class name lookups will only be used for debugging, they
can be as generic as necessary, as long it doesn't add any requirements
to users. Match-on-load and match-on-demand are both fine.
On 23-03-2012 13:19, Matthew Toseland wrote:
On Friday 23 Mar 2012 16:00:15 Marco Schulze
On Friday 23 Mar 2012 16:00:15 Marco Schulze wrote:
> Yes, and yes.
>
> On 23-03-2012 12:43, Matthew Toseland wrote:
> > On Friday 23 Mar 2012 15:29:44 you wrote:
> >> Right now, the map is only used to list class thresholds which are
> >> different from the global threshold, which means it is emp
On Fri, Mar 23, 2012 at 8:58 AM, David ?Bombe? Roden <
bombe at pterodactylus.net> wrote:
> Yes, kids, both your penisses are incredibly long. Now shut up and let the
> grown-ups do some refactoring.
>
>
> Greetings,
>
>David
>
>
Thanks daddy !
Nicolas
-- next part ---
Yes, and yes.
On 23-03-2012 12:43, Matthew Toseland wrote:
On Friday 23 Mar 2012 15:29:44 you wrote:
Right now, the map is only used to list class thresholds which are
different from the global threshold, which means it is empty 99% of the
time. This is the simplest solution, but it also means
Yes, kids, both your penisses are incredibly long. Now shut up and let the
grown-ups do some refactoring.
Greetings,
David
On 23.03.2012, at 04:47, Ximin Luo wrote:
> LOL, are you kidding me?
>
> Please point to the exact lines of code that results in "double-digit
> millisecond paus
On Friday 23 Mar 2012 15:29:44 you wrote:
> Right now, the map is only used to list class thresholds which are
> different from the global threshold, which means it is empty 99% of the
> time. This is the simplest solution, but it also means that the
> possibility of lock contention is way highe
Right now, the map is only used to list class thresholds which are
different from the global threshold, which means it is empty 99% of the
time. This is the simplest solution, but it also means that the
possibility of lock contention is way higher. However, unless this
proves to be very bad in
No one is benchmarking JRE's JIT. If you look closer, there are figures
with the average runtime without JIT, exactly to avoid overspecialization.
With JIT, there is a reduction of 0.02% in runtime. Without JIT, this
becomes 0.06%. Negligible to all but the few people who do everything in
assem
On Friday 23 Mar 2012 00:18:02 Marco Schulze wrote:
> I already have all but log rotation and async ready, and haven't yet
> found a single benchmark supporting the use of a branch as the
> performance holy grail. For example (outputting to /dev/null):
>
> public static void main (String[] args)
On Friday 23 Mar 2012 11:35:44 Ximin Luo wrote:
> lol, OK.
>
> I am just annoyed with everyone that keeps arguing "we need to implement our
> own generic X framework because of minor issue Y whose importance I am
> over-inflating, even though countless other projects with similar requirements
> ge
lol, OK.
I am just annoyed with everyone that keeps arguing "we need to implement our
own generic X framework because of minor issue Y whose importance I am
over-inflating, even though countless other projects with similar requirements
get around these adequately".
To anyone doing refactoring wor
No one is benchmarking JRE's JIT. If you look closer, there are figures
with the average runtime without JIT, exactly to avoid overspecialization.
With JIT, there is a reduction of 0.02% in runtime. Without JIT, this
becomes 0.06%. Negligible to all but the few people who do everything in
asse
LOL, are you kidding me?
Please point to the exact lines of code that results in "double-digit
millisecond pauses"?
Talk is cheap, show us some numbers.
BTW, the "example" I gave is not real code, and contains no variable
declarations, so your challenge makes no sense. Since you apparently didn'
On Fri, Mar 23, 2012 at 8:58 AM, David ‘Bombe’ Roden <
bo...@pterodactylus.net> wrote:
> Yes, kids, both your penisses are incredibly long. Now shut up and let the
> grown-ups do some refactoring.
>
>
> Greetings,
>
>David
>
>
Thanks daddy !
Nicolas
___
Yes, kids, both your penisses are incredibly long. Now shut up and let the
grown-ups do some refactoring.
Greetings,
David
On 23.03.2012, at 04:47, Ximin Luo wrote:
> LOL, are you kidding me?
>
> Please point to the exact lines of code that results in "double-digit
> millisecond paus
The "drastically cleaner syntax" is a red herring. Most of the time when you
are doing a complex calculation, you are not going to put it on one line
anyway. In such cases, the function you are using to do the calculation might
as well be the toString() method of some object.
Your claim of "double
The example you provide is fast because it does not do any object
allocation. Please don't take my word for it - download (or better
yet, build one yourself) a "fastdebug" build from openjdk.org and look
at the opto-assembly that gets generated when you pass the
"-XX:+PrintOptoAssembly" switch.
B
My claim is based on day-to-day observations of hundreds of JVMs under
various load scenarios.
Your claim that modern JVMs "do escape analysis" is worthless as it shows
that you have merely read some blog posts, and even those you've read only
partially. Please point to the exact lines of code in
Lazy evaluation is trivial.
Log.info("{1} did {2}",
new Object(){ public String toString() { return ITEM_1; } },
new Object(){ public String toString() { return ITEM_2; } }
);
Garbage collection with short-lived objects costs next to nothing.
On 22/03/12 21:15, Zlatin Balevsky wrote:
> Const
I already have all but log rotation and async ready, and haven't yet
found a single benchmark supporting the use of a branch as the
performance holy grail. For example (outputting to /dev/null):
public static void main (String[] args) {
for (int i = 0; i < 100; i++) {
LOL, are you kidding me?
Please point to the exact lines of code that results in "double-digit
millisecond pauses"?
Talk is cheap, show us some numbers.
BTW, the "example" I gave is not real code, and contains no variable
declarations, so your challenge makes no sense. Since you apparently didn'
The example you provide is fast because it does not do any object
allocation. Please don't take my word for it - download (or better
yet, build one yourself) a "fastdebug" build from openjdk.org and look
at the opto-assembly that gets generated when you pass the
"-XX:+PrintOptoAssembly" switch.
B
My claim is based on day-to-day observations of hundreds of JVMs under
various load scenarios.
Your claim that modern JVMs "do escape analysis" is worthless as it shows
that you have merely read some blog posts, and even those you've read only
partially. Please point to the exact lines of code in
Double-digit millisecond pauses are not nothing. They may be acceptable
right now but unless you can offer a drastically cleaner syntax Fred should
stick with predicates as they are handled much better by the hotspot jit.
On Mar 22, 2012 5:36 PM, "Ximin Luo" wrote:
> Lazy evaluation is trivial.
The "drastically cleaner syntax" is a red herring. Most of the time when you
are doing a complex calculation, you are not going to put it on one line
anyway. In such cases, the function you are using to do the calculation might
as well be the toString() method of some object.
Your claim of "double
I already have all but log rotation and async ready, and haven't yet
found a single benchmark supporting the use of a branch as the
performance holy grail. For example (outputting to /dev/null):
public static void main (String[] args) {
for (int i = 0; i < 100; i++) {
Constructing the logging strings is half of the problem. The amount of
garbage they will generate will result in significantly more time in
garbage collection pauses.
Unless you figure out a way to mimic lazy evaluation you have to live with
the isLoggable predicates. varargs are not an option e
Double-digit millisecond pauses are not nothing. They may be acceptable
right now but unless you can offer a drastically cleaner syntax Fred should
stick with predicates as they are handled much better by the hotspot jit.
On Mar 22, 2012 5:36 PM, "Ximin Luo" wrote:
> Lazy evaluation is trivial.
Lazy evaluation is trivial.
Log.info("{1} did {2}",
new Object(){ public String toString() { return ITEM_1; } },
new Object(){ public String toString() { return ITEM_2; } }
);
Garbage collection with short-lived objects costs next to nothing.
On 22/03/12 21:15, Zlatin Balevsky wrote:
> Const
Constructing the logging strings is half of the problem. The amount of
garbage they will generate will result in significantly more time in
garbage collection pauses.
Unless you figure out a way to mimic lazy evaluation you have to live with
the isLoggable predicates. varargs are not an option e
On Wednesday 21 Mar 2012 21:18:37 Marco Schulze wrote:
> There are basically two big concerns regarding logging in fred:
>
> - Readability and code clutter, which was my original questioning;
> - Raw throughput, as raised by toad.
>
> Point 1 could mostly be solved by removing any traces of logMI
On Thursday 22 Mar 2012 05:50:48 David ?Bombe? Roden wrote:
> On Tue, 2012-03-20 at 22:44 +, Matthew Toseland wrote:
>
> > I am speaking from experience. write() is supposed to either succeed or
> > throw. PrintWriter busy-loops on disk full when stderr is redirected to a
> > file. Feel free
On 22-03-2012 08:50, Matthew Toseland wrote:
> On Wednesday 21 Mar 2012 21:18:37 Marco Schulze wrote:
>> There are basically two big concerns regarding logging in fred:
>>
>> - Readability and code clutter, which was my original questioning;
>> - Raw throughput, as raised by toad.
>>
>> Point 1 c
On Tue, 2012-03-20 at 22:44 +, Matthew Toseland wrote:
> I am speaking from experience. write() is supposed to either succeed or
> throw. PrintWriter busy-loops on disk full when stderr is redirected to a
> file. Feel free to test it, it may be that it doesn't happen with modern
> JVMs. But
On 22-03-2012 08:50, Matthew Toseland wrote:
On Wednesday 21 Mar 2012 21:18:37 Marco Schulze wrote:
There are basically two big concerns regarding logging in fred:
- Readability and code clutter, which was my original questioning;
- Raw throughput, as raised by toad.
Point 1 could mostly be
On Wednesday 21 Mar 2012 21:18:37 Marco Schulze wrote:
> There are basically two big concerns regarding logging in fred:
>
> - Readability and code clutter, which was my original questioning;
> - Raw throughput, as raised by toad.
>
> Point 1 could mostly be solved by removing any traces of logMI
On Thursday 22 Mar 2012 05:50:48 David ‘Bombe’ Roden wrote:
> On Tue, 2012-03-20 at 22:44 +, Matthew Toseland wrote:
>
> > I am speaking from experience. write() is supposed to either succeed or
> > throw. PrintWriter busy-loops on disk full when stderr is redirected to a
> > file. Feel free
On Tue, 2012-03-20 at 22:44 +, Matthew Toseland wrote:
> I am speaking from experience. write() is supposed to either succeed or
> throw. PrintWriter busy-loops on disk full when stderr is redirected to a
> file. Feel free to test it, it may be that it doesn't happen with modern
> JVMs. But
There are basically two big concerns regarding logging in fred:
- Readability and code clutter, which was my original questioning;
- Raw throughput, as raised by toad.
Point 1 could mostly be solved by removing any traces of logMINOR and
logDEBUG on all but the few places where generating messag
There are basically two big concerns regarding logging in fred:
- Readability and code clutter, which was my original questioning;
- Raw throughput, as raised by toad.
Point 1 could mostly be solved by removing any traces of logMINOR and
logDEBUG on all but the few places where generating messa
Is there a good reason to roll our own logging framework? What about
http://www.slf4j.org/ or one of the many other alternatives?
Ian.
On Sun, Mar 18, 2012 at 6:40 PM, Marco Schulze wrote:
> One thing has been bothering me: those 'if (logMINOR) Logger.minor(...',
> and the mess that logging is
Is there a good reason to roll our own logging framework? What about
http://www.slf4j.org/ or one of the many other alternatives?
Ian.
On Sun, Mar 18, 2012 at 6:40 PM, Marco Schulze wrote:
> One thing has been bothering me: those 'if (logMINOR) Logger.minor(...',
> and the mess that logging is
On Monday 19 Mar 2012 21:56:42 Marco Schulze wrote:
> On 19-03-2012 16:42, Matthew Toseland wrote:
> > No it doesn't. We need to be able to filter *by class name*, not just
> > globally. I agree that in theory the if(logMINOR) is optional if the
> > message is static though; I guess the JVM is fa
On Monday 19 Mar 2012 22:37:05 Marco Schulze wrote:
> On 19-03-2012 18:56, Marco Schulze wrote:
> > On 19-03-2012 16:42, Matthew Toseland wrote:
> >> PrintWriter (System.err) busy-loops. :( It is probably possible to
> >> get the underlying OutputStream though.
> > Will take a look at it.
> From
On normal conditions, never. My reasoning was way off... streams are
finalized (and flushed) even on abnormal exit.
On 20-03-2012 05:09, Martin Nyhus wrote:
> On Tuesday 20. March 2012 00:34:11 Marco Schulze wrote:
>> How often does what happen?
> Crashes that cause the log buffer to be lost befo
On Monday 19 Mar 2012 21:56:42 Marco Schulze wrote:
> On 19-03-2012 16:42, Matthew Toseland wrote:
> > No it doesn't. We need to be able to filter *by class name*, not just
> > globally. I agree that in theory the if(logMINOR) is optional if the
> > message is static though; I guess the JVM is fa
On Monday 19 Mar 2012 22:37:05 Marco Schulze wrote:
> On 19-03-2012 18:56, Marco Schulze wrote:
> > On 19-03-2012 16:42, Matthew Toseland wrote:
> >> PrintWriter (System.err) busy-loops. :( It is probably possible to
> >> get the underlying OutputStream though.
> > Will take a look at it.
> From
On normal conditions, never. My reasoning was way off... streams are
finalized (and flushed) even on abnormal exit.
On 20-03-2012 05:09, Martin Nyhus wrote:
On Tuesday 20. March 2012 00:34:11 Marco Schulze wrote:
How often does what happen?
Crashes that cause the log buffer to be lost before
On Tuesday 20. March 2012 00:34:11 Marco Schulze wrote:
> How often does what happen?
Crashes that cause the log buffer to be lost before it is written to disk and
whatever else you had in mind when you wrote this:
On Monday 19. March 2012 22:56:42 Marco Schulze wrote:
> Synchronization is the r
On Tuesday 20. March 2012 00:34:11 Marco Schulze wrote:
> How often does what happen?
Crashes that cause the log buffer to be lost before it is written to disk and
whatever else you had in mind when you wrote this:
On Monday 19. March 2012 22:56:42 Marco Schulze wrote:
> Synchronization is the r
On Monday 19. March 2012 22:56:42 Marco Schulze wrote:
> Synchronization is the reason every thread should wait. If the log is
> always flushed and fred crashes, you know exactly where the last good
> checkpoint was before the crash. If the log is buffered (or
> asynchronous), the thread may be mil
How often does what happen?
On 19-03-2012 20:21, Martin Nyhus wrote:
> On Monday 19. March 2012 22:56:42 Marco Schulze wrote:
>> Synchronization is the reason every thread should wait. If the log is
>> always flushed and fred crashes, you know exactly where the last good
>> checkpoint was before t
1 - 100 of 120 matches
Mail list logo
