You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Ilya Berezhniuk <il...@gmail.com> on 2007/12/09 03:11:26 UTC
Make GC_CC working
Hi All,
Now we have GC_CC inoperable on most platforms - it works on
Windows/x86/release only.
I've checked M3 build, GC_CC works fine (although hangs from time to time).
I suggest committing HARMONY-5247 and HARMONY-5262 patches to fix most
of current GC_CC problems.
The problems are the following:
1) After r583223 threading commit GC_CC does not work in debug mode
because of multiple assertions.
2) After r587472 commit (symbols exporting policy) GC_CC was broken on
Linux because several symbols required by GC_CC were not added to EXP
files.
3) After r599482 commit (uncompressed references) GC_CC works
incorrectly on x86_64 because of changed object layout for 64bit
platforms.
4) GC_CC often hangs in shutdown. HARMONY-5136 has fixed the problem
for GC_GEN, but for GC_CC the problem still exists because of
different GC/Finalizer threads behavior.
HARMONY-5247 patch finally fixes the problem with shutdown deadlock on
ThreadGroup.lock monitor.
HARMONY-5262 patch fixes GC_CC problems 1) - 3).
With both these patches all 'build test' tests are passed on
Windows/Linux x86 and on Linux/x86_64 in both debug and release modes.
On 4-core Windows/x86_64 I've got 4 intermittent failures on debug
build (see details in HARMONY-5262), but these failures are not
reproducible on release build, and they also do not appear on 2-core
machine.
Looks like these failures are caused by some remaining threading
problems in GC_CC.
Since HARMONY-5262 affects only GC_CC, all tests are passed with
GC_GEN on all 4 tested platforms.
I think it's valuable to make GC_CC working, if we are planning to
include it into M4 builds.
Thanks,
Ilya.
Re: Make GC_CC working
Posted by Xiao-Feng Li <xi...@gmail.com>.
It's committed. Who's going to commit HARMONY-5247?
Thanks,
xiaofeng
On Dec 10, 2007 9:12 PM, Alexey Petrenko <al...@gmail.com> wrote:
> Xiao Feng,
>
> is there any updates? :)
>
> SY, Alexey
>
> 2007/12/9, Xiao-Feng Li <xi...@gmail.com>:
>
> > I'd like to have GC_CC in M4. If no objections in 24 hours, I will
> > commit the patch. Thanks. -xiaofeng
> >
> > On Dec 9, 2007 10:11 AM, Ilya Berezhniuk <il...@gmail.com> wrote:
> > > Hi All,
> > >
> > > Now we have GC_CC inoperable on most platforms - it works on
> > > Windows/x86/release only.
> > >
> > > I've checked M3 build, GC_CC works fine (although hangs from time to time).
> > >
> > >
> > > I suggest committing HARMONY-5247 and HARMONY-5262 patches to fix most
> > > of current GC_CC problems.
> > >
> > > The problems are the following:
> > >
> > > 1) After r583223 threading commit GC_CC does not work in debug mode
> > > because of multiple assertions.
> > >
> > > 2) After r587472 commit (symbols exporting policy) GC_CC was broken on
> > > Linux because several symbols required by GC_CC were not added to EXP
> > > files.
> > >
> > > 3) After r599482 commit (uncompressed references) GC_CC works
> > > incorrectly on x86_64 because of changed object layout for 64bit
> > > platforms.
> > >
> > > 4) GC_CC often hangs in shutdown. HARMONY-5136 has fixed the problem
> > > for GC_GEN, but for GC_CC the problem still exists because of
> > > different GC/Finalizer threads behavior.
> > >
> > >
> > > HARMONY-5247 patch finally fixes the problem with shutdown deadlock on
> > > ThreadGroup.lock monitor.
> > >
> > >
> > > HARMONY-5262 patch fixes GC_CC problems 1) - 3).
> > >
> > > With both these patches all 'build test' tests are passed on
> > > Windows/Linux x86 and on Linux/x86_64 in both debug and release modes.
> > >
> > > On 4-core Windows/x86_64 I've got 4 intermittent failures on debug
> > > build (see details in HARMONY-5262), but these failures are not
> > > reproducible on release build, and they also do not appear on 2-core
> > > machine.
> > > Looks like these failures are caused by some remaining threading
> > > problems in GC_CC.
> > >
> > > Since HARMONY-5262 affects only GC_CC, all tests are passed with
> > > GC_GEN on all 4 tested platforms.
> > >
> > >
> > > I think it's valuable to make GC_CC working, if we are planning to
> > > include it into M4 builds.
> > >
> > >
> > > Thanks,
> > > Ilya.
> > >
> >
> >
> >
> > --
> > http://xiao-feng.blogspot.com
> >
>
--
http://xiao-feng.blogspot.com
Re: Make GC_CC working
Posted by Alexey Petrenko <al...@gmail.com>.
Xiao Feng,
is there any updates? :)
SY, Alexey
2007/12/9, Xiao-Feng Li <xi...@gmail.com>:
> I'd like to have GC_CC in M4. If no objections in 24 hours, I will
> commit the patch. Thanks. -xiaofeng
>
> On Dec 9, 2007 10:11 AM, Ilya Berezhniuk <il...@gmail.com> wrote:
> > Hi All,
> >
> > Now we have GC_CC inoperable on most platforms - it works on
> > Windows/x86/release only.
> >
> > I've checked M3 build, GC_CC works fine (although hangs from time to time).
> >
> >
> > I suggest committing HARMONY-5247 and HARMONY-5262 patches to fix most
> > of current GC_CC problems.
> >
> > The problems are the following:
> >
> > 1) After r583223 threading commit GC_CC does not work in debug mode
> > because of multiple assertions.
> >
> > 2) After r587472 commit (symbols exporting policy) GC_CC was broken on
> > Linux because several symbols required by GC_CC were not added to EXP
> > files.
> >
> > 3) After r599482 commit (uncompressed references) GC_CC works
> > incorrectly on x86_64 because of changed object layout for 64bit
> > platforms.
> >
> > 4) GC_CC often hangs in shutdown. HARMONY-5136 has fixed the problem
> > for GC_GEN, but for GC_CC the problem still exists because of
> > different GC/Finalizer threads behavior.
> >
> >
> > HARMONY-5247 patch finally fixes the problem with shutdown deadlock on
> > ThreadGroup.lock monitor.
> >
> >
> > HARMONY-5262 patch fixes GC_CC problems 1) - 3).
> >
> > With both these patches all 'build test' tests are passed on
> > Windows/Linux x86 and on Linux/x86_64 in both debug and release modes.
> >
> > On 4-core Windows/x86_64 I've got 4 intermittent failures on debug
> > build (see details in HARMONY-5262), but these failures are not
> > reproducible on release build, and they also do not appear on 2-core
> > machine.
> > Looks like these failures are caused by some remaining threading
> > problems in GC_CC.
> >
> > Since HARMONY-5262 affects only GC_CC, all tests are passed with
> > GC_GEN on all 4 tested platforms.
> >
> >
> > I think it's valuable to make GC_CC working, if we are planning to
> > include it into M4 builds.
> >
> >
> > Thanks,
> > Ilya.
> >
>
>
>
> --
> http://xiao-feng.blogspot.com
>
Re: Make GC_CC working
Posted by Gregory Shimansky <gs...@apache.org>.
Alexey Varlamov said the following on 10.12.2007 9:33:
> IMO this fix is a must for M4:
> 1) clearly this is a regression and should be fixed within the same
> milestone as we agreed;
> 2) no point to distribute completely broken component in the milestone
> build, so otherwise we'd need to drop the gc_cc from distribution.
>
> As a side note, we unjustly left the gc_cc overboard BTI testing. IMO
> we should include additional mode to DRLVM suites which support
> multi-mode runs (smoke tests and EHWA-api). The only question is do it
> now or let M4 finish...
> I believe it would not impact testing time too much, <20% for those
> suites (AFAIK they currently run 5 modes: jet,jit,opt,srv,int). Name
> it "gc41" ?
+1 to include gc_cc into regular testing. I think inclusion may wait
until after M4 since according to Ilya there are still some bugs
remaining when using gc_cc.
> 2007/12/9, Ilya Berezhniuk <il...@gmail.com>:
>> Thanks Xiao Feng.
>>
>> But 24h later will be Monday, so '2 committers approval' is required
>> to check in the patches.
>>
>> Committers,
>> please support the patches if no objections :)
>>
>> Thanks,
>> Ilya.
>>
>> 2007/12/9, Xiao-Feng Li <xi...@gmail.com>:
>>> I'd like to have GC_CC in M4. If no objections in 24 hours, I will
>>> commit the patch. Thanks. -xiaofeng
>>>
>>> On Dec 9, 2007 10:11 AM, Ilya Berezhniuk <il...@gmail.com> wrote:
>>>> Hi All,
>>>>
>>>> Now we have GC_CC inoperable on most platforms - it works on
>>>> Windows/x86/release only.
>>>>
>>>> I've checked M3 build, GC_CC works fine (although hangs from time to time).
>>>>
>>>>
>>>> I suggest committing HARMONY-5247 and HARMONY-5262 patches to fix most
>>>> of current GC_CC problems.
>>>>
>>>> The problems are the following:
>>>>
>>>> 1) After r583223 threading commit GC_CC does not work in debug mode
>>>> because of multiple assertions.
>>>>
>>>> 2) After r587472 commit (symbols exporting policy) GC_CC was broken on
>>>> Linux because several symbols required by GC_CC were not added to EXP
>>>> files.
>>>>
>>>> 3) After r599482 commit (uncompressed references) GC_CC works
>>>> incorrectly on x86_64 because of changed object layout for 64bit
>>>> platforms.
>>>>
>>>> 4) GC_CC often hangs in shutdown. HARMONY-5136 has fixed the problem
>>>> for GC_GEN, but for GC_CC the problem still exists because of
>>>> different GC/Finalizer threads behavior.
>>>>
>>>>
>>>> HARMONY-5247 patch finally fixes the problem with shutdown deadlock on
>>>> ThreadGroup.lock monitor.
>>>>
>>>>
>>>> HARMONY-5262 patch fixes GC_CC problems 1) - 3).
>>>>
>>>> With both these patches all 'build test' tests are passed on
>>>> Windows/Linux x86 and on Linux/x86_64 in both debug and release modes.
>>>>
>>>> On 4-core Windows/x86_64 I've got 4 intermittent failures on debug
>>>> build (see details in HARMONY-5262), but these failures are not
>>>> reproducible on release build, and they also do not appear on 2-core
>>>> machine.
>>>> Looks like these failures are caused by some remaining threading
>>>> problems in GC_CC.
>>>>
>>>> Since HARMONY-5262 affects only GC_CC, all tests are passed with
>>>> GC_GEN on all 4 tested platforms.
>>>>
>>>>
>>>> I think it's valuable to make GC_CC working, if we are planning to
>>>> include it into M4 builds.
>>>>
>>>>
>>>> Thanks,
>>>> Ilya.
>>>>
>>>
>>>
>>> --
>>> http://xiao-feng.blogspot.com
>>>
Re: Make GC_CC working
Posted by Alexey Varlamov <al...@gmail.com>.
IMO this fix is a must for M4:
1) clearly this is a regression and should be fixed within the same
milestone as we agreed;
2) no point to distribute completely broken component in the milestone
build, so otherwise we'd need to drop the gc_cc from distribution.
As a side note, we unjustly left the gc_cc overboard BTI testing. IMO
we should include additional mode to DRLVM suites which support
multi-mode runs (smoke tests and EHWA-api). The only question is do it
now or let M4 finish...
I believe it would not impact testing time too much, <20% for those
suites (AFAIK they currently run 5 modes: jet,jit,opt,srv,int). Name
it "gc41" ?
--
Thanks,
Alexey
2007/12/9, Ilya Berezhniuk <il...@gmail.com>:
> Thanks Xiao Feng.
>
> But 24h later will be Monday, so '2 committers approval' is required
> to check in the patches.
>
> Committers,
> please support the patches if no objections :)
>
> Thanks,
> Ilya.
>
> 2007/12/9, Xiao-Feng Li <xi...@gmail.com>:
> > I'd like to have GC_CC in M4. If no objections in 24 hours, I will
> > commit the patch. Thanks. -xiaofeng
> >
> > On Dec 9, 2007 10:11 AM, Ilya Berezhniuk <il...@gmail.com> wrote:
> > > Hi All,
> > >
> > > Now we have GC_CC inoperable on most platforms - it works on
> > > Windows/x86/release only.
> > >
> > > I've checked M3 build, GC_CC works fine (although hangs from time to time).
> > >
> > >
> > > I suggest committing HARMONY-5247 and HARMONY-5262 patches to fix most
> > > of current GC_CC problems.
> > >
> > > The problems are the following:
> > >
> > > 1) After r583223 threading commit GC_CC does not work in debug mode
> > > because of multiple assertions.
> > >
> > > 2) After r587472 commit (symbols exporting policy) GC_CC was broken on
> > > Linux because several symbols required by GC_CC were not added to EXP
> > > files.
> > >
> > > 3) After r599482 commit (uncompressed references) GC_CC works
> > > incorrectly on x86_64 because of changed object layout for 64bit
> > > platforms.
> > >
> > > 4) GC_CC often hangs in shutdown. HARMONY-5136 has fixed the problem
> > > for GC_GEN, but for GC_CC the problem still exists because of
> > > different GC/Finalizer threads behavior.
> > >
> > >
> > > HARMONY-5247 patch finally fixes the problem with shutdown deadlock on
> > > ThreadGroup.lock monitor.
> > >
> > >
> > > HARMONY-5262 patch fixes GC_CC problems 1) - 3).
> > >
> > > With both these patches all 'build test' tests are passed on
> > > Windows/Linux x86 and on Linux/x86_64 in both debug and release modes.
> > >
> > > On 4-core Windows/x86_64 I've got 4 intermittent failures on debug
> > > build (see details in HARMONY-5262), but these failures are not
> > > reproducible on release build, and they also do not appear on 2-core
> > > machine.
> > > Looks like these failures are caused by some remaining threading
> > > problems in GC_CC.
> > >
> > > Since HARMONY-5262 affects only GC_CC, all tests are passed with
> > > GC_GEN on all 4 tested platforms.
> > >
> > >
> > > I think it's valuable to make GC_CC working, if we are planning to
> > > include it into M4 builds.
> > >
> > >
> > > Thanks,
> > > Ilya.
> > >
> >
> >
> >
> > --
> > http://xiao-feng.blogspot.com
> >
>
Re: Make GC_CC working
Posted by Ilya Berezhniuk <il...@gmail.com>.
Thanks Xiao Feng.
But 24h later will be Monday, so '2 committers approval' is required
to check in the patches.
Committers,
please support the patches if no objections :)
Thanks,
Ilya.
2007/12/9, Xiao-Feng Li <xi...@gmail.com>:
> I'd like to have GC_CC in M4. If no objections in 24 hours, I will
> commit the patch. Thanks. -xiaofeng
>
> On Dec 9, 2007 10:11 AM, Ilya Berezhniuk <il...@gmail.com> wrote:
> > Hi All,
> >
> > Now we have GC_CC inoperable on most platforms - it works on
> > Windows/x86/release only.
> >
> > I've checked M3 build, GC_CC works fine (although hangs from time to time).
> >
> >
> > I suggest committing HARMONY-5247 and HARMONY-5262 patches to fix most
> > of current GC_CC problems.
> >
> > The problems are the following:
> >
> > 1) After r583223 threading commit GC_CC does not work in debug mode
> > because of multiple assertions.
> >
> > 2) After r587472 commit (symbols exporting policy) GC_CC was broken on
> > Linux because several symbols required by GC_CC were not added to EXP
> > files.
> >
> > 3) After r599482 commit (uncompressed references) GC_CC works
> > incorrectly on x86_64 because of changed object layout for 64bit
> > platforms.
> >
> > 4) GC_CC often hangs in shutdown. HARMONY-5136 has fixed the problem
> > for GC_GEN, but for GC_CC the problem still exists because of
> > different GC/Finalizer threads behavior.
> >
> >
> > HARMONY-5247 patch finally fixes the problem with shutdown deadlock on
> > ThreadGroup.lock monitor.
> >
> >
> > HARMONY-5262 patch fixes GC_CC problems 1) - 3).
> >
> > With both these patches all 'build test' tests are passed on
> > Windows/Linux x86 and on Linux/x86_64 in both debug and release modes.
> >
> > On 4-core Windows/x86_64 I've got 4 intermittent failures on debug
> > build (see details in HARMONY-5262), but these failures are not
> > reproducible on release build, and they also do not appear on 2-core
> > machine.
> > Looks like these failures are caused by some remaining threading
> > problems in GC_CC.
> >
> > Since HARMONY-5262 affects only GC_CC, all tests are passed with
> > GC_GEN on all 4 tested platforms.
> >
> >
> > I think it's valuable to make GC_CC working, if we are planning to
> > include it into M4 builds.
> >
> >
> > Thanks,
> > Ilya.
> >
>
>
>
> --
> http://xiao-feng.blogspot.com
>
Re: Make GC_CC working
Posted by Xiao-Feng Li <xi...@gmail.com>.
I'd like to have GC_CC in M4. If no objections in 24 hours, I will
commit the patch. Thanks. -xiaofeng
On Dec 9, 2007 10:11 AM, Ilya Berezhniuk <il...@gmail.com> wrote:
> Hi All,
>
> Now we have GC_CC inoperable on most platforms - it works on
> Windows/x86/release only.
>
> I've checked M3 build, GC_CC works fine (although hangs from time to time).
>
>
> I suggest committing HARMONY-5247 and HARMONY-5262 patches to fix most
> of current GC_CC problems.
>
> The problems are the following:
>
> 1) After r583223 threading commit GC_CC does not work in debug mode
> because of multiple assertions.
>
> 2) After r587472 commit (symbols exporting policy) GC_CC was broken on
> Linux because several symbols required by GC_CC were not added to EXP
> files.
>
> 3) After r599482 commit (uncompressed references) GC_CC works
> incorrectly on x86_64 because of changed object layout for 64bit
> platforms.
>
> 4) GC_CC often hangs in shutdown. HARMONY-5136 has fixed the problem
> for GC_GEN, but for GC_CC the problem still exists because of
> different GC/Finalizer threads behavior.
>
>
> HARMONY-5247 patch finally fixes the problem with shutdown deadlock on
> ThreadGroup.lock monitor.
>
>
> HARMONY-5262 patch fixes GC_CC problems 1) - 3).
>
> With both these patches all 'build test' tests are passed on
> Windows/Linux x86 and on Linux/x86_64 in both debug and release modes.
>
> On 4-core Windows/x86_64 I've got 4 intermittent failures on debug
> build (see details in HARMONY-5262), but these failures are not
> reproducible on release build, and they also do not appear on 2-core
> machine.
> Looks like these failures are caused by some remaining threading
> problems in GC_CC.
>
> Since HARMONY-5262 affects only GC_CC, all tests are passed with
> GC_GEN on all 4 tested platforms.
>
>
> I think it's valuable to make GC_CC working, if we are planning to
> include it into M4 builds.
>
>
> Thanks,
> Ilya.
>
--
http://xiao-feng.blogspot.com
Re: Make GC_CC working
Posted by Pavel Rebriy <pa...@gmail.com>.
Thank you, Xiao Feng! I think it help us to avoid several problems on
shutdown.
On 11/12/2007, Ilya Berezhniuk <il...@gmail.com> wrote:
>
> Thanks a lot, Xiao Feng!
>
> 2007/12/11, Xiao-Feng Li <xi...@gmail.com>:
> > I've committed H5247.
> >
> > On Dec 10, 2007 10:21 PM, Ilya Berezhniuk <il...@gmail.com>
> wrote:
> > > Xiao Feng, thanks for committing HARMONY-5262.
> > >
> > > But HARMONY-5262 is insufficient to enable GC_CC; tests are often hang
> > > in shutdown.
> > > HARMONY-5247 is also required.
> > >
> > > Who will commit it?
> > >
> > >
> > > Thanks,
> > > Ilya.
> > >
> > > 2007/12/10, Xiao-Feng Li <xi...@gmail.com>:
> > >
> > > > I think a reasonable plan for GC_CC is to keep it from regressing
> for
> > > > certain sets of tests such as smoke, kernel, regression. There will
> be
> > > > no further improvement for it. When there is another well-supported
> GC
> > > > in future, say GC_NEW, then we can decide if we still want to keep
> > > > GC_CC.
> > > >
> > > > Thanks,
> > > > xiaofeng
> > > >
> > > > On Dec 10, 2007 9:09 PM, Alexey Petrenko <
> alexey.a.petrenko@gmail.com> wrote:
> > > > > What are our future plans about GC_CC? Do we plan to continue
> support it?
> > > > >
> > > > > SY, Alexey
> > > > >
> > > > > 2007/12/9, Ilya Berezhniuk <il...@gmail.com>:
> > > > >
> > > > > > Hi All,
> > > > > >
> > > > > > Now we have GC_CC inoperable on most platforms - it works on
> > > > > > Windows/x86/release only.
> > > > > >
> > > > > > I've checked M3 build, GC_CC works fine (although hangs from
> time to time).
> > > > > >
> > > > > >
> > > > > > I suggest committing HARMONY-5247 and HARMONY-5262 patches to
> fix most
> > > > > > of current GC_CC problems.
> > > > > >
> > > > > > The problems are the following:
> > > > > >
> > > > > > 1) After r583223 threading commit GC_CC does not work in debug
> mode
> > > > > > because of multiple assertions.
> > > > > >
> > > > > > 2) After r587472 commit (symbols exporting policy) GC_CC was
> broken on
> > > > > > Linux because several symbols required by GC_CC were not added
> to EXP
> > > > > > files.
> > > > > >
> > > > > > 3) After r599482 commit (uncompressed references) GC_CC works
> > > > > > incorrectly on x86_64 because of changed object layout for 64bit
> > > > > > platforms.
> > > > > >
> > > > > > 4) GC_CC often hangs in shutdown. HARMONY-5136 has fixed the
> problem
> > > > > > for GC_GEN, but for GC_CC the problem still exists because of
> > > > > > different GC/Finalizer threads behavior.
> > > > > >
> > > > > >
> > > > > > HARMONY-5247 patch finally fixes the problem with shutdown
> deadlock on
> > > > > > ThreadGroup.lock monitor.
> > > > > >
> > > > > >
> > > > > > HARMONY-5262 patch fixes GC_CC problems 1) - 3).
> > > > > >
> > > > > > With both these patches all 'build test' tests are passed on
> > > > > > Windows/Linux x86 and on Linux/x86_64 in both debug and release
> modes.
> > > > > >
> > > > > > On 4-core Windows/x86_64 I've got 4 intermittent failures on
> debug
> > > > > > build (see details in HARMONY-5262), but these failures are not
> > > > > > reproducible on release build, and they also do not appear on
> 2-core
> > > > > > machine.
> > > > > > Looks like these failures are caused by some remaining threading
> > > > > > problems in GC_CC.
> > > > > >
> > > > > > Since HARMONY-5262 affects only GC_CC, all tests are passed with
> > > > > > GC_GEN on all 4 tested platforms.
> > > > > >
> > > > > >
> > > > > > I think it's valuable to make GC_CC working, if we are planning
> to
> > > > > > include it into M4 builds.
> > > > > >
> > > > > >
> > > > > > Thanks,
> > > > > > Ilya.
> > > > > >
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > http://xiao-feng.blogspot.com
> > > >
> > >
> >
> >
> >
> > --
> > http://xiao-feng.blogspot.com
> >
>
>
> --
>
> Ilya
>
--
Best regards,
Pavel Rebriy
Re: Make GC_CC working
Posted by Ilya Berezhniuk <il...@gmail.com>.
Thanks a lot, Xiao Feng!
2007/12/11, Xiao-Feng Li <xi...@gmail.com>:
> I've committed H5247.
>
> On Dec 10, 2007 10:21 PM, Ilya Berezhniuk <il...@gmail.com> wrote:
> > Xiao Feng, thanks for committing HARMONY-5262.
> >
> > But HARMONY-5262 is insufficient to enable GC_CC; tests are often hang
> > in shutdown.
> > HARMONY-5247 is also required.
> >
> > Who will commit it?
> >
> >
> > Thanks,
> > Ilya.
> >
> > 2007/12/10, Xiao-Feng Li <xi...@gmail.com>:
> >
> > > I think a reasonable plan for GC_CC is to keep it from regressing for
> > > certain sets of tests such as smoke, kernel, regression. There will be
> > > no further improvement for it. When there is another well-supported GC
> > > in future, say GC_NEW, then we can decide if we still want to keep
> > > GC_CC.
> > >
> > > Thanks,
> > > xiaofeng
> > >
> > > On Dec 10, 2007 9:09 PM, Alexey Petrenko <al...@gmail.com> wrote:
> > > > What are our future plans about GC_CC? Do we plan to continue support it?
> > > >
> > > > SY, Alexey
> > > >
> > > > 2007/12/9, Ilya Berezhniuk <il...@gmail.com>:
> > > >
> > > > > Hi All,
> > > > >
> > > > > Now we have GC_CC inoperable on most platforms - it works on
> > > > > Windows/x86/release only.
> > > > >
> > > > > I've checked M3 build, GC_CC works fine (although hangs from time to time).
> > > > >
> > > > >
> > > > > I suggest committing HARMONY-5247 and HARMONY-5262 patches to fix most
> > > > > of current GC_CC problems.
> > > > >
> > > > > The problems are the following:
> > > > >
> > > > > 1) After r583223 threading commit GC_CC does not work in debug mode
> > > > > because of multiple assertions.
> > > > >
> > > > > 2) After r587472 commit (symbols exporting policy) GC_CC was broken on
> > > > > Linux because several symbols required by GC_CC were not added to EXP
> > > > > files.
> > > > >
> > > > > 3) After r599482 commit (uncompressed references) GC_CC works
> > > > > incorrectly on x86_64 because of changed object layout for 64bit
> > > > > platforms.
> > > > >
> > > > > 4) GC_CC often hangs in shutdown. HARMONY-5136 has fixed the problem
> > > > > for GC_GEN, but for GC_CC the problem still exists because of
> > > > > different GC/Finalizer threads behavior.
> > > > >
> > > > >
> > > > > HARMONY-5247 patch finally fixes the problem with shutdown deadlock on
> > > > > ThreadGroup.lock monitor.
> > > > >
> > > > >
> > > > > HARMONY-5262 patch fixes GC_CC problems 1) - 3).
> > > > >
> > > > > With both these patches all 'build test' tests are passed on
> > > > > Windows/Linux x86 and on Linux/x86_64 in both debug and release modes.
> > > > >
> > > > > On 4-core Windows/x86_64 I've got 4 intermittent failures on debug
> > > > > build (see details in HARMONY-5262), but these failures are not
> > > > > reproducible on release build, and they also do not appear on 2-core
> > > > > machine.
> > > > > Looks like these failures are caused by some remaining threading
> > > > > problems in GC_CC.
> > > > >
> > > > > Since HARMONY-5262 affects only GC_CC, all tests are passed with
> > > > > GC_GEN on all 4 tested platforms.
> > > > >
> > > > >
> > > > > I think it's valuable to make GC_CC working, if we are planning to
> > > > > include it into M4 builds.
> > > > >
> > > > >
> > > > > Thanks,
> > > > > Ilya.
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > > http://xiao-feng.blogspot.com
> > >
> >
>
>
>
> --
> http://xiao-feng.blogspot.com
>
--
Ilya
Re: Make GC_CC working
Posted by Xiao-Feng Li <xi...@gmail.com>.
I've committed H5247.
On Dec 10, 2007 10:21 PM, Ilya Berezhniuk <il...@gmail.com> wrote:
> Xiao Feng, thanks for committing HARMONY-5262.
>
> But HARMONY-5262 is insufficient to enable GC_CC; tests are often hang
> in shutdown.
> HARMONY-5247 is also required.
>
> Who will commit it?
>
>
> Thanks,
> Ilya.
>
> 2007/12/10, Xiao-Feng Li <xi...@gmail.com>:
>
> > I think a reasonable plan for GC_CC is to keep it from regressing for
> > certain sets of tests such as smoke, kernel, regression. There will be
> > no further improvement for it. When there is another well-supported GC
> > in future, say GC_NEW, then we can decide if we still want to keep
> > GC_CC.
> >
> > Thanks,
> > xiaofeng
> >
> > On Dec 10, 2007 9:09 PM, Alexey Petrenko <al...@gmail.com> wrote:
> > > What are our future plans about GC_CC? Do we plan to continue support it?
> > >
> > > SY, Alexey
> > >
> > > 2007/12/9, Ilya Berezhniuk <il...@gmail.com>:
> > >
> > > > Hi All,
> > > >
> > > > Now we have GC_CC inoperable on most platforms - it works on
> > > > Windows/x86/release only.
> > > >
> > > > I've checked M3 build, GC_CC works fine (although hangs from time to time).
> > > >
> > > >
> > > > I suggest committing HARMONY-5247 and HARMONY-5262 patches to fix most
> > > > of current GC_CC problems.
> > > >
> > > > The problems are the following:
> > > >
> > > > 1) After r583223 threading commit GC_CC does not work in debug mode
> > > > because of multiple assertions.
> > > >
> > > > 2) After r587472 commit (symbols exporting policy) GC_CC was broken on
> > > > Linux because several symbols required by GC_CC were not added to EXP
> > > > files.
> > > >
> > > > 3) After r599482 commit (uncompressed references) GC_CC works
> > > > incorrectly on x86_64 because of changed object layout for 64bit
> > > > platforms.
> > > >
> > > > 4) GC_CC often hangs in shutdown. HARMONY-5136 has fixed the problem
> > > > for GC_GEN, but for GC_CC the problem still exists because of
> > > > different GC/Finalizer threads behavior.
> > > >
> > > >
> > > > HARMONY-5247 patch finally fixes the problem with shutdown deadlock on
> > > > ThreadGroup.lock monitor.
> > > >
> > > >
> > > > HARMONY-5262 patch fixes GC_CC problems 1) - 3).
> > > >
> > > > With both these patches all 'build test' tests are passed on
> > > > Windows/Linux x86 and on Linux/x86_64 in both debug and release modes.
> > > >
> > > > On 4-core Windows/x86_64 I've got 4 intermittent failures on debug
> > > > build (see details in HARMONY-5262), but these failures are not
> > > > reproducible on release build, and they also do not appear on 2-core
> > > > machine.
> > > > Looks like these failures are caused by some remaining threading
> > > > problems in GC_CC.
> > > >
> > > > Since HARMONY-5262 affects only GC_CC, all tests are passed with
> > > > GC_GEN on all 4 tested platforms.
> > > >
> > > >
> > > > I think it's valuable to make GC_CC working, if we are planning to
> > > > include it into M4 builds.
> > > >
> > > >
> > > > Thanks,
> > > > Ilya.
> > > >
> > >
> >
> >
> >
> > --
> > http://xiao-feng.blogspot.com
> >
>
--
http://xiao-feng.blogspot.com
Re: Make GC_CC working
Posted by Rana Dasgupta <rd...@gmail.com>.
5247 looks like a reasonable solution. Weldon was committing threading
patches. If he is not around, someone else should do it.
As a non default gc, for the dll to be to be included in M4, gc_cc needs to
pass smoke/kernel tests in default mode on all the platforms. I don't think
anything more is needed.
On Dec 10, 2007 7:21 AM, Ilya Berezhniuk <il...@gmail.com> wrote:
> Xiao Feng, thanks for committing HARMONY-5262.
>
> But HARMONY-5262 is insufficient to enable GC_CC; tests are often hang
> in shutdown.
> HARMONY-5247 is also required.
>
> Who will commit it?
>
>
> Thanks,
> Ilya.
>
> 2007/12/10, Xiao-Feng Li <xi...@gmail.com>:
> > I think a reasonable plan for GC_CC is to keep it from regressing for
> > certain sets of tests such as smoke, kernel, regression. There will be
> > no further improvement for it. When there is another well-supported GC
> > in future, say GC_NEW, then we can decide if we still want to keep
> > GC_CC.
> >
> > Thanks,
> > xiaofeng
> >
> > On Dec 10, 2007 9:09 PM, Alexey Petrenko <al...@gmail.com>
> wrote:
> > > What are our future plans about GC_CC? Do we plan to continue support
> it?
> > >
> > > SY, Alexey
> > >
> > > 2007/12/9, Ilya Berezhniuk <il...@gmail.com>:
> > >
> > > > Hi All,
> > > >
> > > > Now we have GC_CC inoperable on most platforms - it works on
> > > > Windows/x86/release only.
> > > >
> > > > I've checked M3 build, GC_CC works fine (although hangs from time to
> time).
> > > >
> > > >
> > > > I suggest committing HARMONY-5247 and HARMONY-5262 patches to fix
> most
> > > > of current GC_CC problems.
> > > >
> > > > The problems are the following:
> > > >
> > > > 1) After r583223 threading commit GC_CC does not work in debug mode
> > > > because of multiple assertions.
> > > >
> > > > 2) After r587472 commit (symbols exporting policy) GC_CC was broken
> on
> > > > Linux because several symbols required by GC_CC were not added to
> EXP
> > > > files.
> > > >
> > > > 3) After r599482 commit (uncompressed references) GC_CC works
> > > > incorrectly on x86_64 because of changed object layout for 64bit
> > > > platforms.
> > > >
> > > > 4) GC_CC often hangs in shutdown. HARMONY-5136 has fixed the problem
> > > > for GC_GEN, but for GC_CC the problem still exists because of
> > > > different GC/Finalizer threads behavior.
> > > >
> > > >
> > > > HARMONY-5247 patch finally fixes the problem with shutdown deadlock
> on
> > > > ThreadGroup.lock monitor.
> > > >
> > > >
> > > > HARMONY-5262 patch fixes GC_CC problems 1) - 3).
> > > >
> > > > With both these patches all 'build test' tests are passed on
> > > > Windows/Linux x86 and on Linux/x86_64 in both debug and release
> modes.
> > > >
> > > > On 4-core Windows/x86_64 I've got 4 intermittent failures on debug
> > > > build (see details in HARMONY-5262), but these failures are not
> > > > reproducible on release build, and they also do not appear on 2-core
> > > > machine.
> > > > Looks like these failures are caused by some remaining threading
> > > > problems in GC_CC.
> > > >
> > > > Since HARMONY-5262 affects only GC_CC, all tests are passed with
> > > > GC_GEN on all 4 tested platforms.
> > > >
> > > >
> > > > I think it's valuable to make GC_CC working, if we are planning to
> > > > include it into M4 builds.
> > > >
> > > >
> > > > Thanks,
> > > > Ilya.
> > > >
> > >
> >
> >
> >
> > --
> > http://xiao-feng.blogspot.com
> >
>
Re: Make GC_CC working
Posted by Ilya Berezhniuk <il...@gmail.com>.
Xiao Feng, thanks for committing HARMONY-5262.
But HARMONY-5262 is insufficient to enable GC_CC; tests are often hang
in shutdown.
HARMONY-5247 is also required.
Who will commit it?
Thanks,
Ilya.
2007/12/10, Xiao-Feng Li <xi...@gmail.com>:
> I think a reasonable plan for GC_CC is to keep it from regressing for
> certain sets of tests such as smoke, kernel, regression. There will be
> no further improvement for it. When there is another well-supported GC
> in future, say GC_NEW, then we can decide if we still want to keep
> GC_CC.
>
> Thanks,
> xiaofeng
>
> On Dec 10, 2007 9:09 PM, Alexey Petrenko <al...@gmail.com> wrote:
> > What are our future plans about GC_CC? Do we plan to continue support it?
> >
> > SY, Alexey
> >
> > 2007/12/9, Ilya Berezhniuk <il...@gmail.com>:
> >
> > > Hi All,
> > >
> > > Now we have GC_CC inoperable on most platforms - it works on
> > > Windows/x86/release only.
> > >
> > > I've checked M3 build, GC_CC works fine (although hangs from time to time).
> > >
> > >
> > > I suggest committing HARMONY-5247 and HARMONY-5262 patches to fix most
> > > of current GC_CC problems.
> > >
> > > The problems are the following:
> > >
> > > 1) After r583223 threading commit GC_CC does not work in debug mode
> > > because of multiple assertions.
> > >
> > > 2) After r587472 commit (symbols exporting policy) GC_CC was broken on
> > > Linux because several symbols required by GC_CC were not added to EXP
> > > files.
> > >
> > > 3) After r599482 commit (uncompressed references) GC_CC works
> > > incorrectly on x86_64 because of changed object layout for 64bit
> > > platforms.
> > >
> > > 4) GC_CC often hangs in shutdown. HARMONY-5136 has fixed the problem
> > > for GC_GEN, but for GC_CC the problem still exists because of
> > > different GC/Finalizer threads behavior.
> > >
> > >
> > > HARMONY-5247 patch finally fixes the problem with shutdown deadlock on
> > > ThreadGroup.lock monitor.
> > >
> > >
> > > HARMONY-5262 patch fixes GC_CC problems 1) - 3).
> > >
> > > With both these patches all 'build test' tests are passed on
> > > Windows/Linux x86 and on Linux/x86_64 in both debug and release modes.
> > >
> > > On 4-core Windows/x86_64 I've got 4 intermittent failures on debug
> > > build (see details in HARMONY-5262), but these failures are not
> > > reproducible on release build, and they also do not appear on 2-core
> > > machine.
> > > Looks like these failures are caused by some remaining threading
> > > problems in GC_CC.
> > >
> > > Since HARMONY-5262 affects only GC_CC, all tests are passed with
> > > GC_GEN on all 4 tested platforms.
> > >
> > >
> > > I think it's valuable to make GC_CC working, if we are planning to
> > > include it into M4 builds.
> > >
> > >
> > > Thanks,
> > > Ilya.
> > >
> >
>
>
>
> --
> http://xiao-feng.blogspot.com
>
Re: Make GC_CC working
Posted by Xiao-Feng Li <xi...@gmail.com>.
I think a reasonable plan for GC_CC is to keep it from regressing for
certain sets of tests such as smoke, kernel, regression. There will be
no further improvement for it. When there is another well-supported GC
in future, say GC_NEW, then we can decide if we still want to keep
GC_CC.
Thanks,
xiaofeng
On Dec 10, 2007 9:09 PM, Alexey Petrenko <al...@gmail.com> wrote:
> What are our future plans about GC_CC? Do we plan to continue support it?
>
> SY, Alexey
>
> 2007/12/9, Ilya Berezhniuk <il...@gmail.com>:
>
> > Hi All,
> >
> > Now we have GC_CC inoperable on most platforms - it works on
> > Windows/x86/release only.
> >
> > I've checked M3 build, GC_CC works fine (although hangs from time to time).
> >
> >
> > I suggest committing HARMONY-5247 and HARMONY-5262 patches to fix most
> > of current GC_CC problems.
> >
> > The problems are the following:
> >
> > 1) After r583223 threading commit GC_CC does not work in debug mode
> > because of multiple assertions.
> >
> > 2) After r587472 commit (symbols exporting policy) GC_CC was broken on
> > Linux because several symbols required by GC_CC were not added to EXP
> > files.
> >
> > 3) After r599482 commit (uncompressed references) GC_CC works
> > incorrectly on x86_64 because of changed object layout for 64bit
> > platforms.
> >
> > 4) GC_CC often hangs in shutdown. HARMONY-5136 has fixed the problem
> > for GC_GEN, but for GC_CC the problem still exists because of
> > different GC/Finalizer threads behavior.
> >
> >
> > HARMONY-5247 patch finally fixes the problem with shutdown deadlock on
> > ThreadGroup.lock monitor.
> >
> >
> > HARMONY-5262 patch fixes GC_CC problems 1) - 3).
> >
> > With both these patches all 'build test' tests are passed on
> > Windows/Linux x86 and on Linux/x86_64 in both debug and release modes.
> >
> > On 4-core Windows/x86_64 I've got 4 intermittent failures on debug
> > build (see details in HARMONY-5262), but these failures are not
> > reproducible on release build, and they also do not appear on 2-core
> > machine.
> > Looks like these failures are caused by some remaining threading
> > problems in GC_CC.
> >
> > Since HARMONY-5262 affects only GC_CC, all tests are passed with
> > GC_GEN on all 4 tested platforms.
> >
> >
> > I think it's valuable to make GC_CC working, if we are planning to
> > include it into M4 builds.
> >
> >
> > Thanks,
> > Ilya.
> >
>
--
http://xiao-feng.blogspot.com
Re: Make GC_CC working
Posted by Alexey Petrenko <al...@gmail.com>.
What are our future plans about GC_CC? Do we plan to continue support it?
SY, Alexey
2007/12/9, Ilya Berezhniuk <il...@gmail.com>:
> Hi All,
>
> Now we have GC_CC inoperable on most platforms - it works on
> Windows/x86/release only.
>
> I've checked M3 build, GC_CC works fine (although hangs from time to time).
>
>
> I suggest committing HARMONY-5247 and HARMONY-5262 patches to fix most
> of current GC_CC problems.
>
> The problems are the following:
>
> 1) After r583223 threading commit GC_CC does not work in debug mode
> because of multiple assertions.
>
> 2) After r587472 commit (symbols exporting policy) GC_CC was broken on
> Linux because several symbols required by GC_CC were not added to EXP
> files.
>
> 3) After r599482 commit (uncompressed references) GC_CC works
> incorrectly on x86_64 because of changed object layout for 64bit
> platforms.
>
> 4) GC_CC often hangs in shutdown. HARMONY-5136 has fixed the problem
> for GC_GEN, but for GC_CC the problem still exists because of
> different GC/Finalizer threads behavior.
>
>
> HARMONY-5247 patch finally fixes the problem with shutdown deadlock on
> ThreadGroup.lock monitor.
>
>
> HARMONY-5262 patch fixes GC_CC problems 1) - 3).
>
> With both these patches all 'build test' tests are passed on
> Windows/Linux x86 and on Linux/x86_64 in both debug and release modes.
>
> On 4-core Windows/x86_64 I've got 4 intermittent failures on debug
> build (see details in HARMONY-5262), but these failures are not
> reproducible on release build, and they also do not appear on 2-core
> machine.
> Looks like these failures are caused by some remaining threading
> problems in GC_CC.
>
> Since HARMONY-5262 affects only GC_CC, all tests are passed with
> GC_GEN on all 4 tested platforms.
>
>
> I think it's valuable to make GC_CC working, if we are planning to
> include it into M4 builds.
>
>
> Thanks,
> Ilya.
>