ASPN ActiveState Programmer Network
ActiveState
/ Home / Perl / PHP / Python / Tcl / XSLT /
/ Safari / My ASPN /
Cookbooks | Documentation | Mailing Lists | Modules | News Feeds | Products | User Groups


Recent Messages
List Archives
About the List
List Leaders
Subscription Options

View Subscriptions
Help

View by Topic
ActiveState
.NET Framework
Open Source
Perl
PHP
Python
Tcl
Web Services
XML & XSLT

View by Category
Database
General
SOAP
System Administration
Tools
User Interfaces
Web Programming
XML Programming


MyASPN >> Mail Archive >> perl6-internals
perl6-internals
Re: [RFC] multiple code segments and the interpreter
by Leopold Toetsch other posts by this author
Jan 30 2003 7:42AM messages near this date
Re: [RFC] multiple code segments and the interpreter | Re: [RFC] multiple code segments and the interpreter
Nicholas Clark wrote:

>  On Wed, Jan 29, 2003 at 02:12:01PM +0100, Leopold Toetsch wrote:

>  

> >The variable layout of interpreter->code (actually the packfile) doesn't 

> >fit very good for multiple code segments. There is only one ->byte_code 

> >pointer, the byte_code_size is in bytes and converted zig times into 

> >opcode_t's and so on.


>  Would it be better to store the value as a length in opcode_t's, and convert

>  back to bytes where needed?



Yep. The value in length of op's comes out for free by reading the 
packfile. The length in bytes is not needed at all (AFAIK).


> >3) one PBC file has exactly one const_table (or none if no constants are 

> >used) and may have multiple code segments


>  If I understand you correctly, every time an eval happens, more code is

>  created, and that code's associated constants are appended to the constant

>  table. 



... only if they are not yet there.

>  ... As is, this feels like an effective leak - in a long running process

>  (eg mod_parrot) there is the potential for something to cause repeated

>  evals, where the code is used only once then discarded. The parrot code

>  block can be released, GCed and recycled, but the constant table will keep

>  growing.



Normally constants are folded. I think, there are 2 or 3 kinds of code 
to be evaled:
- code is static - need to be compiled only once
- code changes but constants are the same
- all dynamic

The latter would need a constant_table per eval/code_block, which then 
get's recycled. But as it seems not too easy to detect, if an evaled 
code in a loop does produces always the same constants, it might be 
necessary to always regenerated (and GC) the constant table too.


>  Maybe code blocks should keep their own constants, so that they can be

>  released together. Maybe they should even be in the same bit of allocated

>  memory, so that locality helps caching and VM performance.



Do you like to append the constants to the "normal" code block, to the 
prederefed or to the JITed ;-)


>  Nicholas Clark


leo


Thread:
Leopold Toetsch
Leopold Toetsch
Leopold Toetsch
Nicholas Clark
Nicholas Clark

Privacy Policy | Email Opt-out | Feedback | Syndication
© ActiveState Software Inc. All rights reserved