Refactoring Pros:
* more "logical" structure, looking cool
Refactoring Cons:
* takes time
* "cool" look does not help to read the code
* more interfaces, possible code duplication
* many old patches become outdated because of massive file renaming
So, I am (-1) for that kind of refactoring.
I fe
Good job, Daniel!
--
Alexey A. Ivanov
Intel Middleware Product Division
>-Original Message-
>From: Daniel Fridlender [mailto:[EMAIL PROTECTED]
>Sent: Tuesday, November 07, 2006 3:22 AM
>To: harmony-dev@incubator.apache.org
>Subject: Re: [classlib][java.math] optimization of BigInteger.mo
Daniel,
These results looks really cool!
Could you please add this data or a link to this thread to the
corresponding issue?
And I'll look into the issue and applly it.
SY, Alexey
2006/11/7, Daniel Fridlender <[EMAIL PROTECTED]>:
Hi Alexey,
yes we often tested the speed in our several attemp
2006/11/7, Gregory Shimansky <[EMAIL PROTECTED]>:
Weldon Washburn wrote:
> Folks,
>
> I have spent the last two months committing patches to the VM. While we
> have added a ton of much needed functionality, the stability of the system
> has been ignored. By chance, I looked at thread synchroniz
On the 0x216 day of Apache Harmony Konstantin Anisimov wrote:
> Hi all,
>
> I suggest new patch from the series Igor introdusced.
> 1. To move direct predicated calls in separete node. It allows to have under
> predicate short branch instruction instead of call and thus
>reduce possible mispre
-1 to separating Jitrino.JET and Jitrino.OPT.
As Mikhail and Alex said, JET and OPT share their code in many areas. So, to
achieve true modularity separating them we'll need either to duplicate
shared code or "externalize" internal JIT interfaces. The former is
definitely bad and the latter implie
On 11/6/06, Tony Wu <[EMAIL PROTECTED]> wrote:
A bad news, ICU team refused to support UnicodeBig because it is not
available in nio.
A good news is that I realize there is a smooth way to support these
charsets. I tried to implement a SPI to accept the name "UnicodeBig"
and it worked. We could
On 11/7/06, Nathan Beyer <[EMAIL PROTECTED]> wrote:
On 11/6/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
>
>
> Paulex Yang wrote:
> > Geir Magnusson Jr. wrote:
> >>
> >>
> >> Paulex Yang wrote:
> >>> Geir Magnusson Jr. wrote:
> did we decide not to go to TestNG?
> >>> Sigh...I guess the
Stuart Ballard wrote:
> I've been following this thread as best I can from the archives.
eheh, good luck with that. (I'm keeping you copied so that it's easier
for you to follow)
> I suspect the results you're getting were from the last release of
> Japitools. I can't blame you for this - I ought
On 11/6/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
Paulex Yang wrote:
> Geir Magnusson Jr. wrote:
>>
>>
>> Paulex Yang wrote:
>>> Geir Magnusson Jr. wrote:
did we decide not to go to TestNG?
>>> Sigh...I guess there must be too many ones have waited too long for
>>> TestNG...(includ
On 11/6/06, Paulex Yang <[EMAIL PROTECTED]> wrote:
Geir Magnusson Jr. wrote:
>
>
> Paulex Yang wrote:
>> Geir Magnusson Jr. wrote:
>>> did we decide not to go to TestNG?
>> Sigh...I guess there must be too many ones have waited too long for
>> TestNG...(including me)
>
> I don't understand - what
I've been following this thread as best I can from the archives.
I suspect the results you're getting were from the last release of
Japitools. I can't blame you for this - I ought to have made a new one
long ago - but the last release has a bunch of known bugs compared to
the current code. In par
Hi Alexey,
yes we often tested the speed in our several attempts to improve
performance. Comparing modPow before and after this new patch gave us
the following figures:
size before after
16 5.636e+05 6.351e+05
32 9.727e+04 1.293e+05
48 3.
Agreed. Without the explanation of JET as only a fast path, I also
thought JET and OPT are two different JITs. And actually as I can
recall, JET and OPT are indeed treated as two different JITs that the
EM can select in the JITs chain.
Honestly, "different paths" give me an impression that they a
I tried sending this previously, but Stefano seems to have not
received it (at least I got no response or followup) and (as I
suspected) the list definitely didn't because I wasn't subscribed. I
subscribed to the digest version now so that I'm not so excluded from
japitools-related discussion on h
Weldon Washburn wrote:
Folks,
I have spent the last two months committing patches to the VM. While we
have added a ton of much needed functionality, the stability of the system
has been ignored. By chance, I looked at thread synchronization design
problems this week. Its very apparent that w
Yes, I use a gcc version 4.0.2 on RHEL. I have no problems building +
running it now
> > I can confirm that gcc 4.1.1 compiled this patch without any problems.
> > As I've written, patchlevel shouldn't matter here, and if gcc 4.1.0
> > worked, 4.1.1 should work as well (with very rare exception
On 11/5/06, Weldon Washburn <[EMAIL PROTECTED]> wrote:
>>On 11/5/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
>>
>> first, can we also use this test for gcv4.1?
>>
Yes. The test is a Java test. The reason I placed it in gc_gen is that it is
intended to stress allocation fastpath and corr
So it looks like I was wrong :)
SY, Alexey
2006/11/6, Alexei Fedotov <[EMAIL PROTECTED]>:
Alexey wrote,
> As far as I remember TCK does not check for signature compatibility.
http://jcp.org/en/resources/tdk reads:
Signature Test tool
The Signature Test tool verifies that a Java technology im
Gregory Shimansky wrote:
Salikh Zakirov wrote:
Gregory Shimansky wrote:
I think you could use 4.1.0 in Fedora Core 5. Since patch level
shouldn't really affect the C++ compilation restrictions, the same patch
should break on 4.1.0 as well.
Gregory, I've looked at harmony-1635.patch you've up
2006/11/6, Alexei Fedotov <[EMAIL PROTECTED]>:
All,
I have added a patch to
http://issues.apache.org/jira/browse/HARMONY-2077 [doc] Good issue
resolution guideline,
though some things are rephrased though.
I do not think that we need to insert this guideline to "get involved"
page. I personally
Jet is a startup fast compilation path, not a seperate pluggable jit. So,
while modularity and seperation are important requirements, they may not
be
needed here.
JET can work standalone (-Xem:jet specified), OPT can work standalone
(-Xem:opt), so from "outside" POV they are independent. Also
Alexey wrote,
As far as I remember TCK does not check for signature compatibility.
http://jcp.org/en/resources/tdk reads:
Signature Test tool
The Signature Test tool verifies that a Java technology implementation
undergoing compatibility testing and its reference APIs are mutually
compatible
All,
I have added a patch to
http://issues.apache.org/jira/browse/HARMONY-2077 [doc] Good issue
resolution guideline,
though some things are rephrased though.
On 11/6/06, Fedotov, Alexei A <[EMAIL PROTECTED]> wrote:
Alexey,
Thank you for your answer. Yesterday I tried to prepare an appropriat
Paulex Yang wrote:
Geir Magnusson Jr. wrote:
Paulex Yang wrote:
Geir Magnusson Jr. wrote:
did we decide not to go to TestNG?
Sigh...I guess there must be too many ones have waited too long for
TestNG...(including me)
I don't understand - what do you mean?
Nothing but a joke:). I mean, t
Tim Ellison wrote:
> Thanks for doing this Stefano. I'll investigate the Sun/IBM findings
> and let you know.
My pleasure, really.
Oh, and before anybody thinks there is something malicious about this,
let me state that I do *NOT* think there was anything intentional in the
various JVM about bre
ICU would not see this as a bug, because it is a feature of their
implementation of DecimalFormat. The pattern ".1" for ICU means to round the
value to the nearest tenth, while the RI takes it literally. If you look at
the JavaDocs for ICU, you'll see the following message:
*This is an enhanced v
Thanks for doing this Stefano. I'll investigate the Sun/IBM findings
and let you know.
Regards,
Tim
Stefano Mazzocchi wrote:
> Being a sucker for statistics and charts, I've decided to look into
> japitools myself and regenerate the graph of API coverage progress of
> harmony.
>
> In doing so,
Geir Magnusson Jr. wrote:
> Yes. I have some docs that need to be put in SVN - I hope to do that
> today. Once we do that, we need to simply vote to accept the code.
>
> If you start working with it ahead of time, that will be good :)
>
> geir
Are we ready to vote yet? I can't hold my breath
Jet is a startup fast compilation path, not a seperate pluggable jit. So,
while modularity and seperation are important requirements, they may not be
needed here.
Also, Mikhail and Alex are the best people to decide on this.They are
literally the two people who know this code best :-)
Alexei,
The1363 submission added functionality for lazy exception support, for
exceptions in the VM code. exn_raise_by_name_internal was such a function.
This may not be bug free ( as is true of any code ) and we need to check out
2070. I will take a look, as should Pavel.
I think that while
Alexey,
Thank you for your answer. Yesterday I tried to prepare an appropriate
patch for get-involved.html but faced several things I couldn't resolve
myself. I didn't criticize your text - I was thinking how to fit it into
get-involved.html. That is why I raised all these questions.
I still have
Stefano Mazzocchi wrote:
Paulex Yang wrote:
Gets more interesting with IBM:
-- ibm1.5 vs. sun1.5
Total: 99.77% good, 0% bad, 0.22% missing
java.lang:
Missing
method java.lang.StringBuilder.append(java.lang.StringBuilder): missing
in /home/s
Geir Magnusson Jr. wrote:
Alex Astapchuk wrote:
Pavel Pervov wrote:
Hello, community,
Working through DRLVM sources I (once again) looked at organization of
jitrino code.
Actually, there are two JITs hidden inside "jitrino": JET and OPT.
As far as I may observe - these two are code-indepen
Geir Magnusson Jr. wrote:
Alex Astapchuk wrote:
Geir Magnusson Jr. wrote:
I've been having some problems getting some test cases to exhibit
misbehavior for DRLVM, and it turns out that jitrino is built in
release mode no matter what BUILD_CFG is set to.
Yes, this is a long-long sto
Alex Astapchuk wrote:
Geir Magnusson Jr. wrote:
I've been having some problems getting some test cases to exhibit
misbehavior for DRLVM, and it turns out that jitrino is built in
release mode no matter what BUILD_CFG is set to.
Yes, this is a long-long story.
Was done as 'we-will-ch
That's distressing. I usually throw in a build clean every now and then
- I'm almost sure I did it early yesterday or sat at the earliest and
did a full build, so whatever I committed in the last two days is
problematic. Not clear what though...
geir
Robin Garner wrote:
I've been having so
Alex Astapchuk wrote:
Pavel Pervov wrote:
Hello, community,
Working through DRLVM sources I (once again) looked at organization of
jitrino code.
Actually, there are two JITs hidden inside "jitrino": JET and OPT.
As far as I may observe - these two are code-independent from each other.
JIT-
2006/11/6, Fedotov, Alexei A <[EMAIL PROTECTED]>:
Alexey,
I started looking into this thread. Are guidelines on the web site
already? I failed to find them.
No, this guideline is not published yet.
I'll do this in the nearest future.
I thought about adding them to get-involved.html. Here are
Geir, all,
Could you please find time and look into JIRA 1882 and JIRA 2003. These
contain content updates for the website - one for the devguide,
removing outdated info, etc; and the other one for JIT - introducing a
more-or-less comprehensive description of this component. Adding these
to the we
Geir Magnusson Jr. wrote:
Paulex Yang wrote:
Geir Magnusson Jr. wrote:
did we decide not to go to TestNG?
Sigh...I guess there must be too many ones have waited too long for
TestNG...(including me)
I don't understand - what do you mean?
Nothing but a joke:). I mean, the TestNG depends on j
Alexey Petrenko 写道:
2006/11/6, Spark Shen <[EMAIL PROTECTED]>:
Alexey Petrenko 写道:
> Hi, Mike.
>
> You can find compatybility guideline for Harmony here:
>
http://incubator.apache.org/harmony/subcomponents/classlibrary/compat.html
>
>
> According to your testcase. I think it is a bug and you
I remember that we faced the same problem long time ago.
So it is probably a good candidate for mentioning on wiki.
SY, Alexey
2006/11/5, Fedotov, Alexei A <[EMAIL PROTECTED]>:
Hello,
Since my Linux died due to hardware problem I now abide at computers of
my friends. Pavel's computer showed th
2006/11/5, Anton Luht <[EMAIL PROTECTED]>:
Hello,
Both bugs are verified on
svn = r471521, (Nov 5 2006), Windows/ia32/msvc 1310, debug build
and can be closed.
Done.
SY, Alexey
On 11/5/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
>
>
> Fedotov, Alexei A wrote:
> > Anton,
> >
> > Is i
2006/11/6, Spark Shen <[EMAIL PROTECTED]>:
Alexey Petrenko 写道:
> Hi, Mike.
>
> You can find compatybility guideline for Harmony here:
> http://incubator.apache.org/harmony/subcomponents/classlibrary/compat.html
>
>
> According to your testcase. I think it is a bug and you should file it
> to JIRA
45 matches
Mail list logo
