Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@harmony.apache.org
Received-SPF: pass (herse.apache.org: domain of gcjhd-harmony-dev@m.gmane.org
 designates 80.91.229.2 as permitted sender)
To: dev@harmony.apache.org
From: Egor Pasko <egor.pasko@gmail.com>
Subject: Re: [drlvm][jit][performance] Suggestion: Let's write some small and
 hot native(kernel) methods on vmmagics.
Date: 18 May 2007 00:36:06 -0700
Lines: 45
Message-ID: <0vqps4ymvmh.fsf@gmail.com>
References: <253b20230705170751v540cf115w2236040f9302d7f@mail.gmail.com>
 <bc79dd600705170802o33661063ubce38fb07304fc52@mail.gmail.com>
 <253b20230705170811i21c9e48fsca07fbb715764c2f@mail.gmail.com>
 <f944d83d0705172201p75513f13q28b6c3282090d408@mail.gmail.com>
 <bc79dd600705172243j54d39c1bifdca2df26c14d2d6@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4
Sender: news <news@sea.gmane.org>

On the 0x2D9 day of Apache Harmony Mikhail Fursov wrote:
> On 5/18/07, Alexey Varlamov <alexey.v.varlamov@gmail.com> wrote:
> >
> > As long as annotations are not a part of specifications, and magic
> > impls are general enough to not depend on runtime configuration
> > (particular VM components etc), this approach looks neat.
> > Another issue with using arbitrary magics is potential risk of
> > security breaches; we need to think how to control & restrict origin
> > of magic codes - like allowing only predefined bootstrap packages a la
> > "org.apache.harmony.security.fortress" or introducing & checking
> > dedicated security permissions.
> 
> 
> It's good to restrict magics  to be used only  in bootstrap classes. In this
> case I see no security problems. (?)

Does The Standard allow extra unspecified annotations in bootstrap classes?

> 2007/5/17, Sergey Kuksenko <sergey.kuksenko@gmail.com>:
> > > Mikhail,
> > > I wrote about it:
> > >  "From the other side it is incorrect having a main implemenation of
> > these
> > > methods on vmmagics. Because it needs to support vmmagics in interpreter
> > > and/or any jit. Jitrino supports vmmagics, but for classlib
> > implementation
> > > we shouldn't rely on such support from JIT side."
> > > That if JIT supports vmmagics then it should replace calls of original
> > > methods to vmmagic-based methods.
> > > The idea with annotations is good. But I have a question, where(in which
> > > class/jar) should be located magic version of method?
> >
> > This one is easy - either package magics along with the supported
> > classes, this only adds 1 external dependency to vmmagic.jar; or
> > package them separately as <module>-magics.jar and handle via
> > bootclasspath.properties as any other jar.
> >
> > We can write magic method in the same class with original. Are there any
> potential problems with it?
> 
> -- 
> Mikhail Fursov

-- 
Egor Pasko