From: Brent Roman Date: 2009-02-15T20:15:07+09:00 Subject: [ruby-core:22145] Re: A short memorandum (Re: 1.8.7 Specifics) Charlie, All the methods in the GC module are implementation specific. But, the Garbage Collector is certainly an integral part of the ruby core. This is why, when this issue was discussed a few week ago, I wrote that it would be simplest to spec only that the GC module exists and that what methods it supports is implementation dependent. This works quite well if we standardize such that GC.start, if defined always starts a GC pass. GC.disable, if defined, always prevents GC until the next GC.enable. Etc. I'm sure you get the idea. Applications that must interact with the GC module would be written in the usual Ruby ducktype fashion: GC.disable if GC.respond_to? :disable Introspection is relatively cheap, simple to code and very much "the Ruby way" So, what's wrong with this? And, yes, I guess I'm implying that MRI will spec GC.limit= and the rest. iif GC.limit= has the same meaning in some other implementation, then it should also implement it. JRuby would likely share a couple MRI GC.methods, but also add some unique ones. This approach allows apps to interact with the any GC in an implementation independent way. Regarding the __line__ and __file__ methods: I wrote these over 5 years ago. They were intended to be analogous to __FILE__ and __LINE__ They were easy in Ruby 1.6.8 but getting them ported to 1.8 was a bit tricky because rb_eval had optimized away some of the logic that once tracked the current file and line as AST nodes were being evaluated. I don't really care much what form they ultimately take. I'm just offering the patch up as proof that it can be done in 1.8 efficiently. And, I've shown that it's very easy to write a Ruby wrapper around these methods so they behave like the ones introduced in 1.9. - brent Charles Oliver Nutter-2 wrote: > > Brent Roman wrote: >> GC.increase #returns the number of bytes allocated since the >> last >> garbage collection >> GC.limit #returns the maximum allowed GC.increase >> GC.limit= bytes # sets the maximum allowed GC.increase >> GC.exorcise #Manually purge ghost refs from recently freed >> stack >> space (debugging only) > > These expose implementation-specific details of GC. Should they perhaps > be moved to an extension that's not normally loaded? require 'mri_gc' or > something? > > I'd also argue they're implementation-specific enough to not have any > place in the standard, public Ruby API, since they make several > assumptions about the GC algorithm in use. > > In addition, they may be difficult to support as Ruby's GC evolves, and > they'll certainly be difficult or impossible to support on > implementations with completely different GCs (JRuby at least, perhaps > IronRuby, Rubinius, MagLev, or MacRuby as well). In JRuby's case, we > have our own implementation-specific ways to provide GC information, but > we would never think of making them part of the public, specified API. > >> Proc|Method|UnboundMethod#__line__ #line on which these objects >> were >> defined >> Proc|Method|UnboundMethod#__file__ #file name in which these >> objects >> were defined > > I think something like these were still being discussed...did those > discussions ever agree to add them? If not, perhaps they should be > reopened before being added. > > At any rate I hope *all* API changes will be brought to ruby-core for > consideration. It sounds like you plan to do that. > > - Charlie > > > -- View this message in context: http://www.nabble.com/-ruby-core%3A21997--1.8.7-Specifics-tp21961585p22021573.html Sent from the ruby-core mailing list archive at Nabble.com.