[drlvm] Is it time to say goodbye to dear friend GC v4?

["Geir Magnusson Jr." <ge...@pobox.com>]

Is there any reason to keep this around in the main branch?

geir

Re: [drlvm] Is it time to say goodbye to dear friend GC v4?

[Rana Dasgupta <rd...@gmail.com>]

Right, it is in the default code path. So it is regularly exercised, tested,
fixed. v5 is the one in development. If gcv4 is neither being fixed, nor
developed why keep it? Sorry for the double negatives :-)

On 11/2/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
>
>
>
>
> I don't grok what you mean -  gcv4.1 is our main GC right now, right?
>
> geir
>
>

Re: [drlvm] Is it time to say goodbye to dear friend GC v4?

["Geir Magnusson Jr." <ge...@pobox.com>]

Rana Dasgupta wrote:
> If the code is not being exercised by day to day tests and maintained, 
> or if
> we are not developing it,  we can drop it I think. GCV4.1 is in the first
> category, and GCV5 the second. GCV4 doesn't fit either. Dropping it doesn't
> stop one from pulling it out of an old svn revision for personal use.

I don't grok what you mean -  gcv4.1 is our main GC right now, right?

geir

> 
> Thanks,
> Rana
> 
> On 11/2/06, Ivan Volosyuk <iv...@gmail.com> wrote:
> 
>> I would like to know the opinion of Artem, Salikh and Alexey
>> Ignatenko. They have used the GC and may have reasons to keep it.
>>
>> As for me, I occasionally use it (GCv4) and a modified version of
>> GCv4.1 (which can help detect heap access via lost pointers). Most of
>> the time I prefer second one, but sometimes it is helpful to run with
>> completely different code base. I didn't try GCv5 yet. If it stable I
>> will switch to it.
>>
>> -- 
>> Ivan
>>
>> On 11/2/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
>> > Is there any reason to keep this around in the main branch?
>>
> 

Re: [drlvm] Is it time to say goodbye to dear friend GC v4?

[Rana Dasgupta <rd...@gmail.com>]

If the code is not being exercised by day to day tests and maintained, or if
we are not developing it,  we can drop it I think. GCV4.1 is in the first
category, and GCV5 the second. GCV4 doesn't fit either. Dropping it doesn't
stop one from pulling it out of an old svn revision for personal use.

Thanks,
Rana

On 11/2/06, Ivan Volosyuk <iv...@gmail.com> wrote:

> I would like to know the opinion of Artem, Salikh and Alexey
> Ignatenko. They have used the GC and may have reasons to keep it.
>
> As for me, I occasionally use it (GCv4) and a modified version of
> GCv4.1 (which can help detect heap access via lost pointers). Most of
> the time I prefer second one, but sometimes it is helpful to run with
> completely different code base. I didn't try GCv5 yet. If it stable I
> will switch to it.
>
> --
> Ivan
>
> On 11/2/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
> > Is there any reason to keep this around in the main branch?
>

Re: [drlvm] Is it time to say goodbye to dear friend GC v4?

[Rana Dasgupta <rd...@gmail.com>]

Yes, I actually think that setting an announced date for taking away
deprecated features is a good idea Mikhail. IMHO, dead code also creates
some risk.




On 11/3/06, Mikhail Fursov <mi...@gmail.com> wrote:
>
> On 11/3/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
> >
> >
> > From that argument, I'm now against dropping GCv4, if you actually get
> > use out of it for verification of threading or other important issues.
> >
> > Yes, you can always take older revisions, but that's a pain, and if that
> > is a "speedbump" that prevents you from doing those extra tests or
> > verifications, I'd rather keep it around as a convenience for you. :)
> >
> > Seriously - if you need it, lets keep it.
> >
>
> I have an idea:
> The is an incubation process to accept new projects to Apache. Why not to
> introduce something like "farewell" process in Harmony that is "reversed
> incubation" :) ?
> So the idea is: we all agree that ComponentX is out of date and we should
> drop it. We can announce that we will drop it in a N months. This will be
> a
> signal for everyone to remove any dependencies (like we have today for
> GCv4)
> in other components during this period.
>
> If it is OK we can say that we drop GCv4 in 01/2007 and leave it in the
> trunk without additional support today .
>
> --
> Mikhail Fursov
>
>

Re: [drlvm] Is it time to say goodbye to dear friend GC v4?

[Rana Dasgupta <rd...@gmail.com>]

Since we have accepted GCV4.1 as the default and GCV5 as the development GC
based on several list discussions, I think that we may be OK with announcing
that GCv4 is deprecated, and maybe taken out of the active tree by end of
2006?

Patches that are still coming in that only work with GCV4, probably began
development quite a while ago ... since the default code does not pick up
GCV4, I am not sure how they are passing acceptance tests, unless their
functionality is not covered by the existing tests. Anyway, this is risky
IMHO, since as soon as we add the right test to the acceptance suite, the
functionality will fail( since we will only run tests with default paths ).
Anyway, announcing deprecation will only help, IMHO. Thanks for bringing
this up.

Rana


On 11/4/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
>
> Yeah, put some logging statements in.  Ask Tim if you need some help ;)
>
> I think we can do as you suggest, or simply document it somewhere.
> Cleaerly if someone knows enough to switch GC, they have hit a manual or
> code somewhere.
>
> I guess when I asked the original question, I was thinking that we
> should just be clear that it's now deprecated, and therefore except for
> required changes to keep compatible w/ the interface to GC, nothing
> should change it.  This was driven by my noticing that there was some
> recent patches that worked on GCv4, not 4.1...
>
> geir
>
>
>

Re: [drlvm] Is it time to say goodbye to dear friend GC v4?

[Tim Ellison <t....@gmail.com>]

Geir Magnusson Jr. wrote:
> Yeah, put some logging statements in.  Ask Tim if you need some help ;)

LOL, I'd be delighted.  Of course, native code is different since there
is no opportunity for introspection by the VM, so in this case logging
is a necessary evil^W technique.

Regards,
Tim

> I think we can do as you suggest, or simply document it somewhere.
> Cleaerly if someone knows enough to switch GC, they have hit a manual or
> code somewhere.
> 
> I guess when I asked the original question, I was thinking that we
> should just be clear that it's now deprecated, and therefore except for
> required changes to keep compatible w/ the interface to GC, nothing
> should change it.  This was driven by my noticing that there was some
> recent patches that worked on GCv4, not 4.1...
> 
> geir


-- 

Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.

Re: [drlvm] Is it time to say goodbye to dear friend GC v4?

["Geir Magnusson Jr." <ge...@pobox.com>]

Yeah, put some logging statements in.  Ask Tim if you need some help ;)

I think we can do as you suggest, or simply document it somewhere. 
Cleaerly if someone knows enough to switch GC, they have hit a manual or 
code somewhere.

I guess when I asked the original question, I was thinking that we 
should just be clear that it's now deprecated, and therefore except for 
required changes to keep compatible w/ the interface to GC, nothing 
should change it.  This was driven by my noticing that there was some 
recent patches that worked on GCv4, not 4.1...

geir


Ivan Volosyuk wrote:
> How we inform users of the code?
> My suggestion is to show some clearly visibly text in console when
> GCv4 is loaded something like:
> *********************************************************************
> * The component is deprecated and will be removed 01/15/07
> * Please stop using it or discuss on
> *     harmony-dev@incubator.apache.org
> *********************************************************************
> -- 
> Ivan
> 
> On 11/3/06, Mikhail Fursov <mi...@gmail.com> wrote:
>> On 11/3/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
>> >
>> >
>> > From that argument, I'm now against dropping GCv4, if you actually get
>> > use out of it for verification of threading or other important issues.
>> >
>> > Yes, you can always take older revisions, but that's a pain, and if 
>> that
>> > is a "speedbump" that prevents you from doing those extra tests or
>> > verifications, I'd rather keep it around as a convenience for you. :)
>> >
>> > Seriously - if you need it, lets keep it.
>> >
>>
>> I have an idea:
>> The is an incubation process to accept new projects to Apache. Why not to
>> introduce something like "farewell" process in Harmony that is "reversed
>> incubation" :) ?
>> So the idea is: we all agree that ComponentX is out of date and we should
>> drop it. We can announce that we will drop it in a N months. This will 
>> be a
>> signal for everyone to remove any dependencies (like we have today for 
>> GCv4)
>> in other components during this period.
>>
>> If it is OK we can say that we drop GCv4 in 01/2007 and leave it in the
>> trunk without additional support today .
> 

Re: [drlvm] Is it time to say goodbye to dear friend GC v4?

[Ivan Volosyuk <iv...@gmail.com>]

How we inform users of the code?
My suggestion is to show some clearly visibly text in console when
GCv4 is loaded something like:
*********************************************************************
* The component is deprecated and will be removed 01/15/07
* Please stop using it or discuss on
*     harmony-dev@incubator.apache.org
*********************************************************************
--
Ivan

On 11/3/06, Mikhail Fursov <mi...@gmail.com> wrote:
> On 11/3/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
> >
> >
> > From that argument, I'm now against dropping GCv4, if you actually get
> > use out of it for verification of threading or other important issues.
> >
> > Yes, you can always take older revisions, but that's a pain, and if that
> > is a "speedbump" that prevents you from doing those extra tests or
> > verifications, I'd rather keep it around as a convenience for you. :)
> >
> > Seriously - if you need it, lets keep it.
> >
>
> I have an idea:
> The is an incubation process to accept new projects to Apache. Why not to
> introduce something like "farewell" process in Harmony that is "reversed
> incubation" :) ?
> So the idea is: we all agree that ComponentX is out of date and we should
> drop it. We can announce that we will drop it in a N months. This will be a
> signal for everyone to remove any dependencies (like we have today for GCv4)
> in other components during this period.
>
> If it is OK we can say that we drop GCv4 in 01/2007 and leave it in the
> trunk without additional support today .

Re: [drlvm] Is it time to say goodbye to dear friend GC v4?

[Mikhail Fursov <mi...@gmail.com>]

On 11/3/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
>
>
> From that argument, I'm now against dropping GCv4, if you actually get
> use out of it for verification of threading or other important issues.
>
> Yes, you can always take older revisions, but that's a pain, and if that
> is a "speedbump" that prevents you from doing those extra tests or
> verifications, I'd rather keep it around as a convenience for you. :)
>
> Seriously - if you need it, lets keep it.
>

I have an idea:
The is an incubation process to accept new projects to Apache. Why not to
introduce something like "farewell" process in Harmony that is "reversed
incubation" :) ?
So the idea is: we all agree that ComponentX is out of date and we should
drop it. We can announce that we will drop it in a N months. This will be a
signal for everyone to remove any dependencies (like we have today for GCv4)
in other components during this period.

If it is OK we can say that we drop GCv4 in 01/2007 and leave it in the
trunk without additional support today .

-- 
Mikhail Fursov

Re: [drlvm] Is it time to say goodbye to dear friend GC v4?

["Geir Magnusson Jr." <ge...@pobox.com>]

Nikolay Kuznetsov wrote:
> Let me answer for Artem :), he is on vacation and most probably won't
> answer soon.
> We do occasionally use GCv4 to verify some threading issues, since
> native threading resource allocation depends on "weak references".
> Thus I would agree with Ivan, that sometimes it is helpful to switch
> to different code base(which is handy and considered to be stable
> enough), but if gcv4 won't be supported any more why don't drop it
> having in mind that one can always take older revisions from SVN.
> 
> +1 for dropping GCv4

 From that argument, I'm now against dropping GCv4, if you actually get 
use out of it for verification of threading or other important issues.

Yes, you can always take older revisions, but that's a pain, and if that 
is a "speedbump" that prevents you from doing those extra tests or 
verifications, I'd rather keep it around as a convenience for you. :)

Seriously - if you need it, lets keep it.

geir

> 
> Nik.
> 
> On 11/2/06, Ivan Volosyuk <iv...@gmail.com> wrote:
>> I would like to know the opinion of Artem, Salikh and Alexey
>> Ignatenko. They have used the GC and may have reasons to keep it.
>>
>> As for me, I occasionally use it (GCv4) and a modified version of
>> GCv4.1 (which can help detect heap access via lost pointers). Most of
>> the time I prefer second one, but sometimes it is helpful to run with
>> completely different code base. I didn't try GCv5 yet. If it stable I
>> will switch to it.
>>
>> -- 
>> Ivan
>>
>> On 11/2/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
>> > Is there any reason to keep this around in the main branch?
>>
> 

Re: [drlvm] Is it time to say goodbye to dear friend GC v4?

[Nikolay Kuznetsov <ni...@gmail.com>]

Let me answer for Artem :), he is on vacation and most probably won't
answer soon.
We do occasionally use GCv4 to verify some threading issues, since
native threading resource allocation depends on "weak references".
Thus I would agree with Ivan, that sometimes it is helpful to switch
to different code base(which is handy and considered to be stable
enough), but if gcv4 won't be supported any more why don't drop it
having in mind that one can always take older revisions from SVN.

+1 for dropping GCv4

Nik.

On 11/2/06, Ivan Volosyuk <iv...@gmail.com> wrote:
> I would like to know the opinion of Artem, Salikh and Alexey
> Ignatenko. They have used the GC and may have reasons to keep it.
>
> As for me, I occasionally use it (GCv4) and a modified version of
> GCv4.1 (which can help detect heap access via lost pointers). Most of
> the time I prefer second one, but sometimes it is helpful to run with
> completely different code base. I didn't try GCv5 yet. If it stable I
> will switch to it.
>
> --
> Ivan
>
> On 11/2/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
> > Is there any reason to keep this around in the main branch?
>

Re: [drlvm] Is it time to say goodbye to dear friend GC v4?

[Aleksey Ignatenko <al...@gmail.com>]

GCv4 is an "old friend" actually :), dropping it from the main trunk will
precisely "kill" it . Actually, I would say that it is usefull to have
working GCv4 at least untill we are done with class unloading.
So my
-1 for a quarter.

Aleksey.


On 11/3/06, Ivan Volosyuk <iv...@gmail.com> wrote:
>
> I would like to know the opinion of Artem, Salikh and Alexey
> Ignatenko. They have used the GC and may have reasons to keep it.
>
> As for me, I occasionally use it (GCv4) and a modified version of
> GCv4.1 (which can help detect heap access via lost pointers). Most of
> the time I prefer second one, but sometimes it is helpful to run with
> completely different code base. I didn't try GCv5 yet. If it stable I
> will switch to it.
>
> --
> Ivan
>
> On 11/2/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
> > Is there any reason to keep this around in the main branch?
>

Re: [drlvm] Is it time to say goodbye to dear friend GC v4?

[Salikh Zakirov <Sa...@Intel.com>]

Ivan Volosyuk wrote:
> I would like to know the opinion of Artem, Salikh and Alexey
> Ignatenko. They have used the GC and may have reasons to keep it.

As for me, I used it to debug heap iteration because it had heap iteration
implementation earlier than GC v41.

Now that GC v41 also developed support for heap iteration, there is no
reason for me to keep using GC v4. 

+1 to drop GC v4.

Re: [drlvm] Is it time to say goodbye to dear friend GC v4?

[Ivan Volosyuk <iv...@gmail.com>]

I would like to know the opinion of Artem, Salikh and Alexey
Ignatenko. They have used the GC and may have reasons to keep it.

As for me, I occasionally use it (GCv4) and a modified version of
GCv4.1 (which can help detect heap access via lost pointers). Most of
the time I prefer second one, but sometimes it is helpful to run with
completely different code base. I didn't try GCv5 yet. If it stable I
will switch to it.

--
Ivan

On 11/2/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
> Is there any reason to keep this around in the main branch?

Re: [drlvm] Is it time to say goodbye to dear friend GC v4?

[Weldon Washburn <we...@gmail.com>]

+1 for dumping GCv4 --- I got carried away and forgot to vote!

On 11/1/06, Weldon Washburn <we...@gmail.com> wrote:
>
>
>
> On 11/1/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
> >
> > Is there any reason to keep this around in the main branch?
>
>
> Actually, this brings up something I have been meaning to do for a few
> days -- ask for volunteer(s) to help with the MMTk port.  It turns out that
> the current MMTk port depends on the underlying GC to create a 450MB
> array.  This big array is used as MMTk's "user-level" java heap.  The
> solution of course is to dump GCV4 and also complete the MMTk port.
>
> It seems I am spending most of my time committing drlvm patches,
> discussing VM architecture issues and dealing with stability issues.  It
> does not look like I will get around to working on MMTk port for a while :(
> However, I can certainly show volunteers how to pick up the MMTk port and
> run with it :)  Basically what needs to be done is in the email of Oct 23
> titled, "[DRLVM][MMTk] current status and plan".  I will run a seperate
> email asking for volunteers to work on MMTk port.
>
> --
> Weldon Washburn
> Intel Enterprise Solutions Software Division
>



-- 
Weldon Washburn
Intel Enterprise Solutions Software Division

Re: [drlvm] Is it time to say goodbye to dear friend GC v4?

[Weldon Washburn <we...@gmail.com>]

On 11/1/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
>
> Is there any reason to keep this around in the main branch?


Actually, this brings up something I have been meaning to do for a few days
-- ask for volunteer(s) to help with the MMTk port.  It turns out that the
current MMTk port depends on the underlying GC to create a 450MB
array.  This big array is used as MMTk's "user-level" java heap.  The
solution of course is to dump GCV4 and also complete the MMTk port.

It seems I am spending most of my time committing drlvm patches, discussing
VM architecture issues and dealing with stability issues.  It does not look
like I will get around to working on MMTk port for a while :(  However, I
can certainly show volunteers how to pick up the MMTk port and run with it
:)  Basically what needs to be done is in the email of Oct 23 titled,
"[DRLVM][MMTk] current status and plan".  I will run a seperate email asking
for volunteers to work on MMTk port.

-- 
Weldon Washburn
Intel Enterprise Solutions Software Division

Re: [drlvm] Is it time to say goodbye to dear friend GC v4?

[Xiao-Feng Li <xi...@gmail.com>]

Except for the MMTk integration temporary need, I think the only
reason is to test the interface so that some GC/VM developer may not
break it unintentionally. But two GCs (v4.1/v5) are enough at the
moment for interface maintenance.

Thanks,
xiaofeng

On 11/2/06, Geir Magnusson Jr. <ge...@pobox.com> wrote:
> Is there any reason to keep this around in the main branch?
>
> geir
>