Yes, using an object handle seems not to be the best solution in this
particular case. I was using them since the start of my Rotor project, but
after some checks I've done, this particular case is different to the others
I've been using them. Seems also that GCPROTECT_XXX macros do exactly the
sam
t: Re: [DOTNET-ROTOR] GC Issues
Thank you very much for your help. I will try the
SetObjectReference(...)
function and see what happens now during execution. Hope GC issues will
be
gone now. I think that the "this" issue you mentioned should not happen
to
me, because the "this" obje
Thank you very much for your help. I will try the SetObjectReference(...)
function and see what happens now during execution. Hope GC issues will be
gone now. I think that the "this" issue you mentioned should not happen to
me, because the "this" object is already stored in a HANDLETABLE, and I
thi
April 13, 2005 10:57 PM
To: DOTNET-ROTOR@DISCUSS.DEVELOP.COM
Subject: [DOTNET-ROTOR] GC Issues
Hello,
I'm having several issues with the GC, and some ideas to try to solve it
that I need to clarify. I had a C# method that I stripped down in order
to
reimplement it in C++, using the
Hello,
I'm having several issues with the GC, and some ideas to try to solve it
that I need to clarify. I had a C# method that I stripped down in order to
reimplement it in C++, using the 'extern' keyword and the
[MethodImplAttribute(MethodImplOptions.InternalCall)]modifier, just as
several method
Hi,
When tracing the handle table promotion during ephemeral collection (i.e.
CNameSpace::GcScanHandles in gcsmp.cpp), there are a number of objects that
are moved or promoted to the gen_1 but never got allocated.
Are the the handle table allocations somehow "hidden" (i.e. allocated
differently a
Hi,
It doesnt make sense for the gc to allocate objects when the garbage
collection and the subsequent compaction of the heap is going on. why
would it do so? The allocation in the managed heap would begin once
the heap has been compacted and all the addresses of the references
have been updated
PROTECTED]
Subject: Re: [DOTNET-ROTOR] GC
I mean that when GC occurs there will be one thread performing GC. Will
this
particular thread create some new objects to support the garbage
collection
process?
===
This list is hosted by DevelopMentor(r) http://www.develop.com
I mean that when GC occurs there will be one thread performing GC. Will this
particular thread create some new objects to support the garbage collection
process?
===
This list is hosted by DevelopMentor® http://www.develop.com
ASP.NET courses you may be interested
]
Subject: [DOTNET-ROTOR] GC
Does GC thread allocate some objects in the managed heap during its
lifetime?
===
This list is hosted by DevelopMentor(r) http://www.develop.com
ASP.NET courses you may be interested in:
Guerrilla ASP.NET
15 March 2004, in Boston, MA
17 May
Does GC thread allocate some objects in the managed heap during its lifetime?
===
This list is hosted by DevelopMentor® http://www.develop.com
ASP.NET courses you may be interested in:
Guerrilla ASP.NET
15 March 2004, in Boston, MA
17 May 2004 in Torrance, CA
7 Ju
I have a GC testing application that uses
System.Reflection.Cache.TypeNameCache. It puts
a value into the cache (via RuntimeType.FullName),
does a GC (using a new GC), then tries to extract
the value from the cache (also using RuntimeType.FullName).
Extracting the value from the cache crashes Rot
Hi,
Every object is associated with a sync block index and there exists a
back pointer to that object from the sync table. After a copying
collection when the addresses of the object change How are these back
pointers relocated? Will SyncBlockCache::GCWeakPtrScan(..) perform
this activity?
Thank
t; with no warranties, and confers no
rights.
-Original Message-
From: Discussion of the Rotor Shared Source CLI implementation
[mailto:[EMAIL PROTECTED] On Behalf Of Pedro Felix
Sent: Tuesday, July 15, 2003 6:37 AM
To: [EMAIL PROTECTED]
Subject: [DOTNET-ROTOR] GC: overflow in gen1 while promoting
I've the flowwing question regarding the GC in Rotor.
When promoting gen0 survivors to gen1 (copy_phase) the
function "copy_object_simple" calls "allocate_in_older_generation" to
allocate space in gen1. Is it possible to gen1 to be full at this moment,
which would require a GC in gen1 (mark-and-sw
Regarding the copy_phase of the GC; I posted the following question:
>1)The first part of the "copy_phase" promotes survivors in gen 0 to
> gen 1 (assuming 2 generations) by calling "copy_object_simple". This
> function copies the objects to gen 1 and UPDATES (?) the references.
> If so, why is it
well that clears all my doubts
thank you so much,
archana
Barry Bond wrote:
> Correct - the two pointers are just a macro-level check that may produce
> a false-positive, while IsHeapPointer() produces definitive anwsers.
>
> IsObjRefValid() is also a helper function which may return a
> false-po
ranties, and confers no
rights.
-Original Message-
From: Archana Ravindar [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, December 18, 2002 10:13 PM
To: [EMAIL PROTECTED]
Subject: Re: [DOTNET-ROTOR] gc heap structure for rotor
> Barry Bond wrote:
>
> > For example, take a lo
> Barry Bond wrote:
>
> > For example, take a look at GCHeap::IsHeapPointer() in
> > sscli/src/clr/src/vm/gcsmp.cpp. You can see the range-check that the
> > pointer is between g_lowest_address and g_highest_address, and only if
> > it is, IsHeapPointer() calls gcheap::find_segment to determine wh
Barry Bond wrote:
> The SSCLI's garbage collector can allocate from more than one chunk of
> memory. g_lowest_address and g_highest_address represent the lowest and
> highest addresses that *may* contain garbage collected heaps, and are
> used to quickly estimate whether a pointer is within the G
inter.
Barry
This posting is provided "AS IS" with no warranties, and confers no
rights.
-Original Message-
From: Archana Ravindar [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, December 17, 2002 10:22 PM
To: [EMAIL PROTECTED]
Subject: [DOTNET-ROTOR] gc heap structure for rot
Hi,
the GC interface in rotor includes two parameters- g_lowest_address and
g_highest_address, that define the limits of the heap.
am i right in assuming that, if one has to plug in his GC into rotor he has
to have a one-dimensional chunk of memory for the heap ie. to say it cant
be organized int
Thank you, Jan,
LABELSTACK is exactly what we have missed.
> Also, make sure that you do LABELSTACK before calling your helper in the
> FJIT macro. This is another crucial part to make the GC work while you
> are in the debugger code. LABELSTACK records the locations of the object
> references in
To: [EMAIL PROTECTED]
Subject: [DOTNET-ROTOR] GC in exception handler
Hi,
There is the following problem in our debugger and we can't figure out
its exact reason:
We have the following helper called from JITted code (it may be inserted
at any point in the IL stream) :
FCIMPL0(void,
Hi,
There is the following problem in our debugger and we can't figure out its exact
reason:
We have the following helper called from JITted code (it may be inserted at any point
in the IL stream) :
FCIMPL0(void, JIT_Checkpoint)
{
THROWSCOMPLUSEXCEPTION();
HELPER_METHOD_FRAME_BEGIN_0()
25 matches
Mail list logo
