Front page | perl.perl5.porters |
Postings from February 2017
Re: Stack refcount synopsis
Thread Previous
|
Thread Next
From:
Aaron Crane
Date:
February 15, 2017 23:20
Subject:
Re: Stack refcount synopsis
Message ID:
CACmk_tvEmvfYxs7tMg8hKo-mqdbqnKDA_iAGdopaJLrfJN8DcA@mail.gmail.com
David Nicol <davidnicol@gmail.com> wrote:
> About a decade ago I linked boehm-GC into a Perl, and the Perl did not
> explode. Does that count?
Maybe. I'll assume that the resulting Perl used the Boehm allocator
for its memory regions. That leaves several other questions. One is
whether not just the SV arenas themselves were allocated and GCed by
the Boehm allocator, but the actual SV heads and bodies. I have a
strong suspicion that care would need to be taken to ensure that
happens. If your Perl did that, then I for one would be very
interested in seeing the patch, even against a very old version.
However, another question is the issue you allude to of timely
destruction; it's entirely possible that a GCed Perl would "not
explode", as you put it (which I assume means that it passed a large
fraction of tests) while breaking Perl programs that do things like
this:
sub process_request {
my ($schema, $request) = @_;
my $schema = some_dbix_class_schema();
my $guard = $schema->txn_scope_guard;
do_something_with($schema, $request); # might throw an exception
$guard->commit;
return 1;
}
my $schema = some_dbix_class_schema();
eval { process_request($schema, $_) } or warn $@
for @requests;
The txn_scope_guard method starts a database transactjon, and returns
a value with a DESTROY method that rolls back the transaction if
->commit hasn't been called on it. The object destruction in this
situation *must* happen in a timely fashion — certainly before the
next request is processed — lest that subsequent request issue
database queries that it thinks will take effect, but in a transaction
that's going to be rolled back.
This is, fundamentally, the really hard problem facing any attempt to
use memory management techniques other than reference counting in Perl
5: it is, to say the least, highly non-obvious how the language's
semantics could be preserved under such a scheme.
You also alluded to the possibility of using compile-time escape
analysis to determine whether at least some values (like the $guard
variable in this case) can be subjected to timely destruction even
without a GC implementation that handles the general case of timely
destruction. There are two potential issues I see with that approach.
One is that I'm not sure how much it will help in real code; breaking
the timely-destruction assumptions of even 1% of programs may well be
unacceptable here. The other is that while escape analysis is a
reasonably well understood technique, Perl confounds it both by using
call-by-reference, and by not providing a syntax tree that usefully
accommodates any analysis of that sort — the optree is extremely
ill-suited to such things. (That is, "I wouldn't start from here" —
which is sadly a restatement of the problem we have with the stack not
being refcounted.)
--
Aaron Crane ** http://aaroncrane.co.uk/
Thread Previous
|
Thread Next