This is the mail archive of the
java-discuss@sourceware.cygnus.com
mailing list for the Java project.
Properties
- To: java-discuss@sourceware.cygnus.com
- Subject: Properties
- From: Anthony Green <green@cygnus.com>
- Date: Sun, 12 Sep 1999 15:40:22 -0700 (PDT)
Gcj hackers,
A while back there was some discussion about how to specify
system properties like initial heap size for the GC. Environment
variables are unsuitable because they are global attributes. There
are other properties that might be useful to change on a
per-application basis: default character encoding, java.class.path and
java.home are some examples. For other examples, just look at the
command line options for Sun's `java' program. We realy have no
convenient way to provide similar functionality with ahead-of-time
compilation.
What is really needed is some way to specify default
`Properties' on a per-application basis. Here's an idea that involves
modifying binaries - not a very popular idea, so I thought I'd run it
by folks for comment.
The basic idea is to allow for binding property files (or some
representation of them) to fully linked executables. This proposal
works for systems that support arbitrarily named sections (like ELF).
`objcopy --add-section' can be used to add arbitrary data from
a file to an executable. The trick is for the program to figure out
where the data is at runtime. It might be possible to force the
section to load, but I think it is safer to simply read the property
section from the executable file itself. In order for this to work,
the runtime needs to know the offset of the section from the beginning
of the file. The most straight forward way to do this is to actually
modify the executable (again) with this information. This is easy
enough to do if we can expect to find the data in another special
section. This has the advantage of working even with stripped
executables.
prims.cc will contain....
static struct
{
unsigned int offset;
unsigned int length;
} property_info __attribute__ ((section (".gcj_property_info"))) = {0, 0};
JvRunMain() would then have code like...
if (property_info.offset != 0)
{
read property_info.length worth of data from property_info.offset
into the executable (argv[0])
}
A new program or script, called gcjprop, needs to be written
for:
a) binding a property file to an executable, and
b) printing the property file already bound to an executable
Binding a property file to an executable involves doing
something like:
1. processing the property file into some kind of internal
representation that can be read by libgcj.
2. bind the property data file with
objcopy --add-section=.gcj_property=FILE EXECUTABLE
3. find the exectuable offsets for .gcj_property and
.gcj_property_info with
objdump --section-headers EXECUTABLE
4. modify the contents of .gcj_property_info accordingly
Properties bound to executables are available via
java.lang.System.getProperty, although there needs to be a way to
query these properties before the runtime is initialized (so we can
have an opportunity to configure the GC, for instance).
Comments?
AG
--
Anthony Green Cygnus Solutions
Sunnyvale, California