[Top][All Lists]

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

should print

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


reply via email to

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