On 10 May 2011 16:22, Igor Stasenko <[email protected]> wrote: > On 10 May 2011 13:33, Henrik Sperre Johansen > <[email protected]> wrote: >> On 10.05.2011 12:44, Igor Stasenko wrote: >>> >>> On 10 May 2011 11:27, Mariano Martinez Peck<[email protected]> wrote: >>>> >>>> On Tue, May 10, 2011 at 10:59 AM, Igor Stasenko<[email protected]> >>>> wrote: >>>>> >>>>> On 10 May 2011 09:48, Mariano Martinez Peck<[email protected]> >>>>> wrote: >>>>>> >>>>>> On Tue, May 10, 2011 at 9:41 AM, Marcus Denker<[email protected]> >>>>>> wrote: >>>>>>> >>>>>>> On May 10, 2011, at 9:32 AM, Mariano Martinez Peck wrote: >>>>>>> >>>>>>>> what is even worst, is that even after removing those correct CM, and >>>>>>>> doing a GC etc...they still don't disappear. >>>>>>>> >>>>>>> There is >>>>>>> >>>>>>> ScriptLoader new cleanUpMethods >>>>>>> >>>>>>> This is called from #cleanUpForRelease and normally should make sure >>>>>>> there >>>>>>> are no old methods. >>>>>>> >>>>>> >>>>>> hehehehe if I do: ScriptLoader new cleanUpForRelease, then inspect >>>>>> ((CompiledMethod allInstances select: [:each | each trailer kind = >>>>>> #VarLengthSourcePointer] ) ) >>>>>> >>>>>> they are not GC'ed and if then I click on the first element in the >>>>>> inspector.... VM CRASH!!! with both, InterpreterVM and CogVM. >>>>>> >>>>>> :( >>>>>> >>>>> okay. it seems i found the offender. Its a CompiledMethod >>>>> class>>cleanUp. >>>>> It changing a source pointer of all non-installed methods to 0. >>>> >>>> Good catch!!! :) Anyway, why CompiledMethod class>>cleanUp would like >>>> to >>>> destroy source pointers??? >>>> If I understood correctly (please correct me), all compiled methods will >>>> loose the pointer to sources and hence they will be decompiled after when >>>> they are ask their source! >>> >>> Yes, if you wipe the sourcePointer, there is no way how you can get a >>> source code of method. >> >> I believe the "not getting the source code" was on purpose. >> It's done f.ex. as part of condenseChanges, as the source pointers would >> have been invalid anyways. >> The intent I believe is that you should get decompiled source if you inspect >> old(but still referenced) CompiledMethods, instead of a bogus display of >> some random part of the new changes file, and remove error handling in >> source lookup where pointer could potentially be beyond end of file. >> >> This of course worked much faster before trailers, when setSourcePointer: >> actually modified the instance inline, rather than become'ing a copy, >> nowadays I agree with Igor that it'd probably be more conceptually clean to >> the empty MethodTrailer in destroySourcePointer :) >> >> Just remember to make sure such instances decompile as expected to uphold >> why the zapping was done in the first place. >> If we're lucky, it won't crash the VM either ;) >> > > Actually , in #destroySourcePointer setting sourcePointer = 0 is pretty > useless. > Since now, we can embed source code in trailer, we can replace a > senders of it with #dropSourcePointer. > Then you don't have to decompile the method, even if its no longer > installed and cannot be located in .sources or .changes files anymore. > > We could even do this at the method installation time: > - if a newly installed method replacing an old one, > we tell old one to drop its source pointer immediately. > > Then, by definition, you cannot have non-installed methods with wrong > source pointer, and all those methods will still be able to show you > an original source code. > > Sounds like an idea? >
oh , and forgot to note, that having a source code available at all times is quite useful in cases, when your methods using some kind of DSL. Because decompiler can only reconstruct a source code of smalltalk methods, but not the ones, which were authored using customized parser/compiler .. like using Helvetia. >> Cheers, >> Henry >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > -- Best regards, Igor Stasenko AKA sig.
