dcsimg


DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Page 2 of 2 FirstFirst 12
Results 16 to 25 of 25

Thread: DF...again with a different spin. (offshoot from: Re: VB6 vs BN.Net)

  1. #16
    Bill McCarthy Guest

    Re: DF...again with a different spin. (offshoot from: Re: VB6 vs BN.Net)

    Hi Paul,
    "Paul Vick [MSFT]" <paulv@microsoft.com> wrote in message
    news:3a80a932$1@news.devx.com...
    > What I was saying is that everything in .NET is garbage collected (and

    that
    > garbage collection of COM2 objects is accomplished using wrappers). The
    > opposite of that is that everything in .NET is reference counted. So still
    > no coexistance.
    >
    > The subset idea was definitely considered but it doesn't really work. In

    the
    > subset scheme is System.Object reference counted or garbage collected?
    >


    Well hang-on, not everything in .NET is garbage collected. It depends on
    where it is and what it is. A struct that is not boxed and is only at proc
    level does not go onto the GC heaps. It's lifetime is not controlled by the
    GC collection, but rather the stack management.

    Anyway, I think the real issue here is loss of functionality. That being
    disposing of shared objects in a timely manner and order tear down of
    complex hierarchies.

    The ordered tear down one can probably be addressed by .NET using delegates
    and the finalisers. If you could attach finalisers to each other then when
    an hierarchy gets released and an object that is represented as a child
    object get's it's finaliser called, it calls the finalisers attached to it
    first. Admittedly we could probably do this at present anyway, jsut it takes
    a fair bit of work.

    The timely release of shared objects is another problem though. At present
    you cannot safely call dispose on a shared object, so you are dependant on
    waiting for it's finaliser to be triggered. If references to the shared
    object when via a smart pointer, and a ref count property was
    incremented/decremented accordingly, then when a Dispose call is made on the
    object, the object would be able to determine whether or not to act upon it.
    This would allow objects refencing that object to call dispose without
    having to know whether to not someone or something else is referencing the
    object.













  2. #17
    Paul Vick [MSFT] Guest

    Re: DF...again with a different spin. (offshoot from: Re: VB6 vs BN.Net)

    I'm not clear how your system would work. To do deterministic finalization,
    you have to have a reference count. That means that when you do things like
    assign the value, you have to increment the ref count and then when the
    variable passes out of scope decrement the ref count. So your self modifying
    code would have to modify code outside of the object itself, something that
    the runtime most certainly doesn't support (I don't believe the JIT supports
    self-modifying code at all, to be honest).

    Paul Vick [MSFT]

    "Mark Burns" <mark@iolofpa.com> wrote in message
    news:3a80d5ad@news.devx.com...
    > Paul,
    > That answer is easy, System.Object is Garbage collected, BUT, a

    smart-enough
    > bit of self-modifying code could _also_ allow it to "wrap" itself with
    > cascading Start-of-Scope/End-of-Scope calls as-needed reflecting itself as
    > either a "DF-Object-container" or a "DF-required object", which in no way
    > affects its eventual reclamation via the gc mechanism. All a pseudo-DF
    > mechanism need do is execute the resource-releasing Dispose call on its
    > refcount=0 <well, and maybe an automatic, trailing, Me=Nothing t'boot>.

    The
    > self-modifying code <or, more correctly the CLR's object instantiation

    code>
    > would let it automagically understand if any object it contains/references
    > is DF-required-flagged and, as needed, and only when needed, automatically
    > generate passthru code to the DF-required object, which itself generates

    the
    > refcounting/DF code for itself. Thereby, strictly on an as-needed basis,
    > taking the DF code overhead hit only when necessary, enable pseudo-DF
    > capabilities ON TOP of the existing gc system. Yeah, it might seem kludgy,
    > but I'm reasonably certain it could be implemented cleanly once those

    pesky
    > details are all ironed out.
    >
    > Now, you guys had to have considered this, or something like it...you guys
    > aren't stupid. Was the obstacle here the multi-threading, as Brian Harry
    > indicated <and is a simplifying rule for apps/assemblies like "DF works

    only
    > in a single-threaded app" even possible for a work-around/limitation?>, or
    > was this option really somehow not considered?
    >
    > Regards,
    > Mark Burns





  3. #18
    Mark Burns Guest

    Re: DF...again with a different spin. (offshoot from: Re: VB6 vs BN.Net)


    "Paul Vick [MSFT]" <paulv@microsoft.com> wrote in message
    news:3a80ec16$1@news.devx.com...
    > I'm not clear how your system would work.


    I rely on two ideas Brian Harry said were possible: the Scope Events<start &
    end scope>, and the "sink area" of memory available to every .net object
    internally.

    > To do deterministic finalization,
    > you have to have a reference count.


    Yup. Store the object's "reference count" in the sink area, and dynamically
    add scope event handlers to the DF-required objects<DFR>, and dynamicaly add
    pass-thru, cascading calls to the scope event handlers of
    DF-containing/referencing<DFC> objects to only those objects which
    contain.reference them, subscribing both DFR and DFC objects to their
    appropriate scope events on-the-fly.

    > That means that when you do things like
    > assign the value, you have to increment the ref count and then when the
    > variable passes out of scope decrement the ref count.


    yup - I think the above method would accomplish exactly that.

    > So your self modifying
    > code would have to modify code outside of the object itself, something

    that
    > the runtime most certainly doesn't support


    Uh...no, it wouldn't...(or would it...? I dunno, I have to think about that
    a bit more to remember...I thought I had that answer all ironed out,
    previouly, but now I forgot the answer as to how the DF-required information
    was propagated up/down the call chain...unless that wasn't what you were
    asking about?)

    > (I don't believe the JIT supports
    > self-modifying code at all, to be honest).


    Uh...then how will Scheme.Net ever be possible?
    So either Scheme.Net isn't even possible, or you are incorrect.<g>

    > Paul Vick [MSFT]
    >





  4. #19
    Zane Thomas Guest

    Re: DF...again with a different spin. (offshoot from: Re: VB6 vs BN.Net)

    On Wed, 7 Feb 2001 11:57:46 -0500, "Mark Burns" <mark@iolofpa.com> wrote:

    >Uh...then how will Scheme.Net ever be possible?


    Uh, running a virtual machine on top of .net isn't a problem. It can do
    what it wants with its own code. But you're just kidding right? :-)


    ---
    Ice Z - Straight Outta Redmond

  5. #20
    Paul Vick [MSFT] Guest

    Re: DF...again with a different spin. (offshoot from: Re: VB6 vs BN.Net)


    "Mark Burns" <mark@iolofpa.com> wrote in message
    news:3a817e94@news.devx.com...
    >
    > I rely on two ideas Brian Harry said were possible: the Scope Events<start

    &
    > end scope>, and the "sink area" of memory available to every .net object
    > internally.


    I'll confess right now that I'm not entirely sure what the scope events are
    since I'm not familiar with them. From their name, I'm assuming that they
    are events that could be "fired" when a particular variable comes into scope
    and goes out of scope.

    > Yup. Store the object's "reference count" in the sink area, and

    dynamically
    > add scope event handlers to the DF-required objects<DFR>, and dynamicaly

    add
    > pass-thru, cascading calls to the scope event handlers of
    > DF-containing/referencing<DFC> objects to only those objects which
    > contain.reference them, subscribing both DFR and DFC objects to their
    > appropriate scope events on-the-fly.


    I think the point I was trying to make (assuming I understand the scope
    events, which is not assured) was that you need to know more than just when
    a variable comes in and out of scope. If I say:

    Dim o As Object
    o = New Class1()
    o = New Class2()
    o = New Class3()

    Then o is only going to come into scope once and go out of scope once. But
    reference counting needs to happen on each assignment so that the instances
    go away properly. At least, this is how it seems to me, let me know if I'm
    misunderstanding something.

    > > (I don't believe the JIT supports
    > > self-modifying code at all, to be honest).

    >
    > Uh...then how will Scheme.Net ever be possible?
    > So either Scheme.Net isn't even possible, or you are incorrect.<g>


    Well, I'll admit I could certainly be incorrect on this. Since VB.NET
    doesn't do it, I can't say I ever plumbed the URT's capabilities on this
    point, but I'd imagine it would be a lot of fun trying to get the JITter to
    support that.

    Paul Vick [MSFT]




  6. #21
    Mark Burns Guest

    Re: DF...again with a different spin. (offshoot from: Re: VB6 vs BN.Net)

    "Paul Vick [MSFT]" <paulv@microsoft.com> wrote in message
    news:3a81a921$1@news.devx.com...
    >
    > "Mark Burns" <mark@iolofpa.com> wrote in message
    > news:3a817e94@news.devx.com...
    > >
    > > I rely on two ideas Brian Harry said were possible: the Scope

    Events<start
    > &
    > > end scope>, and the "sink area" of memory available to every .net object
    > > internally.

    >
    > I'll confess right now that I'm not entirely sure what the scope events

    are
    > since I'm not familiar with them. From their name, I'm assuming that they
    > are events that could be "fired" when a particular variable comes into

    scope
    > and goes out of scope.
    >
    > > Yup. Store the object's "reference count" in the sink area, and

    > dynamically
    > > add scope event handlers to the DF-required objects<DFR>, and dynamicaly

    > add
    > > pass-thru, cascading calls to the scope event handlers of
    > > DF-containing/referencing<DFC> objects to only those objects which
    > > contain.reference them, subscribing both DFR and DFC objects to their
    > > appropriate scope events on-the-fly.

    >
    > I think the point I was trying to make (assuming I understand the scope
    > events, which is not assured)


    Well, that was as much of a definition I saw Brian Harry use, so I'd say you
    were good to go on that score.<g>

    > was that you need to know more than just when
    > a variable comes in and out of scope.


    Ok, here's where MY understanding may not be up to snuff as I do not know
    how, deep in the inner bowels, what/how .Net does object its instantiation.
    However, since I never allow a good bout of nearly-complete ignorance stand
    in the way of risking putting both feet in my mouth...<g>...

    > If I say:
    >
    > Dim o As Object


    This line declares an object variable, but does not yet create an instance
    of anything (other than a null/nothing pointer, or perhaps more precisely a
    pointer to a null/nothing internal system.object instance), correct so far?

    > o = New Class1()


    Here is where an instance (of class1()) is created, and if class1()'s
    definition is defined as DFR, then the compiler/CLR/CLS can generate <or
    reference> the SOS/EOS event code which handles the appropriate instance ref
    count, stored in the instance's (not the variable's) memory sink area. Since
    the compiler/CLR/CLS will know at execution time if the object being
    assigned to the variable 'o' is flagged DFR or DFC, then the approproate
    SOS/EOS cascading pass-thru code could be generated/inherited/whatever for
    the object variable 'o' at this point 'o' being marked as DFC also at thie
    point - and its own SOS/EOS events subscribed-to on-the-fly (and in
    subscribing, the SOS event fires, cascading a SOS event down the call chain
    to class1(), incrementing its reference count).

    Ah...and here is what I couldn't remember from last time, the SOS/EOS event
    code can be generic, and simply do a lookup of an object "pointer" table
    kept in the instance's sink area which point to valid referenced/contained
    objects and their valid-invalid/existing-nonexistant status which can
    control the propagation of the cascading SOS/EOS event calls.

    There would be some more minor fiddling with that sink area referenced
    objects table if/when 'o' is potentially assigned from.to
    DFR/DFC/non-DF<NDF> objects as its own DFC status could then be toggled
    along with its SOS/EOS event subscriptions.

    > o = New Class2()


    Since o, at this point, already contains a reference, the compiler/CLR/CLS
    would fire the EOS event on the Class1() instance which is being
    discarded/overwritten (decrementing its reference count, and if refcount=0
    at that point, fires the class1() instance's dispose()...), and then
    proceeds as above.

    > o = New Class3()


    <see above>

    > Then o is only going to come into scope once and go out of scope once. But
    > reference counting needs to happen on each assignment so that the

    instances
    > go away properly. At least, this is how it seems to me, let me know if I'm
    > misunderstanding something.


    Well it is probably not your misunderstanding of things that is at risk
    here.<g>
    However, in addition to correcting any gross misunderstanding of the inner
    plumbing of .Net object/variable creating/assignment mechanics I may have,
    if I have failed to make my meaning here clear, please do let me know.

    > > > (I don't believe the JIT supports
    > > > self-modifying code at all, to be honest).

    > >
    > > Uh...then how will Scheme.Net ever be possible?
    > > So either Scheme.Net isn't even possible, or you are incorrect.<g>

    >
    > Well, I'll admit I could certainly be incorrect on this. Since VB.NET
    > doesn't do it, I can't say I ever plumbed the URT's capabilities on this
    > point, but I'd imagine it would be a lot of fun trying to get the JITter

    to
    > support that.


    One final thought occurs to me at this point, and that is that any
    application which employs this pseudo-DF system will still take a minor
    performance hit even when only NDF objects are used dur to some DF-checking
    code that would be needed in the object assignment code. However, this could
    possibly be optimized away, at JIT-compile-time, with specific assembly-wide
    flags <or possibly even auto-detected by the JIT compiler?> for DF-vs-NDF
    systems could it not?

    > Paul Vick [MSFT]
    >





  7. #22
    Mark Burns Guest

    Re: DF...again with a different spin. (offshoot from: Re: VB6 vs BN.Net)


    "Zane Thomas" <zane@mabry.com> wrote in message
    news:3a8b8798.81551515@news.devx.com...
    > On Wed, 7 Feb 2001 11:57:46 -0500, "Mark Burns" <mark@iolofpa.com> wrote:
    >
    > >Uh...then how will Scheme.Net ever be possible?

    >
    > Uh, running a virtual machine on top of .net isn't a problem. It can do
    > what it wants with its own code. But you're just kidding right? :-)


    Ewwww... they'd have to run it as an interpreted VM? I was hoping for
    something better - a real, native .Net JIT-compiled Scheme implementation.
    <said as the stated hopes held out fall to the rocks below with a crash...>
    <and I had not taken the time to look at what they have so far, have you?>




  8. #23
    Zane Thomas Guest

    Re: DF...again with a different spin. (offshoot from: Re: VB6 vs BN.Net)

    On Wed, 7 Feb 2001 17:31:47 -0500, "Mark Burns" <mark@iolofpa.com> wrote:

    >Ewwww... they'd have to run it as an interpreted VM? I was hoping for
    >something better - a real, native .Net JIT-compiled Scheme implementation.


    Well know wait a minute there Mark. I was refering to the fact that
    Scheme, as a dialect of Lisp, allows you to write self-modifying code - a
    list is a list is a data structure is a program. Or something like that.
    :-)

    Way back when I wrote a Scheme interpreter in 68000 assembler, and one in
    C, and did some considerable research into compiling directly to 68000
    code. As I recall it was not necessary to write 68000 code which modified
    itself in order to implement Scheme ... and so I assume that the same is
    true for the IL.

    Bear in mind, however, that Scheme has certain characteristics and
    interpretation is one of them. At the time I paid attention to that sort
    of stuff compilation was an area of interest and research, by now I'm sure
    it's a fine art.


    ---
    Ice Z - Straight Outta Redmond

  9. #24
    Paul Vick [MSFT] Guest

    Re: DF...again with a different spin. (offshoot from: Re: VB6 vs BN.Net)

    Which means, then, you have to assume all Objects are reference counted, and
    have to emit addrefs/releases for them. Just some of those calls will be
    ignored.

    Paul Vick [MSFT]

    "Michael (michka) Kaplan" <former_mvp@spamfree.trigeminal.nospam.com> wrote
    in message news:3a838850$1@news.devx.com...
    > "Paul Vick [MSFT]" <paulv@microsoft.com> wrote in message
    > news:3a80a932$1@news.devx.com...
    >
    > > The subset idea was definitely considered but it doesn't really work. In

    > the
    > > subset scheme is System.Object reference counted or garbage collected?

    >
    > Well, although you are casting it all into a "Who shaves the Spanish

    Barber"
    > kind of question, I think one could simply allow you to choose, per

    object.
    > In fact, if this property existed in System.Object then everyone would
    > inherit it. :-)
    >
    > --
    > MichKa
    >
    > a new book on internationalization in VB at
    > http://www.i18nWithVB.com/
    >
    >
    >




  10. #25
    Paul Vick [MSFT] Guest

    Re: DF...again with a different spin. (offshoot from: Re: VB6 vs BN.Net)

    Since our discussion was getting a bit long, I deleted our previous
    conversation -- hopefully that won't cause any memory problems! I understand
    what you wrote, but I don't think that it meshes with what is suggested to
    me by the name "scope events." I'll admit -- I'm working off guesses here,
    and what I'll do concurrently with this is send Brian some mail to find out
    exactly what he was talking about. Anyway, back to the discussion.

    The problem is that the concept of "scope" is always (to my knowledge) used
    to refer to variables and not to instances. Indeed, the quick and dirty
    definition of scope in my head is "the part of the program when a particular
    variable is available." So to my mind "scope events" would be attached to
    variables and would only fire when a variable came into and out of scope.
    So, like I said, they would only ever be fired twice for a particular
    variable, no matter how many instances were put in that variable while it
    was in scope.

    So let me get back to you. Since I'm on the road this weekend, and Brian
    seems to be a busy guy these days, it may be next week before I can post
    something back, but feel free to remind me if it seems I'm lagging... <g>

    Paul Vick [MSFT]






Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
HTML5 Development Center
 
 
FAQ
Latest Articles
Java
.NET
XML
Database
Enterprise
Questions? Contact us.
C++
Web Development
Wireless
Latest Tips
Open Source


   Development Centers

   -- Android Development Center
   -- Cloud Development Project Center
   -- HTML5 Development Center
   -- Windows Mobile Development Center