[Vm-dev] How to return an array in a primitive ?

Mariano Martinez Peck marianopeck at gmail.com
Wed Apr 28 17:46:45 UTC 2010


On Tue, Apr 27, 2010 at 5:04 PM, Bert Freudenberg <bert at freudenbergs.de>wrote:

>
> On 27.04.2010, at 16:18, Mariano Martinez Peck wrote:
> >
> >> As Bert says, it is safer to avoid allacations in the primitive. But
> >> for an example of how to do it properly, see
> >>  FilePlugin>>makeDirEntryName:size:createDate:modDate:isDir:fileSize:
> >>
> >> Note the use of #pushRemappableOop: and popRemappableOop, which is
> required
> >> to prevent the object pointers from changing due to garbage collection.
> >> Allocating an object in the primitive can and will invoke garbage
> >> collection, which leads to nasty intermittent bugs if you do not
> >> use #pushRemappableOop:.
> >>
> > Thanks Dave. I was just going to ask why it was "unsafe" but you already
> answered.
>
> Not quite. There is more to it than just remapping oops. Try to imagine
> what happens if the allocation fails because there is not enough memory,
> even after GC.
>
>
Bert, forgive my ignorance, but I don't understand the difference between
allocating object in this place (inside a VM primitive)  and allocating
objects in the image side. Why in the VM side I should take care about this
problems but not when do it from image side ?


> For small allocations there should be enough of a safe margin (hopefully
> the low-space watcher kicks in early enough). But at least for big
> allocations you also need to check if they failed.
>
>
Ok, thanks. In my particular case, it is an array with just 4 numbers and to
get statistics.

Thanks

Mariano


> - Bert -
>
> > I was going to ask an example too, but I got it also :)
> >
> > So...perfect. I just write my primitive with something similar to the
> FilePlugin example.
> >
> > Thank you very much to both of you.
> >
> > mariano
> >
> >
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20100428/cb34ae98/attachment.htm


More information about the Vm-dev mailing list