harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stepan Mishura" <stepan.mish...@gmail.com>
Subject Re: [bti][p-unit] finally, it is ready
Date Tue, 16 Oct 2007 04:18:17 GMT
On 10/15/07, Alexei Fedotov <alexei.fedotov@gmail.com> wrote:
> Stepan,
> Thank you for your attention to this issue.
> Let me define a term we are using first. "VM specific behavior"
> actually is an abstract behavior which is VM specific, and not a
> behavior, which is specific for DRLVM. To make tests flexible for any
> behavior, I've made them looking like performance tests. For reporting
> performance-like metrics p-unit was a viable alternative, see the wiki
> page [1] for comparison. So p-unit integration is not something
> separate from the stress test suite: it suites actual needs.


I'd like to have clear distinction between HARMONY-4114, (according to
the its description - "VM intermittently throws *UNEXPECTED*
OutOfMemoryError on the test which defines heap fragmentation") and
p-unit integration.

IMHO we shouldn't mix patches for different tasks/issues in one JIRA.

> From technical point of view the patch may be split into several
> patches. There is even more interesting alternative to get p-unit as
> an external dependency for our repository.

Yes, please separate them if that possible - it will make easier
understanding changes. Also please provide some relevant comments for
updates. Otherwise, it is hard to understand from comments below that
the patch integrates p-unit:

"28/Sep/07 11:08 AM:
should be applied:
5. harness_test_handler.patch (30 kb)
7. stress.patch (1.12 Mb)

should be executed:
1. add_remove.sh (8 kb) "


> Thanks.
> [1] http://wiki.apache.org/harmony/Harmony_Test_Harness_Comparison
> On 10/15/07, Stepan Mishura <stepan.mishura@gmail.com> wrote:
> > Alexei,
> >
> > Why you attached patches for integrating p-unit to HARMONY-4114 that
> > primary aimed to fix specific VM behaviour? IMHO p-unit integration a
> > different story and needs a separate JIRA to keep things clear. Agree?
> >
> > Thanks,
> > Stepan.
> >

View raw message