On 12/15/06, Pavel Pervov <[EMAIL PROTECTED]> wrote:
First of all, I do not understand, why alternate implementation was commited without ANY discussion on the mailing list.
Actually, nothing should be committed without sufficient discussion. However committing code often requires a judgement call else the entire harmony development process would slow down significantly. Given that 2560 does not disrupt the existing finalizer operation and that it is straight forward to commit compensating changes, I decided to go ahead and do the commit. So, it would be more correct from my POV to revert the patch, politely ask
the authors of that patch to speak up, why it was required to reimplement finalizers and weak references support in DRLVM and then start a vote (if there will be anything to vote for) or fix the issues GCv5 authors have with current design present in DRLVM.
Good point. Consider it done. <SNIP>
Regards -- Pavel Pervov, Intel Enterprise Solutions Software Division P.S. BTW, making such commit would prevent us from developing class unloading design which may show way better performance than original design had.
This is valuable insight. Please tell more. -- Weldon Washburn Intel Enterprise Solutions Software Division
