Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@harmony.apache.org
Received-SPF: pass (nike.apache.org: domain of t.p.ellison@gmail.com
 designates 64.233.182.187 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding;
        b=FpUVC3FoC+yXao0/UE7yFUE1mUk9M9ce/QWhIaHMyxi4cjLiWHQ2Fls/fXVeBw3jaVq/rgSDGw5hrrGe54luZl5CIecsNIfpcTFBLk9ZtYvzqQ9weVC46EvF50vDtYCl/uacvN3n03KDSrzKQYmgwPSf0yHhw9NK/ZmPdLG4zvo=
Message-ID: <4816D9A4.2020001@gmail.com>
Date: Tue, 29 Apr 2008 09:17:40 +0100
From: Tim Ellison <t.p.ellison@gmail.com>
User-Agent: Thunderbird 2.0.0.12 (Windows/20080213)
MIME-Version: 1.0
To: dev@harmony.apache.org
Subject: Re: [classlib][performance] @Inline and @NoBoundsCheck annotation
 support
References: <4bebff790804250403v1c661d6u5d5b32b0f6283cac@mail.gmail.com>
	 <3b3f27c60804281703h73bff889r442c576343b88ee0@mail.gmail.com>
	 <9623c9a50804281803s6ecbe528m46779d6f0cc0414f@mail.gmail.com>
	 <3b3f27c60804281813p7dc08af1r5746cb35b4b1a4b1@mail.gmail.com>
	 <9623c9a50804281902s1a17175ehc0ad2a2e5770be85@mail.gmail.com>
	 <3b3f27c60804281911r2cc543f5oefcf59352e66d06a@mail.gmail.com>
 <9623c9a50804281927s406dc3e1k30d2192b14c9f919@mail.gmail.com>
In-Reply-To: <9623c9a50804281927s406dc3e1k30d2192b14c9f919@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Xiao-Feng Li wrote:
> On Tue, Apr 29, 2008 at 10:11 AM, Nathan Beyer <nbeyer@gmail.com> wrote:
>>  Additionally, these annotations scare me a bit. What if the annotation is
>>  wrong? Does the VM just crash in this case?
> 
> Valid concern. You can think annotation as part of code. But basically
> it's only a hint, so much less dangerous than wrong code.

The JIT is free to ignore the hint, in which case you get regular rules 
applied, but if the hint is taken it can be more dangerous than wrong 
Java code -- though not so wrong native code I agree.

> If wrong code can cause VM crash, it is possible for annotation as
> well. Annotation can be completely ignored normally, and only
> respected when aggressive optimizations are desirable.

With these annotations it is possible to get new and creative ways to 
crash too :-)  Class library developers will have to understand the 
annotations and ensure they are maintained alongside the body of the 
method so that they still hold true.  They are real code, not just hints 
to the class library developer.

Regards,
Tim