[fpc-pascal] ppcjvm issues

Dmitry Boyarintsev skalogryz.lists at gmail.com
Fri Jan 27 19:37:48 CET 2017

On Fri, Jan 27, 2017 at 12:52 PM, Jon Foster <jon-lists at jfpossibilities.com>

> Correct me if I'm wrong: It would seem like that your free implementation
>> doesn't actually do anything, other than fulfilling the obligation of
>> having a "free". If I do this:
> var
>     o: TObject;
> begin
>     o:=TObject.create;
>     { do something ... }
>     o.free;
> end.
> Wouldn't "o" still contain a reference after "free" is called? In non-JVM
> FPC "self" is just another variable, who's origin is somewhat hidden by the
> compiler. The call to "o.free" would do something like "TObject.free(o)"
> where "o" is passed by *value* into the procedure variable "self". "Self"
> comes and goes with the scope of the "TObject.free" procedure. Which is why
> if I'm concerned about detecting whether or not "o" still contains a
> correct object reference I would need to do something like this: "o.free;
> o:=nil;" so I can test for "nil" later. Although I think FPC added a
> procedure to do that some time back. Yup, I see it "SysUtils.FreeAndNil".
> I'm not sure of the specific semantics of the JVM calls but from what I
> read in the various FPC JVM related pages on the wiki it would seem to use
> similar semantics.

Object Pascal semantic of calling .Free suggests that "o" would no longer
be a valid object.
If a dummy Free method is available for JVM, then such semantic is violated.

However, if JVM free method would at least reset "o" reference to nil, then
the semantic of "o" being an invalid object remains.

It also suggests to the garbage collector that the memory could be recycled
earlier, that the variable leaves the scope.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-pascal/attachments/20170127/5f494e32/attachment.html>

More information about the fpc-pascal mailing list