[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Help-smalltalk] ReadOnly
From: |
Gwenaël Casaccio |
Subject: |
[Help-smalltalk] ReadOnly |
Date: |
Wed, 06 Nov 2013 10:25:06 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 |
Hi,
The current implementation of the read-only support is not finished
a read-only object can change the value of an instance variable.
So I've made two implementations of the read-only the first with
a write barrier using sigsegv and the other checking the read-only
bit.
The write barrier implementation uses the fixed space as a
read-only space after the allocation and the copy of the object
to the space the pages are marked read only and registered to
a read_ony_space_handler. Before the STORE_RECEIVER_ operation in vm.def
the interpreter state is exported. Once a write is done
oldspace_sigsegv_handler
is called and a check is done to see it's a read-only page or not (using
sigsegv library)
the read-only space handler is called and does a long jump in the
interpreter. I send
a message to _gst_self.
The other implementation uses the bit check, nothing really special
here :) I've made
a simple "benchmark" and the difference between both approaches is not
really noticeable.
Frankly speaking I don't know what is the best approach to use (using
write barrier or not).
I think it could be nice to use an other heap for the read only objects:
there are less wrong
positive with grey pages.
I see at least two issues the first with C programs and the write
barrier that uses
libgst and write an object directly the handler is not correct in that
case.
Second issue - in both cases - with the bytecode set for instance if
it's the bc 80
and I send an tryToWriteAt::put: message and if the code simply returns
it's
going to crash.
Gwen
- [Help-smalltalk] ReadOnly,
Gwenaël Casaccio <=