Immutability through hardware

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Immutability through hardware

Igor Stasenko
 
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.
Reply | Threaded
Open this post in threaded view
|

Re: Immutability through hardware

Gerardo Richarte
 
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
Reply | Threaded
Open this post in threaded view
|

Re: Immutability through hardware

Mariano Martinez Peck
In reply to this post by Igor Stasenko
 


On Mon, May 9, 2011 at 2:16 PM, Igor Stasenko <[hidden email]> 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 ;)


--
Mariano
http://marianopeck.wordpress.com

Reply | Threaded
Open this post in threaded view
|

Re: Immutability through hardware

Igor Stasenko
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.
Reply | Threaded
Open this post in threaded view
|

Re: Immutability through hardware

Andreas.Raab
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?
>
Reply | Threaded
Open this post in threaded view
|

Re: Immutability through hardware

stephane ducasse-2
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.