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 thi
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, proba
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 w
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
*
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 <[EMAIL PROTECTED]> wrote:
On 11/3/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
>
>
> From that argument, I
On 11/3/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> 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
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 he
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 sup
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 <[EMAIL PROTECTED]> 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
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. <[EMAIL PROTECTED]> wrote:
I don't grok what you mean
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 rev
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 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
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. <[EMAIL PROTEC
+1 for dumping GCv4 --- I got carried away and forgot to vote!
On 11/1/06, Weldon Washburn <[EMAIL PROTECTED]> wrote:
On 11/1/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
>
> Is there any reason to keep this around in the main branch?
Actually, this brings up something I have been mean
On 11/1/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> 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 depend
Is there any reason to keep this around in the main branch?
geir
18 matches
Mail list logo
