harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mikhail Fursov" <mike.fur...@gmail.com>
Subject Re: [drlvm][jit][performance] Suggestion: Let's write some small and hot native(kernel) methods on vmmagics.
Date Fri, 18 May 2007 05:43:54 GMT
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. (?)

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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message