[perl #18097] [PATCH] allow NULL interpreter in sprintf like functions
Leopold Toetsch
> # New Ticket Created by Jürgen Bömmels
> # Please include the string: [perl #18097]
> # in the subject line of all future correspondence about this issue.
> # <URL: http://rt.perl.org/rt2/Ticket/Display.html?id=18097 >
Thanks applied.
Though, /me thinks, that we should always have a valid interpreter. When
there is no interpreter, all allocated memory leaks. This is currently
not a big problem, but when there are finally long running programs,
that do generate interpreters on the fly and eval some code, they would
run out of mem soon.
So IMHO we should making an interpreter mandatory and - where needed -
change the startup sequence of the interpreter, so that all used memory
gets managed. Second advantage: all these tests for a non null
interpreter are in fast paths - we would get faster execution speed.
leo
Leopold Toetsch
> At 1:05 PM +0100 10/27/02, Leopold Toetsch wrote:
>> Though, /me thinks, that we should always have a valid interpreter.
> I tried very hard to make sure that there was always a valid
> interpreter.
Now we have one ;-)
I did change the startup sequence, so that _all_ memory allocated during
early start up (except of course the managing structures themselves)
gets managed in our pools. These are mainly vtable->name()s and the
Parrot_base_classname_hash.
I did change PIO_eprintf slightly: It does now an immediate
vfprintf(stderr,..), when there is no interpreter. This means, that w/o
interpreter only arguments according to printf(3) are valid.
There a still function's like PackFile_new w/o interpreter, but they
don't allocate any unmanaged memory except the packfile itself.
You might need a "make realclean && perl Configure.pl && make" to get
things running again.
leo
Brent Dax
# Brent Dax wrote:
# > When I was working on switching most fprintf calls to PIO,
# there were
# > so many functions that didn't take an interpreter that I eventually
# > made PIO_printf and PIO_eprintf (output to stderr) fall
# back to stdio
# > if given a null interpreter.
#
# But actually, the only case, when there is no interpreter, is when
# constructing the interpreter itself fails.
Perhaps you don't understand what I mean. What I'm talking about is the
fact that most functions in packfile.c don't even take an interpreter
argument.
C:\brent\Visual Studio Projects\Perl 6\parrot\parrot>grep -l
"PIO_eprintf(NULL" *.c
debug.c
malloc.c
packdump.c
packfile.c
packout.c
--Brent Dax <bren...@cpan.org>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
Wire telegraph is a kind of a very, very long cat. You pull his tail in
New York and his head is meowing in Los Angeles. And radio operates
exactly the same way. The only difference is that there is no cat.
--Albert Einstein (explaining radio)
Leopold Toetsch
> Perhaps you don't understand what I mean. What I'm talking about is the
> fact that most functions in packfile.c don't even take an interpreter
> argument.
I know. Please fetch the new code from CVS.
When there is no interpreter in PIO_eprint, vfprintf gets called.
leo
Juergen Boemmels
As we are in the state of changing packfile.c (at least long term):
Should the packfile functions have an interpreter or should the
packfile stay on its own.
bye
b.
--
Juergen Boemmels boem...@physik.uni-kl.de
Fachbereich Physik Tel: ++49-(0)631-205-2817
Universitaet Kaiserslautern Fax: ++49-(0)631-205-3906
PGP Key fingerprint = 9F 56 54 3D 45 C1 32 6F 23 F6 C7 2F 85 93 DD 47
Leopold Toetsch
> Leopold Toetsch <l...@toetsch.at> writes:
>>When there is no interpreter in PIO_eprint, vfprintf gets called.
>>
>
> As we are in the state of changing packfile.c (at least long term):
> Should the packfile functions have an interpreter or should the
> packfile stay on its own.
As long as packfile functions don't allocate memory (besides their own
structures) it doesn't matter very much. Nethertheless, when doing
changes I would include an interpreter param.
Allocating strings or PMCs does require a valid interpreter now. The
current PIO_eprintf calls with a null interpreter call vfprintf, so
don't harm.
> bye
> b.
leo
Dan Sugalski
>Dan Sugalski wrote:
>
>>At 1:05 PM +0100 10/27/02, Leopold Toetsch wrote:
>
>Though, /me thinks, that we should always have a valid interpreter.
>
>I tried very hard to make sure that there was always a valid interpreter.
>
>Now we have one ;-)
I have, in the past, considered having a parent interpreter that
doesn't ever run any code, and is around for the sole purpose of
hanging 'global' parrot memory off of. I never did it because I
wasn't sure we needed it, but it might be time to dust off the idea.
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk
Dan Sugalski
>Leopold Toetsch <l...@toetsch.at> writes:
>
>> Brent Dax wrote:
>>
>>
>> > Perhaps you don't understand what I mean. What I'm talking about is the
>> > fact that most functions in packfile.c don't even take an interpreter
>> > argument.
>>
>> I know. Please fetch the new code from CVS.
>>
>> When there is no interpreter in PIO_eprint, vfprintf gets called.
>
>As we are in the state of changing packfile.c (at least long term):
>Should the packfile functions have an interpreter or should the
>packfile stay on its own.
They should have an interpreter.
Leopold Toetsch
> I have, in the past, considered having a parent interpreter that doesn't
> ever run any code, and is around for the sole purpose of hanging
> 'global' parrot memory off of. I never did it because I wasn't sure we
> needed it, but it might be time to dust off the idea.
No more need for it. All PMCs/Buffers of the running interpreter are
managed now. As for the interpreters structures itself - I'm almost
finished with Parrot_destroy: I currently have _one_ memory leak WRT PIO
- that's it.
leo
Piers Cawley
> Juergen Boemmels wrote:
>
>> Leopold Toetsch <l...@toetsch.at> writes:
>
>>>When there is no interpreter in PIO_eprint, vfprintf gets called.
>>>
>> As we are in the state of changing packfile.c (at least long term):
>> Should the packfile functions have an interpreter or should the
>> packfile stay on its own.
>
>
> As long as packfile functions don't allocate memory (besides their
> own structures) it doesn't matter very much. Nethertheless, when
> doing changes I would include an interpreter param.
I wonder if 'interpreter' is fast becoming the wrong name for the
thing you're passing around (at least from the point of view of
functions like the bytecode generator where you're only really using
the thing as a memory manager.)
--
Piers
"It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite."
-- Jane Austen?
Leopold Toetsch
> Leopold Toetsch <l...@toetsch.at> writes:
>> As long as packfile functions don't allocate memory (besides their
>> own structures) it doesn't matter very much. Nethertheless, when
>> doing changes I would include an interpreter param.
> I wonder if 'interpreter' is fast becoming the wrong name for the
> thing you're passing around (at least from the point of view of
> functions like the bytecode generator where you're only really using
> the thing as a memory manager.)
Yep. I wrote (or a void* argument), though I don't know, how these
functions would know, what this argument really is. Maybe callback
functions would be a better choice, so that byte code generators could
better communicate with packout.
WRT memory manager, why not but packfile functions don't need one.
leo
Juergen Boemmels
> In perl.perl6.internals, you wrote:
> > Leopold Toetsch <l...@toetsch.at> writes:
>
> >> As long as packfile functions don't allocate memory (besides their
> >> own structures) it doesn't matter very much. Nethertheless, when
> >> doing changes I would include an interpreter param.
>
> > I wonder if 'interpreter' is fast becoming the wrong name for the
> > thing you're passing around (at least from the point of view of
> > functions like the bytecode generator where you're only really using
> > the thing as a memory manager.)
The memory subsytem can be factored out of the interpreter. Each
interpreter will have one memory subsystem.
> Yep. I wrote (or a void* argument), though I don't know, how these
> functions would know, what this argument really is. Maybe callback
> functions would be a better choice, so that byte code generators could
> better communicate with packout.
>
> WRT memory manager, why not but packfile functions don't need one.
The packfile functions allways need to have a memory manager. This is
at the moment a very simple one: The memory is allocated directly from
the system and is managed there, when the packfile is destroyed all
associated memory will be destroyed also. This is not a very clever
management, but a management.
The problem starts when the memory comes from a diffrent source, e.g
if a compiler uses Buffers and garbage-collection for intermediate
storage of bytecode, which then is entered into the packfile. Who is
responsible for destroying the Memory? These kind of problems arise at
all interfaces between memory systems.
Some evil idea just comes up my mind: Why is the packfile not yet an
other PMC? The memory is simply managed by the interpreter, the
individual chunks/segments/sections are simple keyed access
functions. I must think a little more about this.