This is the mail archive of the java-patches@sources.redhat.com mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: PATCH: object stream dumping


Warren Levy wrote:

> Thanks Bryce, it certainly is an improvement on what I checked in before.
> I should mention that my original desire (though not achieved in what I
> checked in) was to allow for code in a "production" environment that was
> devoid of the debug checks and the overhead they incurred (hence, my
> attempt to at least partially accomplish this via the #ifdef's in the
> native code).
>
> I'd still like that to be the case.  The only clean way I can think of
> doing this without resorting to a lot more native code, is to have 2
> versions of the ObjectInputStream module (i.e. with and without the
> dumping code; with the desired one is used based on --enable-libjava-debug).
> Or am I underestimating the ability of the compiler to optimize out calls
> to the dumping code when --enable-libjava-debug is not set?

Right now gcj probibly won't actually do it. But since DEBUG is a compile-time
constant, it will be trivial for the optimizer to eliminate the calls once
private method inlining is fully working, and we compile libgcj with -O.

so given that we have:

void stuff()
{
  ...
  debugln(...);
}

private void debugln()
{
  if (Configuration.DEBUG && ...)
    {
      ... do stuff...
    }
}

The compiler will inline the debugln call so it looks like:

void stuff()
{
  ...
  if (Configuration.DEBUG && ...)
    {
      ... do stuff...
    }
}

Then expand DEBUG to get:

void stuff()
{
  ...
  if (FALSE && ...)
    {
      ... do stuff...
    }
}

And finally elimate the unreachable block to get:

void stuff()
{
  ...
}

regards

  [ bryce ]



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]