On 06/11/2013 13:05, Paolo Bonzini wrote:
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.
You've right
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
Yes I agree for the stack, I'm thinking about the bytecode combination
if in the bc 80
I send a message when it leave the message the ip is the next ip and it
will go to the next
instruction and for the bc 80 it's bad because it's the last
instruction, if I'm right.
Gwen
_______________________________________________
help-smalltalk mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/help-smalltalk
