Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: harmony-dev@incubator.apache.org
Received-SPF: pass (asf.osuosl.org: domain of mike.fursov@gmail.com designates
 64.233.182.185 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references;
        b=Y5UdoIslbimD/z1xZYzeRaDLO4ay0F1gDu66eURxy9BCQ4gBJN6TDAU0oIuUXDEfpv63dKLy5PNI1LtC39B9oDoQQxQx3DJFk9sJWUREzMvPfHZQTpMezx5bVb0zzzUKR79O2/xVfvVyRqc3CjdCjBjNKpbZkpPy2k1D/baOqJo=
Message-ID: <bc79dd600610100501t6b4efe76ofbaa8ac7ed852c67@mail.gmail.com>
Date: Tue, 10 Oct 2006 19:01:20 +0700
From: "Mikhail Fursov" <mike.fursov@gmail.com>
To: harmony-dev@incubator.apache.org
Subject: Re: [drlvm] the big soup of VM properties (HARMONY-1626)
In-Reply-To: <e29119980610100439p255a17aene4b1878cba7443e5@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_3050_2531611.1160481680952"
References: <4525EB2E.6020301@pobox.com> <45268722.9030804@pobox.com>
	 <c6c2ebe00610092130o6b0c9d24p9a08bdd1705b3687@mail.gmail.com>
	 <452B4D76.8070109@pobox.com>
	 <bc79dd600610100203m1e4a6da2u18a7b774045a0c4d@mail.gmail.com>
	 <f944d83d0610100232g643e8ab7tf131c7f57f7b815a@mail.gmail.com>
	 <bc79dd600610100251u180865bdve95b91d092a9c736@mail.gmail.com>
	 <c6c2ebe00610100401k43cbb70et48d1e7715599203d@mail.gmail.com>
	 <bc79dd600610100407p5131ab62j11346b98ec675a38@mail.gmail.com>
	 <e29119980610100439p255a17aene4b1878cba7443e5@mail.gmail.com>

------=_Part_3050_2531611.1160481680952
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

IMO "vm.dlls" property is useless today and should be removed at all. So we
need more precise example :)
+ I do not actually feel the difference between -X and -D options. Could
anyone explain when it's better to use -X and when -D?

On 10/10/06, Evgueni Brevnov <evgueni.brevnov@gmail.com> wrote:
>
> I don't think it is good idea to use -Dvm.dlls for setting up DRLVM
> specific properties. It should be much safer to use somthing like
> -Xvm.dlls. In that case it is really user's responisbility.
>
> Evgueni
>
> On 10/10/06, Mikhail Fursov <mike.fursov@gmail.com> wrote:
> > Dmitry,
> > Why do we need to hide the properties like "vm.dlls"? Once user
> overrides it
> > - he becomes responsible for a probable application failure.
> >
> > For example all of JIT properties are passed like system properties and
> it's
> > very convenient to override the default ones as command line parameters.
> >
> > On 10/10/06, Dmitry Yershov <dmitry.yershov@gmail.com> wrote:
> > >
> > > 2006/10/10, Mikhail Fursov <mike.fursov@gmail.com>:
> > > > On 10/10/06, Alexey Varlamov <alexey.v.varlamov@gmail.com> wrote:
> > > > >
> > > > > I think there is correlation between these 2 questions :). If we
> use
> > > > > "const char*", we simply copy key and value when setting a
> property.
> > > > > And this is impossible with void*.
> > > >
> > > >
> > > > Ok, this way it does works!
> > > >
> > > > BTW, there is alternative functionality named VMLocalStorage - so
> why
> > > > > make properties competing with VMLS? Do we really need "hidden"
> > > > > properties?
> > > >
> > > >
> > > > +1. Want to know the answer.
> > >
> > > Seems, that we need "hidden" properties.
> > >     Users can define any properties through command line
> -D<key>=<value>.
> > > Our VM has a set of "dangerous" properties (vm.dlls, vm.ee_dlls,
> > > vm.other_natives_dlls ...). We should hide their from users because
> > > redefining of their may lead to a crush. On the other hand users can
> > > define such properties and they should be visible for java
> applications.
> > >
> > > If You know other solution, lets discuss it.
> > >
> > > Dmitry
> > >
> > > >
> > > > --
> > > > Mikhail Fursov
> > > >
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > Terms of use : http://incubator.apache.org/harmony/mailing.html
> > > To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> > > For additional commands, e-mail: harmony-dev-help@incubator.apache.org
> > >
> > >
> >
> >
> > --
> > Mikhail Fursov
> >
> >
>
> ---------------------------------------------------------------------
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>
>


-- 
Mikhail Fursov

------=_Part_3050_2531611.1160481680952--