Messages in this thread | | | Date | Tue, 7 Sep 2010 15:14:26 +0300 | Subject | Re: disabling group leader perf_event | From | Pekka Enberg <> |
| |
On Tue, Sep 7, 2010 at 1:57 PM, KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> wrote: >> As for the intermediate form, you might want to take a look at Dalvik: >> >> http://www.netmite.com/android/mydroid/dalvik/docs/dalvik-bytecode.html >> >> and probably ParrotVM bytecode too. The thing to avoid is stack-based >> instructions like in Java bytecode because although it's easy to write >> interpreters for them, it makes JIT'ing harder (which needs to convert >> stack-based representation to register-based) and probably doesn't >> lend itself well to stack-constrained kernel code. > > (offtopic) > > Afaik, NetBSD plan to include lua interpreter in kernel. it is optimized embedded environment. > > (more offtopic) > > in kernel interpreter is needed some concern. 1) restricted stack size (typical userland VM > often use >100K stack size) 2) restrected memory allocation, especially high order allocation > often fail. 3) GC often makes unacceptable large lag especially on UP kernel. etc etc > So, We can't apply rich interpreter (e.g. Dalvik, Parrrot) so easily. I think. personally I prefer > minimum component.
Yes, we definitely don't want to support memory allocation in the first stages (if ever). I didn't mean that we should integrate Dalvik or Parriot but that we should look at their _intermediate code_ ("bytecode") as an example what we could design for the kernel. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |