search

cosmos72 / stmx

High performance Transactional Memory for Common Lisp
http://stmx.org/
241 stars 14 forks source link

make-array with specialized type must be initialized with that type a… #22

Closed ajberkley closed 3 years ago

ajberkley commented 3 years ago

…nd tighten up tlog-func-vector definition

(sbcl emits a warning otherwise, clhs agrees)

Tests pass; this is not a functional change (modulo bugs introduced).

I don't understand the (not simple-array) in the deftype of tlog-func-vector --- maybe a work around for a broken lisp implementation? Otherwise just (vector function *) is sufficient.

cosmos72 commented 3 years ago

The (not simple-array) part in (deftype tlog-func-vector ...) is probably redundant: I originally added it to tell the compiler not to check for simple arrays, which probably have a different code path to get/set elements.

I agree with the type tightening, less so with the functions refactoring - could you please move the latter to a different pull request ?

ajberkley commented 3 years ago

Will do!

Since then I have thought a bit about it. The (not simple-array) is not redundant (though whether it adds value or distracts the reader is up to you). It makes no difference as far as I can tell in the code generated, at least for sbcl, you are telling the compiler and any future programmers that a tlog could in principle be a displaced array and/or that it has a fill pointer. Totally unrelated, I don't seem to find a way in the Common Lisp type system to say an array is not displaced to another but has a fill pointer.

As to my other changes, I had misunderstood the CLHS, being biased by the SBCL warning. It is not required that a specialized array be initialized with the correct type, it just results in undefined behavior if accessed. Since you use (aref tlog elt) it is possible for you to access beyond the fill pointer nominally, but the only place you ever shrink the vector is in clear-tlog. So it might just be better to leave things alone.

I don't know the standard uses of stmx, but if any tlog has a lot of before or after commit functions, they will never get garbage collected (at least not on sbcl, and I doubt on any implementations) even after clear-tlog and only will go away when overwritten. Since the tlogs are kept around indefinitely this could be a minor issue.