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?
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.
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
On 9 May 2011 15:23, Gerardo Richarte gera@corest.com 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
On Mon, May 9, 2011 at 2:16 PM, Igor Stasenko siguctua@gmail.com 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?
Javier Pimas proposed me last month a very similar idea but for proxies instead of immutable objects ;)
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?
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.
vm-dev@lists.squeakfoundation.org