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
 66.249.92.170 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=frd8r0kvQ8653y8UOYhNSZi3QUPee+WvMi8oNKCaTs+7zH8Q238Tjg9H/fhuDRSNBvACzmIvR7/VVS50hgnM/gn6jqlEWOGolSckL+l/TRrLy1OpovNi6fLvV2jIidzyt0hfIn3chYeJwDSrOEnios0VPcZNO4tptdgKfr+i99o=
Message-ID: <bc79dd600610161118y176d52a0rf5fa79189d46672b@mail.gmail.com>
Date: Tue, 17 Oct 2006 01:18:11 +0700
From: "Mikhail Fursov" <mike.fursov@gmail.com>
To: harmony-dev@incubator.apache.org
Subject: =?WINDOWS-1252?Q?Re:_[drlvm]_=93java.compiler=94_property?=
In-Reply-To: <e0f125db0610161002u4b9a231er7d23f7ba3a05f73@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_49866_3025694.1161022691680"
References: <2c9597b90610130555r514c525bhed9d4cc6acbfbbe7@mail.gmail.com>
	 <bc79dd600610130607h2fcc277bk58d52c3107803344@mail.gmail.com>
	 <2c9597b90610130638y12af65f6x13da9f56f64182ae@mail.gmail.com>
	 <bc79dd600610130641n6bd13b34gdf548bc6dd52b3ec@mail.gmail.com>
	 <2c9597b90610130723m71b0a63eq6f577729ddcea2d9@mail.gmail.com>
	 <453298CC.8030107@gmail.com> <45337806.4050507@pobox.com>
	 <2c9597b90610160545n1469bb0ci47e8889f39e32e93@mail.gmail.com>
	 <bc79dd600610160555x2fbf5dfp1c01af1a92d41dce@mail.gmail.com>
	 <e0f125db0610161002u4b9a231er7d23f7ba3a05f73@mail.gmail.com>

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

On 10/17/06, Pavel Pervov <pmcfirst@gmail.com> wrote:
>
> Mikhail,
>
> EM, as I see it, is interchangeable component. Should we require defining
> "
> java.compiler" for interpreted mode from all EMs?


EM does not know the semantic of options it adds to the system properties.
See client.emconf file to see how options are passed to JIT and EM knows
nothing about their meaning.
EM configuration is very convenient place to put all options that affect the
current execution mode. And if you want to have meaningful "java.compiler"
option a EM configuration file is the only place.

My idea is to initialize "java.compiler" to some default value ("none"?) in
> VM, and then overwrite it with actual value wherever actual information is
> available (in EM in our case).


EM does not override system options that are already set. Such a behaviour
allows to  make cmd-line option to have higher priority then those in EM
configuration file. I would vote to keep the behaviour.


And one question follows: what if we have three different JITs defined in EM

> configuration file? :) What value "java.compiler" will contain in this
> case?


client.emconf already has 3 JITS configured inside. The common name for the
configuration is 'client mode'

-- 
Mikhail Fursov

------=_Part_49866_3025694.1161022691680--