[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Help-smalltalk] ReadOnly

From: Gwenaël Casaccio
Subject: Re: [Help-smalltalk] ReadOnly
Date: Wed, 06 Nov 2013 20:56:53 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0

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
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
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;

should print

     42           "result of #tryToWriteAt:put:"
     nil          "nothing was stored actually"


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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]