Account Options

  1. Sign in
The old Google Groups will be going away soon, but your browser is incompatible with the new version.
Google Groups Home
« Groups Home
perl.perl6.internals
+ new post
About this group
Subscribe to this group
This is a Usenet group - learn more
Message from discussion GC_DEBUG, Some GC Fixes, and Remaining GC Bugs
The group you are posting to is a Usenet group. Messages posted to this group will make your email address visible to anyone on the Internet.
Your reply message has not been sent.
Your post was successful
 
From:
To:
Cc:
Followup To:
Add Cc | Add Followup-to | Edit Subject
Subject:
Validation:
For verification purposes please type the characters you see in the picture below or the numbers you hear by clicking the accessibility icon. Listen and type the numbers you hear
 
Mike Lambert  
View profile  
 More options Aug 12 2002, 4:48 pm
Newsgroups: perl.perl6.internals
From: pe...@jall.org (Mike Lambert)
Date: Mon, 12 Aug 2002 16:23:14 -0400 (EDT)
Local: Mon, Aug 12 2002 4:23 pm
Subject: Re: [COMMIT] GC_DEBUG, Some GC Fixes, and Remaining GC Bugs
Print | View thread | Show original | Report this message | Find messages by this author

> > Anyone more well-versed in these departments than I care to take a look at
> > the potential problems? Just change GC_DEBUG in parrot.h, and you can be
> > on your way. :)

> I can't get to it because parrot doesn't survive past initialization
> for me. When it creates the Array PMC for userargv, it allocates the
> PMC first and then the buffer for the array's data. During the
> buffer's creation, it does a collection that wipes out the PMC. My
> lo_var_ptr and hi_var_ptr are set to reasonable-sounding values at the
> top of trace_system_stack(), but I haven't been able to track it
> farther yet. Oh, and I do have your recent patch to set
> interpreter->lo_var_ptr early.

> The userargv PMC is not anchored other than in the C stack, because it
> dies in the pmc_new() creation process before the assignment to P0 can
> run.

Weird. I had to move the lo_var_ptr initialization code to runcode instead
of runops, in order to avoid collecting the ARGV pmc. The new code looks
like:

void *dummy_ptr;
PMC *userargv;

Is it possible that some systems might put dummy_ptr higher in memory than
userargv, thus causing userargv to become prematurely collected? If
so, there are three options:
- make two dummy ptrs, and choose the lesser of the two.
- set the dummy ptr to userargv, and hope we don't add two
header variables. ;)
- force the setting of lo_var_ptr upon the 'main' code in test_main.c,
above all possible functions.

I think 1 is easiest, but 3 does have the advantage of allowing the user
to do GC stuff outside of the parrot execution loop, like allocating
global variables (like argv, but app-specific), etc. Of course, it also
imposees additional coding overhead on the embedding programmer.

Mike Lambert


 
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Create a group - Google Groups - Google Home - Terms of Service - Privacy Policy
©2013 Google