Yes, I'm agree we should protected them (In the initial letter I was not
sure)
+ We have to divide the helpers into the groups: VM helpers, GC helpers. So
switching to the different type of GC version only GC helpers implementation
will be changed.
But this means that GC must provide some of the
Mikhail,
It all seems reasonable. Regarding #6. Maybe I misunderstand what you are
saying but it seems best to put the java vmhelpers in the same isolation as
other security sensitive kernel classes.
On 10/10/06, Rana Dasgupta <[EMAIL PROTECTED]> wrote:
Mikhail,
Please see inline.
On 1
On 10/11/06, Rana Dasgupta <[EMAIL PROTECTED]> wrote:
Mikhail,
Please see inline.
>2) How will JIT know if to use "magic" helpers?
> >The one option is to pass cmd-line parameter, like -
> >Djit.use_magic_vmhelpers=on. This option could be placed into the EM
> >configuration file as any
Mikhail,
Please see inline.
On 10/9/06, Mikhail Fursov <[EMAIL PROTECTED]> wrote:
>All,
>We have 'org.vmmagic.unboxed' package (address arithmetic) support in
both
J>itrino.OPT and Jitrino.JET compilers today. So we can rewrite part of
our
>VM helper's fast paths in Java and teach JIT comp
All,
We have 'org.vmmagic.unboxed' package (address arithmetic) support in both
Jitrino.OPT and Jitrino.JET compilers today. So we can rewrite part of our
VM helper's fast paths in Java and teach JIT compiler to inline it.
The only thing is left to do is to get the answers to the following
questio