On Fri, Jun 6, 2008 at 1:08 AM, Regis <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Matcher and Assumptions are great ideas! Thanks Nathan.
> They would be very helpful for our new test cases. But I notice that
> Junit 4.4 doesn't support group which is very important feature for
> both old tests and new t
Again, I'll mention that it was a long time ago -- Jul 2006; two years ago.
There has been two years of work on building tests and TestNG wasn't that
compelling then and still isn't that compelling now. I've read many articles
and blog posts like the one you mentioned, but I've yet to actually seen
On Fri, Jun 6, 2008 at 1:43 PM, Aleksey Shipilev <[EMAIL PROTECTED]>
wrote:
> I think adding parent class for java.lang.Thread is against the Java
> spec, as the class hierarchy should be consistent with that documented
> in spec.
If AbstractThread is package-private, it will be consistent w/ th
On Fri, Jun 6, 2008 at 1:43 PM, Aleksey Shipilev <[EMAIL PROTECTED]>
wrote:
> I think adding parent class for java.lang.Thread is against the Java
> spec, as the class hierarchy should be consistent with that documented
> in spec.
If AbstractThread is package-private, it will be consistent w/ th
On Sat, Jun 7, 2008 at 12:32 AM, Bob Lee <[EMAIL PROTECTED]> wrote:
> One thing I mentioned in the bug is that we should consider introducing a
> package-private AbstractThread parent class so we only have to change the
> code in one place.
I think adding parent class for java.lang.Thread is agains
One thing I mentioned in the bug is that we should consider introducing a
package-private AbstractThread parent class so we only have to change the
code in one place.
On Jun 6, 2008 11:50 AM, "Aleksey Shipilev"� wrote:
Thanks for a thoughtful reply, Bob!
Let's get the code to the trunk.
Tim
Thanks for a thoughtful reply, Bob!
Let's get the code to the trunk.
Tim, Mark, Nathan, should we acquire a gold ticket to modify java.lang.Thread?
Thanks,
Aleksey.
On Fri, Jun 6, 2008 at 10:36 PM, Bob Lee <[EMAIL PROTECTED]> wrote:
> On Fri, Jun 6, 2008 at 10:09 AM, Aleksey Shipilev <
> [EMAIL
On Fri, Jun 6, 2008 at 10:09 AM, Aleksey Shipilev <
[EMAIL PROTECTED]> wrote:
> I'm not saying that your implementation is bad. On contrary, your
> implementation is much faster than original Harmony one. What I'm
> saying is, ThreadLocalBench is still 3x slower on Harmony/DRLVM than
> on Sun 1.6.
Bob,
I'm not saying that your implementation is bad. On contrary, your
implementation is much faster than original Harmony one. What I'm
saying is, ThreadLocalBench is still 3x slower on Harmony/DRLVM than
on Sun 1.6.0_05. That might be connected with poor codegeneration on
Harmony JIT, some disab
I'm not sure how you ran it, but I ran MTHarness and Doug Lea's own test
suites on Sun's VM using -server.
Mine was a tad slower on MTHarness (results in bug). In Doug Lea's tests,
the RI and my impl were neck and neck. Josh Bloch ran the same performance
tests on a different machine and saw the s
Tim Ellison wrote:
Bartek Teodorczyk wrote:
2. I'd suggest moving microemulator in SVN one level deeper to the
trunk folder, we'll be able to easy make branches, tags in the future.
I've looked into Harmony repository that is a popular way to organize
"super" modules.
Yep, I'll do that. It wa
Bartek Teodorczyk wrote:
I've collected my initial questions in points:
1. What's the best JIRA component assignment for microemulator issues.
In my opinion, it should be Classlib with [microemulator] prefix, but
if that component is very tightly related to the classlib SVN location
then somethi
On Fri, Jun 6, 2008 at 2:16 PM, Xiao-Feng Li <[EMAIL PROTECTED]> wrote:
>> NB: This patch gives 7.6x boost on MTHarness/ThreadLocalBench and +25%
>> to SPECjvm2008:serial.
> Good numbers! I read the perf is still bad compared to RI? Have you
> any estimation about the reason?
The performance of Thr
On Mon, Jun 2, 2008 at 2:48 PM, Tim Ellison <[EMAIL PROTECTED]> wrote:
> Bartek Teodorczyk wrote:
>>
>> On Tue, May 27, 2008 at 12:56 AM, Tim Ellison <[EMAIL PROTECTED]>
>> wrote:
>>>
>>> Following the successful vote to accept the HARMONY-5742 contribution, I
>>> have made the initial checkin of t
On Fri, Jun 6, 2008 at 5:00 PM, Aleksey Shipilev
<[EMAIL PROTECTED]> wrote:
> Hi Bob, guys!
>
> I had successfully applied Bob's patch for Harmony/DRLVM last night,
> though we need to change java.lang.Thread in luni-kernel. Should we
> discuss this change? Despite the fact my patch defines the sam
I have also noticed that some code will just load the class regardless
the classloader.
Obiviously, we should take the parameter into consideration.
We shall use the classloader from parameter to load class when
processing the xml file.
But I don't think we are required to do "exactly" what RI do.
Ok, thanks!
On Fri, Jun 6, 2008 at 5:30 PM, Sean Qiu (JIRA) <[EMAIL PROTECTED]> wrote:
>
> [
> https://issues.apache.org/jira/browse/HARMONY-5866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel]
>
> Sean Qiu reassigned HARMONY-5866:
> -
>
>
Hi Bob, guys!
I had successfully applied Bob's patch for Harmony/DRLVM last night,
though we need to change java.lang.Thread in luni-kernel. Should we
discuss this change? Despite the fact my patch defines the same fields
in java.lang.Thread of DRLVM, this change might break J9+Harmony.
NB: This
18 matches
Mail list logo
