Re: [Sablevm-developer] request for log messages

[Chris P. <chr...@ma...>]

David Bélanger wrote:
> On Sun, Mar 14, 2004 at 05:22:15PM -0500, Chris Pickett wrote:
> 
>>Hi,
>>
>>I think it would be good if all log messages were written to stderr. 
>>This means you can run benchmarks, and use the stdout to check that they 
>>executed properly, and stderr to analyse your changes.  If this was 
>>done, I think it means that there would be zero occurrences of stdout in 
>>the SableVM tree, save for the license / help information ... but 
>>perhaps even that could be changed.
>>
>>Anyway, it's something that I'm doing now, just thought I'd mention it 
>>in case there are any big problems.
>>
> 
> 
> Hello,
> 
> I assume you are talking about the verbose mode and stats.

Well, there's not much else :) -- I did introduce some verbose modes of 
my own though.

Side note: I have come to learn that gathering statistics via trace 
files generated with a given verbose mode and bash is not practical for 
normal-sized benchmarks (even if all they output, for example, is the 
signature of a method on each invoke).  A lot of the problem is that gnu 
sort is inefficient (yes, I tried splitting the outputs, sorting them, 
and doing 'sort -m').  It is still possible, if you really need temporal 
information, but I think it is better to wait for / work on some kind of 
*J integration.  At the moment I think one should use / change the stats 
stuff directly inside SableVM instead.

> I will not comment on what is better since I'm never sure myself
> what to use.  :)
> 
> But I guess one option could be to use a variable for the FILE* to use
> for these "log" messages.  The FILE* would default to either stdout or
> stderr but it could also be set to other (ex: a disk file) if stdout
> and stderr are used for other purposes.

Actually, yes -- since Java allows you to write to stdout and stderr, it 
would be better if SableVM's messages could be sent elsewhere if the 
user was having problems (imagine a benchmark that generated output on 
stdout as well as a log of what it was doing on stderr).  For now stderr 
is fine for my purposes (SPECjvm98 and JOlden), but when I prepare this 
change I will send log / debugging messages to vm->stderr and the help / 
license information to vm->stdout.  The user will be able to specify 
'-o' for the stdout and '-e' for the stderr (with a clear explanation 
that this does not apply to the Java stdout / stderr).  Sound good?

Chris