classpath
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: A java DEBUG flag


From: Mark Wielaard
Subject: Re: A java DEBUG flag
Date: Fri, 24 Nov 2000 12:27:51 +0100
User-agent: Mutt/1.2.5i

Hi,

On Fri, Nov 24, 2000 at 11:21:12PM +1300, Bryce McKinlay wrote:
> Mark Wielaard wrote:
> 
> > What I meant was something like the following:
> >
> > interface I {
> >     boolean SERIALISATION_DEBUG =
> >         Boolean.getBoolean("gnu.java.io.serialisation.debugging");
> > }
> 
> But this is not a constant! It can only be evaluated at runtime. A bytecode
> compiler or native compiler like gcj cannot determine the value of the flag,
> and must emit a branch.
OK. We had different goals. You wanted to disable the code during compile
time. I wanted to be able to enable the code during runtime.

I should have read java-patches were you write:
> To get the debugging output, you should do BOTH of the following:
>   
> 1. configure libgcj with "--enable-libgcj-debug"
> 2. set "gcj.dumpobjects" to anything other than null or the empty
> string. You can do this by calling System.setProperty("gcj.dumpobjects",
> "true") in program code or by using "-Dgcj.dumpobjects=true" on the gcj
> command line.
So you already solved both our problems. Thanks.

> Granted, a smart JIT will be able to take advantage
> of it being a final field and eliminate the debug code from what it
> generates. However, if it is used extensively in the runtime then it is
> probable that the flag would be evaluated before the system property is set,
> making it useless.
So you have to reevaluate the System property every time (as you seem to
do in your ObjectInputStream patch). I was hoping that you could set system
properties on the command line with gcj compiled binaries then you could
be sure that such a property was always set (or not set). This is what
gij seems to do.

Cheers,

Mark



reply via email to

[Prev in Thread] Current Thread [Next in Thread]