[Oorexx-devel] GC : Which is the rule to decide if objectVariables must be marked ?
I had a crash during GC that I was able to fix by marking the attribute objectVariables (RexxContextualSource). RexxActivation::run : Seems that when a method is guarded, then the attribute objectVariables is assigned a value, and this value must be protected from GC. Most of the exported classes do this marking, except : Pointer Buffer WeakReference RexxContext StackFrame Exception So I wonder which is the rule to decide if objectVariables must be marked ? All the classes above have guarded methods, so the same problem as mine could happen, no ? Jean-Louis -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] GC : Which is the rule to decide if objectVariables must be marked ?
On Wed, Oct 26, 2011 at 3:45 AM, Jean-Louis Faucher jfaucher...@gmail.com wrote: I had a crash during GC that I was able to fix by marking the attribute objectVariables (RexxContextualSource). RexxActivation::run : Seems that when a method is guarded, then the attribute objectVariables is assigned a value, and this value must be protected from GC. Most of the exported classes do this marking, except : Pointer Buffer WeakReference RexxContext StackFrame Exception So I wonder which is the rule to decide if objectVariables must be marked ? All the classes above have guarded methods, so the same problem as mine could happen, no ? Yes, you are absolutely right, all exported classes should be marking the object variables. For the ones you highlighted above, this could only become an issue if somebody created a subclass of these classes. Since they are not widely used, this apparently has never happened. StackFrame and Exception have never been in a released version, but the Exception class is definitely intended to be something one would subclass. Rick Jean-Louis -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] GC : Which is the rule to decide if objectVariables must be marked ?
thanks Rick. One more question I forgot to ask : what about ~flatten for objectVariables ? Is it always flatten_reference(newThis-objectVariables, envelope); or is it ok to do newThis-objectVariables = OREF_NULL ? My class is somewhat similar to RexxContext, i.e. not intended to be serialized in the image (assuming flatten is for image...). Jean-Louis 2011/10/26 Rick McGuire object.r...@gmail.com On Wed, Oct 26, 2011 at 3:45 AM, Jean-Louis Faucher jfaucher...@gmail.com wrote: I had a crash during GC that I was able to fix by marking the attribute objectVariables (RexxContextualSource). RexxActivation::run : Seems that when a method is guarded, then the attribute objectVariables is assigned a value, and this value must be protected from GC. Most of the exported classes do this marking, except : Pointer Buffer WeakReference RexxContext StackFrame Exception So I wonder which is the rule to decide if objectVariables must be marked ? All the classes above have guarded methods, so the same problem as mine could happen, no ? Yes, you are absolutely right, all exported classes should be marking the object variables. For the ones you highlighted above, this could only become an issue if somebody created a subclass of these classes. Since they are not widely used, this apparently has never happened. StackFrame and Exception have never been in a released version, but the Exception class is definitely intended to be something one would subclass. Rick Jean-Louis -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] GC : Which is the rule to decide if objectVariables must be marked ?
On Wed, Oct 26, 2011 at 7:00 AM, Jean-Louis Faucher jfaucher...@gmail.com wrote: thanks Rick. One more question I forgot to ask : what about ~flatten for objectVariables ? Is it always flatten_reference(newThis-objectVariables, envelope); or is it ok to do newThis-objectVariables = OREF_NULL ? My class is somewhat similar to RexxContext, i.e. not intended to be serialized in the image (assuming flatten is for image...). Flattening is not used for creating the image, but rather to create program images used for saving (e.g., what happens when you use rexxc on a program). If the class in question can show up as part of serialized source, then the object variables should always be included in the flattening process. Rick Jean-Louis 2011/10/26 Rick McGuire object.r...@gmail.com On Wed, Oct 26, 2011 at 3:45 AM, Jean-Louis Faucher jfaucher...@gmail.com wrote: I had a crash during GC that I was able to fix by marking the attribute objectVariables (RexxContextualSource). RexxActivation::run : Seems that when a method is guarded, then the attribute objectVariables is assigned a value, and this value must be protected from GC. Most of the exported classes do this marking, except : Pointer Buffer WeakReference RexxContext StackFrame Exception So I wonder which is the rule to decide if objectVariables must be marked ? All the classes above have guarded methods, so the same problem as mine could happen, no ? Yes, you are absolutely right, all exported classes should be marking the object variables. For the ones you highlighted above, this could only become an issue if somebody created a subclass of these classes. Since they are not widely used, this apparently has never happened. StackFrame and Exception have never been in a released version, but the Exception class is definitely intended to be something one would subclass. Rick Jean-Louis -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] GC : Which is the rule to decide if objectVariables must be marked ?
ok, thanks ! 2011/10/26 Rick McGuire object.r...@gmail.com On Wed, Oct 26, 2011 at 7:00 AM, Jean-Louis Faucher jfaucher...@gmail.com wrote: thanks Rick. One more question I forgot to ask : what about ~flatten for objectVariables ? Is it always flatten_reference(newThis-objectVariables, envelope); or is it ok to do newThis-objectVariables = OREF_NULL ? My class is somewhat similar to RexxContext, i.e. not intended to be serialized in the image (assuming flatten is for image...). Flattening is not used for creating the image, but rather to create program images used for saving (e.g., what happens when you use rexxc on a program). If the class in question can show up as part of serialized source, then the object variables should always be included in the flattening process. Rick Jean-Louis 2011/10/26 Rick McGuire object.r...@gmail.com On Wed, Oct 26, 2011 at 3:45 AM, Jean-Louis Faucher jfaucher...@gmail.com wrote: I had a crash during GC that I was able to fix by marking the attribute objectVariables (RexxContextualSource). RexxActivation::run : Seems that when a method is guarded, then the attribute objectVariables is assigned a value, and this value must be protected from GC. Most of the exported classes do this marking, except : Pointer Buffer WeakReference RexxContext StackFrame Exception So I wonder which is the rule to decide if objectVariables must be marked ? All the classes above have guarded methods, so the same problem as mine could happen, no ? Yes, you are absolutely right, all exported classes should be marking the object variables. For the ones you highlighted above, this could only become an issue if somebody created a subclass of these classes. Since they are not widely used, this apparently has never happened. StackFrame and Exception have never been in a released version, but the Exception class is definitely intended to be something one would subclass. Rick Jean-Louis -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] GC : Which is the rule to decide if objectVariables must be marked ?
On Wed, Oct 26, 2011 at 3:45 AM, Jean-Louis Faucher jfaucher...@gmail.com wrote: I had a crash during GC that I was able to fix by marking the attribute objectVariables (RexxContextualSource). RexxActivation::run : Seems that when a method is guarded, then the attribute objectVariables is assigned a value, and this value must be protected from GC. Most of the exported classes do this marking, except : Pointer Buffer WeakReference RexxContext StackFrame Exception So I wonder which is the rule to decide if objectVariables must be marked ? All the classes above have guarded methods, so the same problem as mine could happen, no ? An additional follow up on this. Pointer and Buffer are actually ok. These classes do not override the live() and liveGeneral() methods, so they inherit the ones from the Object class, which does mark objectVariables. WeakReference is definitely a problem in 4.1. I've fixed up all of the problem areas. Rick Jean-Louis -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
