From 6c7d45e4631784d0e077e806521a736da6b0266e Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Sun, 7 Apr 2013 18:18:44 +0200 Subject: IRC. --- open_issues/managed_runtime_initiative.mdwn | 72 +++++++++++++++++++++++++++++ 1 file changed, 72 insertions(+) create mode 100644 open_issues/managed_runtime_initiative.mdwn (limited to 'open_issues/managed_runtime_initiative.mdwn') diff --git a/open_issues/managed_runtime_initiative.mdwn b/open_issues/managed_runtime_initiative.mdwn new file mode 100644 index 00000000..7a880beb --- /dev/null +++ b/open_issues/managed_runtime_initiative.mdwn @@ -0,0 +1,72 @@ +[[!meta copyright="Copyright © 2013 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_gnumach]] + + +# IRC, freenode, #hurd, 2013-04-02 + + hi again, maybe someone has some metrics + is mprotect / munprotect faster in hurd then in linux ? + ? + can i protected a memory page against write access in hurd + and if so, is it a fast operation ? + you can, I never measured, but it's probably the same cost as in + linux + I don't see why it would be different, as it boils down to the same + x86 trick + but i suppose it is part of the mach kernel doing the protection + and not part of the unix layer ? + it is + the unix layer doesn't have mm control + it has to ask the kernel + it's slower on mach, as it's less optimized because of historical + reasons + but that's about it + less optimized, how so? + well, more entry fragmentation + in the end you mark the page table and flush the tlb + yes + the high level virtual memory layer is a bit slower + but fragmentation doesn't come into play it you just have one + memory object, does it? + it does, as it's about memory areas, not objects + the object is merely a backing store + protection, inheritance, copy on write are all area (vm_map_entry) + attributes + also, some operations affect all the address spaces where a + physical page is mapped + although i think linux does the same thing as mach/bsd now + but mprotect/munprotect doesn't, does it? + no + or perhaps by side effect, in some situations, i'm not sure + i think it depends if the memory is shared between processes, but + i don't remember the details and can't think of a proper example right + now + but anyway, "slower" here is negligible unless address spaces are + really huge and filled with lots of map entries + psockali: why do you ask ? + can i post a link here ? + about what ? + it's regarding azul / managed runtime initiative + a GC for java + why not + although i don't see the point for now :) + they have a custom MM management module for their GC as linux + kernel modul + and i was wondering if mach would be any faster then linux in + that aspect + + http://stackoverflow.com/questions/3358545/whats-actually-in-the-managed-runtime-initiatives-kernel-patches-and-jvm + psockali: generally speaking, mach is slower than linux because of + its age and the fact it didn't receive as much attention and + microoptimization as linux did + psockali: about this article, there is no reason mach would be + faster -- cgit v1.2.3