Just a follow-up to recent thread. Suppose that we have new object format which supports multiple memory regions. I.e. eden space old space pinned space ... and immutable space so, instead of adding a flag per object whether its immutable or not, and then check this flag every time there is a write attempt, we could simply let hardware handle this. And immutable space is a memory region with read-only access, So once placed & sealed , any attempt to write, we lead to a hardware exception, which can be nicely handled :) So, we will have a single entry point for all write access , and don't need to spread an immutability logic all over the places. And of course hardware 'check if memory is writeable' is much faster than software one. What you think? -- Best regards, Igor Stasenko AKA sig. |
On 05/09/2011 09:16 AM, Igor Stasenko wrote: > > Just a follow-up to recent thread. > > Suppose that we have new object format which supports multiple memory regions. > I.e. > eden space > old space > pinned space > ... > and > immutable space no sure what immutable means, so I'm throwing here some thoughts. Immutable means that the object (imm) can't change, does it mean they can't also move in space? (like, immutable implies pinned?). Not necessary true, however if we have in mind the next question: can immutable objects only refer other immutable/pinned objects? otherwise when this other objects move the GC would need to update the references, right? (including any class pointers) of course the GC could change the permissions of the page to update this objects and then set it back to read only. other than this, I think the idea is good, and together with thorough exception handling, it could simplify the logic in the VM. Do we have now immutable objects? do we need them? does Newspeak need immutable objects? gera |
In reply to this post by Igor Stasenko
On Mon, May 9, 2011 at 2:16 PM, Igor Stasenko <[hidden email]> wrote:
Javier Pimas proposed me last month a very similar idea but for proxies instead of immutable objects ;) -- Mariano http://marianopeck.wordpress.com |
In reply to this post by Gerardo Richarte
On 9 May 2011 15:23, Gerardo Richarte <[hidden email]> wrote: > > On 05/09/2011 09:16 AM, Igor Stasenko wrote: >> >> Just a follow-up to recent thread. >> >> Suppose that we have new object format which supports multiple memory regions. >> I.e. >> eden space >> old space >> pinned space >> ... >> and >> immutable space > interesting idea indeed! > > no sure what immutable means, so I'm throwing here some thoughts. > > Immutable means that the object (imm) can't change, does it mean they > can't also move in space? (like, immutable implies pinned?). Not necessary > true, however if we have in mind the next question: > > can immutable objects only refer other immutable/pinned objects? > otherwise when this other objects move the GC would need to update > the references, right? (including any class pointers) > > of course the GC could change the permissions of the page to update > this objects and then set it back to read only. > Yes, during GC you have to enable writing to these pages anyways, because some of immutable objects can become a garbage, and you have to condense space somehow. But when it runs in normal mode, it could simply protect those pages from writing. > other than this, I think the idea is good, and together with > thorough exception > handling, it could simplify the logic in the VM. Do we have now > immutable objects? > do we need them? does Newspeak need immutable objects? > > gera > -- Best regards, Igor Stasenko AKA sig. |
In reply to this post by Igor Stasenko
Yes, that idea has been discussed before. If you can assume an MMU there are various useful things you can do, incl. a page-based write-barrier that is effectively zero-cost (i.e., mprotect old space; trap the write access, mark the page as root) which of course works well in combination with read-only memory regions. Cheers, - Andreas On 5/9/2011 14:16, Igor Stasenko wrote: > > Just a follow-up to recent thread. > > Suppose that we have new object format which supports multiple memory regions. > I.e. > eden space > old space > pinned space > ... > and > immutable space > > so, instead of adding a flag per object whether its immutable or not, > and then check this flag every time there is a write attempt, > we could simply let hardware handle this. > And immutable space is a memory region with read-only access, So once > placed& sealed , any attempt to write, we lead to a hardware > exception, > which can be nicely handled :) > > So, we will have a single entry point for all write access , and don't > need to spread an immutability logic all over the places. > And of course hardware 'check if memory is writeable' is much faster > than software one. > > What you think? > |
In reply to this post by Igor Stasenko
On May 9, 2011, at 2:16 PM, Igor Stasenko wrote: > > Just a follow-up to recent thread. > > Suppose that we have new object format which supports multiple memory regions. > I.e. > eden space > old space > pinned space > ... > and > immutable space > > so, instead of adding a flag per object whether its immutable or not, > and then check this flag every time there is a write attempt, > we could simply let hardware handle this. > And immutable space is a memory region with read-only access, So once > placed & sealed , any attempt to write, we lead to a hardware > exception, > which can be nicely handled :) I would love that to play with secure object space. > > So, we will have a single entry point for all write access , and don't > need to spread an immutability logic all over the places. > And of course hardware 'check if memory is writeable' is much faster > than software one. > > What you think? > > -- > Best regards, > Igor Stasenko AKA sig. |
Free forum by Nabble | Edit this page |