[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Help-smalltalk] ReadOnly
From: |
Paolo Bonzini |
Subject: |
Re: [Help-smalltalk] ReadOnly |
Date: |
Wed, 06 Nov 2013 13:05:49 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130923 Thunderbird/17.0.9 |
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