harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexey Varlamov" <alexey.v.varla...@gmail.com>
Subject Re: [drlvm] Ignoring Sun command line options?
Date Thu, 15 Feb 2007 16:03:19 GMT
In my understanding, we face 2 issues here:
1) Support "-XX:" format for internal options; this is straightforward
and I'll fix this shortly.
This way such options will not be refused but silently ignored.

2) Validate all specified internal options. More generally, VM
components should parse/validate related cmd-line args and report
back, instead of current hardcoded parsing in vmcore. This is a good
designing exercise, need to consider possible circular dependencies
between components and such. Any volunteers?


2007/2/15, Zakharov, Vasily M <vasily.m.zakharov@intel.com>:
>
> Yes, I fully agree.
>
> And sure, we should track Sun options, it's a general question of
> compatibility.
>
>  Vasily
>
>
> -----Original Message-----
> From: Ilya Berezhniuk [mailto:ilya.berezhniuk@gmail.com]
> Sent: Thursday, February 15, 2007 6:16 PM
> To: dev@harmony.apache.org
> Subject: Re: [drlvm] Ignoring Sun command line options?
>
> To check Sun options we must hardcode some particular Sun options, and
> update it when Sun options list is changed.
> But items (1) and (2) are very good :)
> I suggest the following sequence:
>
> 1. VM core takes the options it knows.
> 2. Other components take the options they know.
> 3. If remaining options contain only special options like -X then print
> warnings, skip these options and continue.
> 4. If remaining options contain unknown general options then print error
> and
> abort.
>
>
> 2007/2/15, Zakharov, Vasily M <vasily.m.zakharov@intel.com>:
> >
> >
> > Can we add checking for unsupported Sun options before throwing an
> > error?
> > I mean, the options processing logic could be like this:
> >
> > 1. VM core takes the options it knows.
> >
> > 2. Other components take the options they know.
> >
> > 3. The remaining options are checked for whether they are Sun options.
> >
> > 4. If anything remains - print error and abort.
> >
> > Vasily
> >
> >
> > -----Original Message-----
> > From: Alexey Varlamov [mailto:alexey.v.varlamov@gmail.com]
> > Sent: Thursday, February 15, 2007 5:48 PM
> > To: dev@harmony.apache.org
> > Subject: Re: [drlvm] Ignoring Sun command line options?
> >
> > +1
> > Actually I thought we already agreed we should support this format,
> > and I even promised to fix this. So thanks for the reminder :)
> >
> > Yet there might be a problem to detect if an option is not supported,
> > as VM core knows nothing about options consumed by other components
> > (as gc or jit) and not able to validate them. But this is a separate
> > problem...
> >
> > --
> > Alexey
> >
> > 2007/2/15, Gregory Shimansky <gshimansky@gmail.com>:
> > > Zakharov, Vasily M wrote:
> > > > Hi, all,
> > > >
> > > > I'm now trying to run Netbeans on Harmony. On IBM VM it starts,
> > > > though with many errors, but on DRL VM it exits immediately with
> > > > the following diagnostic:
> > > >
> > > > Unknown option -XX:PermSize=32m
> > > > Use java -help to get help on command line options
> > > >
> > > > The problem is Netbeans startup file is .exe that makes up the
> > > > command line and starts java. And that .exe adds -XX:PermSize
> > > > and -XX:MaxPermSize options to command line, and DRL VM can't
> > > > handle them.
> > > >
> > > > JRockit also doesn't support these options, but it just ignores
> > > > them and starts normally:
> > > >
> > > > [JRockit] WARNING:  '-XX:PermSize=32m' is not a valid VM option.
> > > > Ignoring.
> > > > [JRockit] WARNING:  '-XX:MaxPermSize=160m' is not a valid VM
> option.
> > > > Ignoring.
> > > >
> > > > I think we should follow the JRockit/IBM way in DRL VM and ignore
> > > > Sun options we do not support.
> > > >
> > > > My suggestion is to file this as an app-oriented RI-compatibility
> > bug
> > > > in DRLVM and fix it as such.
> > > >
> > > > What do you think?
> > >
> > > +1
> > > Create a JIRA for this.
> > >
> > > --
> > > Gregory
> > >
> > >
> >
>

Mime
View raw message