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 other JIT option.
>>> Could use both ?
Yes, all of the JIT options in EM configuration file are simple -Djit...
Java properties and could be overriden from the command line.
>4) How to detect native helper calling convention?
> >We can use one of the approaches JUnit uses: a) check the prefix for
the
> >method: stdcall_new(..), cdecl_new(): b) check the Java annotation for
> the
> >method.
> >I prefer to use approach a). But the only reason for that is that I'm
not
> >sure DRLVM has interface to access to the class annotations today.
Could
> VM
> >gurus correct me?
>>> We had discussed this elsewhere and annotations look cleaner.
Annotations should be obtainable via reflection methods
get/resolve_annotations() on the class, but Alexey V could confirm. We
could
have a default like cdecl and even use this exclusively initially, unless
you want to use a custom platform independent JIT calling convention
Ok, I'll use annotation if we support them.
> >6) Where to keep and which classloader to use to load "unboxed" +
> "helpers"
> >Java code? Would it be part of the kernel classes and loaded by
bootstrap
> >classloader?
> >I vote leave it outside of the kernel class. But this way could cause
> >security problems in future. Any other opinion?
>>> I did not really understand why you are recommending leaving them out
of
the boot loader set.
I changed my opinion after posting this proposal. Once VM helpers are
internals of VM we should protect them and use only boot classloader to load
them.
I'm going to implement the first helper today/tomorrow. I know that while
doing it there will more problems arise and I'll report them to discuss.
--
Mikhail Fursov
