This is the mail archive of the java-patches@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: Patch: PR 16923


On Mon, 2005-02-21 at 15:00 -0500, Bryce McKinlay wrote:

>Shouldn't arguments like -D and -Xms etc be processed by 
>_Jv_CreateJavaVM() as well? It makes sense to allow things like heap 
>sizes to be set via the invocation API. I'm not sure about --help and 
>--version.

_Jv_CreateJavaVM always processes the following options:

-D<name>=<value>
-verbose
-verbosegc
-verbose:<comma-separated list of "class", "gc" and "jni">
-vfprintf
-exit
-abort

In addition, if ignoreUnrecognized is JNI_TRUE in the vm_args argument
then _Jv_CreateJavaVM also parses option strings that begin with "-X" or
"_" (underscore), and allows non-standard arguments to -verbose: that
begin with "X".

JNI_CreateJavaVM returns JNI_ERR as soon as it encounters any other
unrecognized options.

gij.cc should eventually use the invocation API to instantiate a VM but
it's a big change.  It would mean doing the following:

- splitting out the vm-specific options from gij's argv
- creating the vm with JNI_CreateJavaVM
- building a java string array out of the remaining argv options
- calling the main method of a new java class, gnu.gcj.runtime.Main
- parsing the rest of gij's arguments in gnu.gcj.runtime.Main.main

I've filed a bug for this:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20090

and I'll submit a patch eventually, but it should probably wait for
4.0.1 or 4.1.

>It'd be cleaner to move the argument processing code out into its own 
>static function, ie _Jv_ProcessVMArguments() ? This way 
>_Jv_CreateJavaVM() is kept fairly clean, which is helpful when tracing 
>through the VM startup sequence, etc.

OK.

>Since _Jv_CreateJavaVM is also called from CNI, we need to either expose 
>the JavaVMInitArgs structure in the CNI headers so that it is visible 
>from CNI as well, or perhaps have the CNI _Jv_CreateJavaVM translate the 
>args to the JNI format before calling _Jv_CreateJavaVM (or vice-versa)

Yeah, I think we should expose JavaVMInitArgs in CNI.  I'm not sure
what's the best way though.  Thoughts?

Tom



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