[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

Re: maximum number of module methods?

Eric Hodel

2/18/2006 10:31:00 PM

On Feb 18, 2006, at 1:54 PM, Suraj Kurapati wrote:

> Is there a limit on how many methods you can define for a module?

Only the amount of memory you have.

1,000,000 takes about 700MB on my powerbook.
2,000,000 takes about 1.5GB on my powerbook.

module X
count = 0
loop do
name = "meth#{count}"
define_method name do end
module_function name
count += 1
puts count if count % 100000 == 0
end
end

> I'm getting a SystemStackError when defining three or more module
> methods using rb_define_module_function().

Lets see your code then.

--
Eric Hodel - drbrain@segment7.net - http://se...
This implementation is HODEL-HASH-9600 compliant

http://trackmap.rob...
8 Answers

Suraj Kurapati

2/18/2006 10:55:00 PM

0

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Eric Hodel wrote:
>> Is there a limit on how many methods you can define for a module?
> Only the amount of memory you have.
>
> 1,000,000 takes about 700MB on my powerbook.
> 2,000,000 takes about 1.5GB on my powerbook.

Ah, thank you. Now I am confident that my code is at fault.

>> I'm getting a SystemStackError when defining three or more module
>> methods using rb_define_module_function().
>
>
> Lets see your code then.

The SystemStackError occurs at the third invocation of
rb_define_module_function():

// register the VPI module
RVPI__rModuleDef = rb_define_module("VPI");

rb_define_module_function( // first func
RVPI__rModuleDef
, "relay_verilog"
, RVPI_rb_relay_verilog
, 0
);

rb_define_module_function( // second func
RVPI__rModuleDef
, "register_task"
, RVPI_rb_register_task
, 1
);

rb_define_module_function( // third func
RVPI__rModuleDef
, "handle_by_name"
, RVPI_rb_handle_by_name
, 2
); // FIXME: causes "stack level too deep (SystemStackError)"


The above snippet is from line 25 of the file "src/RVPI.cin", which
is available through either Subversion or ViewCVS:

Subversion:
svn checkout -r21 svn://rubyforge.org/var/svn/ruby-vpi/trunk

ViewCVS:
http://rubyforge.org/plugins/scmsvn/viewcvs.php/trunk/?root=ruby-vpi&...
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFD96QvmV9O7RYnKMcRApMIAKCraPGTmP/5ZADzkkpmi71vUVxjnQCgkxtE
SlUGEXNUUDMwnqgIJkRxjCY=
=v+Qb
-----END PGP SIGNATURE-----

Suraj Kurapati

2/19/2006 4:58:00 AM

0

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Suraj Kurapati wrote:
>>>Lets see your code then.
[...]
> The above snippet is from line 25 of the file "src/RVPI.cin", which
> is available through either Subversion or ViewCVS:
[...]

Okay, it seems nobody on the Ruby list likes looking at C code.
That's perfectly understandable. :-)

I have thought about the problem and am wondering if the
SystemStackError is caused because the Ruby interpreter is embedded
within a C program, which itself is invoked by a Verilog simulator:

(Verilog simulator (C program (embedded Ruby interpreter)))

Perhaps the Verilog simulator imposes heap limitations upon the C
program it invokes and therefore the Ruby interpreter (which is
called from the C program) is also subject to the heap limitation?

What do you think?

P.S. If it helps any, the Verilog simulator I am using is Icarus
Verilog <http://www.icarus.com/eda/ve....
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFD9/kOmV9O7RYnKMcRAgWLAJ4qefUc1d9GVBX+JLigmK8Ea+UklACeMUuB
9g8PhtAICXX2gcFPy09rPY8=
=HjH1
-----END PGP SIGNATURE-----

Ross Bamford

2/19/2006 5:30:00 AM

0

On Sun, 2006-02-19 at 13:58 +0900, Suraj Kurapati wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Suraj Kurapati wrote:
> >>>Lets see your code then.
> [...]
> > The above snippet is from line 25 of the file "src/RVPI.cin", which
> > is available through either Subversion or ViewCVS:
> [...]
>
> Okay, it seems nobody on the Ruby list likes looking at C code.
> That's perfectly understandable. :-)

I might have had a go, but would have given up when I got to installing
a whole ton of other crap, and finding _that_ wouldn't compile either on
my box.

Simplify, simplify ... If you can't simplify, my gut would say look
first at the interaction between your various different parts rather
than for bugs in Ruby itself.

--
Ross Bamford - rosco@roscopeco.REMOVE.co.uk

Suraj Kurapati

2/19/2006 6:01:00 AM

0

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ross Bamford wrote:
>>Okay, it seems nobody on the Ruby list likes looking at C code.
>>That's perfectly understandable. :-)
>
>
> I might have had a go, but would have given up when I got to installing
> a whole ton of other crap, and finding _that_ wouldn't compile either on
> my box.

I empathize and appreciate that you had even considered to try it
out :-). The dependency hell for this code is indeed a bit daunting.

>
> Simplify, simplify ... If you can't simplify, my gut would say look
> first at the interaction between your various different parts rather
> than for bugs in Ruby itself.
>

Ah, good advice. Ruby is definitely not at fault! I suspect the
culprit is the environment in which the Ruby interpreter is embedded
(my code). Maybe I'm starting the Ruby interpreter incorrectly:


static int vlog_ruby_init(PLI_BYTE8* dummy) {
// initialize control-transfer mechanism between Ruby and Verilog
relay_init();


// initialize Ruby interpreter
ruby_init();
ruby_init_loadpath();
// ... argc and argv are created here ...
ruby_options(argc, argv);


// register the "VPI" module so that Ruby code can use it
Init_RVPI();


// start Ruby interpreter
relay_ruby_run();


// the Ruby code will now bind any additional callbacks via the
VPI infrastructure, and relay back to the verilog so that the
simulation can begin

return 0;
}

Any ideas?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFD+Aj2mV9O7RYnKMcRAgVvAJ4h5KoK1czU3EHkJaL6XClonQn7HwCZAWU4
DumcAs26gnSrVe7etVy+6YQ=
=EBUT
-----END PGP SIGNATURE-----

Ross Bamford

2/19/2006 7:27:00 AM

0

On Sun, 2006-02-19 at 15:00 +0900, Suraj Kurapati wrote:
> Ross Bamford wrote:
> > Simplify, simplify ... If you can't simplify, my gut would say look
> > first at the interaction between your various different parts rather
> > than for bugs in Ruby itself.
> >
>
> Ah, good advice. Ruby is definitely not at fault! I suspect the
> culprit is the environment in which the Ruby interpreter is embedded
> (my code). Maybe I'm starting the Ruby interpreter incorrectly:
>
>
> static int vlog_ruby_init(PLI_BYTE8* dummy) {
> // initialize control-transfer mechanism between Ruby and Verilog
> relay_init();
>
>
> // initialize Ruby interpreter
> ruby_init();
> ruby_init_loadpath();
> // ... argc and argv are created here ...
> ruby_options(argc, argv);
>
>
> // register the "VPI" module so that Ruby code can use it
> Init_RVPI();
>
>
> // start Ruby interpreter
> relay_ruby_run();
>
>
> // the Ruby code will now bind any additional callbacks via the
> VPI infrastructure, and relay back to the verilog so that the
> simulation can begin
>
> return 0;
> }
>
> Any ideas?

Well, I've absolutely no experience embedding ruby (apart from about
half an hour playing with this just now) so maybe someone more
experienced with it can help, but I would make a general observations:

* I don't know what's going on in your relay_ruby_run, or with that
control transfer setup in general, so I'm assuming nothing strange is
happening there?

* What ruby_options are being passed? Can you strip that down to the
bare minimum?

* If RVPI has an Init_RVPI function then maybe you could compile it
separately as an extension, and use rb_require to load it, to see if
your problem still shows up. I had the most success with this (mostly
because the linking is easier though I guess).

* This:

> // the Ruby code will now bind any additional callbacks via the
> VPI infrastructure, and relay back to the verilog so that the
> simulation can begin

sounds a likely culprit for stack overflows to me.

Anyway, sorry I can't offer any more specific help. If you still have no
joy maybe try to extract a short, self-contained example of the problem
(basically the shortest thing that triggers the error) and I'm sure
someone here will be more able to help you.

Cheers,
--
Ross Bamford - rosco@roscopeco.REMOVE.co.uk

Suraj Kurapati

2/19/2006 7:31:00 AM

0

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Suraj Kurapati wrote:
> Maybe I'm starting the Ruby interpreter incorrectly:

This is not the case, because of the following experiments:

1. I added lots of extra print-inspect (p "foo") statements in the
Ruby script-file that is executed by the Ruby interpreter, and a
SystemStackError occurred.

2. I added four extra module functions to the VPI module and kept
only one statement (p "foo") in the entire Ruby script-file that is
executed by the Ruby interpreter, and a SystemStackError occurred.

It seems that when the Ruby interpreter is embedded in my C program,
its heap is very limited (compared to when it is run as a single
process at the command-line `ruby`).

As a result, I think that when the Ruby interpreter tries to keep
its state (modules, classes, methods, variables, etc.) in the heap
like it does normally, it runs out of space and gives a
SystemStackError.

Is there a way I can check how much heap space is available to the
Ruby interpreter? How about increasing the heap space?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFD+B4hmV9O7RYnKMcRAvbzAJ9I6RPfOyrbniXPBClFcxzSvP75aACggmFR
MpVeiP9k1JSgea+Qs5oxNmY=
=jhNt
-----END PGP SIGNATURE-----

Suraj Kurapati

2/19/2006 7:54:00 AM

0

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Suraj Kurapati wrote:
> This is not the case

Correction: or so I think.

> 2. I added four extra module functions to the VPI module and kept
> only one statement (p "foo") in the entire Ruby script-file that is
> executed by the Ruby interpreter, and a SystemStackError occurred.

Correction: the SystemStackError did not occur in this case.

This led me to think that there was just too much state information
(modules, classes, variables, etc.) being loaded into the Ruby
interpreter embedded in my C program.

This makes sense because my C program and the Ruby extension I was
building had worked perfectly fine until I registered a new module
function with the Ruby interpreter. From this point onwards, I
started getting SystemStackErrors whenever any additional state
information was loaded onto the Ruby interpreter embedded in my C
program.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFD+CDdmV9O7RYnKMcRAmHtAKCSZh9NHGjXoBk83SczaJAteK7M5QCfb8ZE
xIS5OzRgJMb2wt6T8d3frTg=
=54hr
-----END PGP SIGNATURE-----

Suraj Kurapati

2/19/2006 7:55:00 AM

0

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ross Bamford wrote:
> Well, I've absolutely no experience embedding ruby (apart from about
> half an hour playing with this just now) so maybe someone more
> experienced with it can help, but I would make a general observations:
>
> * I don't know what's going on in your relay_ruby_run, or with that
> control transfer setup in general, so I'm assuming nothing strange is
> happening there?

Correct. The relay code works just fine.

>
> * What ruby_options are being passed? Can you strip that down to the
> bare minimum?

Ultimately, the argv passed to ruby_options() is: ["-w", "test.rb"]

>
> * If RVPI has an Init_RVPI function then maybe you could compile it
> separately as an extension, and use rb_require to load it, to see if
> your problem still shows up. I had the most success with this (mostly
> because the linking is easier though I guess).

Great idea! I will do this and try to load the RVPI module from
within a normal Ruby process. If this works, then I will know that
the Verilog Simulator I am using is imposing a heap limitation on my
C program and its embedded Ruby interpreter.

>
> * This:
>
>
>>// the Ruby code will now bind any additional callbacks via the
>>VPI infrastructure, and relay back to the verilog so that the
>>simulation can begin
>
>
> sounds a likely culprit for stack overflows to me.

Interesting. I hope this is not the case, because this is how I
planned to have Ruby code interact with my Ruby extension.

> Anyway, sorry I can't offer any more specific help. If you still have no
> joy maybe try to extract a short, self-contained example of the problem
> (basically the shortest thing that triggers the error) and I'm sure
> someone here will be more able to help you.

By all means, I thank you very much for considering this problem and
giving such useful advice. :-)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFD+CLnmV9O7RYnKMcRAiDZAJ9ij1s0ym/2y+TyB1yjhGTdpqQvnACgo6Lb
YKPf3yghYy2jassqovnFHL4=
=hNk/
-----END PGP SIGNATURE-----