Closed utgarda closed 13 years ago
The original C extension could just pass ruby object pointers into the chipmunk callbacks, and viola you had a ruby object. We could possibly keep our own global count and hash to use, that may help with performance, not sure about GC problems though. I'm open to suggestions.
We could avoid holding onto objects that would otherwise be garbage collected by using WeakRefs in our hash. So, every time a shape, body, constraint, etc is created, store the object_id in the data field as we do now (doesn't have to be obj_id, but, that guarantees uniqueness and is readily available), then, insert a pair into our hash, with the object_id (or whatever we put in the data field) as the key, and as the value, WeakRef.new(<the object we just created>). I wonder what the performance of that would be, in comparison?
For the time being, I just enabled ObjectSpace dynamically : utgarda@7b7de31f536a804bc1e2c01fd5a04ac13ceb6f68 to try to get specs working.
.
... so, though spec runs cool with normal Ruby, this call @space.point_query_first(point, CP::ALL_ONES, 0) with JRuby drops a warning and return just nil. chipmunk-ffi-1.0.0/lib/chipmunk-ffi/space.rb:290 warning: ObjectSpace is disabled; _id2ref only supports immediates, pass -X+O to enable
Yep, guess I can enable it back, even dynamically, so this is not so big an issue, require 'jruby' JRuby.objectspace=true but before disabling ObjectSpace by default, they discussed if they should do it in the first place : http://www.ruby-forum.com/topic/129606 and they say it gains up to 10 times better performance.
ObjectSpace._id2ref is used in chipmunk-ffi quite a lot ( 11 times ), so, I guess, it's essential for the library?