This is the mail archive of the java@gcc.gnu.org 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]
Other format: [Raw text]

Re: gcj/SWT gc() and memory


Long explanation follows re why I'm interested in using
the internal call rather than the external environment variable.

GC_set_max_heap_size should be documented elsewhere but I don't think it
is. It was intended to be rarely used. The fact that you need to use
it suggests a problem elsewhere.


I want my application to startup up automatically from a CD
on Windows via Autorun.inf without throwing up an intermediate
command shell.  For this to happen (I believe) I need to run
the command directly in Autorun.inf and not indirectly via
a batch file in which I can set the environment variables.

As gcj/java/swt goes mainstream you'll see more corner
cases like this come up.  That's probably a good sign
of the maturity and value of gcj/swt.

In the meantime, if I use the gcj/exe in production in a
couple of days instead of the jre/jar it's a simple
enough explanation in the FAQ that a black box
will pop up momentarily when the program starts up
under Windows.  The reason why I'm wanting to
get rid of the black box is every naive user gets
spooked by it.

Note that I haven't tried doing the
   SET blat=blat && runProgramExecutable.exe
in Autorun.inf to see if that takes care of the
black box popping up.  That might be a solution
as well.  (but I'd need to research what flavors of
Win support joining commands on one line and whether
that is possible in Autorun.inf).

I'm still guessing that something like the graphics memory is being
treated as roots. Your workaround will limit the heap, but in doing
so, you are circumventing the collectors heap expansion strategy, which is
designed to bound the amount of time it spends in the collector.
Thus you may see an unreasonable fraction of the execution time in the
collector.


I avoided doing the gc dumps because I'm not familiar with reading them.
With the environment variable limiting heap in place in a batch file memory
use was limited and performance seemed (no timed tests) as good as
jre/jar version. If this information (dump/roots) is useful to you email me directly
or via this list and I'll generate the info requested and post the roots
info back.


If you notice such a problem, it's still worth tracking this down.
If you can alwasy identify the extra memory being traced, you can
use GC_exclude_static_roots() to eliminate the problem.  But the
locatin of graphics memory tends to be a bit elusive.  Otherwise the
collector would already do this automatically.

Hans




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