Il 06/11/2013 10:25, Gwenaël Casaccio ha scritto:
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 think most read-only objects are old (and mmap-ed directly from the
image) anyway, so it shouldn't be a big change.
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.
Yes, C programs might expect to be able to write to read-only objects.
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.
I think whatever #tryToWriteAt:put: returns should be left on the stack.
So this:
Object subclass: A [
| a |
tryToWriteAt: index put: object [ ^42 ]
test [ (a := 123) printNl. a printNl ]
]
Eval [
A new
makeReadOnly: true;
test
]
should print
42 "result of #tryToWriteAt:put:"
nil "nothing was stored actually"
Paolo