On Thu, 4 May 2000 [EMAIL PROTECTED] wrote:
Sounds like a good plan. The first piece to put together is the
script that can register callbacks, and iterate through the perl
threads. Do we have a devel version that's got the mip-avail type
stuff together, or is this something that will be
what i'd really like to see is a generic symbol table walker (written in
c), where you can register callbacks foreach symbol type (SVt_*). then
once you hit an SVt_PVCV, there can be any number of registered callbacks
that fiddle with the padlist (cleaner, reporter, etc.)
So what you want
On Wed, 3 May 2000 [EMAIL PROTECTED] wrote:
So what you want is something more general, climbs through the symbol
table and can register callbacks for various things, right? One of
right.
which, the area I'm most interested in, is the PADLIST? Well, that's
same here!
certainly
On Tue, 25 Apr 2000 [EMAIL PROTECTED] wrote:
Let me know when you want the garbage collector. I'll re-write it in
apache style, and add some debugging stuff. I figure there should be
two pieces. One that analyzes the packages that are running, the
other that actually kills off variables.
Doug modperlers...
however, padlists are not shared. as i mentioned, i'd like to look at
using your "garbage collector" for 2.0. if it could run in it's own
thread and examine the padlists of idle interpreters, it could be big win.
i wouldn't want it to release all allocations in the
Justin,
On Tue, Apr 25, 2000 at 11:26:00PM -0400, [EMAIL PROTECTED] wrote:
On Sat, 15 Apr 2000 [EMAIL PROTECTED] wrote:
It is very memory inneffecient basically. Each process of apache has
it's registry which holds the compiled perl scripts in..., a copy of
each for each process.
On Tue, 25 Apr 2000 [EMAIL PROTECTED] wrote:
With mod_proxy you really only need a few mod_perl processes because
no longer is the mod_perl ("heavy") apache process i/o bound. It's
now CPU bound. (or should be under heavy load)
I think for most of us this is usually not the case, since most
According to Perrin Harkins:
On Tue, 25 Apr 2000 [EMAIL PROTECTED] wrote:
With mod_proxy you really only need a few mod_perl processes because
no longer is the mod_perl ("heavy") apache process i/o bound. It's
now CPU bound. (or should be under heavy load)
I think for most of us this
On Wed, 26 Apr 2000, Leslie Mikesell wrote:
According to Perrin Harkins:
On Tue, 25 Apr 2000 [EMAIL PROTECTED] wrote:
With mod_proxy you really only need a few mod_perl processes because
no longer is the mod_perl ("heavy") apache process i/o bound. It's
now CPU bound. (or should be
Everything gets slowed down some by context switching, but my point is
that a long request doesn't hold up short requests in the same way if you
are processing in parallel. Also, if all of your requests are n seconds
long, and you process 10 of them that arrive at the server simultaneously,
On Sat, 15 Apr 2000 [EMAIL PROTECTED] wrote:
Modperlers...,
I'd like to start a discussion about the deficiences in Apache/modperl
and get you feedback with regard to this issue. The problem as I see
it is that the process model that Apache uses is very hard on modperl.
On Sat, 15 Apr 2000 [EMAIL PROTECTED] wrote:
It is very memory inneffecient basically. Each process of apache has
it's registry which holds the compiled perl scripts in..., a copy of
each for each process. This has become an issue for one of the
companies that I work for, and I noted
On Tue, 18 Apr 2000, Stas Bekman wrote:
What do you say? 1003520 bytes are returned to OS when @x goes out of
scope. Note that this doesn't happen if you use a global @x instead.
because under linux Perl defaults to system malloc:
% perl -V:usemymalloc
usemymalloc='n';
if
From: "Jeff Stuart" [EMAIL PROTECTED]
To: "Gunther Birznieks" [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: RE: Modperl/Apache deficiencies... Memory usage.
Date: Tue, 18 Apr 2000 02:07:24 -0400
I understand that. :) And that was something that I had to learn myself.
PROTECTED]
Subject: RE: Modperl/Apache deficiencies... Memory usage.
If you aren't careful with your programming, an apache HTTPD can always
grow pretty quickly because Perl never releases the RAM it allocates
previously. While it does that reference count garbage collection, that is
internal to the RAM
Since you are talking about garbage collection (memory shrinking) you
might want to re-read the thread I've started back in Aug, 99:
http://forum.swarthmore.edu/epigone/modperl/zarwhegerd
It includes the real show case of memory shrinking (at least on Linux).
Consider this code:
On Tue, 18 Apr 2000 [EMAIL PROTECTED] wrote:
On Mon, Apr 17, 2000 at 01:33:08PM -0600, Jason Terry wrote:
This is the first i have seen "delete" referenced. What does it do? How is it
used?
Thank you
-Jason
It's the stack cleaner... but it only works for scalars, and maybe
On Tue, Apr 18, 2000 at 02:07:24AM -0400, Jeff Stuart wrote:
I understand that. :) And that was something that I had to learn myself.
:) It's a BAD thing when suddenly your httpd process takes up 100 MB. :)
It's just that it sounded like Shane was saying that his httpds were
starting OUT
On Tue, Apr 18, 2000 at 01:24:16PM +0800, Gunther Birznieks wrote:
If you aren't careful with your programming, an apache HTTPD can always
grow pretty quickly because Perl never releases the RAM it allocates
previously. While it does that reference count garbage collection, that is
Actually, it is a bit more complicated. I was wrong in my assumptions. To
be more blunt, I was wrong period. :)
I had been testing some stuff using global variables and experienced this
behavior of non-releasing RAM. Since then a few people privately showed me
otherwise and Stas' posted a
No. I have not worked with XSL processers. I tend to use XML SAX parsers as
I know they are faster and deterministic-- specially Sun's XML SAX Parser.
It could be that the XSL processors are making use of a DOM based structure
which is causing all sorts of references to other data structures,
On Sun, 16 Apr 2000, Leslie Mikesell wrote:
Do you happen to know of anyone doing xml/xsl processing in
servlets? A programmer here has written some nice looking stuff
but it appears that the JVM is never garbage-collecting and
will just grow and get slower until someone restarts it. I
Is this still true under 5.6, now that weak references
are available?
-P
-Original Message-
From: Matt Sergeant [mailto:[EMAIL PROTECTED]]
Sent: Monday, April 17, 2000 4:14 AM
To: Leslie Mikesell
Cc: (Gunther Birznieks); [EMAIL PROTECTED]
Subject: Re: Modperl/Apache deficiencies
Gunther- (What follows is some servlet talk... and anyone interested
in a mod_perl garbage collector?)
If you want the ultimate in clean models, you may want to consider coding
in Java Servlets. It tends to be longer to write Java than Perl, but it's
much cleaner as all memory is shared and
On Mon, 17 Apr 2000, Paul G. Weiss wrote:
Is this still true under 5.6, now that weak references
are available?
Yes. You still have to do a lot of re-implementation to make weak refs
work, and your users have to have the WeakRef module from CPAN. Not a nice
situation.
--
Matt/
Fastnet
[EMAIL PROTECTED] wrote:
Now with modperl the Perl garbage collector is
NEVER used. Because the reference count of those variables is never
decremented... it's because it's all in the registry, and it's hard to
tell... hmm... what should I throw away, and what should I keep? ;-).
What I
On Mon, Apr 17, 2000 at 11:12:24AM -0700, Perrin Harkins wrote:
[EMAIL PROTECTED] wrote:
Now with modperl the Perl garbage collector is
NEVER used. Because the reference count of those variables is never
decremented... it's because it's all in the registry, and it's hard to
tell...
On Apr 18, [EMAIL PROTECTED] wrote:
On Mon, Apr 17, 2000 at 11:12:24AM -0700, Perrin Harkins wrote:
[EMAIL PROTECTED] wrote:
Now with modperl the Perl garbage collector is
NEVER used. Because the reference count of those variables is never
decremented... it's because it's all in the
Go out of scope, yes. Destroyed, no. Want to test? No problem. Do
the following in a perl script.
my($funnything);
print"Value of funnything is $funnything";
$funnything="Uh oh... check this out";
You'll find some interesting results on your second interation :-).
Even funnier
I get it. You're talking about Apache::Registry scripts.
http://perl.apache.org/guide/perl.html#my_Scoped_Variable_in_Nested_S
Jim
On Tue, 18 Apr 2000 [EMAIL PROTECTED] wrote:
Go out of scope, yes. Destroyed, no. Want to test? No problem. Do
the following in a perl script.
my($funnything);
print"Value of funnything is $funnything";
$funnything="Uh oh... check this out";
This only happens with Apache::Registry
[EMAIL PROTECTED] wrote:
my $i=0;
dosomefunnierstuff();
sub dosomefunnierstuff {
my $funnierstuff;
if($funnierstuff=~/funnier/) {
dosomefunnierstuff();
} else {
$funnierstuff="funnier".$i++;
}
print "Funnierstuff is
This is the first i have seen "delete" referenced. What does it do? How
is it used?
Well, you should read the manuyal, or "Programming Perl" for the real
answer. Or, were you speaking in reference to delete() specifically under
mod_perl?
In either case, delete() removes the specified key
You're right. I am mistaken :-(. Just tested it, and it was
something silly in an old script I had lying around that I thought was
a bug... my mistake. (Note to self: Test all examples before
posting... or you look like an idiot :-) )
Sorry,
Shane.
I think you're mistaken. Try the
[EMAIL PROTECTED] wrote:
On Mon, Apr 17, 2000 at 01:33:08PM -0600, Jason Terry wrote:
This is the first i have seen "delete" referenced. What does it do?
How is it used?
Thank you
-Jason
It's the stack cleaner... but it only works for scalars, and maybe
arrays, but its better for
While I agree that a true garbage collector would be cool. I wonder what
the utility would really be when you would primarily want it in mod_perl
type stuff. Yet, mod_perl is also great because of speed. One of the nice
things about Perl right now is that it is fast and that is partially due
PROTECTED]]
Sent: Saturday, April 15, 2000 6:46 PM
To: Perrin Harkins
Cc: [EMAIL PROTECTED]
Subject: Re: Modperl/Apache deficiencies... Memory usage.
Your apache processes would be the size of a stock
apache process, like 4-6M or so, and you would have 1 process that
would be 25MB or so that would
--Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Saturday, April 15, 2000 6:46 PM
To: Perrin Harkins
Cc: [EMAIL PROTECTED]
Subject: Re: Modperl/Apache deficiencies... Memory usage.
Your apache processes would be the size of a stock
apache process, like 4-6M or so, and
[ By the way, Stas - is there a CVS version of the guide that I can make
patches against? I found a few inaccuracies. ]
Yeah, but it's not accessible for people from the outside. I think I'll
start using the same mechanism apache.org does -- rolling out CVS
snapshots every few hours. At this
Perrin-
On Sat, Apr 15, 2000 at 11:33:15AM -0700, Perrin Harkins wrote:
Each process of apache has
it's registry which holds the compiled perl scripts in..., a copy of
each for each process. This has become an issue for one of the
companies that I work for, and I noted from monitoring
On Sat, 15 Apr 2000 [EMAIL PROTECTED] wrote:
I wrote a very small perl engine
for phhttpd that worked within it's threaded paradigm that sucked up a
neglibible amount of memory which used a very basic version of
Apache's registry.
Can you explain how this uses less memory than
I think I may be a bit dense on this list so forgive me if I try to clarify
(at least for myself to make sure I have this right)...
I think what you are proposing is not that much different from the proxy
front-end model. The mod_proxy is added overhead, but that solves your
memory problem.
On Sun, Apr 16, 2000 at 09:28:56AM +0300, Stas Bekman wrote:
On Sat, 15 Apr 2000 [EMAIL PROTECTED] wrote:
I wrote a very small perl engine
for phhttpd that worked within it's threaded paradigm that sucked up a
neglibible amount of memory which used a very basic version of
At 11:52 PM 4/15/00 +, [EMAIL PROTECTED] wrote:
On Sun, Apr 16, 2000 at 09:28:56AM +0300, Stas Bekman wrote:
On Sat, 15 Apr 2000 [EMAIL PROTECTED] wrote:
I wrote a very small perl engine
for phhttpd that worked within it's threaded paradigm that sucked
up a
neglibible
According to Gunther Birznieks:
If you want the ultimate in clean models, you may want to consider coding
in Java Servlets. It tends to be longer to write Java than Perl, but it's
much cleaner as all memory is shared and thread-pooling libraries do exist
to restrict 1-thread (or few
Modperlers...,
I'd like to start a discussion about the deficiences in Apache/modperl
and get you feedback with regard to this issue. The problem as I see
it is that the process model that Apache uses is very hard on modperl.
It is very memory inneffecient basically. Each process of apache has
[EMAIL PROTECTED] wrote:
Modperlers...,
I'd like to start a discussion about the deficiences in Apache/modperl
and get you feedback with regard to this issue. The problem as I see
it is that the process model that Apache uses is very hard on modperl.
It is very memory inneffecient basically.
Each process of apache has
it's registry which holds the compiled perl scripts in..., a copy of
each for each process. This has become an issue for one of the
companies that I work for, and I noted from monitoring the list that
some people have apache processes that are upwards of 25Megs,
On Sat, 15 Apr 2000 [EMAIL PROTECTED] wrote:
This has become an issue for one of the
companies that I work for, and I noted from monitoring the list that
some people have apache processes that are upwards of 25Megs, which is
frankly ridiculous.
1) I've seen them bigger than 25 megs.
2) Do
49 matches
Mail list logo
