[Vm-dev] Suggested change for SpurMemoryManager>>#classAtIndex:

[Eliot Miranda]

Hi Hernan,
On Wed, Oct 10, 2018 at 2:45 AM Hernan Wilkinson <
hernan.wilkinson at 10pines.com> wrote:

>
> well, I have the same problem but with the message #lengthOf:, but now the
> behavior is weird.
> If I have the following code, everything works fine:
> typesSize := (objectMemory lengthOf: types) - 1.
>
> If I remove the - 1, like this:
> typesSize := objectMemory lengthOf: types.
>
> I get redefinition of labels errors:
> ../../spurstack64src/vm/gcc3x-interp.c:4879:2: error: redefinition of
> label 'l46'
>         l46:    /* end lengthOf:format: */;
>         ^
> ../../spurstack64src/vm/gcc3x-interp.c:4693:2: note: previous definition
> is here
>         l46:    /* end lengthOf:format: */;
>         ^
>
> The thing is that in the first case #lengthOf: is not inlined but in the
> second it is and it looks like that the label is not regenerated every time
> it gets inlined.
>  Is there a well know workaround for this? I mean, I could do:
> typesSize := (objectMemory lengthOf: types) - 0.
>
>  and it will compile but that is not the point.
>

This does look like a bug.  Can you mail me the complete method and I'll
try and have a look (or could you commit the package to VMMakerInbox and
tell me the method?).  I'd like to understand if this is a fixable bug or a
limitation.


>  Also, why in the first case the code generator decides not to inline
> #lengthOf: but it does in the second case?
>

The inlines chooses to inline methods not marked as inlined based on (IIRC)
two properties:

a) if the thing being inlined is only used once it is always inlined
b) if the thing is short it will be inlined

So it is a bit arbitrary (and in my experience extremely fragile).  Things
marked as <inline: true> or <inline: #always> always get inlined.  With
<inline: #always> the original is not generated.  <inline: false> and
<inline: #never> also don't get inlined, but in addition <inline: #never>
generates a pragma for the C compiler to prevent the C compiler from
inlining (which is useful for profiling or debugging).


> Thanks!
> Hernan.
>
>
>
> On Tue, Oct 9, 2018 at 8:40 PM Hernan Wilkinson <
> hernan.wilkinson at 10pines.com> wrote:
>
>> Hi,
>>  I got compile errors when setting <inline: true> in a method I created.
>>  The errors where a label redefinition such as:
>> ../../spurstack64src/vm/gcc3x-interp.c:4790:2: error: redefinition of
>> label 'l35'
>>         l35:    /* end classAtIndex: */;
>>         ^
>> ../../spurstack64src/vm/gcc3x-interp.c:4634:2: note: previous definition
>> is here
>>         l35:    /* end classAtIndex: */;
>>         ^
>>
>>  After some research I concluded that the problem was
>> at SpurMemoryManager>>#classAtIndex: due to how it returns:
>> ...
>> classTablePage = nilObj ifTrue:
>> [^nil].
>> ^self
>> fetchPointer: (classIndex bitAnd: self classTableMinorIndexMask)
>> ofObject: classTablePage
>>
>>  I think the source code generator does not support correctly returning
>> at different points when inlining the same method more than once.
>>  So I changed that implementation to:
>> ...
>> ^classTablePage = nilObj
>> ifTrue: [nil]
>> ifFalse: [ self
>> fetchPointer: (classIndex bitAnd: self classTableMinorIndexMask)
>> ofObject: classTablePage ]
>>
>>  Doing so the compile errors were gone and the VM keeps working correctly.
>>  Is this fix correct or does it have some performance hit I do not know?
>>  Should I inform about this change with a PR? (Sorry about this question
>> but I'm new to this vm stuff :-) )
>>
>>  Here is the complete code of the method:
>> classAtIndex: classIndex
>> <api>
>> <inline: true>
>> | classTablePage |
>> self assert: (classIndex >= 0 and: [classIndex <= self tagMask or:
>> [classIndex >= self arrayClassIndexPun and: [classIndex <= self
>> classIndexMask]]]).
>> classTablePage := self fetchPointer: classIndex >> self
>> classTableMajorIndexShift
>> ofObject: hiddenRootsObj.
>> ^classTablePage = nilObj
>> ifTrue: [nil]
>> ifFalse: [ self
>> fetchPointer: (classIndex bitAnd: self classTableMinorIndexMask)
>> ofObject: classTablePage ]
>>
>>  Cheers!
>>  Hernan.
>> --
>>
>> *Hernán WilkinsonAgile Software Development, Teaching & Coaching*
>> *Phone: +54-011*-4893-2057
>> *Twitter: @HernanWilkinson*
>> *site: http://www.10Pines.com <http://www.10pines.com/>*
>> Address: Alem 896, Floor 6, Buenos Aires, Argentina
>>
>
>
> --
>
> *Hernán WilkinsonAgile Software Development, Teaching & Coaching*
> *Phone: +54-011*-4893-2057
> *Twitter: @HernanWilkinson*
> *site: http://www.10Pines.com <http://www.10pines.com/>*
> Address: Alem 896, Floor 6, Buenos Aires, Argentina
>


-- 
_,,,^..^,,,_
best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20181011/d59cc5c9/attachment-0001.html>