Re: Patch: PR 16923

[Bryce McKinlay <mckinlay at redhat dot com>]

On 22-Feb-05, at 8:02 PM, Thomas Fitzsimmons wrote:

> Index: gcc/java/gcj.texi
> ===================================================================
> RCS file: /cvs/gcc/gcc/gcc/java/gcj.texi,v
> retrieving revision 1.72
> diff -u -r1.72 gcj.texi
> --- gcc/java/gcj.texi	6 Feb 2005 20:20:59 -0000	1.72
> +++ gcc/java/gcj.texi	23 Feb 2005 00:49:32 -0000
> @@ -2110,7 +2110,8 @@
>  allowing Java code to call into C++. Several functions, known as the
>  @dfn{invocation API}, are provided to support this.
>
> -@deftypefun jint JvCreateJavaVM (void* @var{vm_args})
> +@deftypefun jint JvCreateJavaVM (JvVMInitArgs* @var{vm_args})
> +
>  Initializes the Java runtime. This function performs essential 
> initialization
>  of the threads interface, garbage collector, exception handling and 
> other key
>  aspects of the runtime. It must be called once by an application with
> @@ -2119,8 +2120,37 @@
>  once provided it is only called from a single thread.
>  The @var{vmargs} parameter can be used to specify initialization 
> parameters
>  for the Java runtime. It may be @code{NULL}.
> -This function returns @code{0} upon success, or @code{-1} if the 
> runtime is
> -already initialized.
> +
> +JvVMInitArgs is typedef'd from _Jv_VMInitArgs and JvVMOption is
> +typedef'd from _Jv_VMOption:
> +
> +@example
> +struct _Jv_VMOption
> +@{
> +  // a VM initialization option
> +  char* optionString;
> +  // extra information associated with this option
> +  void* extraInfo;
> +@};
> +
> +struct _Jv_VMInitArgs
> +@{
> +  // for compatibility with JavaVMInitArgs
> +  jint version;
> +
> +  // number of VM initialization options
> +  jint nOptions;
> +
> +  // an array of VM initialization options
> +  struct _Jv_VMOption* options;
> +
> +  // true if the option parser should ignore unrecognized options
> +  jboolean ignoreUnrecognized;
> +@};
> +@end example
> +
> +@code{JvCreateJavaVM()} returns @code{0} upon success, or @code{-1} if
> +the runtime is already initialized.

Lets just document these structs as JvVMInitArgs etc, not _Jv_*. The 
user isn't going to be interested in the fact that its a typedef.

>   @emph{Note:} In GCJ 3.1, the @code{vm_args} parameter is ignored. It 
> may be
>  used in a future release.
> Index: gcc/java/jvgenmain.c
> ===================================================================
> RCS file: /cvs/gcc/gcc/gcc/java/jvgenmain.c,v
> retrieving revision 1.35
> diff -u -r1.35 jvgenmain.c
> --- gcc/java/jvgenmain.c	10 Feb 2004 19:12:34 -0000	1.35
> +++ gcc/java/jvgenmain.c	23 Feb 2005 00:49:32 -0000
> @@ -106,6 +106,7 @@
>    /* At this point every element of ARGV from 1 to LAST_ARG is a `-D'
>       option.  Process them appropriately.  */
>    fprintf (stream, "extern const char **_Jv_Compiler_Properties;\n");
> +  fprintf (stream, "extern int _Jv_Properties_Count;\n");
>    fprintf (stream, "static const char *props[] =\n{\n");
>    for (i = 1; i < last_arg; ++i)
>      {
> @@ -127,7 +128,21 @@
>    fprintf (stream, "extern int %s;\n", mangled_classname);
>    fprintf (stream, "int main (int argc, const char **argv)\n");
>    fprintf (stream, "{\n");
> -  fprintf (stream, "   _Jv_Compiler_Properties = props;\n");
> +  fprintf (stream, "   int i = 0;\n");
> +  fprintf (stream, "   _Jv_Compiler_Properties = 0;\n");
> +  fprintf (stream, "   _Jv_Properties_Count = (sizeof (props) " \
> +                   "/ sizeof (const char *)) - 1;\n");
> +  fprintf (stream, "   if (_Jv_Properties_Count > 0)\n");
> +  fprintf (stream, "     {\n");
> +  fprintf (stream, "       _Jv_Compiler_Properties = " \
> +                   "(const char**) _Jv_Realloc\n");
> +  fprintf (stream, "         (_Jv_Compiler_Properties, " \
> +                   "_Jv_Properties_Count);\n");
> +  fprintf (stream, "       for (i = 0; i < _Jv_Properties_Count; 
> i++)\n");
> +  fprintf (stream, "         {\n");
> +  fprintf (stream, "           _Jv_Compiler_Properties[i] = 
> props[i];\n");
> +  fprintf (stream, "         }\n");
> +  fprintf (stream, "     }\n");
>    fprintf (stream, "   JvRunMain (&%s, argc, argv);\n", 
> mangled_classname);
>    fprintf (stream, "}\n");
>    if (stream != stdout && fclose (stream) != 0)



Is it necessary to put this code in the generated main rather than in 
the library? Having it here complicates the ABI, potentially reducing 
our ability to make changes later. Plus, it bloats each binary a 
little.

Perhaps this can me moved to JvRunMain, and gij can just call a 
different variant of JvRunMain that doesn't do this processing?

Otherwise this patch looks good. aph will have to approve the 
jvgenmain.c change, if it does need to change - but ideally I'd like to 
see a solution that doesn't involve changes to the generated main().

Bryce