Re: [DRLVM] General stability

[Alexey Petrenko]

2006/11/8, Mikhail Fursov <[EMAIL PROTECTED]>:

If our classlib is not 100% compatible we can't stop addition of new
features.
The same is with VM.

Nobody trying to freeze new features forever. At least I don't :)


If we want to have "unnamed" milestones, the solution could be: every last
month of a quoter is a "stability" period. No new features are accepted during
this period. This could work for a long period of time without need
in additional discussions.

But we need to define what is stability in this case. Unit tests? It's
a precommit criteria and should not fail always.
Big applications? Which applications? Which scenarios?
If we adds some new features then application list should increase.
This needs discussions and so no

SY, Alexey


On 11/8/06, Alexey Petrenko <[EMAIL PROTECTED]> wrote:
>
> 2006/11/8, Mikhail Fursov <[EMAIL PROTECTED]>:
> > On 11/8/06, Alexey Petrenko <[EMAIL PROTECTED]> wrote:
> > >
> > > Probably it's time to create some release plan :)
> > >
> > So let's start this discussion?
> > >
> > Good idea!
> > The only release I can imagine is Harmony Java5SE 100% compatible.
> To be Java5SE 100% compatible we need TCK first.
> So we could think about some less impressive goal for the first release :)
>
> SY, Alexey

Re: [DRLVM] General stability

[Mikhail Fursov]

If our classlib is not 100% compatible we can't stop addition of new
features.
The same is with VM.

If we want to have "unnamed" milestones, the solution could be: every last
month of a quoter is a "stability" period. No new features are accepted
during this period. This could work for a long period of time without need
in additional discussions.
?

On 11/8/06, Alexey Petrenko <[EMAIL PROTECTED]> wrote:


2006/11/8, Mikhail Fursov <[EMAIL PROTECTED]>:
> On 11/8/06, Alexey Petrenko <[EMAIL PROTECTED]> wrote:
> >
> > Probably it's time to create some release plan :)
> >
> So let's start this discussion?
> >
> Good idea!
> The only release I can imagine is Harmony Java5SE 100% compatible.
To be Java5SE 100% compatible we need TCK first.
So we could think about some less impressive goal for the first release :)

SY, Alexey





--
Mikhail Fursov

Re: [DRLVM] General stability

[Alexey Petrenko]

2006/11/8, Mikhail Fursov <[EMAIL PROTECTED]>:

On 11/8/06, Alexey Petrenko <[EMAIL PROTECTED]> wrote:
>
> Probably it's time to create some release plan :)
>
So let's start this discussion?
>
Good idea!
The only release I can imagine is Harmony Java5SE 100% compatible.

To be Java5SE 100% compatible we need TCK first.
So we could think about some less impressive goal for the first release :)

SY, Alexey

Re: [DRLVM] General stability

[Mikhail Fursov]

On 11/8/06, Alexey Petrenko <[EMAIL PROTECTED]> wrote:


Probably it's time to create some release plan :)


So let's start this discussion?



Good idea!
The only release I can imagine is Harmony Java5SE 100% compatible. We can
make feature freeze in 2 or 3 monthes before this date and after we have all
features in classlib and vm implemented.
If this proposal is OK we will have feature freeze only in Q1 2007.. ?

--
Mikhail Fursov

Re: [DRLVM] General stability

[Alexey Petrenko]

2006/11/4, Weldon Washburn <[EMAIL PROTECTED]>:

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  we lack the regression testing
to really find threading bugs, test the fixes and test against regression.
No doubt there are similar problems in other VM subsystems.   "build test"
is necessary but not sufficient for where we need to go.  In a sense,
committing code with only "build test" to prevent regression is the
equivalent to flying in the fog without instrumentation.

So that we can get engineers focused on stability, I am thinking of coding
the JIRAs that involve new features as "later" or even "won't fix".  Please
feel free to comment.

I prefer to move the issue to the next milestone or release if I'm not
sure that it will not break stability of the product and we are in
"near release" phase.

Probably it's time to create some release plan :)
I think it will make many things much easier. If we will have a list
of features for release and release date it will be much easier to
decide do we want to apply the fix or postpone it to the next release.

So let's start this discussion?

SY, Alexey


We also need to restart the old email threads on regression tests.  For
example, we need some sort of automated test script that runs Eclipse and
tomcat, etc. in a deterministic fashion so that we can compare test
results.  It does not have to be perfect for starts, just repeatable and
easy to use.  Feel free to beat me to starting these threads :)

--
Weldon Washburn
Intel Enterprise Solutions Software Division

Re: [Cocoon] Cocoon 2.1.9 works on Harmony

[Alexey Petrenko]

2006/11/8, Anton Rusanov <[EMAIL PROTECTED]>:

Cocoon 2.1.9 now works on Harmony (IBM VME + Classlib)!
It starts and works normally.

Great news!
Have you tried it with DRLVM?


The only issues are:
 * It cannot be built from source code using Harmony because the build
tries to do this with com.sun.tools.javac.Main.
 An attempt to make a wrapper with such name for Harmony javac didn't
succeed: (%COCOON%\tools\targets\compile-build.xml:54: Error starting
modern compiler).

You can change compile-build.xml (can you?) to specify Eclipse
compiler. You can check Harmony's build files to see how to do that.



 * While checking up the "Hello, World!" sample it was discovered that
Cocoon failed to display the JPEG representation of that text because
of this error: java.lang.NoClassDefFoundError:
com.sun.image.codec.jpeg.JPEGCodec.

We have jpeg encoder. But it has another name :)
Probably we need to check is it possible to change Cocoon code to be
compatible with RI and Harmony at the same time and suggest the
patch...
Can you do this? :)

SY, Alexey

Re: [DRLVM] General stability

[Egor Pasko]

On the 0x21B day of Apache Harmony Oleg Oleinik wrote:
> Such model works but there is a risk of fixing again "from scratch" those
> bugs which were fixed once on the previous milestones.

sometimes it is easier to fix a couple of bugs "from scratch" than to
spend large amount of resources on regular complex checks (that also
do not guarantee 100% stability)

> We can eliminate this if follow "no regression" policy - if something works
> (classlib unit tests, Tomacat or Eclipse Unit Tests pass 100%, for example),
> it should continue working - any regression is a subject for reporting and
> fixing as soon as possible (it is easier to find root cause and fix since we
> will know which commit caused regression).
> 
> Will this model work? Isn't it a little bit better than focusing on runtime
> stability periodically?

"no regression" policy should be relevant to a number of *small* tests
that are easy to run and are running fast, to make them good as
pre-commit criteria.

Complex workloads _cannot_ be run as a pre-commit criteria. So there
_should be regressions_. That's because:
* we cannot afford to run them as pre-commit
* we cannot afford complex rollbacks and stop-the world

Many successful projects (probably, all of them) have stability
periods, even stability releases (and, yes, stability branches). That
is considered effective. And IMO our project should act the same.

We _have to_ allow some bugs to continue active development. But not
too many. It is always a tradeoff.

To summarize. I support you idea to improve the regression test base
and infrastructure. Let it be a step-by-step improvement. Then we can
decide which tests to run as pre-commit and which are to measure the
overall stability.

> On 11/8/06, Tim Ellison <[EMAIL PROTECTED]> wrote:
> >
> > I wouldn't go so far as to label issues as "won't fix" unless they are
> > really high risk and low value items.
> >
> > It's useful to go through a stabilization period where the focus is on
> > getting the code solid again and delaying significant new functionality
> > until it is achieved.  A plan that aims to deliver stable milestones on
> > regular periods is, in my experience, a good way to focus the
> > development effort.
> >
> > Regards,
> > Tim
> >
> > 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  we lack the regression
> > testing
> > > to really find threading bugs, test the fixes and test against
> > regression.
> > > No doubt there are similar problems in other VM subsystems.   "build
> > test"
> > > is necessary but not sufficient for where we need to go.  In a sense,
> > > committing code with only "build test" to prevent regression is the
> > > equivalent to flying in the fog without instrumentation.
> > >
> > > So that we can get engineers focused on stability, I am thinking of
> > coding
> > > the JIRAs that involve new features as "later" or even "won't
> > fix".  Please
> > > feel free to comment.
> > >
> > > We also need to restart the old email threads on regression tests.  For
> > > example, we need some sort of automated test script that runs Eclipse
> > and
> > > tomcat, etc. in a deterministic fashion so that we can compare test
> > > results.  It does not have to be perfect for starts, just repeatable and
> > > easy to use.  Feel free to beat me to starting these threads :)
> > >
> >
> > --
> >
> > Tim Ellison ([EMAIL PROTECTED])
> > IBM Java technology centre, UK.
> >

-- 
Egor Pasko

Re: svn commit: r472149 - /incubator/harmony/enhanced/classlib/trunk/modules/beans/src/test/java/org/apache/harmony/beans/tests/java/beans/PersistenceDelegateTest.java

[Stepan Mishura]

Hi Alexei,

Sorry, I don't understand your logic. Is the test case valid? If there was
another bug (for example: "[another_VM][unit] half of classlib beans tests
crashes VM"), would you agree to comment out a half of beans tests?

Thanks,
Stepan.


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Tuesday, November 07, 2006 10:09 PM
To: [EMAIL PROTECTED]
Subject: svn commit: r472149 -
/incubator/harmony/enhanced/classlib/trunk/modules/beans/src/test/java/org/
apache/harmony/beans/tests/java/beans/PersistenceDelegateTest.java

Author: ayza
Date: Tue Nov  7 08:09:27 2006
New Revision: 472149

URL: http://svn.apache.org/viewvc?view=rev&rev=472149
Log:
I commented out testInitialize_circularRedundancy test since it crashes
DRLVM DEBUG build (HARMONY-2073) and no prompt solution has been provided.

Modified:

incubator/harmony/enhanced/classlib/trunk/modules/beans/src/test/java/org/a
pache/harmony/beans/tests/java/beans/PersistenceDelegateTest.java

Modified:
incubator/harmony/enhanced/classlib/trunk/modules/beans/src/test/java/org/a
pache/harmony/beans/tests/java/beans/PersistenceDelegateTest.java
URL:
http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/modu
les/beans/src/test/java/org/apache/harmony/beans/tests/java/beans/Persisten
ceDelegateTest.java?view=diff&rev=472149&r1=472148&r2=472149
===




--
Stepan Mishura
Intel Middleware Products Division
--
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [classlib][concurrent] Complete support?

[Alexey Petrenko]

2006/11/8, Nathan Beyer <[EMAIL PROTECTED]>:

Instead of continuing to add functionality to the DRLVM-specific
Atomics class, I'd like to get a consensus on the Threads/Objects
(include CAS operations) interfaces in luni-kernel. Then we can get
DRLVM to implement these classes and the donated IBM VM to do the same
so we can have concurrent support from both VMs.

That would be great.

SY, Alexey


On 11/7/06, Nikolay Kuznetsov <[EMAIL PROTECTED]> wrote:
> please see the following JIRA issue for the missing function:
> http://issues.apache.org/jira/browse/HARMONY-2086
>
> Nik.
>
> On 11/7/06, Nikolay Kuznetsov <[EMAIL PROTECTED]> wrote:
> > While I'm not familiar with j.u.concurrent build infrastructure, but
> > the issue about missing native function is known and I'll file a jira
> > and provide a fix today.
> >
> > Nik.
> >
> > > 1) Natives are missing. In particular,
> > > java.util.concurrent.atomic.AtomicLong.VMSupportsCS8 looks like should  be
> > > implemented on VM side.
> > > 2) ant test -Dbuild.module=concurrent does not work. The output is as
> > > follows:
> > >
> > > support-jar:
> > >   [jar] Building jar:
> > > C:\_work_\harmony\enhanced\classlib\trunk\deploy\build
> > > \test\support.jar
> > >
> > > test-modules:
> > >
> > > test:
> > >
> > > full-report:
> > >
> > > BUILD FAILED
> > > C:\_work_\harmony\enhanced\classlib\trunk\build.xml:167: The following 
error
> > > occ
> > > urred while executing this line:
> > > C:\_work_\harmony\enhanced\classlib\trunk\make\build-test.xml:58:
> > > C:\_work_\harm
> > > ony\enhanced\classlib\trunk\build\test_report not found.
> > >
> > > Do I miss something important?
> > >
> > > --
> > > Pavel Pervov,
> > > Intel Enterprise Solutions Software Division
> > >
> > >
> >
>

Re: [Cocoon] Cocoon 2.1.9 works on Harmony

[Egor Pasko]

On the 0x21B day of Apache Harmony Anton Rusanov wrote:
> Cocoon 2.1.9 now works on Harmony (IBM VME + Classlib)!
> It starts and works normally.

great! 
If you find some DRLVM-specific problems, please, let us know (ASAP)

> The only issues are:
>  * It cannot be built from source code using Harmony because the build
> tries to do this with com.sun.tools.javac.Main.
>   An attempt to make a wrapper with such name for Harmony javac didn't
> succeed: (%COCOON%\tools\targets\compile-build.xml:54: Error starting
> modern compiler).
>  * While checking up the "Hello, World!" sample it was discovered that
> Cocoon failed to display the JPEG representation of that text because
> of this error: java.lang.NoClassDefFoundError:
> com.sun.image.codec.jpeg.JPEGCodec.
> 
> I will update the application status in Wiki.
> 
> -- 
> Thanks,
> Anton
> 

-- 
Egor Pasko

RE: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs)

[Konovalova, Svetlana]

Nadya wrote:
>Candidates:
>http://incubator.apache.org/harmony/guidelines.html 
>http://incubator.apache.org/harmony/get-involved.html
+1

>it's not quite convenient for me just now to add patches, so if someone
>volunteers to help, I'd be grateful.
If you do not mind, I can create the necessary patches.

Best regards,
Sveta Konovalova

-Original Message-
From: Morozova, Nadezhda [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, November 07, 2006 8:24 PM
To: harmony-dev@incubator.apache.org
Subject: RE: [jira] Good issue resolution guideline (was:
[classlib]volunteer to supply patches for old JIRAs)

Well, 
I guess the simplest solution would be to add the link to the
Conventions section on the front page of wiki. You can do it yourself!
Adding a link from the static website would also be useful. Candidates:
http://incubator.apache.org/harmony/guidelines.html 
http://incubator.apache.org/harmony/get-involved.html 

it's not quite convenient for me just now to add patches, so if someone
volunteers to help, I'd be grateful.

Thank you, 
Nadya Morozova
 

-Original Message-
From: Alexey Petrenko [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, November 07, 2006 4:44 PM
To: harmony-dev@incubator.apache.org
Subject: Re: [jira] Good issue resolution guideline (was:
[classlib]volunteer to supply patches for old JIRAs)

Nadya,

we definetly need a link to this page. That's not a question.
Question is where to place the link.
And as I said in previous email link place suggestions are welcome.

SY, Alexey

2006/11/7, Morozova, Nadezhda <[EMAIL PROTECTED]>:
> Alexey,
> Would be great if there we some page that had a link to the page;
> otherwise, you cannot find it from within wiki, only from the link in
> your mail :(
>
> Thank you,
> Nadya Morozova
>
>
> -Original Message-
> From: Alexey Petrenko [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, November 07, 2006 1:32 PM
> To: harmony-dev@incubator.apache.org
> Subject: Re: [jira] Good issue resolution guideline (was:
> [classlib]volunteer to supply patches for old JIRAs)
>
> I've published "Good issue resolution guideline" on Harmony site:
> http://incubator.apache.org/harmony/issue_resolution_guideline.html
> (wait for a while for the web site synchronization). It is not linked
> to other pages yet.
>
> So comments to guideline and link place suggestions are welcome.
>
> SY, Alexey
>
> 2006/9/28, Geir Magnusson Jr. <[EMAIL PROTECTED]>:
> >
> > On Sep 28, 2006, at 3:21 AM, Alexey Petrenko wrote:
> >
> > > Guys,
> > >
> > > Since there is no additional comments on this guideline...
> > >
> > > Let's put it somewhere.
> > > We got two options: Harmony site and wiki.
> > > I prefer wiki because it will be easy to edit it and I can put it
> > > there myself :)
> >
> > And if you put in a patch for website, we can get it there too :)
if
> > you put in wiki, I'm going to take and put on site, so maybe save us
> > some effort? (ok, save me the effort...)
> >
> > geir
> >
> > >
> > > Thoughts?
> > >
> > > SY, Alexey
> > >
> > > 2006/9/26, Alexey Petrenko <[EMAIL PROTECTED]>:
> > >> I've combined all the comments again.
> > >>
> > >> And here is the last version. I hope... :)
> > >>
> > >> === cut ===
> > >> Preface
> > >> This guideline covers a wide range of issues but not all of them.
> > >> If you cannot do one of the steps, then write a comment to the
> issue.
> > >> Use your common sense!
> > >>
> > >> Issue reporter:
> > >> 1. Explicitly state the expected behavior and the
> > >> actual behavior of Harmony code. Use links to specs, rfcs, etc.
> > >> 2. Try to create as small a test case as possible. A patch
> > >> to test will be highly appreciated.
> > >> 3. Provide max. information about steps necessary to recreate the
> > >> bug.
> > >> If a patch for the test has not been supplied, provide as much
> > >> diagnostic information about the failure as possible (stack
trace,
> > >> failure output, expected output etc).
> > >> 4. Remember to use issue links if applicable.
> > >> 5. Check the issue resolution when it is committed. Add a
comment.
> > >>
> > >> Resolution provider :) :
> > >> Depending on the type of issue, do the following:
> > >>
> > >> 1. Issue is probably a non-bug difference, not a bug or invalid:
> > >>   1.1. Discuss on the dev list.
> > >>   1.2. Add a link to the discussion thread as a comment to issue.
> > >> 2. Issue is a bug:
> > >>   2.1. Notify the community that you started investigation by
> adding
> > >> a comment to the issue and send a message to dev list. If you
> cannot
> > >> produce a patch, add another comment with the results of your
> > >> investigation.
> > >>   2.2. If reporter did not provide a patch to test:
> > >>   2.2.1. Try to create a patch to test.
> > >>   2.2.2. If you cannot produce a patch, write a comment about
> it.
> > >>   2.3. Create a patch to fix the issue
> > >>   2.3.1. Any concerns? Discuss on the dev list. Add a link to
> > >> discussion as a comment.
> > >>   2.4. All the pacthes (test and

Re: svn commit: r472115 - /incubator/harmony/enhanced/classlib/trunk/modules/swing/src/main/java/common/javax/swing/text/GapContent.java

[Stepan Mishura]

Hi,

Any chance to see regression test (that I asked for in HARMONY-1975)? :-)

Thanks,
Stepan.


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Tuesday, November 07, 2006 7:50 PM
To: [EMAIL PROTECTED]
Subject: svn commit: r472115 -
/incubator/harmony/enhanced/classlib/trunk/modules/swing/src/main/java/comm



on/javax/swing/text/GapContent.java

Author: apetrenko
Date: Tue Nov  7 05:50:07 2006
New Revision: 472115

URL: http://svn.apache.org/viewvc?view=rev&rev=472115
Log:
Patch for HARMONY-1809
"[classlib][swing]javax.swing.text.GapContent.replace(int, int,
java.lang.Object, int) throws unspescified BadLocationException"

Modified:

incubator/harmony/enhanced/classlib/trunk/modules/swing/src/main/java/commo
n/javax/swing/text/GapContent.java




--
Stepan Mishura
Intel Middleware Products Division
--
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [drlvm] Class unloading support - tested one approach

[Aleksey Ignatenko]

Hi, Robin.
I do really like this proposed idea of marking VTables from objects via
additional word field in VTable.

But I have one question about detecting reachability of the classloaders
("sweep the vtables and check the reachability of the classloaders").
Possibly I missed something, but here is my view of the current model of
drlvm: all j.l.Classes and j.l.Classloaders are enumerated as strong roots
(strong references). Therefore we meet situation when all j.l.Classes and
j.l.Classloaders are always reachable (marked). And no sweep will help to
detect classloaders reachability.
I see the single way to distinguish if j.l.Classloader or j.l.Class was
marked not by strong root from VM but by some reference from heap - is
to write unique object value into VTable. Then we can detect if some
jlClasloader was marked from rootset (strong root from VM) or from some live
object.

I also want to say that 1-st proposed design from me assumed addtional
mark&scan phase without enumeration of jlClasses and jlClassloaders to be
able to detect their reachability.

Could you, please, clarify this moment.
Thanks, Aleksey.

On 11/3/06, Rana Dasgupta <[EMAIL PROTECTED]> wrote:


On 11/2/06, Xiao-Feng Li <[EMAIL PROTECTED]> wrote:
>
> >Robin, thanks for all the clarifications. Now it seems clear to me >and
> >I am convinced by this proposal. :-)


Yes, this proposal is the simplest and has the least perf impact. Thanks
Robin.

Re: [DRLVM] General stability

[Oleg Oleinik]

Such model works but there is a risk of fixing again "from scratch" those
bugs which were fixed once on the previous milestones.

We can eliminate this if follow "no regression" policy - if something works
(classlib unit tests, Tomacat or Eclipse Unit Tests pass 100%, for example),
it should continue working - any regression is a subject for reporting and
fixing as soon as possible (it is easier to find root cause and fix since we
will know which commit caused regression).

Will this model work? Isn't it a little bit better than focusing on runtime
stability periodically?


On 11/8/06, Tim Ellison <[EMAIL PROTECTED]> wrote:


I wouldn't go so far as to label issues as "won't fix" unless they are
really high risk and low value items.

It's useful to go through a stabilization period where the focus is on
getting the code solid again and delaying significant new functionality
until it is achieved.  A plan that aims to deliver stable milestones on
regular periods is, in my experience, a good way to focus the
development effort.

Regards,
Tim

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  we lack the regression
testing
> to really find threading bugs, test the fixes and test against
regression.
> No doubt there are similar problems in other VM subsystems.   "build
test"
> is necessary but not sufficient for where we need to go.  In a sense,
> committing code with only "build test" to prevent regression is the
> equivalent to flying in the fog without instrumentation.
>
> So that we can get engineers focused on stability, I am thinking of
coding
> the JIRAs that involve new features as "later" or even "won't
fix".  Please
> feel free to comment.
>
> We also need to restart the old email threads on regression tests.  For
> example, we need some sort of automated test script that runs Eclipse
and
> tomcat, etc. in a deterministic fashion so that we can compare test
> results.  It does not have to be perfect for starts, just repeatable and
> easy to use.  Feel free to beat me to starting these threads :)
>

--

Tim Ellison ([EMAIL PROTECTED])
IBM Java technology centre, UK.

Re: [classlib] [suncompat] completion (was; Re: [classlib]Harmony classlib with J9 VM passes all the tests provided by JUnit4.1)

[Nathan Beyer]

I just looked at the changes you made and have a question about this snippet.

+if (VM.callerClassLoader() != null) {
+throw new SecurityException("Unsafe");
+}

I just want to understand what this actually means. If the
'callerClassLoader' is null, then the caller is the bootstrap class
loader, correct? Assuming that's correct, we're asserting that only
classes in the bootstrap class loader can call Unsafe, correct?

thanks
-Nathan


On 11/7/06, Tim Ellison <[EMAIL PROTECTED]> wrote:

Nathan Beyer wrote:
> I believe we're down to agreeing to the Objects/Threads classes [1] in
> luni-kernel and getting them implemented in DRLVM and the donated IBM
> VM. I believe the Unsafe class needs to be re-implemented with these
> interfaces, but that may already be done.

yes, we are very close so should finish this off.

Also FYI, I was looking at our Unsafe I've just added a security check
and extra initialization.

Regards,
Tim

--

Tim Ellison ([EMAIL PROTECTED])
IBM Java technology centre, UK.

Re: [classlib][concurrent] Complete support?

[Nathan Beyer]

Instead of continuing to add functionality to the DRLVM-specific
Atomics class, I'd like to get a consensus on the Threads/Objects
(include CAS operations) interfaces in luni-kernel. Then we can get
DRLVM to implement these classes and the donated IBM VM to do the same
so we can have concurrent support from both VMs.

-Nathan

On 11/7/06, Nikolay Kuznetsov <[EMAIL PROTECTED]> wrote:

please see the following JIRA issue for the missing function:
http://issues.apache.org/jira/browse/HARMONY-2086

Nik.

On 11/7/06, Nikolay Kuznetsov <[EMAIL PROTECTED]> wrote:
> While I'm not familiar with j.u.concurrent build infrastructure, but
> the issue about missing native function is known and I'll file a jira
> and provide a fix today.
>
> Nik.
>
> > 1) Natives are missing. In particular,
> > java.util.concurrent.atomic.AtomicLong.VMSupportsCS8 looks like should  be
> > implemented on VM side.
> > 2) ant test -Dbuild.module=concurrent does not work. The output is as
> > follows:
> >
> > support-jar:
> >   [jar] Building jar:
> > C:\_work_\harmony\enhanced\classlib\trunk\deploy\build
> > \test\support.jar
> >
> > test-modules:
> >
> > test:
> >
> > full-report:
> >
> > BUILD FAILED
> > C:\_work_\harmony\enhanced\classlib\trunk\build.xml:167: The following error
> > occ
> > urred while executing this line:
> > C:\_work_\harmony\enhanced\classlib\trunk\make\build-test.xml:58:
> > C:\_work_\harm
> > ony\enhanced\classlib\trunk\build\test_report not found.
> >
> > Do I miss something important?
> >
> > --
> > Pavel Pervov,
> > Intel Enterprise Solutions Software Division
> >
> >
>

[Cocoon] Cocoon 2.1.9 works on Harmony

[Anton Rusanov]

Cocoon 2.1.9 now works on Harmony (IBM VME + Classlib)!
It starts and works normally.

The only issues are:
* It cannot be built from source code using Harmony because the build
tries to do this with com.sun.tools.javac.Main.
 An attempt to make a wrapper with such name for Harmony javac didn't
succeed: (%COCOON%\tools\targets\compile-build.xml:54: Error starting
modern compiler).
* While checking up the "Hello, World!" sample it was discovered that
Cocoon failed to display the JPEG representation of that text because
of this error: java.lang.NoClassDefFoundError:
com.sun.image.codec.jpeg.JPEGCodec.

I will update the application status in Wiki.

--
Thanks,
Anton

Re: [classlib] NLS exception messages arn't displayed correctly

[Evgueni Brevnov]

On 11/8/06, Tim Ellison <[EMAIL PROTECTED]> wrote:

Oliver Deakin wrote:
> Hi all,
>
> I was checking out some JIRAs and spotted that when we
> print exception stack traces at the moment we're not getting
> the full NLS message. For example, running the following:
>
> public class Test {
>  public static void main(String[] args) throws Throwable {
>  throw new NullPointerException();
>  }
> }
>
> prints:
>
> K0319java.lang.NullPointerException
>at Test.main(Test.java:3)
> FAILED to invoke JVM.
>
> I can spot 2 things wrong with this output (pats on the back
> if you spot more!):
> 1) K0319 should actually say something like
> 'Exception in thread "main" '. It looks like out NLS messages
> arn't being printed correctly - anyone got any ideas about this
> one?

The message was missing in the catalog.  I added it in r472226.

> 2) The bogus "FAILED to invoke JVM" message.
> Looks like this is coming from the launcher (Im running
> Harmony + IBM VME).
> It appears that this happens because in main_runJavaMain
> (in the launcher main.c) after we make the CallStaticVoidMethod()
> call to run main, we do the following:
>
> if ((*env)->ExceptionCheck (env))
>{
>  if (rc == 0)
>rc = 100;
>}
>
> which causes a return code of 100 to be passed back to
> gpProtectedMain() via the invocation() function, where it is used
> in the following way:
>
> if (invocation(...))
>{
>  hytty_printf (PORTLIB, "FAILED to invoke JVM.\n");
>  goto bail;
>}
>
> I imagine this misleading message also appears with DRLVM?
> I'm not setup at the moment to test it.
> Is there a reason we set the return code to 100 if there's an
> unhandled exception?

I'll leave that one for the person who changed the code ;-)


Yes, I also observed such message when running with DRLVM. Actually,
there is  the patch already which fixes the problem with the error
code returned by the launcher to OS. Moreover this patch removes the
misleading message as well. Look at
http://issues.apache.org/jira/browse/HARMONY-2006 
classlib_exit_code.patch

Thanks
Evgueni



Regards,
Tim

--

Tim Ellison ([EMAIL PROTECTED])
IBM Java technology centre, UK.

Re: [classlib]Harmony classlib with J9 VM passes all the tests provided by JUnit4.1

[Nathan Beyer]

On 11/7/06, Paulex Yang <[EMAIL PROTECTED]> wrote:

Nathan Beyer wrote:
> 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 do you mean?
>> Nothing but a joke:). I mean, the TestNG depends on j.u.c, so that it
>> cannot be used for months, so people may think let's just use JUnit
>> instead...
>>
>> Ignore it, I'm all for TestNG...:)
>
> If you're looking for another opinion, I'm not convinced. JUnit 4.x
> seems just as capable as TestNG.
There was a(or several?) long long thread discussing the TestNG/JUnit 4
comparison, and IIRC most people prefer TestNG at that time, I just
don't want to trig another thread on this topic...We have waited so long
for TestNG, so let's just go for it if nothing is preventing us now...:)


This is NOT the impression I got from the various threads. I was under
the impression that we were waiting to demonstrate that TestNG could
be used to execute tests with the various mix-n-match uses cases (OS,
failing, etc). I was waiting for an actual demonstration of the
complex use cases.

It's possible I missed the consensus; I couldn't keep up with all of
the threads.

-Nathan



>
> -Nathan
>
>> >
>> > geir
>> >
>> >>
>> >> Paulex - being desperate
>> >>
>> >
>>
>>
>> --
>> Paulex Yang
>> China Software Development Lab
>> IBM
>>
>>
>>
>


--
Paulex Yang
China Software Development Lab
IBM

Re: [DRLVM] General stability

[Oleg Oleinik]

 "build test" is necessary but not sufficient for where we need to go.  In

a sense, committing code with only "build test" to prevent regression is the
equivalent to flying in the fog without instrumentation.

Right.

Here I see 2 aspects - creating VM/JIT regression tests and running various
tests regularaly / tracking regressions timely.

1. VM/JIT regression test development.

We can start with these guidelines:

Who creates/integrates a regression test? - committer.
How? - typically, from bug's reproducer code.
Where? - drlvm\trunk\src\test\vm\\harmony-\ or
drlvm\trunk\src\test\jit\\harmony-\
Format: Junit, Jasmin
When? - Consider creating a regression test for each fixed bug against
Harmony DRLVM or JIT, if reasonable and technically possible.
Creation of regression test may be omitted if:
- Bug in documentation, build, test, code comment, code style, enhancement
is fixed.
- Performance-related bug is fixed.
- Bug is found by existing Harmony test (Harmony regression or unit test).
// to avoid duplication of tests

Try to use public API to provide implementation independence and stability
of the tests.

This test suite can/should be used in pre-commit testing.


2. Timely regression tracking via test execution.

Now we have some solution for code integrity testing via Cruise Control
(buildtest/trunk/CC + HARMONY-995) - good start point to track regressions
hourly using classlib unit tests and "build test" on your specific platform.

I see HARMONY-2038 which is about automation of Ecilpse Unit Tests execution
in context of buildtest/ infrastructure - to start running EUT regularly
using buildtest/ (say, nightly) and reporting timely about new test failures
(and causing commits).

I think, it would be great if we continue adding more automation scripts
into buildtest/ for various public unit test suites and scenarios (Derby,
Tomcat, etc.), so that one could take automation scripts from buildtest/ and
run them regularly on his specific platform, report regressions timely (what
Nina, I suppose, is going to do with EUT).



On 11/4/06, Weldon Washburn <[EMAIL PROTECTED]> 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  we lack the regression
testing
to really find threading bugs, test the fixes and test against regression.
No doubt there are similar problems in other VM subsystems.   "build test"
is necessary but not sufficient for where we need to go.  In a sense,
committing code with only "build test" to prevent regression is the
equivalent to flying in the fog without instrumentation.

So that we can get engineers focused on stability, I am thinking of coding
the JIRAs that involve new features as "later" or even "won't
fix".  Please
feel free to comment.

We also need to restart the old email threads on regression tests.  For
example, we need some sort of automated test script that runs Eclipse and
tomcat, etc. in a deterministic fashion so that we can compare test
results.  It does not have to be perfect for starts, just repeatable and
easy to use.  Feel free to beat me to starting these threads :)

--
Weldon Washburn
Intel Enterprise Solutions Software Division

Re: [drlvm] questions on class unloading (JIRA H2000) and cleaning class.h (JIRA H1558)

[Weldon Washburn]

On 11/7/06, Gregory Shimansky <[EMAIL PROTECTED]> wrote:


On Friday 03 November 2006 19:18 Weldon Washburn wrote:
> H1558 has been a big battle to get it into committable shape.  I would
> really like to commit it first.  (In fact, Pavel and I are working on it
> right now!)

The patch in HARMONY-1558 is huge and often is broken by new VM commits.
Shall
we make a freeze on VM commits to allow this patch it? Maintaining so many
code changes is probably not an easy task.

I've tried to apply it today and it doesn't apply cleanly (no surprise, 5
days
passed since the last update). I think some cooperation between VM
committers
is required to allow this patch to be finally integrated into the code.

We should either agree to let it in or let it die. I support the first
option.

Weldon, Geir, what do you think?



Pavel and I will work on 1558 in the next 12 hours.  Hopefully
we will commit it very soon.   It has been a very difficult patch to apply
for all the reasons you describe.  It would be appreciated if you can hold
off applying any patches that might modify the same files as 1558.

--

Gregory Shimansky, Intel Middleware Products Division





--
Weldon Washburn
Intel Enterprise Solutions Software Division

Re: [drlvm] vote on class unloading design (was Class unloading support - tested one approach)

[Robin Garner]

My proposal is purely for the performance critical operation of marking 
the classes that have live objects - as far as I'm aware, 90% of 
Etienne's design still stands.


cheers

Xiao-Feng Li wrote:

Yes, I think the discussion on class unloading is one the successful
examples of open community in coming up with a good design and making
design decision. Although the final  design can be one person's
proposal, but it's based on or enlightened by all the participants'
opinions. Eitenne's proposal is a big stride over the original one.

Cheers,
xiaofeng

On 11/8/06, Rana Dasgupta <[EMAIL PROTECTED]> wrote:

It's worth a lot, since you have implemented this in SableVM yourself.
Thanks.

On 11/7/06, Etienne Gagnon <[EMAIL PROTECTED]> wrote:
>
> For what it's worth, I'll add my humble +1.
>
> Etienne
>
> Xiao-Feng Li wrote:
> > Agreed, so plus me.
> >
> > Thanks,
> > xiaofeng
> >
> > On 11/8/06, Rana Dasgupta <[EMAIL PROTECTED]> wrote:
> >
> >> On 11/7/06, Weldon Washburn <[EMAIL PROTECTED]> wrote:
> >> >
> >> > All,
> >> >
> >> > It looks like the debate on class unloading has concluded.
> >> >
> >> > Let's vote on implementing Robin's proposal.
> >> >
> >> > +1
> >> >
> >> >Weldon
> >> >
> >> > PS -- When class unloading gets implemented and committed is a
> seperate
> >> > issue.
> >> >
> >> >
> >> >
> >> > +1 I think it's the best proposal among those that were discuussed
> >>
> >>
> >
>
> --
> Etienne M. Gagnon, Ph.D.http://www.info2.uqam.ca/~egagnon/
> SableVM:   http://www.sablevm.org/
> SableCC:   http://www.sablecc.org/
>
>
>





--
Robin Garner
Dept. of Computer Science
Australian National University

Re: [classlib]Harmony classlib with J9 VM passes all the tests provided by JUnit4.1

[Richard Liang]

Paulex Yang wrote:

Richard Liang wrote:

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 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.u.c, so 
that it

> > cannot be used for months, so people may think let's just use JUnit
> > instead...
> >
>
> What's left for j.u.c?  I lost track of that Saga, IIRC.

I believe we're down to agreeing to the Objects/Threads classes [1] in
luni-kernel and getting them implemented in DRLVM and the donated IBM
VM. I believe the Unsafe class needs to be re-implemented with these
interfaces, but that may already be done.


Yes, I just run testNG successfully by appending suncompat.jar and
luni-kernel-stubs.jar to bootclasspath ;-)

So you mean we can start the TestNG migration work at any time?

No for current IBM VME; Maybe yes for drlvm (I will try it today ;-) )






-Nathan

[1] 
http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/modules/luni-kernel/src/main/java/org/apache/harmony/kernel/vm/ 



>
> > Ignore it, I'm all for TestNG...:)
> >>
> >> geir
> >>
> >>>
> >>> Paulex - being desperate
> >>>
> >>
> >
> >
>
>









--
Richard Liang
China Software Development Lab, IBM 

Re: [classlib]Harmony classlib with J9 VM passes all the tests provided by JUnit4.1

[Richard Liang]

Tim Ellison wrote:

Richard Liang wrote:
  

On 11/7/06, Nathan Beyer <[EMAIL PROTECTED]> wrote:


I believe we're down to agreeing to the Objects/Threads classes [1] in
luni-kernel and getting them implemented in DRLVM and the donated IBM
VM. I believe the Unsafe class needs to be re-implemented with these
interfaces, but that may already be done.
  

Yes, I just run testNG successfully by appending suncompat.jar and
luni-kernel-stubs.jar to bootclasspath ;-)



Why do you need to put the stubs on the bootclasspath? and there is a
sun.misc.Unsafe in the DRLVM kernel.jar so I expect you are using that.

  
Sorry ;-) I'm using IBM VME which does not include 
"org.apache.harmony.kernel.vm.Objects" and 
"org.apache.harmony.kernel.vm.Threads". I will try it with DRLVM.



We need to agree on the extensions to the luni kernel classes so that we
can implement them in the IBM VME too (and then share the Unsafe in
suncompat).

Regards,
Tim

  


--
Richard Liang
China Software Development Lab, IBM 

Re: [Japi] [general] interesting discoveries with japitools - part 2

[Stuart Ballard]

On 11/7/06, Stefano Mazzocchi <[EMAIL PROTECTED]> wrote:

java.awt.peer:
Missing
method java.awt.peer.WindowPeer.updateFocusableWindowState(): missing in
bea1.5


This one indicates that your set of packages is not correct:
java.awt.peer is not a documented package. Unfortunately getting the
right set of packages is hard on Windows - I just posted on
japitools-list about improving that situation. If you do happen to be
on a unix-like system this should work:

japiextractpkgs docs/api/overview-frame.html >jdk15.pkgs
japize as jdk15 packages jre/lib/*.jar `cat jdk15.pkgs`

where "docs/api" is a folder containing the JDK javadocs.

The trouble is that the "backquote" quoting and the cat command aren't
available on Windows and I'm not aware of an alternative. So the plan
is to get Japize to accept "@jdk15.pkgs" as an alternative syntax. Any
volunteers or anyone who knows where I could find code to do that,
dealing with quoting and the like, under a GPL-compatible license,
please speak up on japitools-list...


java.util.concurrent:
Abs.add
method java.util.concurrent.Delayed.compareTo(java.lang.Object): new
interface method in bea1.5


So, it appears that that Sun added a method that is not available in the
javadocs (bad Sun, no donut for you!) and that BEA did not (correctly)
implement.

Also, BEA added the method "compareTo" to the
java.util.concurrent.Delayed interface. This is not really a problem
because Delayed extends Comparable, therefore all classes implementing
Delayed will have to have the compareTo method anyway.


Comparable is really fun in the presence of generics. Does Delayed
implement Comparable or Comparable or Comparable or what?

If it implements Comparable then it *doesn't* technically
have a compareTo(Object) method but a compareTo(Delayed) instead. If
Sun added a compareTo(Object) method as well... well that'd have some
rather weird effects. I'll need to take a while to get my head round
that. Could you produce and send me Japi files of *just* the Delayed
class in both implementations so I can look at the differences in
detail?


Stuart, do you think this is something that japitools should check?

I would call this a false positive.


I think it's an indicator of something, I'd say more investigation is
needed before determining it's a Japitools bug.


java.awt.peer:
Missing
method java.awt.peer.WindowPeer.updateFocusableWindowState(): missing in
ibm1.5


Again peer should not be included.


java.util.concurrent:
Abs.add
method java.util.concurrent.Delayed.compareTo(java.lang.Object): new
interface method in ibm1.5


Same as above.


javax.xml.datatype:
Bad
field
javax.xml.datatype.DatatypeFactory.DATATYPEFACTORY_IMPLEMENTATION_CLASS:
constant
[com.sun.org.apache.xerces.internal.jaxp.datatype.DatatypeFactoryImpl]
in sun1.5, but constant
[org.apache.xerces.jaxp.datatype.DatatypeFactoryImpl] in ibm1.5


This is an API bug on Sun's part; alternative implementers are screwed
here either way. Constant fields are inlined so the value will be
taken from the implementation the code was *compiled* against, not
what it's running against. Japitools is correct to report this as an
error, but the only *correct* fix is for Sun to un-constify that
field.


java.util.concurrent:
Abs.add
method java.util.concurrent.Delayed.compareTo(java.lang.Object): new
interface method in sun1.5
Done.

Hmmm, the compareTo is in both the direct and the reverse? smells like a
japitool bug to me.


Yes that is odd. Please do send me those two Japi files.


java.lang:
Missing
method java.lang.StringBuilder.append(java.lang.StringBuilder): missing
in sun1.5


Weird.


 2) package org.w3c.dom.xpath: missing in sun1.5


This again is a "not getting the right set of packages" issue. Adding
extra packages isn't illegal (at least not in Japitools's view of the
world); the comparisons should be done based on which packages are
*documented* as present.


The results show clearly that japitools did indeed improve a lot over
the last released version.


Great :)


NOTE: the results were taken with the following package passed to the
"japize" tool:

 +java +javax +org -org.apache -org.ietf


Yup, that's your trouble ;)

Stuart.
--
http://sab39.dev.netreach.com/

Re: Japi diffs for harmony

[Stuart Ballard]

Tim Ellison wrote:

I'm no fan of stubs for just such reason.  But for those dev's that are
following along, there is an
org.apache.harmony.luni.util.NotYetImplementedException that is defined
for just such purposes.


Would you consider renaming this to NotImplementedException since Japi
recognizes that name in throws clauses and treats it specially?

If you feel strongly about not changing the existing name, I can add
NotYetImplementedException as an alternative hardcoded name in
Japitools but that seems kinda redundant...

What do you think?

Stuart.
--
http://sab39.dev.netreach.com/

Re: [drlvm][sablevm] Desing of Class Unloading Support

[Robin Garner]

Weldon Washburn wrote:

On 11/7/06, Ivan Volosyuk <[EMAIL PROTECTED]> wrote:


On 07 Nov 2006 14:35:55 +0600, Egor Pasko <[EMAIL PROTECTED]> wrote:
> > I already have one idea how to benefit from movable vtables.



There would have to be a very compelling argument for making vtables
movable.  Like a business workload that Harmony needs to run within the 
next

12 months.


The cost of moving vtables would be huge.  It would have to be a very 
hefty optimization :)


--
Robin Garner
Dept. of Computer Science
Australian National University

Re: [drlvm] [testing] Excluding commit tests until the problem is fixed

[Rana Dasgupta]

Though I tried several times, I could not repro 2070 or Alexey's specific
problems. The test attached to 2018 repros, and that I think is enough.

Pavel,
  1. The patch looks good, but I could not apply and try it since my Linux
box is down.
  2. Did you run all tests ( smoke, cuint, kernel, and classlib )? Since
this fully turns on lazy exceptions, we need to ensure that all tests pass,
or at least have identical behaviour before and after the pacth.
  3. Adding a finalizer based stack test to smoke is a good idea.
  4. On Linux you extend the guard region up ( or down whatever ) by a
page. Did you find a good reason for it, or is this just being careful?

Rana




On 11/7/06, Pavel Afremov <[EMAIL PROTECTED]> wrote:


Rana,

Everything is correct in you description, but it looks like that *
HARMONY-2018*  should
fix described bug. I think Alexei will have a chance to check it.



Thank you.

Pavel Afremov.

[classlib][java.math] optimization of BigInteger.modInverse

[Daniel Fridlender]

Hi,

In http://issues.apache.org/jira/browse/HARMONY-2091 there is an
optimization for modInverse.  The issue includes a patch and two html
files showing the performance of the method before and after the
patch.

In order to obtain this optimized version algorithms from the articles
"The Montgomery Modular Inverse - Revisited" (by Savas, E; Koc, C) and
"New Algorithm for Classical Modular Inverse" (by Lórencz, R) were
implemented.  Also some ad-hoc combination of arithmetic operations
were introduced in order to avoid unnecessary creation of intermediate
data.

Thanks,

Daniel

Re: [drlvm] vote on class unloading design (was Class unloading support - tested one approach)

[Etienne Gagnon]

Rana Dasgupta wrote:
> It's worth a lot, since you have implemented this in SableVM yourself.

But I haven't!  I was simply discussing the general design so that I
could suggest it as a term project in SableVM for my Virtual Machine
course, next term. :-)

Etienne

-- 
Etienne M. Gagnon, Ph.D.http://www.info2.uqam.ca/~egagnon/
SableVM:   http://www.sablevm.org/
SableCC:   http://www.sablecc.org/


signature.asc
Description: OpenPGP digital signature

Re: [drlvm] vote on class unloading design (was Class unloading support - tested one approach)

[Xiao-Feng Li]

Yes, I think the discussion on class unloading is one the successful
examples of open community in coming up with a good design and making
design decision. Although the final  design can be one person's
proposal, but it's based on or enlightened by all the participants'
opinions. Eitenne's proposal is a big stride over the original one.

Cheers,
xiaofeng

On 11/8/06, Rana Dasgupta <[EMAIL PROTECTED]> wrote:

It's worth a lot, since you have implemented this in SableVM yourself.
Thanks.

On 11/7/06, Etienne Gagnon <[EMAIL PROTECTED]> wrote:
>
> For what it's worth, I'll add my humble +1.
>
> Etienne
>
> Xiao-Feng Li wrote:
> > Agreed, so plus me.
> >
> > Thanks,
> > xiaofeng
> >
> > On 11/8/06, Rana Dasgupta <[EMAIL PROTECTED]> wrote:
> >
> >> On 11/7/06, Weldon Washburn <[EMAIL PROTECTED]> wrote:
> >> >
> >> > All,
> >> >
> >> > It looks like the debate on class unloading has concluded.
> >> >
> >> > Let's vote on implementing Robin's proposal.
> >> >
> >> > +1
> >> >
> >> >Weldon
> >> >
> >> > PS -- When class unloading gets implemented and committed is a
> seperate
> >> > issue.
> >> >
> >> >
> >> >
> >> > +1 I think it's the best proposal among those that were discuussed
> >>
> >>
> >
>
> --
> Etienne M. Gagnon, Ph.D.http://www.info2.uqam.ca/~egagnon/
> SableVM:   http://www.sablevm.org/
> SableCC:   http://www.sablecc.org/
>
>
>

[stats] harmony cost 46M$ to write

[Stefano Mazzocchi]

Continuing on my stats-a-holism, here is David A. Wheeler's 'sloccount'
run on top of harmony classlib trunk of today

--

SLOCDirectory   SLOC-by-Language (Sorted)
942739  modules java=867844,ansic=61533,cpp=12807,asm=555
4633support java=4629,perl=4
12  depends sh=12

Totals grouped by language (dominant language first):
java:872473 (92.09%)
ansic:61533 (6.50%)
cpp:  12807 (1.35%)
asm:555 (0.06%)
sh:  12 (0.00%)
perl: 4 (0.00%)

Total Physical Source Lines of Code (SLOC)= 947,384
Development Effort Estimate, Person-Years (Person-Months) = 266.92
(3,203.05)
 (Basic COCOMO model, Person-Months = 2.4 * (KSLOC**1.05))
Schedule Estimate, Years (Months) = 4.48 (53.71)
 (Basic COCOMO model, Months = 2.5 * (person-months**0.38))
Estimated Average Number of Developers (Effort/Schedule)  = 59.64
Total Estimated Cost to Develop   = $ 36,057,364
 (average salary = $56,286/year, overhead = 2.40).

--

Then I ran it against the DRLVM trunk of today:

--

SLOCDirectory   SLOC-by-Language (Sorted)
281088  vm  cpp=223849,java=38033,ansic=18140,asm=1066
1093build   ansic=601,java=458,sh=34
401 src_testjava=401

Totals grouped by language (dominant language first):
cpp: 223849 (79.22%)
java: 38892 (13.76%)
ansic:18741 (6.63%)
asm:   1066 (0.38%)
sh:  34 (0.01%)

Total Physical Source Lines of Code (SLOC)= 282,582
Development Effort Estimate, Person-Years (Person-Months) = 74.94 (899.32)
 (Basic COCOMO model, Person-Months = 2.4 * (KSLOC**1.05))
Schedule Estimate, Years (Months) = 2.76 (33.15)
 (Basic COCOMO model, Months = 2.5 * (person-months**0.38))
Estimated Average Number of Developers (Effort/Schedule)  = 27.13
Total Estimated Cost to Develop   = $ 10,123,795
 (average salary = $56,286/year, overhead = 2.40).

---

So, according to Wheeler's metric, Harmony would have taken 46 million
dollars to build.

NOTE: of course I'm perfectly aware that this is an incredibly bogus
metric. I'm also aware that there are days that I write several hundreds
(if not thousands) of lines of code and days that I write one
(especially when it's a nasty bug to fix).

So, while the dollarized metrics are to be taken with a grain of salt
(or tongue-in-cheek if you wish), the SLOC breakdowns by language are
actually useful.

BTW, if you have better suggestions on what folders of our svn repo I
should run this tool against, just say so.

-- 
Stefano.

Re: [drlvm] vote on class unloading design (was Class unloading support - tested one approach)

[Rana Dasgupta]

It's worth a lot, since you have implemented this in SableVM yourself.
Thanks.

On 11/7/06, Etienne Gagnon <[EMAIL PROTECTED]> wrote:


For what it's worth, I'll add my humble +1.

Etienne

Xiao-Feng Li wrote:
> Agreed, so plus me.
>
> Thanks,
> xiaofeng
>
> On 11/8/06, Rana Dasgupta <[EMAIL PROTECTED]> wrote:
>
>> On 11/7/06, Weldon Washburn <[EMAIL PROTECTED]> wrote:
>> >
>> > All,
>> >
>> > It looks like the debate on class unloading has concluded.
>> >
>> > Let's vote on implementing Robin's proposal.
>> >
>> > +1
>> >
>> >Weldon
>> >
>> > PS -- When class unloading gets implemented and committed is a
seperate
>> > issue.
>> >
>> >
>> >
>> > +1 I think it's the best proposal among those that were discuussed
>>
>>
>

--
Etienne M. Gagnon, Ph.D.http://www.info2.uqam.ca/~egagnon/
SableVM:   http://www.sablevm.org/
SableCC:   http://www.sablecc.org/

Re: [drlvm] vote on class unloading design (was Class unloading support - tested one approach)

[Etienne Gagnon]

For what it's worth, I'll add my humble +1.

Etienne

Xiao-Feng Li wrote:
> Agreed, so plus me.
> 
> Thanks,
> xiaofeng
> 
> On 11/8/06, Rana Dasgupta <[EMAIL PROTECTED]> wrote:
> 
>> On 11/7/06, Weldon Washburn <[EMAIL PROTECTED]> wrote:
>> >
>> > All,
>> >
>> > It looks like the debate on class unloading has concluded.
>> >
>> > Let's vote on implementing Robin's proposal.
>> >
>> > +1
>> >
>> >Weldon
>> >
>> > PS -- When class unloading gets implemented and committed is a seperate
>> > issue.
>> >
>> >
>> >
>> > +1 I think it's the best proposal among those that were discuussed
>>
>>
> 

-- 
Etienne M. Gagnon, Ph.D.http://www.info2.uqam.ca/~egagnon/
SableVM:   http://www.sablevm.org/
SableCC:   http://www.sablecc.org/


signature.asc
Description: OpenPGP digital signature

Re: [drlvm] vote on class unloading design (was Class unloading support - tested one approach)

[Xiao-Feng Li]

Agreed, so plus me.

Thanks,
xiaofeng

On 11/8/06, Rana Dasgupta <[EMAIL PROTECTED]> wrote:

On 11/7/06, Weldon Washburn <[EMAIL PROTECTED]> wrote:
>
> All,
>
> It looks like the debate on class unloading has concluded.
>
> Let's vote on implementing Robin's proposal.
>
> +1
>
>Weldon
>
> PS -- When class unloading gets implemented and committed is a seperate
> issue.
>
>
>
> +1 I think it's the best proposal among those that were discuussed

Re: [drlvm] dynamic object layout

[Rana Dasgupta]

Again, this makes sense. Functional completenes is needed, but over a
period, based on when we want to release. Identifying a couple of milestones
before 1.0 for which we choose features to complete, and performance
objectives can help. For each, we can add a bug-fix/stability period.
Branching that happens at the start and end of each milestone automatically
improves stability.
In addition, as Etienne mentions, we should not hesitate to use branches to
partition new platforms, large new development etc. For example GCv5 is
effectively in a branch currently. It is not executed without a specific
command line option and is not picked up by our regular test runs.



On 11/7/06, Tim Ellison <[EMAIL PROTECTED]> wrote:



Just to add my 2c, in that I concur with this position.  There has to be
a judgement call on each of the new areas of functional improvement to
decide whether it will further disrupt improved stability goals.  In
general it is preferable to be solid but functionally incomplete rather
than vice versa.

Regards,
Tim

Re: [drlvm] questions on class unloading (JIRA H2000) and cleaning class.h (JIRA H1558)

[Gregory Shimansky]

On Friday 03 November 2006 19:18 Weldon Washburn wrote:
> H1558 has been a big battle to get it into committable shape.  I would
> really like to commit it first.  (In fact, Pavel and I are working on it
> right now!)

The patch in HARMONY-1558 is huge and often is broken by new VM commits. Shall 
we make a freeze on VM commits to allow this patch it? Maintaining so many 
code changes is probably not an easy task.

I've tried to apply it today and it doesn't apply cleanly (no surprise, 5 days 
passed since the last update). I think some cooperation between VM committers 
is required to allow this patch to be finally integrated into the code.

We should either agree to let it in or let it die. I support the first option.

Weldon, Geir, what do you think?

-- 
Gregory Shimansky, Intel Middleware Products Division

Re: [DRLVM] General stability

[Rana Dasgupta]

+1

This makes more sense than putting a sudden unannounced stop to new
features. Possibly Weldon means "on a case by case basis after risk
assessment". However, announced stability periods at the end of milestones
is a good practice. For example, since we have been focussing on development
for a while, and there are many open JIRA bugs, we could consider rounding
off the year with a "no new features and only bugfixing" period for 3-4
weeks starting December 1, to round off the year. We can fork and create a
development branch to support some new work during this period. Going
forward, we can try to plan for milestones and repeat this
plan-development-stabilization process.

Thanks,
Rana



On 11/7/06, Tim Ellison <[EMAIL PROTECTED]> wrote:


I wouldn't go so far as to label issues as "won't fix" unless they are
really high risk and low value items.

It's useful to go through a stabilization period where the focus is on
getting the code solid again and delaying significant new functionality
until it is achieved.  A plan that aims to deliver stable milestones on
regular periods is, in my experience, a good way to focus the
development effort.

Regards,
Tim

[general] interesting discoveries with japitools - part 2

[Stefano Mazzocchi]

Stuart told me that using the released version of japitools was not
ideal, so I've re-run the tests with the latest version of japitools
from CVS.

I did find a few bugs in japitools when dealing with JRockit and J9
(submitted to the japitools mail list) but there are still interesting
results.

 sun 1.5 vs bea 1.5 

Total: 99.99% good, 0% missing, 0% abs.add

Error Summary:
Methods: 1 missing, 1 abs.add.

Errors:

java.awt.peer:
Missing
method java.awt.peer.WindowPeer.updateFocusableWindowState(): missing in
bea1.5

java.util.concurrent:
Abs.add
method java.util.concurrent.Delayed.compareTo(java.lang.Object): new
interface method in bea1.5


So, it appears that that Sun added a method that is not available in the
javadocs (bad Sun, no donut for you!) and that BEA did not (correctly)
implement.

Also, BEA added the method "compareTo" to the
java.util.concurrent.Delayed interface. This is not really a problem
because Delayed extends Comparable, therefore all classes implementing
Delayed will have to have the compareTo method anyway.

Stuart, do you think this is something that japitools should check?

I would call this a false positive.



 sun 1.5 vs ibm 1.5 ===

Total: 99.93% good, 0% bad, 0.06% missing, 0% abs.add

Error Summary:
Classes: 2 missing.
Fields: 1 bad.
Methods: 5 missing, 6 abs.add.

Errors:

java.awt.peer:
Missing
method java.awt.peer.WindowPeer.updateFocusableWindowState(): missing in
ibm1.5

java.util.concurrent:
Abs.add
method java.util.concurrent.Delayed.compareTo(java.lang.Object): new
interface method in ibm1.5

javax.xml.datatype:
Bad
field
javax.xml.datatype.DatatypeFactory.DATATYPEFACTORY_IMPLEMENTATION_CLASS:
constant
[com.sun.org.apache.xerces.internal.jaxp.datatype.DatatypeFactoryImpl]
in sun1.5, but constant
[org.apache.xerces.jaxp.datatype.DatatypeFactoryImpl] in ibm1.5

org.omg.stub.javax.management.remote.rmi:
Missing
class org.omg.stub.javax.management.remote.rmi._RMIConnectionImpl_Tie:
missing in ibm1.5
class org.omg.stub.javax.management.remote.rmi._RMIServerImpl_Tie:
missing in ibm1.5

org.w3c.dom.html:
Missing
method org.w3c.dom.html.HTMLFrameElement.getContentDocument(): missing
in ibm1.5
method org.w3c.dom.html.HTMLIFrameElement.getContentDocument(): missing
in ibm1.5
method org.w3c.dom.html.HTMLObjectElement.getContentDocument(): missing
in ibm1.5
method org.w3c.dom.html.HTMLOptionElement.setSelected(boolean): missing
in ibm1.5
Abs.add
method org.w3c.dom.html.HTMLOptionElement.setIndex(int): new interface
method in ibm1.5
method org.w3c.dom.html.HTMLTableCellElement.setCellIndex(int): new
interface method in ibm1.5
method
org.w3c.dom.html.HTMLTableRowElement.setCells(org.w3c.dom.html.HTMLCollection):
new interface method in ibm1.5
method org.w3c.dom.html.HTMLTableRowElement.setRowIndex(int): new
interface method in ibm1.5
method org.w3c.dom.html.HTMLTableRowElement.setSectionRowIndex(int): new
interface method in ibm1.5

So, it seems that the new japitools does fix some problems. The first
two are the same as with BEA. The datatype factory is not problematic.
The RMI over IIOP stubs should probably be ignored.

The only substantial difference is the HTML DOM (which nobody uses anyway).

Now the reverse checks

== bea 1.5 vs sun 1.5 ==

Total: 100% good, 0% abs.add

Error Summary:
Methods: 2 abs.add.

Errors:

java.awt.peer:
Abs.add
method java.awt.peer.WindowPeer.updateFocusableWindowState(): new
interface method in sun1.5

java.util.concurrent:
Abs.add
method java.util.concurrent.Delayed.compareTo(java.lang.Object): new
interface method in sun1.5
Done.

Hmmm, the compareTo is in both the direct and the reverse? smells like a
japitool bug to me.


=== IBM 1.5 vs. Sun 1.5 

Total: 99.78% good, 0% bad, 0.21% missing, 0% abs.add

Error Summary:
Packages: 4 missing.
Classes: 2 missing.
Fields: 1 bad.
Methods: 6 missing, 6 abs.add.

Errors:

java.lang:
Missing
method java.lang.StringBuilder.append(java.lang.StringBuilder): missing
in sun1.5

java.awt.peer:
Abs.add
method java.awt.peer.WindowPeer.updateFocusableWindowState(): new
interface method in sun1.5

java.util.concurrent:
Abs.add
method java.util.concurrent.Delayed.compareTo(java.lang.Object): new
interface method in sun1.5

javax.management.remote.rmi:
Missing
class javax.management.remote.rmi._RMIConnectionImpl_Tie: missing in sun1.5
class javax.management.remote.rmi._RMIServerImpl_Tie: missing in sun1.5

javax.xml.datatype:
Bad
field
javax.xml.datatype.DatatypeFactory.DATATYPEFACTORY_IMPLEMENTATION_CLASS:
constant [org.apache.xerces.jaxp.datatype.DatatypeFactoryImpl] in
ibm1.5, but constant
[com.sun.org.apache.xerces.internal.jaxp.datatype.DatatypeFactoryImpl]
in sun1.5

org.omg.stub.java.lang:
Missing
package org.omg.stub.java.lang: missing in sun1.5

org.omg.stub.java.security:
Missing
package org.omg.stub.java.security: missing in sun1.5

org.omg.stub.java.util:
Missing
package org.omg.stub.java.util: missing in sun1

Re: [DRLVM] General stability

[Tim Ellison]

I wouldn't go so far as to label issues as "won't fix" unless they are
really high risk and low value items.

It's useful to go through a stabilization period where the focus is on
getting the code solid again and delaying significant new functionality
until it is achieved.  A plan that aims to deliver stable milestones on
regular periods is, in my experience, a good way to focus the
development effort.

Regards,
Tim

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  we lack the regression testing
> to really find threading bugs, test the fixes and test against regression.
> No doubt there are similar problems in other VM subsystems.   "build test"
> is necessary but not sufficient for where we need to go.  In a sense,
> committing code with only "build test" to prevent regression is the
> equivalent to flying in the fog without instrumentation.
> 
> So that we can get engineers focused on stability, I am thinking of coding
> the JIRAs that involve new features as "later" or even "won't fix".  Please
> feel free to comment.
> 
> We also need to restart the old email threads on regression tests.  For
> example, we need some sort of automated test script that runs Eclipse and
> tomcat, etc. in a deterministic fashion so that we can compare test
> results.  It does not have to be perfect for starts, just repeatable and
> easy to use.  Feel free to beat me to starting these threads :)
> 

-- 

Tim Ellison ([EMAIL PROTECTED])
IBM Java technology centre, UK.

Re: [drlvm] dynamic object layout

[Tim Ellison]

Geir Magnusson Jr. wrote:
> 
> Alexei Fedotov wrote:
>> Weldon,
>>
>> I agree with you that it is nearly impossible to achieve stability for
>> a branch under active development.
>>
>>  From the other side, adding new features is fun, and also has a reason
>> behind it. If we strive for a complete implementation of J2SE, we
>> cannot avoid this type of activity.
>>
>> So my suggestion is to create separate branches for new features which
>> could be merged into the main branch when mature enough to achieve an
>> appropriate level of stability. What do you think?
> 
> Well, there's a couple of things here.  Any committer is free to go off
> into a sandbox to do something radical.  However, there are features we
> simply need - class unloading, for example - that aren't new features
> being done just for fun.
> 
> Things are complicated and we've seen how some features from the past,
> say the TM or invocation API, were done off in a corner, that led to two
> problems when brought forward -
> 
> 1) There were lots of others that had useful input who weren't able to
> contribute until the feature was finished  and
> 
> 2) The iterations of discussion about the patch while ongoing progress
> was happening in the trunk made the big patches stale, which made it
> hard for people to examine, test and comment on.
> 
> I think that for something like this, we should evaluate the "new ideas"
> on the merit, and decide if it's critical to our goal of a competitive,
> compatible Harmony v1.0 (for example, class unloading) or simply a
> nice-to-have improvement (GCv5, maybe).
> 
> We have a really difficult job to do in the next 7.5 months - to get to
> a compatible 1.0* - so I'd like to encourage people to remain as focused
> as we can to get to that point.  That doesn't mean this isn't fun, but
> the way I see it, we have a few focused months of efforts before we
> begin TCK testing, and we probably need to make some hard choices to
> delay stuff.  We're a mighty community, but a relatively small one, so
> the more of us rowing in the same direction, the better.
> 
> So if JVMTI is slow?  What's the tradeoff?  My persoal perference would
> be to take stability for now, and revisit the JVMTI  performance later...

Just to add my 2c, in that I concur with this position.  There has to be
a judgement call on each of the new areas of functional improvement to
decide whether it will further disrupt improved stability goals.  In
general it is preferable to be solid but functionally incomplete rather
than vice versa.

Regards,
Tim

> geir
> 
> * Yeah, I dream of Harmony as the first compatible open source
> implementation of the JDK, beating Sun...
> 
> 
>>
>> Alexei
>>
>> On 11/3/06, Weldon Washburn <[EMAIL PROTECTED]> wrote:
>>> Salikh,
>>>  I glanced at the patch.  What you propose below looks reasonable.  I
>>> really
>>> don't see any other way to do it and still get "usable" performance.
>>>
>>> All,
>>> My only worry is disturbing highly critical code like object layout. 
>>> Given
>>> that this JIRA has been open a long time, I guess its OK to apply the
>>> patch.  At some point, we need to stop adding functionality and focus on
>>> stability.
>>>
>>>
>>>
>>> On 11/3/06, Salikh Zakirov <[EMAIL PROTECTED]> wrote:
>>> >
>>> > Hi,
>>> >
>>> > I am currently continuing to work on improving JVMTI Heap Iteration
>>> > (HARMONY-1635),
>>> > particularly, tagging objects.
>>> >
>>> > The use case that I've heard of is tagging *all* objects for the
>>> purpose
>>> > of memory
>>> > profiling. According to what I've heard it causes 60x slowdown on
>>> Sun's
>>> > VM.
>>> > However, the initial tags implementation that I've uploaded to
>>> > HARMONY-1635
>>> > is far worse, as it uses linear search for get/set tag operations.
>>> >
>>> > (* for those who didn't read JVMTI spec, tags are jlong (8 byte
>>> integer)
>>> > values,
>>> > which can be attached to arbitrary objects in get/set manner *)
>>> >
>>> > The alternative approach I came up with is to use (mostly) constant
>>> time
>>> > algorithms
>>> > for get/set operations, is to store a tag pointer in each object.
>>> > Storing tag itself in an object is not an option, as JVMTI requires to
>>> > send
>>> > OBJECT_FREE events with tags for each reclaimed objects, and this
>>> > information would not be
>>> > available if the tag would be reclaimed together with the object.
>>> >
>>> > However, since the general consensus was that increasing object
>>> header is
>>> > highly undesired,
>>> > I've tried to implement the _conditional_ increase in object header.
>>> > Additional object header field is allocated in case JVMTI Agent has
>>> > requested
>>> > can_tag_objects capability.
>>> >
>>> > The modified object layout I used is as follows:
>>> >
>>> > +---+
>>> > |   VTable pointer  |
>>> > +---+
>>> > |  lockword |
>>> > +---+
>>> > |   [array length]  |
>>> > +---+
>>> > |   [tag pointer]   |
>>> > +

Re: [general] Transition to TLP

[Tim Ellison]

Just give a shout if I can help with any infra tasks for the transition.

Regards,
Tim

Geir Magnusson Jr. wrote:
> I was going to start organizing the infrastructure transition to TLP. On
> the list are :
> 
> 1) website goes to "http://harmony.apache.org/";
> 
> 2) mail lists become
> 
>  [EMAIL PROTECTED]
> 
> etc.  This will be transparent - we'll move subscribers over, and I
> suppose we forward @incubator traffic to @harmony.
> 
> 3) move SVN from it's /incubator/harmony root to just /harmony and
> associated permissioning change (all internal to our SVN permissioning
> scheme)
> 
> 4) minor tweaks like changing location of snapshots, slight mods to
> website, tweak in JIRA to change our 'group' or whatever it's called,
> touch up's here and there on the wiki
> 
> Anything else?  I did ponder changes to our mail list.  I think adding a
> user list is something good to do now as it's non-disruptive, but I'm
> not convinced that breaking up the dev list is something needed at this
> point - I'd rather see us minimize the changes during this transition
> and do it later once settled.  I'm also still worried about fracturing
> things - it's wonderful to see us working as one community.
> 
> geir
> 

-- 

Tim Ellison ([EMAIL PROTECTED])
IBM Java technology centre, UK.

Re: Japi diffs for harmony

[Tim Ellison]

Stuart Ballard wrote:
> Wow, I'm impressed that harmony is 94.66 against 1.5. That's
> incredibly good progress - especially if all of that is actual
> functional implementations rather than stubbed out methods. (If you
> have stubbed out methods by the way, I suggest defining a
> RuntimeException subclass called "NotImplementedException" in any
> package and adding it to the throws clause of the methods in question.
> Japi will recognize those methods as not implemented.

I'm no fan of stubs for just such reason.  But for those dev's that are
following along, there is an
org.apache.harmony.luni.util.NotYetImplementedException that is defined
for just such purposes.

Regards,
Tim

-- 

Tim Ellison ([EMAIL PROTECTED])
IBM Java technology centre, UK.

Re: [general] Interesting discoveries playing around with japitools

[Tim Ellison]

Stefano Mazzocchi wrote:
> 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 breaking WORA or things like that.
> 
> It's obviously just a bug somewhere, in japitools, in the TCK coverage
> tests, in the IBM JVM class library or (more likely) in a weird
> combination of all of the above.
> 
> What I want to emphasize (especially to the Sun officials that watch us)
> is that not only open source is not about breaking compatibility, but
> it's able to catch incompatibilities that not even Sun did. ;-)

Understood, but thanks for making it clear.  I always prefer the
'cock-up' theory to the 'conspiracy' theory for such things ;-)

I can't see the Sun-based code delivered in IBM 1.5, so had to go
through other people who can to get some answers.  Here's what I found
out, slightly reformatted from your original listing:


 == sun 1.5 vs. ibm1.5 ==

 java.awt.peer:
 Method java.awt.peer.WindowPeer.updateFocusableWindowState() is missing
in IBM1.5

The claim is that this method doesn't exist in Sun code either (as I
said above, I can't check directly).  This package isn't listed in the
JSE5.0 javadoc.

 javax.xml.datatype:
 Field
javax.xml.datatype.DatatypeFactory.DATATYPEFACTORY_IMPLEMENTATION_CLASS
has value
 “com.sun.org.apache.xerces.internal.jaxp.datatype.DatatypeFactoryImpl”
in Sun1.5, but value
 “org.apache.xerces.jaxp.datatype.DatatypeFactoryImpl” in IBM1.5

This is deliberate, since IBM doesn't do the 'com.sun' package renaming,
so this field has the name of the actual type that is to be used as the
factory impl.

 org.omg.stub.javax.management.remote.rmi:
 Class org.omg.stub.javax.management.remote.rmi._RMIConnectionImpl_Tie
missing in IBM1.5
 Class org.omg.stub.javax.management.remote.rmi._RMIServerImpl_Tie
missing in IBM1.5

This package is not part of the JSE API (but the inconsistency is being
checked).

 org.w3c.dom.html:
 method org.w3c.dom.html.HTMLFrameElement.getContentDocument() missing
in IBM1.5
 method org.w3c.dom.html.HTMLIFrameElement.getContentDocument() missing
in IBM1.5
 method org.w3c.dom.html.HTMLObjectElement.getContentDocument(): missing
in IBM1.5
 method org.w3c.dom.html.HTMLOptionElement.setSelected(boolean): missing
in IBM1.5

This package is also not part of the JSE API (but the inconsistency is being
checked).

   - o -

 == ibm1.5 vs. sun1.5 ==

 java.lang:
 method java.lang.StringBuilder.append(java.lang.StringBuilder): missing
in Sun1.5

This is a bug in the IBM impl. you can expect that method to disappear.

 javax.management.remote.rmi:
 Class javax.management.remote.rmi._RMIConnectionImpl_Tie missing in Sun1.5
 Class javax.management.remote.rmi._RMIServerImpl_Tie missing in Sun1.5

This also looks like a bug in the IBM impl (and looking at how the type
names match those listed above as missing in org.omg.stub... it looks to
me like the Ties were somehow created in the wrong package).

 javax.xml.datatype:
 Field
javax.xml.datatype.DatatypeFactory.DATATYPEFACTORY_IMPLEMENTATION_CLASS
has value   "org.apache.xerces.jaxp.datatype.DatatypeFactoryImpl” in
IBM1.5, but value
 “com.sun.org.apache.xerces.internal.jaxp.datatype.DatatypeFactoryImpl”
in Sun1.5

This is the same String const case as listed above.

... and the remainder of these are non-JSE-API packages.  Again, the
difference is being checked.

 org.omg.stub.java.lang:
 Package org.omg.stub.java.lang: missing in Sun1.5

 org.omg.stub.java.security:
 Package org.omg.stub.java.security: missing in Sun1.5

 org.omg.stub.java.util:
 Package org.omg.stub.java.util: missing in Sun1.5

 org.w3c.dom.html:
 Method org.w3c.dom.html.HTMLOptionElement.setIndex(int) missing in Sun1.5
 Method org.w3c.dom.html.HTMLTableCellElement.setCellIndex(int) missing
in Sun1.5
 Method
org.w3c.dom.html.HTMLTableRowElement.setCells(org.w3c.dom.html.HTMLCollection)
missing in Sun1.5
 Method org.w3c.dom.html.HTMLTableRowElement.setRowIndex(int) missing in
Sun1.5
 Method org.w3c.dom.html.HTMLTableRowElement.setSectionRowIndex(int)
missing in Sun1.5

 org.w3c.dom.xpath:
 Package org.w3c.dom.xpath: missing in Sun1.5

   - o -

Thanks again for pointing these out.  Of course, the IBM Java SDKs all
pass the JCK, so it may be that we require additional signature tests to
catch some of these.

Regards,
Tim

-- 

Tim Ellison ([EMAIL PROTECTED])
IBM Java technology centre, UK.

[classlib] [suncompat] completion (was; Re: [classlib]Harmony classlib with J9 VM passes all the tests provided by JUnit4.1)

[Tim Ellison]

Nathan Beyer wrote:
> I believe we're down to agreeing to the Objects/Threads classes [1] in
> luni-kernel and getting them implemented in DRLVM and the donated IBM
> VM. I believe the Unsafe class needs to be re-implemented with these
> interfaces, but that may already be done.

yes, we are very close so should finish this off.

Also FYI, I was looking at our Unsafe I've just added a security check
and extra initialization.

Regards,
Tim

-- 

Tim Ellison ([EMAIL PROTECTED])
IBM Java technology centre, UK.

Re: [classlib]Harmony classlib with J9 VM passes all the tests provided by JUnit4.1

[Tim Ellison]

Richard Liang wrote:
> On 11/7/06, Nathan Beyer <[EMAIL PROTECTED]> wrote:
>> I believe we're down to agreeing to the Objects/Threads classes [1] in
>> luni-kernel and getting them implemented in DRLVM and the donated IBM
>> VM. I believe the Unsafe class needs to be re-implemented with these
>> interfaces, but that may already be done.
> 
> Yes, I just run testNG successfully by appending suncompat.jar and
> luni-kernel-stubs.jar to bootclasspath ;-)

Why do you need to put the stubs on the bootclasspath? and there is a
sun.misc.Unsafe in the DRLVM kernel.jar so I expect you are using that.

We need to agree on the extensions to the luni kernel classes so that we
can implement them in the IBM VME too (and then share the Unsafe in
suncompat).

Regards,
Tim

-- 

Tim Ellison ([EMAIL PROTECTED])
IBM Java technology centre, UK.

Re: [classlib] NLS exception messages arn't displayed correctly

[Tim Ellison]

Oliver Deakin wrote:
> Hi all,
> 
> I was checking out some JIRAs and spotted that when we
> print exception stack traces at the moment we're not getting
> the full NLS message. For example, running the following:
> 
> public class Test {
>  public static void main(String[] args) throws Throwable {
>  throw new NullPointerException();
>  }
> }
> 
> prints:
> 
> K0319java.lang.NullPointerException
>at Test.main(Test.java:3)
> FAILED to invoke JVM.
> 
> I can spot 2 things wrong with this output (pats on the back
> if you spot more!):
> 1) K0319 should actually say something like
> 'Exception in thread "main" '. It looks like out NLS messages
> arn't being printed correctly - anyone got any ideas about this
> one?

The message was missing in the catalog.  I added it in r472226.

> 2) The bogus "FAILED to invoke JVM" message.
> Looks like this is coming from the launcher (Im running
> Harmony + IBM VME).
> It appears that this happens because in main_runJavaMain
> (in the launcher main.c) after we make the CallStaticVoidMethod()
> call to run main, we do the following:
> 
> if ((*env)->ExceptionCheck (env))
>{
>  if (rc == 0)
>rc = 100;
>}
> 
> which causes a return code of 100 to be passed back to
> gpProtectedMain() via the invocation() function, where it is used
> in the following way:
> 
> if (invocation(...))
>{
>  hytty_printf (PORTLIB, "FAILED to invoke JVM.\n");
>  goto bail;
>}
> 
> I imagine this misleading message also appears with DRLVM?
> I'm not setup at the moment to test it.
> Is there a reason we set the return code to 100 if there's an
> unhandled exception?

I'll leave that one for the person who changed the code ;-)

Regards,
Tim

-- 

Tim Ellison ([EMAIL PROTECTED])
IBM Java technology centre, UK.

RE: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs)

[Morozova, Nadezhda]

Well, 
I guess the simplest solution would be to add the link to the
Conventions section on the front page of wiki. You can do it yourself!
Adding a link from the static website would also be useful. Candidates:
http://incubator.apache.org/harmony/guidelines.html 
http://incubator.apache.org/harmony/get-involved.html 

it's not quite convenient for me just now to add patches, so if someone
volunteers to help, I'd be grateful.

Thank you, 
Nadya Morozova
 

-Original Message-
From: Alexey Petrenko [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, November 07, 2006 4:44 PM
To: harmony-dev@incubator.apache.org
Subject: Re: [jira] Good issue resolution guideline (was:
[classlib]volunteer to supply patches for old JIRAs)

Nadya,

we definetly need a link to this page. That's not a question.
Question is where to place the link.
And as I said in previous email link place suggestions are welcome.

SY, Alexey

2006/11/7, Morozova, Nadezhda <[EMAIL PROTECTED]>:
> Alexey,
> Would be great if there we some page that had a link to the page;
> otherwise, you cannot find it from within wiki, only from the link in
> your mail :(
>
> Thank you,
> Nadya Morozova
>
>
> -Original Message-
> From: Alexey Petrenko [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, November 07, 2006 1:32 PM
> To: harmony-dev@incubator.apache.org
> Subject: Re: [jira] Good issue resolution guideline (was:
> [classlib]volunteer to supply patches for old JIRAs)
>
> I've published "Good issue resolution guideline" on Harmony site:
> http://incubator.apache.org/harmony/issue_resolution_guideline.html
> (wait for a while for the web site synchronization). It is not linked
> to other pages yet.
>
> So comments to guideline and link place suggestions are welcome.
>
> SY, Alexey
>
> 2006/9/28, Geir Magnusson Jr. <[EMAIL PROTECTED]>:
> >
> > On Sep 28, 2006, at 3:21 AM, Alexey Petrenko wrote:
> >
> > > Guys,
> > >
> > > Since there is no additional comments on this guideline...
> > >
> > > Let's put it somewhere.
> > > We got two options: Harmony site and wiki.
> > > I prefer wiki because it will be easy to edit it and I can put it
> > > there myself :)
> >
> > And if you put in a patch for website, we can get it there too :)
if
> > you put in wiki, I'm going to take and put on site, so maybe save us
> > some effort? (ok, save me the effort...)
> >
> > geir
> >
> > >
> > > Thoughts?
> > >
> > > SY, Alexey
> > >
> > > 2006/9/26, Alexey Petrenko <[EMAIL PROTECTED]>:
> > >> I've combined all the comments again.
> > >>
> > >> And here is the last version. I hope... :)
> > >>
> > >> === cut ===
> > >> Preface
> > >> This guideline covers a wide range of issues but not all of them.
> > >> If you cannot do one of the steps, then write a comment to the
> issue.
> > >> Use your common sense!
> > >>
> > >> Issue reporter:
> > >> 1. Explicitly state the expected behavior and the
> > >> actual behavior of Harmony code. Use links to specs, rfcs, etc.
> > >> 2. Try to create as small a test case as possible. A patch
> > >> to test will be highly appreciated.
> > >> 3. Provide max. information about steps necessary to recreate the
> > >> bug.
> > >> If a patch for the test has not been supplied, provide as much
> > >> diagnostic information about the failure as possible (stack
trace,
> > >> failure output, expected output etc).
> > >> 4. Remember to use issue links if applicable.
> > >> 5. Check the issue resolution when it is committed. Add a
comment.
> > >>
> > >> Resolution provider :) :
> > >> Depending on the type of issue, do the following:
> > >>
> > >> 1. Issue is probably a non-bug difference, not a bug or invalid:
> > >>   1.1. Discuss on the dev list.
> > >>   1.2. Add a link to the discussion thread as a comment to issue.
> > >> 2. Issue is a bug:
> > >>   2.1. Notify the community that you started investigation by
> adding
> > >> a comment to the issue and send a message to dev list. If you
> cannot
> > >> produce a patch, add another comment with the results of your
> > >> investigation.
> > >>   2.2. If reporter did not provide a patch to test:
> > >>   2.2.1. Try to create a patch to test.
> > >>   2.2.2. If you cannot produce a patch, write a comment about
> it.
> > >>   2.3. Create a patch to fix the issue
> > >>   2.3.1. Any concerns? Discuss on the dev list. Add a link to
> > >> discussion as a comment.
> > >>   2.4. All the pacthes (test and fix) should be relative to the
> > >> directory where the main build.xml is:
> > >> https://svn.apache.org/repos/asf/incubator/harmony/enhanced/
> > >> classlib/trunk.
> > >> Or to the module root directory.
> > >>   2.5. Test and fix patches should be in different files.
> > >>   2.6. If the patch requires to add, remove or move some files in
> the
> > >> repository, add the appropriate script.
> > >>   2.6. Check that all unit tests pass.
> > >>   2.8. If it is an application-oriented issue, check the
> application.
> > >>   2.9. Remember to use issue links if applicable.
> > >>
> > >> Committer:
>

Re: [drlvm] vote on class unloading design (was Class unloading support - tested one approach)

[Rana Dasgupta]

On 11/7/06, Weldon Washburn <[EMAIL PROTECTED]> wrote:


All,

It looks like the debate on class unloading has concluded.

Let's vote on implementing Robin's proposal.

+1

   Weldon

PS -- When class unloading gets implemented and committed is a seperate
issue.



+1 I think it's the best proposal among those that were discuussed

[drlvm] vote on class unloading design (was Class unloading support - tested one approach)

[Weldon Washburn]

All,

It looks like the debate on class unloading has concluded.

Let's vote on implementing Robin's proposal.

+1

   Weldon

PS -- When class unloading gets implemented and committed is a seperate
issue.



-- Forwarded message --
From: Robin Garner <[EMAIL PROTECTED]>
Date: Nov 2, 2006 6:16 PM
Subject: Re: [drlvm] Class unloading support - tested one approach
To: harmony-dev@incubator.apache.org

Xiao-Feng Li wrote:

Robin, good idea.

I understand the main difference between your design and Aleksey's
proposal 1 is, the tracing in your design stops as vtable, but
Aleksey's continues to classloader. On the other hand, your approach
requires an extra step to sweep the vtables in order to determine the
classloaders' reachability.


Actually there are quite a few more differences:
- This mark phase is built into the standard GC trace, like Aleksey's
automatic class unloading proposal.
- This approach requires no additional fields in headers or objects
(except maybe something to allow enumeration of vtables if this doesn't
already exist)
- The additional mark comes at an extremely low cost as discussed
previously.

The operation to sweep vtables is very cheap, and only needs to be done
when you believe there are classloaders that can be unloaded, rather
than at every GC.  You might for example trigger class unloading every
time a new classloader is loaded.


If this is true, why not just let the tracing to continue as a
complete step to determine the classloaders' reachability?


Because that adds a large overhead to every GC, and requires vtables and
classloader structures to be traced at every GC.  While the numbers of
vtables is not large, the number of pointers to them is.  The particular
flavour of mark in my proposal is much cheaper than the standard test
and mark operation.


Another difference is to mark the reachability with an unconditional
write instead of a bit mask write. I think this can be applied to
either approach.


Not really.

If you use an unconditional mark, you lose the ability to test whether
any particular mark is the first, and therefore enqueue an object for
scanning only once, and therefore the heap trace can never complete.
You can only use unconditional marks to process 'leaf' objects in the heap.

You can always turn a bit map into a byte map and avoid synchronized
update, but you can't eliminate the dependent load in a standard trace
algorithm.  The difference in performance between a load-test-write and
a load-test-mask-write is insignificant.


Of course a separate trace of the heap is an attractive operation - in
MMTk, this is simple to build because the transitive closure code can
simply be subclassed (eg the sanity checker is ~250 lines of code).
Depending on how reusable the DRLVM heap trace code is, this may or may
not be a good option.

cheers,
Robin



Thanks,
xiaofeng

On 11/1/06, Robin Garner <[EMAIL PROTECTED]> wrote:

Actually, just thinking about how I would implement this in JikesRVM, I
would use the reachability based algorithm, but piggyback on the
existing GC mechanisms:

- Allocate a byte (or word) in each vtable for the purpose of tracking
class reachability.
- Periodically, at a time when no GC is running (even the most
aggressive concurrent GC algorithms have these, I believe), zero this
flag across all vtables.  This is the beginning of a class-unloading
epoch.
- During each GC, when the GC is fetching the GC map for an object,
*unconditionally* write a value to the class reachability byte.  It may
make sense for this byte to be in either the first cache-line of the
vtable, or the cache line that points to the GC map - just make sure the
mark operation doesn't in general fetch an additional cache line.
- At a point in the sufficiently far future, when all reachable objects
are known to have been traced by the GC, sweep the vtables and check the
reachability of the classloaders.

The features of this approach are:

- Minimal additional work at GC time.  The additional write will cause
some additional memory traffic, but a) it's to memory that is already
guaranteed to be in L1 cache, and b) it's an unconditional independent
write, and c) multiple writes to common classes will be absorbed by the
write buffer.

- Space cost of at most 1 word per vtable.

- This works whether vtables are objects or VM structures

- If the relationship between a class and a vtable is not 1:1, this only
need affect the periodic sweep process, which should be infrequent and
small compared to a GC.

- shouldn't need a stop-the-world at any point.

I've implemented and tested the GC-relevant part of this in JikesRVM,
and the GC time overhead appears to be just under 1% in the MMTk
MarkSweep collector.

cheers,
Robin





--
Weldon Washburn
Intel Enterprise Solutions Software Division

RE: [doc] What should be improved in DRLVM Doxygen documentation?

[Morozova, Nadezhda]

Mikhail,
Do you think it is part of 'culture' to update a comment when changing
behavior of its function? Otherwise, you can erase all comments
altogether since you don't guarantee they're up-to-date :) 

Thank you, 
Nadya Morozova
 
-Original Message-
From: Mikhail Fursov [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, November 07, 2006 4:30 PM
To: harmony-dev@incubator.apache.org
Subject: Re: [doc] What should be improved in DRLVM Doxygen
documentation?

On 07 Nov 2006 19:08:35 +0600, Egor Pasko <[EMAIL PROTECTED]> wrote:
>
>
> > Another problem: anyone who changes a document behaviour must update
> > comments too :(
>
> excuse me, what is "document behaviour"? :)
>

Read it as 'method/function behaviour'.  I mean if you have good
comments in
file you can't submit a patch with code refactoring without update in
comments. Does it become a new requirement?

IMO we should start to collect metrics and add comments for
intercomponent
interfaces only (vm/include/*).


-- 
Mikhail Fursov

[classlib] NLS exception messages arn't displayed correctly

[Oliver Deakin]

Hi all,

I was checking out some JIRAs and spotted that when we
print exception stack traces at the moment we're not getting
the full NLS message. For example, running the following:

public class Test {
 public static void main(String[] args) throws Throwable {
 throw new NullPointerException();
 }
}

prints:

K0319java.lang.NullPointerException
   at Test.main(Test.java:3)
FAILED to invoke JVM.

I can spot 2 things wrong with this output (pats on the back
if you spot more!):
1) K0319 should actually say something like
'Exception in thread "main" '. It looks like out NLS messages
arn't being printed correctly - anyone got any ideas about this
one?

2) The bogus "FAILED to invoke JVM" message.
Looks like this is coming from the launcher (Im running
Harmony + IBM VME).
It appears that this happens because in main_runJavaMain
(in the launcher main.c) after we make the CallStaticVoidMethod()
call to run main, we do the following:

if ((*env)->ExceptionCheck (env))
   {
 if (rc == 0)
   rc = 100;
   }

which causes a return code of 100 to be passed back to
gpProtectedMain() via the invocation() function, where it is used
in the following way:

if (invocation(...))
   {
 hytty_printf (PORTLIB, "FAILED to invoke JVM.\n");
 goto bail;
   }

I imagine this misleading message also appears with DRLVM?
I'm not setup at the moment to test it.
Is there a reason we set the return code to 100 if there's an
unhandled exception?

Regards,
Oliver

--
Oliver Deakin
IBM United Kingdom Limited

Re: [drlvm][sablevm] Desing of Class Unloading Support

[Weldon Washburn]

On 11/7/06, Ivan Volosyuk <[EMAIL PROTECTED]> wrote:


On 07 Nov 2006 14:35:55 +0600, Egor Pasko <[EMAIL PROTECTED]> wrote:
> > I already have one idea how to benefit from movable vtables.



There would have to be a very compelling argument for making vtables
movable.  Like a business workload that Harmony needs to run within the next
12 months.



> in GCV4.1? :)

Yes

--
Ivan
Intel Enterprise Solutions Software Division





--
Weldon Washburn
Intel Enterprise Solutions Software Division

Re: [classlib]Harmony classlib with J9 VM passes all the tests provided by JUnit4.1

[Paulex Yang]

Nathan Beyer wrote:

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 do you mean?
Nothing but a joke:). I mean, the TestNG depends on j.u.c, so that it
cannot be used for months, so people may think let's just use JUnit
instead...

Ignore it, I'm all for TestNG...:)


If you're looking for another opinion, I'm not convinced. JUnit 4.x
seems just as capable as TestNG.
There was a(or several?) long long thread discussing the TestNG/JUnit 4 
comparison, and IIRC most people prefer TestNG at that time, I just 
don't want to trig another thread on this topic...We have waited so long 
for TestNG, so let's just go for it if nothing is preventing us now...:)


-Nathan


>
> geir
>
>>
>> Paulex - being desperate
>>
>


--
Paulex Yang
China Software Development Lab
IBM








--
Paulex Yang
China Software Development Lab
IBM

Re: [Fwd: Re: Interesting discoveries playing around with japitools]

[Stuart Ballard]

On 11/7/06, Stefano Mazzocchi <[EMAIL PROTECTED]> wrote:

btw, I signed up on the japi mail list, so I think we should take it
from there.


cc'ing both harmony-dev and japitools-list for now so that at least
harmony folks are aware the discussion is moving. Feel free to just
stick to japitools-list for followups.


If you need some CSS/webdesign skills, I'll be happy to give a hand.


Heh, yeah, I know it's ugly. I generally know enough CSS and HTML to
achieve a particular desired result - it's knowing *what* desired
result I want to achieve that's tricky.

In theory I like the idea of a site that mimics the look of the
results pages somewhat, since that's what most people know Japitools
from. It'd be great if that could be achieved while still being
attractive and usable though.


> I'd really love if some Harmony developers would join the japitools
> mailing list if you're interested in the Japi results and how to make
> best use of them. I plan to announce both the lists and the new
> website more prominently when I have a new release to announce as
> well, but seeing as there was active discussion going on right now, I
> didn't want to wait.

oh, didn't even know one existed.


It didn't. I created it about 2 days ago ;)


> (Yes, the japitools list is on an FSF server. I really really hope
> that this isn't going to be a political problem for you guys. I
> selected Savannah for hosting japitools before Harmony even existed,
> because it made most sense at the time when Classpath developers were
> the main users. Please don't let that hinder our ability to
> communicate on something that makes sense for all projects concerned)

you kidding? of course I'll join.


I'm never quite sure. Some of the politics between the Classpath and
Harmony projects have been quite scary from my point of view.

Stuart.
--
http://sab39.dev.netreach.com/

Re: [classlib]Harmony classlib with J9 VM passes all the tests provided by JUnit4.1

[Paulex Yang]

Richard Liang wrote:

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 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.u.c, so 
that it

> > cannot be used for months, so people may think let's just use JUnit
> > instead...
> >
>
> What's left for j.u.c?  I lost track of that Saga, IIRC.

I believe we're down to agreeing to the Objects/Threads classes [1] in
luni-kernel and getting them implemented in DRLVM and the donated IBM
VM. I believe the Unsafe class needs to be re-implemented with these
interfaces, but that may already be done.


Yes, I just run testNG successfully by appending suncompat.jar and
luni-kernel-stubs.jar to bootclasspath ;-)

So you mean we can start the TestNG migration work at any time?





-Nathan

[1] 
http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/modules/luni-kernel/src/main/java/org/apache/harmony/kernel/vm/ 



>
> > Ignore it, I'm all for TestNG...:)
> >>
> >> geir
> >>
> >>>
> >>> Paulex - being desperate
> >>>
> >>
> >
> >
>
>







--
Paulex Yang
China Software Development Lab
IBM

Re: [compatibility] Compatibility guideline and HARMONY-2085

[Alexey Petrenko]

But Harmony provides more info...
Anyway if we agreed to be compatible with RI in toString messages we
should do this. So thanks for you patch :)

SY, Alexey

2006/11/7, Miguel Montes <[EMAIL PROTECTED]>:

Alexey:
Although it's no big deal, I think is useful to be compatible with the RI in
this issue.
The RI version is simpler, and doesn't expose the internal representation.

On 11/7/06, Alexey Petrenko <[EMAIL PROTECTED]> wrote:
>
> 2006/11/7, Andrew Zhang <[EMAIL PROTECTED]>:
> > On 11/7/06, Alexey Petrenko <[EMAIL PROTECTED]> wrote:
> > >
> > > Guys,
> > >
> > > have we agreed on toString compatibility? Our compatibility guideline
> > > [1] says nothing about compatibility of toString results...
> > iirc, Geir has asked SUN about toString issue, and we have no problem to
> > keep the same string as RI's. To avoid unnecessary compatibility
> problem,
> > we'd better return the same value, and we also agreed to do this job
> > lazily.  :)
> Right! Now I recall that thread.
> Thanks, Andrew.
>
> SY, Alexey
>
> > I think that we do not *need* to follow the RI in this case. Since
> > > toString results are not documented and it will be strange to see an
> > > application which is rely on them. Or we can discuss each case.
> > >
> > > Thoughts?
> > >
> > > The second question: should we apply the patch from HARMONY-2085 [2]
> > > which just makes javax.swing.text.html.parser.Element.toString()
> > > method compatible with RI.
> > >
> > > SY, Alexey
> > >
> > > [1]
> > >
> http://incubator.apache.org/harmony/subcomponents/classlibrary/compat.html
> > > [2] http://issues.apache.org/jira/browse/HARMONY-2085
> > >
> >
> >
> >
> > --
> > Best regards,
> > Andrew Zhang
> >
> >
>



--
Miguel Montes

Re: [compatibility] Compatibility guideline and HARMONY-2085

[Miguel Montes]

Alexey:
Although it's no big deal, I think is useful to be compatible with the RI in
this issue.
The RI version is simpler, and doesn't expose the internal representation.

On 11/7/06, Alexey Petrenko <[EMAIL PROTECTED]> wrote:


2006/11/7, Andrew Zhang <[EMAIL PROTECTED]>:
> On 11/7/06, Alexey Petrenko <[EMAIL PROTECTED]> wrote:
> >
> > Guys,
> >
> > have we agreed on toString compatibility? Our compatibility guideline
> > [1] says nothing about compatibility of toString results...
> iirc, Geir has asked SUN about toString issue, and we have no problem to
> keep the same string as RI's. To avoid unnecessary compatibility
problem,
> we'd better return the same value, and we also agreed to do this job
> lazily.  :)
Right! Now I recall that thread.
Thanks, Andrew.

SY, Alexey

> I think that we do not *need* to follow the RI in this case. Since
> > toString results are not documented and it will be strange to see an
> > application which is rely on them. Or we can discuss each case.
> >
> > Thoughts?
> >
> > The second question: should we apply the patch from HARMONY-2085 [2]
> > which just makes javax.swing.text.html.parser.Element.toString()
> > method compatible with RI.
> >
> > SY, Alexey
> >
> > [1]
> >
http://incubator.apache.org/harmony/subcomponents/classlibrary/compat.html
> > [2] http://issues.apache.org/jira/browse/HARMONY-2085
> >
>
>
>
> --
> Best regards,
> Andrew Zhang
>
>





--
Miguel Montes

Re: [doc] What should be improved in DRLVM Doxygen documentation?

[Mikhail Fursov]

On 07 Nov 2006 21:17:45 +0600, Egor Pasko <[EMAIL PROTECTED]> wrote:


Do we feel that it is time to set responsibilities on documenting
vm/include/* ?



+1 To start working on intercomponent interfaces. Going to commit a couple
of EM interface files with documentation tomorrow. I do not believe that
someday we will have all component's local code documented (-1 to make such
policy for patches), but intercomponent documentation is something we must
have (actually we must not only document but clean the code too)

--
Mikhail Fursov

Re: [doc] What should be improved in DRLVM Doxygen documentation?

[Egor Pasko]

On the 0x21A day of Apache Harmony Mikhail Fursov wrote:
> On 07 Nov 2006 19:08:35 +0600, Egor Pasko <[EMAIL PROTECTED]> wrote:
> >
> >
> > > Another problem: anyone who changes a document behaviour must update
> > > comments too :(
> >
> > excuse me, what is "document behaviour"? :)
> >
> 
> Read it as 'method/function behaviour'.  I mean if you have good comments in
> file you can't submit a patch with code refactoring without update in
> comments. Does it become a new requirement?

So, if someone changes semantic of an interface fuction, s/he should
document the new semantics. I think, it is a good policy.

> IMO we should start to collect metrics and add comments for intercomponent
> interfaces only (vm/include/*).

OK. But no one can stop us to document other parts occasionally.

Do we feel that it is time to set responsibilities on documenting
vm/include/* ?

-- 
Egor Pasko

Re: [compatibility] Compatibility guideline and HARMONY-2085

[Alexey Petrenko]

2006/11/7, Andrew Zhang <[EMAIL PROTECTED]>:

On 11/7/06, Alexey Petrenko <[EMAIL PROTECTED]> wrote:
>
> Guys,
>
> have we agreed on toString compatibility? Our compatibility guideline
> [1] says nothing about compatibility of toString results...
iirc, Geir has asked SUN about toString issue, and we have no problem to
keep the same string as RI's. To avoid unnecessary compatibility problem,
we'd better return the same value, and we also agreed to do this job
lazily.  :)

Right! Now I recall that thread.
Thanks, Andrew.

SY, Alexey


I think that we do not *need* to follow the RI in this case. Since
> toString results are not documented and it will be strange to see an
> application which is rely on them. Or we can discuss each case.
>
> Thoughts?
>
> The second question: should we apply the patch from HARMONY-2085 [2]
> which just makes javax.swing.text.html.parser.Element.toString()
> method compatible with RI.
>
> SY, Alexey
>
> [1]
> http://incubator.apache.org/harmony/subcomponents/classlibrary/compat.html
> [2] http://issues.apache.org/jira/browse/HARMONY-2085
>



--
Best regards,
Andrew Zhang

Re: [compatibility] Compatibility guideline and HARMONY-2085

[Andrew Zhang]

On 11/7/06, Alexey Petrenko <[EMAIL PROTECTED]> wrote:


Guys,

have we agreed on toString compatibility? Our compatibility guideline
[1] says nothing about compatibility of toString results...



iirc, Geir has asked SUN about toString issue, and we have no problem to
keep the same string as RI's. To avoid unnecessary compatibility problem,
we'd better return the same value, and we also agreed to do this job
lazily.  :)

I think that we do not *need* to follow the RI in this case. Since

toString results are not documented and it will be strange to see an
application which is rely on them. Or we can discuss each case.

Thoughts?

The second question: should we apply the patch from HARMONY-2085 [2]
which just makes javax.swing.text.html.parser.Element.toString()
method compatible with RI.

SY, Alexey

[1]
http://incubator.apache.org/harmony/subcomponents/classlibrary/compat.html
[2] http://issues.apache.org/jira/browse/HARMONY-2085





--
Best regards,
Andrew Zhang

[compatibility] Compatibility guideline and HARMONY-2085

[Alexey Petrenko]

Guys,

have we agreed on toString compatibility? Our compatibility guideline
[1] says nothing about compatibility of toString results...

I think that we do not *need* to follow the RI in this case. Since
toString results are not documented and it will be strange to see an
application which is rely on them. Or we can discuss each case.

Thoughts?

The second question: should we apply the patch from HARMONY-2085 [2]
which just makes javax.swing.text.html.parser.Element.toString()
method compatible with RI.

SY, Alexey

[1] http://incubator.apache.org/harmony/subcomponents/classlibrary/compat.html
[2] http://issues.apache.org/jira/browse/HARMONY-2085

Re: [classlib][concurrent] Complete support?

[Nikolay Kuznetsov]

please see the following JIRA issue for the missing function:
http://issues.apache.org/jira/browse/HARMONY-2086

Nik.

On 11/7/06, Nikolay Kuznetsov <[EMAIL PROTECTED]> wrote:

While I'm not familiar with j.u.concurrent build infrastructure, but
the issue about missing native function is known and I'll file a jira
and provide a fix today.

Nik.

> 1) Natives are missing. In particular,
> java.util.concurrent.atomic.AtomicLong.VMSupportsCS8 looks like should  be
> implemented on VM side.
> 2) ant test -Dbuild.module=concurrent does not work. The output is as
> follows:
>
> support-jar:
>   [jar] Building jar:
> C:\_work_\harmony\enhanced\classlib\trunk\deploy\build
> \test\support.jar
>
> test-modules:
>
> test:
>
> full-report:
>
> BUILD FAILED
> C:\_work_\harmony\enhanced\classlib\trunk\build.xml:167: The following error
> occ
> urred while executing this line:
> C:\_work_\harmony\enhanced\classlib\trunk\make\build-test.xml:58:
> C:\_work_\harm
> ony\enhanced\classlib\trunk\build\test_report not found.
>
> Do I miss something important?
>
> --
> Pavel Pervov,
> Intel Enterprise Solutions Software Division
>
>

Re: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs)

[Alexey Petrenko]

Nadya,

we definetly need a link to this page. That's not a question.
Question is where to place the link.
And as I said in previous email link place suggestions are welcome.

SY, Alexey

2006/11/7, Morozova, Nadezhda <[EMAIL PROTECTED]>:

Alexey,
Would be great if there we some page that had a link to the page;
otherwise, you cannot find it from within wiki, only from the link in
your mail :(

Thank you,
Nadya Morozova


-Original Message-
From: Alexey Petrenko [mailto:[EMAIL PROTECTED]
Sent: Tuesday, November 07, 2006 1:32 PM
To: harmony-dev@incubator.apache.org
Subject: Re: [jira] Good issue resolution guideline (was:
[classlib]volunteer to supply patches for old JIRAs)

I've published "Good issue resolution guideline" on Harmony site:
http://incubator.apache.org/harmony/issue_resolution_guideline.html
(wait for a while for the web site synchronization). It is not linked
to other pages yet.

So comments to guideline and link place suggestions are welcome.

SY, Alexey

2006/9/28, Geir Magnusson Jr. <[EMAIL PROTECTED]>:
>
> On Sep 28, 2006, at 3:21 AM, Alexey Petrenko wrote:
>
> > Guys,
> >
> > Since there is no additional comments on this guideline...
> >
> > Let's put it somewhere.
> > We got two options: Harmony site and wiki.
> > I prefer wiki because it will be easy to edit it and I can put it
> > there myself :)
>
> And if you put in a patch for website, we can get it there too :)  if
> you put in wiki, I'm going to take and put on site, so maybe save us
> some effort? (ok, save me the effort...)
>
> geir
>
> >
> > Thoughts?
> >
> > SY, Alexey
> >
> > 2006/9/26, Alexey Petrenko <[EMAIL PROTECTED]>:
> >> I've combined all the comments again.
> >>
> >> And here is the last version. I hope... :)
> >>
> >> === cut ===
> >> Preface
> >> This guideline covers a wide range of issues but not all of them.
> >> If you cannot do one of the steps, then write a comment to the
issue.
> >> Use your common sense!
> >>
> >> Issue reporter:
> >> 1. Explicitly state the expected behavior and the
> >> actual behavior of Harmony code. Use links to specs, rfcs, etc.
> >> 2. Try to create as small a test case as possible. A patch
> >> to test will be highly appreciated.
> >> 3. Provide max. information about steps necessary to recreate the
> >> bug.
> >> If a patch for the test has not been supplied, provide as much
> >> diagnostic information about the failure as possible (stack trace,
> >> failure output, expected output etc).
> >> 4. Remember to use issue links if applicable.
> >> 5. Check the issue resolution when it is committed. Add a comment.
> >>
> >> Resolution provider :) :
> >> Depending on the type of issue, do the following:
> >>
> >> 1. Issue is probably a non-bug difference, not a bug or invalid:
> >>   1.1. Discuss on the dev list.
> >>   1.2. Add a link to the discussion thread as a comment to issue.
> >> 2. Issue is a bug:
> >>   2.1. Notify the community that you started investigation by
adding
> >> a comment to the issue and send a message to dev list. If you
cannot
> >> produce a patch, add another comment with the results of your
> >> investigation.
> >>   2.2. If reporter did not provide a patch to test:
> >>   2.2.1. Try to create a patch to test.
> >>   2.2.2. If you cannot produce a patch, write a comment about
it.
> >>   2.3. Create a patch to fix the issue
> >>   2.3.1. Any concerns? Discuss on the dev list. Add a link to
> >> discussion as a comment.
> >>   2.4. All the pacthes (test and fix) should be relative to the
> >> directory where the main build.xml is:
> >> https://svn.apache.org/repos/asf/incubator/harmony/enhanced/
> >> classlib/trunk.
> >> Or to the module root directory.
> >>   2.5. Test and fix patches should be in different files.
> >>   2.6. If the patch requires to add, remove or move some files in
the
> >> repository, add the appropriate script.
> >>   2.6. Check that all unit tests pass.
> >>   2.8. If it is an application-oriented issue, check the
application.
> >>   2.9. Remember to use issue links if applicable.
> >>
> >> Committer:
> >> Depending on the issue type, do:
> >> 1. Issue is a non-bug difference, not a bug or invalid:
> >> Close the issue.
> >> 2. Issue is a bug:
> >>   2.1. If a patch to test is available, apply it.
> >>   2.2. Check that the test fails.
> >>   2.3. Apply the fix for the issue.
> >>   2.4. Check that test succeeds now.
> >>   2.5. Make sure that all unit tests pass.
> >>   2.6. For application-oriented issues, check the application.
> >>   2.7. If there are problems on previous steps, post a comment to
> >> JIRA and let "resolution provider" to resolve.
> >>   2.8. Make sure that the issue reporter is happy with the
> >> resolution.
> >>   2.9. Add revision info into JIRA issue
> >> === cut ===
> >>
> >
> >
> > --
> > Alexey A. Petrenko
> > Intel Middleware Products Division
> >
> >
-
> > Terms of use : http://incubator.apache.org/harmony/mailing.html
> >

RE: Re: [doc] What should be improved in DRLVM Doxygen documentation?

[Morozova, Nadezhda]

+1.
Doxygen has a @todo tag that we can use.
Quote from manual:
\todo { paragraph describing what is to be done }
Starts a paragraph where a TODO item is described. The description will
also add an item to a separate TODO list. The two instances of the
description will be cross-referenced. Each item in the TODO list will be
preceded by a header that indicates the origin of the item.



Thank you, 
Nadya Morozova
 
-Original Message-
From: news [mailto:[EMAIL PROTECTED] On Behalf Of Egor Pasko
Sent: Tuesday, November 07, 2006 4:09 PM
To: harmony-dev@incubator.apache.org
Subject: Re: [doc] What should be improved in DRLVM Doxygen
documentation?

On the 0x21A day of Apache Harmony Mikhail Fursov wrote:
> On 11/7/06, Morozova, Nadezhda <[EMAIL PROTECTED]> wrote:
> >
> > +1
> >
> > "For in much wisdom is much grief: and he that increaseth knowledge
> increaseth sorrow"
> 
> I'm also +1 to document all of our sources. But it's not always
possible to
> write a meaningful comment  without a lot of "TODO", "this is a
workaround",
> "due to historical reasons" or "I do not remember why this way is the
best"
> comments :).

so, there should be a special dictionary for "TODO", "workaround",
etc. Found a bad word, decrease the doc quality.

Seriously, we do not need to fight for numbers. But quick quality
estimations would help us to make the next step in Doxygen docs, IMHO.

> Another problem: anyone who changes a document behaviour must update
> comments too :(

excuse me, what is "document behaviour"? :)

-- 
Egor Pasko

Re: [build] ant-contrib downloading problems

[Gregory Shimansky]

I changed links to another SF mirror at 472107. Let me know if it doesn't 
work.

On Tuesday 07 November 2006 15:54 Dmitry Irlyanov wrote:
>  Good day
>
>
>
> There is a problem, arising during dependency check in vm build:
> ant-contrib.zip cannot be download from
> http://prdownloads.sourceforge.net/ant-contrib/ant-contrib-1.0b2-bin.zip?do
>wnload&failedmirror=belnet.dl.sourceforge.net
>
> but download successful in the case mirror usage
>
>
>
> Output is:
>
> ---
>
> get.external:
>
>   [get] Getting:
> http://belnet.dl.sourceforge.net/sourceforge/ant-contrib/ant-contrib-1.0b2-
>bin.zip
>
>   [get] To:
> /harmony/trunk/working_vm/build/pre-copied/archives/common/ANTCONTRIB/ant-
> contrib.zip
>
>   [get] Error getting
> http://belnet.dl.sourceforge.net/sourceforge/ant-contrib/ant-contrib-1.0b2-
>bin.zipto
> /harmony/trunk/working_vm/build/pre-copied/archives/common/ANTCONTRIB/ant-
> contrib.zip
>
> ---
>
>
>
> Should be I have changed a hyperlink and sent patch to JIRA?
> ___
> With Best Regards,
> Irlyanov Dmitry
> Intel Corporation
> Middleware Products Division

-- 
Gregory Shimansky, Intel Middleware Products Division

Re: [doc] What should be improved in DRLVM Doxygen documentation?

[Mikhail Fursov]

On 07 Nov 2006 19:08:35 +0600, Egor Pasko <[EMAIL PROTECTED]> wrote:



> Another problem: anyone who changes a document behaviour must update
> comments too :(

excuse me, what is "document behaviour"? :)



Read it as 'method/function behaviour'.  I mean if you have good comments in
file you can't submit a patch with code refactoring without update in
comments. Does it become a new requirement?

IMO we should start to collect metrics and add comments for intercomponent
interfaces only (vm/include/*).


--
Mikhail Fursov

Re: [doc] What should be improved in DRLVM Doxygen documentation?

[Egor Pasko]

On the 0x21A day of Apache Harmony Mikhail Fursov wrote:
> On 11/7/06, Morozova, Nadezhda <[EMAIL PROTECTED]> wrote:
> >
> > +1
> >
> > "For in much wisdom is much grief: and he that increaseth knowledge
> increaseth sorrow"
> 
> I'm also +1 to document all of our sources. But it's not always possible to
> write a meaningful comment  without a lot of "TODO", "this is a workaround",
> "due to historical reasons" or "I do not remember why this way is the best"
> comments :).

so, there should be a special dictionary for "TODO", "workaround",
etc. Found a bad word, decrease the doc quality.

Seriously, we do not need to fight for numbers. But quick quality
estimations would help us to make the next step in Doxygen docs, IMHO.

> Another problem: anyone who changes a document behaviour must update
> comments too :(

excuse me, what is "document behaviour"? :)

-- 
Egor Pasko

Re: [drlvm] [ipf] I suggest a series of patches for ipf code generator

[Egor Pasko]

On the 0x21A day of Apache Harmony Mikhail Fursov wrote:
> On 07 Nov 2006 18:38:23 +0600, Egor Pasko <[EMAIL PROTECTED]> wrote:
> >
> > * the relative path is still
> >   'working_vm/vm/jitrino/src/codegenerator/ipf', but 'working_vm' would
> > be better. (this is a minor issue, just for future)
> >
> 
> +1 Yes, this is the problem. I have no 'working_vm' folder at all (I use
> straightforward VM built without this dir) so I can't apply the patch
> without modification.

'working_vm' should be there if you do 'ant populate_source' as
suggested in [1].

I do not see a big problem here, you can 'cd' to 'blah-blah/ipf' and
apply the patch out of there (without manual modifications). Not so
neat, anyway.

[1] http://incubator.apache.org/harmony/quickhelp_contributors.html

-- 
Egor Pasko

Re: Re: [doc] What should be improved in DRLVM Doxygen documentation?

[Mikhail Fursov]

On 11/7/06, Morozova, Nadezhda <[EMAIL PROTECTED]> wrote:


+1

"For in much wisdom is much grief: and he that increaseth knowledge

increaseth sorrow"

I'm also +1 to document all of our sources. But it's not always possible to
write a meaningful comment  without a lot of "TODO", "this is a workaround",
"due to historical reasons" or "I do not remember why this way is the best"
comments :).
Another problem: anyone who changes a document behaviour must update
comments too :(

--
Mikhail Fursov

[build] ant-contrib downloading problems

[Dmitry Irlyanov]

Good day



There is a problem, arising during dependency check in vm build:
ant-contrib.zip cannot be download from
http://prdownloads.sourceforge.net/ant-contrib/ant-contrib-1.0b2-bin.zip?download&failedmirror=belnet.dl.sourceforge.net

but download successful in the case mirror usage



Output is:

---

get.external:

 [get] Getting:
http://belnet.dl.sourceforge.net/sourceforge/ant-contrib/ant-contrib-1.0b2-bin.zip

 [get] To:
/harmony/trunk/working_vm/build/pre-copied/archives/common/ANTCONTRIB/ant-
contrib.zip

 [get] Error getting
http://belnet.dl.sourceforge.net/sourceforge/ant-contrib/ant-contrib-1.0b2-bin.zipto
/harmony/trunk/working_vm/build/pre-copied/archives/common/ANTCONTRIB/ant-
contrib.zip

---



Should be I have changed a hyperlink and sent patch to JIRA?
___
With Best Regards,
Irlyanov Dmitry
Intel Corporation
Middleware Products Division

RE: Re: [doc] What should be improved in DRLVM Doxygen documentation?

[Morozova, Nadezhda]

+1

Thank you, 
Nadya Morozova
 

-Original Message-
From: news [mailto:[EMAIL PROTECTED] On Behalf Of Egor Pasko
Sent: Tuesday, November 07, 2006 11:23 AM
To: harmony-dev@incubator.apache.org
Subject: Re: [doc] What should be improved in DRLVM Doxygen
documentation?

On the 0x216 day of Apache Harmony Alexei A. Fedotov wrote:
> Nadya wrote,
> > we could check for required Doxygen tags in certain elements.
> 
> I wasn't asked, but cannot resist, sorry. You may achieve this right
now
> without additional coding. Doxygen warns about many problems you
> describe, when you have the following option set.
> 
> # If WARN_IF_UNDOCUMENTED is set to YES, then doxygen will generate
> warnings
> # for undocumented members. If EXTRACT_ALL is set to YES then this
flag
> will
> # automatically be disabled.
> WARN_IF_UNDOCUMENTED   = YES
> 
> The resulting log consists of warning messages about different
problems.
> My DoxygenDrlvmLog.txt, for example, contains the following one:
> 
>
drlvm/trunk/vm/MMTk/ext/vm/HarmonyDRLVM/org/apache/HarmonyDRLVM/mm/mmtk/
> Scanning.java:47: Warning: The following parameters of
>
org::apache::HarmonyDRLVM::mm::mmtk::Scanning::precopyChildren(TraceLoca
> l trace, ObjectReference object) are not documented:
>   parameter trace

does it make sense to convert warnings to quality metrics and put on
harmonytest.org (or even Wiki) regularly? It should encourage people
(like me) to document sources better. Or it is too much effort?

> With best regards,
> Alexei Fedotov,
> Intel Java & XML Engineering
> 
> >-Original Message-
> >From: Morozova, Nadezhda [mailto:[EMAIL PROTECTED]
> >Sent: Friday, November 03, 2006 6:26 PM
> >To: harmony-dev@incubator.apache.org
> >Subject: RE: Re: [doc] What should be improved in DRLVM Doxygen
> >documentation?
> >
> >Egor,
> >I agree with you on the idea of simplicity: documented vs.
> >non-documented.
> >An additional point: do you think we need/want to evaluate quality of
> >comments? we could check for required Doxygen tags in certain
elements.
> >For example, a function is almost certain to include @param and
> @return.
> >Surely, this is heuristics and does not solve all our problems. But
the
> >Doxygen quality check sometimes shows that the file does have
comments,
> >but they are not processed properly by Doxygen - which results in a
low
> >rating for an html file. Maybe this is a crazy idea - I'd be glad to
> >know your opinion.
> >
> >Thank you,
> >Nadya Morozova
> >
> >
> >-Original Message-
> >From: news [mailto:[EMAIL PROTECTED] On Behalf Of Egor Pasko
> >Sent: Friday, November 03, 2006 12:18 PM
> >To: harmony-dev@incubator.apache.org
> >Subject: Re: [doc] What should be improved in DRLVM Doxygen
> >documentation?
> >
> >On the 0x216 day of Apache Harmony Alexei Fedotov wrote:
> >> Egor,
> >>
> >> Thank you for your interest.
> >
> >We definitely need to improve our documentation. Necessity is not a
> >real interest :)
> >
> >> Here is an algorithm:
> >>
> >> 1. Create a list of words from HTML files.
> >> 2. Merge a dictionary of all words used in documentation.
> >> 3. Remove a half of the most frequently used words from the
> dictionary
> >> - I believe they do not add much sense.
> >> 4. Remove misspelled words (including identifiers) from the
> >dictionary.
> >> 5. Give a page +1 for each rare, correctly spelled word according
to
> >> the dictionary.
> >> 6. Divide to the total number of words on the page.
> >
> >hm, strange heuristic. More unique correctly spelled words is
> >beneficial. It does not give a clue on the overall quality of
> >documentation, which is rather confusing..
> >
> >I thought of something more natural. Number of documented items
> >vs. number of non-documented. Plus a penalty to the relative number
of
> >misspelled words.
> >
> >> I've collected nice RFEs from your letter. Most of them make me
think
> >> and I like them.
> >> a. Update an ASF block comment
> >> b. Improve readability. Some things are really easy - like removing
> >> awk and rewriting most things in perl. Others are a bit more
complex
> -
> >> I targeted script performance when created auto-generated perl
> script.
> >> Also, initial algorithm was a bit more complex - different words
had
> a
> >> different cost based on their popularity.
> >> c. Use junit test output format to integrate with
> >> http://harmonytest.org. I believe I need a feature request for that
> >> site as well - we need some way to import performance-like rankings
> to
> >> the site.
> >
> >Yes, I thought of the RFE to harmonytest. At least, put the doc items
> >on a separate page from the build items.
> >
> >> d. I will think of parsing sources. But I don't think we need to
> >> maintain both scripts. The generic rule is simple - improve your .h
> >> and .java files - .cpp files don't count. I suggest better to link
> >> .html files to contributors.
> >
> >can you calculate a list of relevant filenames from a doc page? give
> >filename +1 for each documented it

Re: [drlvm] [ipf] I suggest a series of patches for ipf code generator

[Mikhail Fursov]

On 07 Nov 2006 18:38:23 +0600, Egor Pasko <[EMAIL PROTECTED]> wrote:


* the relative path is still
  'working_vm/vm/jitrino/src/codegenerator/ipf', but 'working_vm' would
be better. (this is a minor issue, just for future)



+1 Yes, this is the problem. I have no 'working_vm' folder at all (I use
straightforward VM built without this dir) so I can't apply the patch
without modification.


--
Mikhail Fursov

RE: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs)

[Morozova, Nadezhda]

Alexey,
Would be great if there we some page that had a link to the page;
otherwise, you cannot find it from within wiki, only from the link in
your mail :(

Thank you, 
Nadya Morozova
 

-Original Message-
From: Alexey Petrenko [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, November 07, 2006 1:32 PM
To: harmony-dev@incubator.apache.org
Subject: Re: [jira] Good issue resolution guideline (was:
[classlib]volunteer to supply patches for old JIRAs)

I've published "Good issue resolution guideline" on Harmony site:
http://incubator.apache.org/harmony/issue_resolution_guideline.html
(wait for a while for the web site synchronization). It is not linked
to other pages yet.

So comments to guideline and link place suggestions are welcome.

SY, Alexey

2006/9/28, Geir Magnusson Jr. <[EMAIL PROTECTED]>:
>
> On Sep 28, 2006, at 3:21 AM, Alexey Petrenko wrote:
>
> > Guys,
> >
> > Since there is no additional comments on this guideline...
> >
> > Let's put it somewhere.
> > We got two options: Harmony site and wiki.
> > I prefer wiki because it will be easy to edit it and I can put it
> > there myself :)
>
> And if you put in a patch for website, we can get it there too :)  if
> you put in wiki, I'm going to take and put on site, so maybe save us
> some effort? (ok, save me the effort...)
>
> geir
>
> >
> > Thoughts?
> >
> > SY, Alexey
> >
> > 2006/9/26, Alexey Petrenko <[EMAIL PROTECTED]>:
> >> I've combined all the comments again.
> >>
> >> And here is the last version. I hope... :)
> >>
> >> === cut ===
> >> Preface
> >> This guideline covers a wide range of issues but not all of them.
> >> If you cannot do one of the steps, then write a comment to the
issue.
> >> Use your common sense!
> >>
> >> Issue reporter:
> >> 1. Explicitly state the expected behavior and the
> >> actual behavior of Harmony code. Use links to specs, rfcs, etc.
> >> 2. Try to create as small a test case as possible. A patch
> >> to test will be highly appreciated.
> >> 3. Provide max. information about steps necessary to recreate the
> >> bug.
> >> If a patch for the test has not been supplied, provide as much
> >> diagnostic information about the failure as possible (stack trace,
> >> failure output, expected output etc).
> >> 4. Remember to use issue links if applicable.
> >> 5. Check the issue resolution when it is committed. Add a comment.
> >>
> >> Resolution provider :) :
> >> Depending on the type of issue, do the following:
> >>
> >> 1. Issue is probably a non-bug difference, not a bug or invalid:
> >>   1.1. Discuss on the dev list.
> >>   1.2. Add a link to the discussion thread as a comment to issue.
> >> 2. Issue is a bug:
> >>   2.1. Notify the community that you started investigation by
adding
> >> a comment to the issue and send a message to dev list. If you
cannot
> >> produce a patch, add another comment with the results of your
> >> investigation.
> >>   2.2. If reporter did not provide a patch to test:
> >>   2.2.1. Try to create a patch to test.
> >>   2.2.2. If you cannot produce a patch, write a comment about
it.
> >>   2.3. Create a patch to fix the issue
> >>   2.3.1. Any concerns? Discuss on the dev list. Add a link to
> >> discussion as a comment.
> >>   2.4. All the pacthes (test and fix) should be relative to the
> >> directory where the main build.xml is:
> >> https://svn.apache.org/repos/asf/incubator/harmony/enhanced/
> >> classlib/trunk.
> >> Or to the module root directory.
> >>   2.5. Test and fix patches should be in different files.
> >>   2.6. If the patch requires to add, remove or move some files in
the
> >> repository, add the appropriate script.
> >>   2.6. Check that all unit tests pass.
> >>   2.8. If it is an application-oriented issue, check the
application.
> >>   2.9. Remember to use issue links if applicable.
> >>
> >> Committer:
> >> Depending on the issue type, do:
> >> 1. Issue is a non-bug difference, not a bug or invalid:
> >> Close the issue.
> >> 2. Issue is a bug:
> >>   2.1. If a patch to test is available, apply it.
> >>   2.2. Check that the test fails.
> >>   2.3. Apply the fix for the issue.
> >>   2.4. Check that test succeeds now.
> >>   2.5. Make sure that all unit tests pass.
> >>   2.6. For application-oriented issues, check the application.
> >>   2.7. If there are problems on previous steps, post a comment to
> >> JIRA and let "resolution provider" to resolve.
> >>   2.8. Make sure that the issue reporter is happy with the
> >> resolution.
> >>   2.9. Add revision info into JIRA issue
> >> === cut ===
> >>
> >
> >
> > --
> > Alexey A. Petrenko
> > Intel Middleware Products Division
> >
> >
-
> > Terms of use : http://incubator.apache.org/harmony/mailing.html
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail:
[EMAIL PROTECTED]
> >
>
>
> -
> Terms of use : http://incubator.apache.org/harmony/mailing

Re: [drlvm] [ipf] I suggest a series of patches for ipf code generator

[Egor Pasko]

On the 0x21A day of Apache Harmony Konstantin Anisimov wrote:
> Egor,
> 
> thank you for the suggestions. I have taken them into account prepareing 
> next patch version.
> Please find it in Jira HARMONY-2061 request.

Konstantin, thank you for updating:
* map -> StlMap
* removed "Revision" substrings

But several issues are not resolved as suggested. Let's discuss those
and converge fast. Here they are one by one. Please, comment:

* RegOpnd::RegOpnd is still not updated according to the changes in
  the .h file. Does it compile on IPF?

* IpfCodeLayouter.cpp:436: commented code is still there. Is there any
  reason for that?

-node->addInst(new(mm) Inst(INST_BR, CMPLT_BTYPE_COND, p0, targetNode));
+//node->addInst(new(mm) Inst(mm, INST_BR, CMPLT_BTYPE_COND, CMPLT_WH_SPTK, 
p0, targetNode));
+node->addInst(new(mm) Inst(mm, INST_BR, CMPLT_WH_SPTK, CMPLT_PH_FEW, p0, 
targetNode));

* the relative path is still
  'working_vm/vm/jitrino/src/codegenerator/ipf', but 'working_vm' would
  be better. (this is a minor issue, just for future)

> "Egor Pasko" <[EMAIL PROTECTED]> wrote in message 
> news:[EMAIL PROTECTED]
> > 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 misprediction penalty.
> >> 2. I have implemented new node merging algorithm. It is more effective 
> >> than
> >> previouc one and besides purging empty nodes.
> >>
> >> All changes made in Code layouting and I suggest integrate them in one
> >> patch.
> >
> > Konstantin,
> >
> > I took a quick look at the HARMONY-2061 you are introducing. Changes
> > look generally good to me, but I have some suggestions (some minor and
> > some requiring to update the patch).
> >
> > Here they are for the easier reply. I'll duplicate them in JIRA for
> > the easier tracking.
> >
> > Changes do *not* affect the IA-32 build. Which is great! (I verified
> > this)
> >
> > I am slightly unhappy with changes like:
> >
> > 
> > +++ include/IpfCodeLayouter.h   (working copy)
> > @@ -17,7 +17,7 @@
> >
> > /**
> >  * @author Intel, Konstantin M. Anisimov, Igor V. Chebykin
> > - * @version $Revision$
> > + * @version $Revision: 1.1.1.6 $
> >  *
> >  */
> > 
> >
> > is it easy to overcome them? maybe, remove the $Revision$ keyword at
> > all? too CVS-ish, not for today
> >
> > Why do you use 'map' instead of more commonly used StlMap
> > (MemoryManager based)?  For the sake of safety to memory leakage we
> > use memory managers (and allocate them on stack).  I understand that
> > your map is allocated on stack, and, hence induces no memory leakage,
> > but it is not like the common style we use. Someone can allocate the
> > map in heap by mistake.  Could you, please, make it an StlMap?
> >
> > I see some bugfixes. Cool :)
> >
> > here:
> > 
> > @@ -436,7 +538,8 @@
> > // Add branch to through edge target
> > Opnd*p0 = cfg.getOpndManager()->getP0();
> > NodeRef *targetNode = cfg.getOpndManager()->newNodeRef(target);
> > -node->addInst(new(mm) Inst(INST_BR, CMPLT_BTYPE_COND, p0, 
> > targetNode));
> > +//node->addInst(new(mm) Inst(mm, INST_BR, CMPLT_BTYPE_COND, 
> > CMPLT_WH_SPTK, p0, targetNode));
> > +node->addInst(new(mm) Inst(mm, INST_BR, CMPLT_WH_SPTK, CMPLT_PH_FEW, 
> > p0, targetNode));
> > 
> >
> > does it make sense to leave this line commented-out? Please, remove it
> > completely.
> >
> > Minor suggestion: please, provide patches for the "working_vm"
> > directory, or one level above, otherwise it needs an extra guess where
> > to apply it (this time it is vm/jitrino/src/codegenerator/ipf)
> >
> > RegOpnd constructor signature changed, but no changes followed in the 
> > implementation
> > (IpfOpnd.cpp). You probably forgot to include the file into the diff. 
> > Please,
> > update.
> >
> > Do I get it right that the new CFG verifier is going to be put in the
> > IpfCfgVerifier.{cpp|h}? Is it going to be worked out soon? Who is
> > working on it?
> >
> >> "Igor Chebykin" <[EMAIL PROTECTED]> wrote in message
> >> news:[EMAIL PROTECTED]
> >> Hello all,
> >>
> >> I suggest a short series of patches for drlvm ipf code generator.
> >> We have some improvements for jitrino/ipf
> >> and would like to commit its to harmony.
> >>
> >> All patches will change only vm/jitrino/src/codegenerator/ipf/* files,
> >> therefore ia32 remains OK.
> >>
> >> The first patch is about 67k size and contains following files:
> >> IpfCfg.h, IpfCfg.cpp
> >>methods added in Edge and Node classes
> >> IpfCodeLayouter.h, IpfCodeLayouter.cpp
> >>  

Re: [drlvm][icl] Fix for the gc_gen compilation problem with Intel Compiler, windows

[Salikh Zakirov]

Alexey Petrenko wrote:
> Salikh could you please attach your patch to the HARMONY-1897
> specified by Alexei?

done

Re: [drlvm][sablevm] Desing of Class Unloading Support

[Ivan Volosyuk]

On 07 Nov 2006 14:35:55 +0600, Egor Pasko <[EMAIL PROTECTED]> wrote:

> I already have one idea how to benefit from movable vtables.

in GCV4.1? :)


Yes

--
Ivan
Intel Enterprise Solutions Software Division

Re: [drlvm] building jitrino in release mode

[Mikhail Fursov]

It looks very strange to me. I've just checked linux debug build with the
only change in build.sh (replaced  -Dvm.jitrino.cfg=releaase to  -
Dvm.jitrino.cfg=debug) and debug version of library was built without any
problems.


On 11/6/06, Alex Astapchuk <[EMAIL PROTECTED]> wrote:


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 story.
>> Was done as 'we-will-change-it-back-soon' thing, but remains till this
>> moment. :-)
>
> When I get it to build, I'll change it back today :)
>
>>
>>>
>>> Putting this inconsistency aside for a moment, how do I get jitrino
>>> to build in debug?
>>
>> Here it is: http://tinyurl.com/yxjp4v
>>
>> This are patches for jitrino.xml & build.bat, the same change (remove
>> -Dvm.jitrino.cfg=release) need to be done for build.sh as well.
>
> k (I made the change in build.sh, as I never work on windows...).  I'll
> look at jitrino.xml (I can't see your URL... I'm in a car at the
moment...)
>

If it helps, then here is the copy:

=
  
-
+
  
  
  
@@ -48,7 +48,8 @@
  

  
-
+
=


--
Thanks,
   Alex





--
Mikhail Fursov

RE: [classlib][swing] compatibility: j.s.text.GapContent.replace() behaviour

[Ivanov, Alexey A]

>-Original Message-
>From: Oleg Khaschansky [mailto:[EMAIL PROTECTED]
>Sent: Thursday, November 02, 2006 3:28 PM
>To: harmony-dev@incubator.apache.org
>Subject: Re: [classlib][swing] compatibility:
j.s.text.GapContent.replace()
>behaviour
>
>+1. Silently doing nothing if invalid parameters are passed seems to
>me a right behavior in this case.
>
>Will someone apply changes to GapContent from the harmony-1975.patch
>or we need to make a separate patch for this?

I've created a separate patch which also adds final modifier to three
methods which are final according to the spec.

There were two votes for silently ignoring BadLocationException which
may be thrown from methods implementing replace() in Harmony. There were
no other votes.
Hence silent ignore was selected.


Thanks for everybody who participated.
Alexey.

>
>On 11/2/06, Alexey Petrenko <[EMAIL PROTECTED]> wrote:
>> 2006/11/2, Ivanov, Alexey A <[EMAIL PROTECTED]>:
>> > Hi all,
>> >
>> > I've started fixing HARMONY-1809. To remove throws clause from the
>> > declaration of replace method, as it was proposed by Oleg in
>> > HARMONY-1975, I placed removeItems() and insertItems() calls into
>> > try-catch block. This would work OK for any valid arguments.
>> >
>> > I was going to handle invalid arguments by making adjustments so
that
>> > the following removeItems() and insertItems() will not throw the
>> > exception. After I wrote several tests, I faced strange behaviour
of RI
>> > with regards to invalid arguments to replace.
>> >
>> > (The Javadoc say nothing about which valid ranges for replace()
>> > parameters as well as any exceptions.)
>> >
>> > RI accepts invalid arguments but the result differs from what I'd
>> > expect.
>> > For example, if the content has "text" in it, I'd expect that
>> > content.replace(-2, 4, null, 0) would give "xt" as the result. I
mean
>> > the invalid start position is adjusted to 0, and the length of
remove
>is
>> > adjusted to be 2 accordingly. But this is not the case. As the
result
>of
>> > this call, all characters are removed leaving "" in the content.
>> >
>> > Moreover the content object becomes unusable after that:
>> > content.insertString(0, "1") throws ArrayIndexOutOfBoundsException.
>> >
>> > Similarly if number of characters to be removed is greater than the
>> > length of the content (content.replace(2, 4, null, 0) with "text"
in
>> > it), the object will throw ArrayIndexOutOfBoundsException when
doing
>> > insertString.
>> >
>> >
>> > Considering the fact that GapContent is pretty low-level class in
text
>> > representation model and that it is protected, I think that Harmony
>> > implementation can silently ignore BadLocationException possible
thrown
>> > from insertItems() and removeItems(). Taking into account erroneous
>> > behaviour of RI's replace, we can do that until an application is
>> > broken.
>> +1 for this solution.
>>
>> SY, Alexey
>>
>> > As another option, we can throw an Error from catch block to make
>> > application which depends on implementation of replace() fast-fail.
>> >
>> >
>> > Any objections, comments, opinions?
>> >
>> > Thanks,
>> > Alexey.
>> >
>> >
>> > P.S. The related JIRA issues:
>> > https://issues.apache.org/jira/browse/HARMONY-1809
>> > https://issues.apache.org/jira/browse/HARMONY-1975
>> >
>> > GapContent Javadoc:
>> >
>http://java.sun.com/j2se/1.5.0/docs/api/javax/swing/text/GapContent.htm
l
>> > Description of GapContent.replace:
>> >
>http://java.sun.com/j2se/1.5.0/docs/api/javax/swing/text/GapContent.htm
l
>> > #replace(int,%20int,%20java.lang.Object,%20int)
>> >
>> >
>> > --
>> > Alexey A. Ivanov
>> > Intel Middleware Product Division
>> >
>>

--
Alexey A. Ivanov
Intel Middleware Product Division

Re: [drlvm] [testing] Excluding commit tests until the problem is fixed

[Pavel Afremov]

Rana,

Everything is correct in you description, but it looks like that *
HARMONY-2018*  should
fix described bug. I think Alexei will have a chance to check it.



Thank you.

Pavel Afremov.


On 11/6/06, Rana Dasgupta <[EMAIL PROTECTED]> wrote:


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 committing 1363, StackTest failed and there were
other
asserts, which Geir disabled to not block the large submission. This is
not
really anything to do with lazy exceptions. This is an issue where parts
of
the main thread's stack virtual memory are unmapped on Linux. I later
added
a fix for this. The two issues are orthogonal to each other.

Rana



On 11/5/06, Fedotov, Alexei A <[EMAIL PROTECTED]> wrote:
>
> Rana, Pavel (Afremov), All,
>
> Geir's comment on r443504 (fix for
> http://issues.apache.org/jira/browse/HARMONY-1363 [drlvm] Java 1.5, 64
> bit support, JVMTI improvements) reads:
>
> > 1) Stack overflow exception stuff is broken.  I had to remove the
> assert
> >in signals_ia32.cpp line 336.  Rana knows and will look.  I also
> >disabled the StackTest.
>
> I have noticed that the patch added a new function
> exn_raise_by_name_internal which fails on the first invocation checking
> an assertion about thread state, see
> http://issues.apache.org/jira/browse/HARMONY-2070 [drlvm][unit]
> org.apache.harmony.beans.tests.java.beans.PersistenceDelegateTest
> crashes DRLVM.
>
> I also have noticed that this function is called to create
> java.lang.StackOverflowError.
>
> Could you help me to understand the current status of the problem?
>
> With best regards,
> Alexei Fedotov,
> Intel Java & XML Engineering
>
> >-Original Message-
> >From: Rana Dasgupta [mailto:[EMAIL PROTECTED]
> >Sent: Wednesday, October 18, 2006 4:27 AM
> >To: harmony-dev@incubator.apache.org
> >Subject: Re: [drlvm] [testing] Excluding commit tests until the problem
> is
> >fixed
> >
> >I fixed the StackOverflow functionality problem by going back and
> mapping
> >all pages ( guard, alternate stack ) meticulously before trying to
> protect
> >them. I think we should have done this in the first place.  I also
> cleaned
> >up the previous initialization workarounds and asserts Geir and I had
> >discussed on the JIRA. The Stacktest and all other stack related tests
> now
> >pass.
> >
> >I'll submit the patch against 1786 in the next few hours after running
> >acceptance tests.
> >
> >Rana
> >
> >
> >
> >> On 10/16/06, Rana Dasgupta <[EMAIL PROTECTED]> wrote:
> >> >
> >> >
> >> >
> >> > On 10/16/06, Gregory Shimansky <[EMAIL PROTECTED]> wrote:
> >> > >
> >> > > On Tuesday 17 October 2006 00:01 Geir Magnusson Jr. wrote:
> >> > > >> I tried to put some back.  StackTest still doesn't work.  It's
> >hard
> >> > > to
> >> > > >> believe...   so I gave up and just kept going :)
> >> > >
> >> > > >I wonder if the test or the implementation are wrong. Maybe
> someone
> >> > > who added
> >> > > >the test initially could know the answer.
> >> >
> >> >
> >> >
> >> >  There is nothing wrong with the stacktest test itself. The
> >> > > implementation is not quite 100%complete( I think ), but has
> enough
> >> > > functionality and the test passes on Windows. On Linux, it fails.
> I
> >am not
> >> > > sure if this is a regression, or if this ever worked. There is a
> JIRA
> >issue
> >> > > 1786. In summary, memory protection setup for the guard page
> fails on
> >the
> >> > > main thread(only). So the guard does not work and the overflow is
> not
> >> > > detected.
> >> >
> >> >
> >> >mprotect fails with an ENOMEM which is either a mapping failure
> or a
> >> > kernel failure. mprotect() has some known flakiness it seems, as
> per
> >> > literature.
> >> >
> >> >   The basic implementation on Linux is sound. There are secondary
> >design
> >> > issues,but we can only get to them later after we have figured out
> why
> >the
> >> > guard setup fails on the main thread.
> >> >
> >> >
> >> >
> >> >
> >>
> >
> >>
> >>
> >>
> >>
> >>
>

Re: [classlib][luni][charset]Strange behavior of UnicodeBig

[Andrew Zhang]

On 11/7/06, Tony Wu <[EMAIL PROTECTED]> wrote:


Different with RI, our io/lang use the same charsets
implementation(ICU) as nio. You know, it is not recommend to modify
ICU's code. To fix this problem under the precondition I mentioned, I
have to write a BOM before every encoding operation and handle BOM
before every decoding, It will obviously broke the structure of our
existing io/lang implementation.
So, I think supplying a harmony SPI is easier and more clear.



Make sense. :)

On 11/7/06, Andrew Zhang <[EMAIL PROTECTED]> wrote:

> 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 support any other charsets and fix the bug
> > which ICU team hesitated to do this way.  I think it also brings us
> > the extensibility, do you have any concern about implementing a
> > harmony SPI? I'll go on if no one objects.
>
>
> Hey Tony, if we only consider io/lang to support UnicodeBig, will the
thing
> be simpler?
>
> On 10/19/06, Andrew Zhang <[EMAIL PROTECTED]> wrote:
> > > On 10/19/06, Tony Wu <[EMAIL PROTECTED]> wrote:
> > > >
> > > > I think to support UnicodeBig in nio is not a bug but a feature.
And
> > > > the key point is how can I get UnicodeBig supportted in IO/Lang?
> > >
> > >
> > > If ICU/NIO supports "UnicodeBig", wouldn't IO/LANG support
> > "UnicodeBig"  as
> > > well?
> > >
> > > On 10/19/06, Andrew Zhang <[EMAIL PROTECTED]> wrote:
> > > > > On 10/19/06, Tony Wu <[EMAIL PROTECTED]> wrote:
> > > > > >
> > > > > > The implemetion is from ICU, so, I think we'd better not to
wrap
> > it by
> > > > > > ourselves. I'll post to ICU mailing list and ask if they can
help
> > to
> > > > > > supply these legacy charsets.
> > > > >
> > > > >
> > > > > Hey Tony, please keep in mind that following code[1] should
print
> > false
> > > > and
> > > > > throw an UnsupportedCharsetException. If ICU provides
"UnicodeBig"
> > > > support,
> > > > > does it mean harmony nio also support "UnicodeBig"?
> > > > >
> > > > > [1]
> > > > > System.out.println(Charset.isSupported("UnicodeBig"));
> > > > > Charset.forName("UncodeBig");
> > > > >
> > > > > On 10/19/06, Andrew Zhang <[EMAIL PROTECTED]> wrote:
> > > > > > > On 10/19/06, Tony Wu <[EMAIL PROTECTED]> wrote:
> > > > > > > >
> > > > > > > > Thank you all,
> > > > > > > > It is not just an issue about name.
> > > > > > > > The precondition of mapping is that ICU has really
supported
> > this
> > > > > > > > charset. AFAIK UnicodeBig is not implemented by ICU, refer
to
> > [1].
> > > > > > > > Shall we map the UnicodeBit&UnicodeLittle to UTF-16 as
work
> > > > around[2]?
> > > > > > >
> > > > > > >
> > > > > > > No, I don't think so. The only difference between
"UnicodeBig"
> > and
> > > > > > > "UTF-16BE" is with/without byte-order mark. So it should be
easy
> > to
> > > > wrap
> > > > > > > "UTF-16BE"  as "UnicodeBig" for java.io/java.lang. Just put
0xFE
> > > > 0xFF at
> > > > > > the
> > > > > > > begining of the bytes and then encode the buffer as
"UTF-16BE".
> > Do I
> > > > > > miss
> > > > > > > something?
> > > > > > >
> > > > > > > [1]http://dev.icu-
> > > > > > > >
> > > > > >
> > > >
> >
project.org/cgi-bin/viewcvs.cgi/icu/source/data/mappings/convrtrs.txt?view=co
> > > > > > > >
> > > > > > > > [2]
> > > > > > > > UTF-16
> > > > > > > > Sixteen-bit UCS Transformation Format, byte order
identified
> > by an
> > > > > > > > optional byte-order mark
> > > > > > > > UnicodeBig
> > > > > > > > Sixteen-bit Unicode Transformation Format, big-endian byte
> > order,
> > > > > > > > with byte-order mark
> > > > > > > > UnicodeLittle
> > > > > > > > Sixteen-bit Unicode Transformation Format, little-endian
byte
> > > > order,
> > > > > > > > with byte-order mark
> > > > > > > >
> > > > > > > > On 10/17/06, Paulex Yang <[EMAIL PROTECTED]> wrote:
> > > > > > > > > Tony Wu wrote:
> > > > > > > > > > Thank you Andrew,
> > > > > > > > > > I think I got the point. The j.l.String of RI uses the
> > > > encoding of
> > > > > > IO
> > > > > > > > > > whereas Charset.forName use another of NIO.
> > > > > > > > > >
> > > > > > > > > > And the new problem is shall we follow the spec[1] to
> > support
> > > > the
> > > > > > two
> > > > > > > > > > suites of charset implemetation? I just have a look
and
> > find
> > > > we
> > > > > > does
> > > > > > > > > > not support some Canonical Name for java.io and
java.langAPI
> > > > such
> > > > > > as
> > > > > > > > > >
> > > > > >
> > UnicodeBigUnmarked,UnicodeLittleUnmarked,UnicodeBig,Unicodelittle,etc.
> > > > > > > > > There is such a charset name mapping in
InputStreamReader, I
> > > > think
> > > > > > we
> > > > > > > > > have no choice but to support these legacy charset
names,
> > you
> > > > may
> > > > > > need
> > > > > > > > > some refactory work to mak

Re: [drlvm] [testing] Excluding commit tests until the problem is fixed

[Pavel Afremov]

Hello.

Could you be so kind to check
*HARMONY-2018*
before start fixing and discussing this bug,  please?

I reported it and provided a fix a week ago.



Thanks.

Pavel Afremov.

On 11/5/06, Fedotov, Alexei A <[EMAIL PROTECTED]> wrote:


Rana, Pavel (Afremov), All,

Geir's comment on r443504 (fix for
http://issues.apache.org/jira/browse/HARMONY-1363 [drlvm] Java 1.5, 64
bit support, JVMTI improvements) reads:

> 1) Stack overflow exception stuff is broken.  I had to remove the
assert
>in signals_ia32.cpp line 336.  Rana knows and will look.  I also
>disabled the StackTest.

I have noticed that the patch added a new function
exn_raise_by_name_internal which fails on the first invocation checking
an assertion about thread state, see
http://issues.apache.org/jira/browse/HARMONY-2070 [drlvm][unit]
org.apache.harmony.beans.tests.java.beans.PersistenceDelegateTest
crashes DRLVM.

I also have noticed that this function is called to create
java.lang.StackOverflowError.

Could you help me to understand the current status of the problem?

With best regards,
Alexei Fedotov,
Intel Java & XML Engineering

>-Original Message-
>From: Rana Dasgupta [mailto:[EMAIL PROTECTED]
>Sent: Wednesday, October 18, 2006 4:27 AM
>To: harmony-dev@incubator.apache.org
>Subject: Re: [drlvm] [testing] Excluding commit tests until the problem
is
>fixed
>
>I fixed the StackOverflow functionality problem by going back and
mapping
>all pages ( guard, alternate stack ) meticulously before trying to
protect
>them. I think we should have done this in the first place.  I also
cleaned
>up the previous initialization workarounds and asserts Geir and I had
>discussed on the JIRA. The Stacktest and all other stack related tests
now
>pass.
>
>I'll submit the patch against 1786 in the next few hours after running
>acceptance tests.
>
>Rana
>
>
>
>> On 10/16/06, Rana Dasgupta <[EMAIL PROTECTED]> wrote:
>> >
>> >
>> >
>> > On 10/16/06, Gregory Shimansky <[EMAIL PROTECTED]> wrote:
>> > >
>> > > On Tuesday 17 October 2006 00:01 Geir Magnusson Jr. wrote:
>> > > >> I tried to put some back.  StackTest still doesn't work.  It's
>hard
>> > > to
>> > > >> believe...   so I gave up and just kept going :)
>> > >
>> > > >I wonder if the test or the implementation are wrong. Maybe
someone
>> > > who added
>> > > >the test initially could know the answer.
>> >
>> >
>> >
>> >  There is nothing wrong with the stacktest test itself. The
>> > > implementation is not quite 100%complete( I think ), but has
enough
>> > > functionality and the test passes on Windows. On Linux, it fails.
I
>am not
>> > > sure if this is a regression, or if this ever worked. There is a
JIRA
>issue
>> > > 1786. In summary, memory protection setup for the guard page
fails on
>the
>> > > main thread(only). So the guard does not work and the overflow is
not
>> > > detected.
>> >
>> >
>> >mprotect fails with an ENOMEM which is either a mapping failure
or a
>> > kernel failure. mprotect() has some known flakiness it seems, as
per
>> > literature.
>> >
>> >   The basic implementation on Linux is sound. There are secondary
>design
>> > issues,but we can only get to them later after we have figured out
why
>the
>> > guard setup fails on the main thread.
>> >
>> >
>> >
>> >
>>
>
>>
>>
>>
>>
>>

Re: [drlvm] [ipf] I suggest a series of patches for ipf code generator

[Konstantin Anisimov]

Egor,

thank you for the suggestions. I have taken them into account prepareing 
next patch version.
Please find it in Jira HARMONY-2061 request.

Thank you,
Konstantin

"Egor Pasko" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
> 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 misprediction penalty.
>> 2. I have implemented new node merging algorithm. It is more effective 
>> than
>> previouc one and besides purging empty nodes.
>>
>> All changes made in Code layouting and I suggest integrate them in one
>> patch.
>
> Konstantin,
>
> I took a quick look at the HARMONY-2061 you are introducing. Changes
> look generally good to me, but I have some suggestions (some minor and
> some requiring to update the patch).
>
> Here they are for the easier reply. I'll duplicate them in JIRA for
> the easier tracking.
>
> Changes do *not* affect the IA-32 build. Which is great! (I verified
> this)
>
> I am slightly unhappy with changes like:
>
> 
> +++ include/IpfCodeLayouter.h   (working copy)
> @@ -17,7 +17,7 @@
>
> /**
>  * @author Intel, Konstantin M. Anisimov, Igor V. Chebykin
> - * @version $Revision$
> + * @version $Revision: 1.1.1.6 $
>  *
>  */
> 
>
> is it easy to overcome them? maybe, remove the $Revision$ keyword at
> all? too CVS-ish, not for today
>
> Why do you use 'map' instead of more commonly used StlMap
> (MemoryManager based)?  For the sake of safety to memory leakage we
> use memory managers (and allocate them on stack).  I understand that
> your map is allocated on stack, and, hence induces no memory leakage,
> but it is not like the common style we use. Someone can allocate the
> map in heap by mistake.  Could you, please, make it an StlMap?
>
> I see some bugfixes. Cool :)
>
> here:
> 
> @@ -436,7 +538,8 @@
> // Add branch to through edge target
> Opnd*p0 = cfg.getOpndManager()->getP0();
> NodeRef *targetNode = cfg.getOpndManager()->newNodeRef(target);
> -node->addInst(new(mm) Inst(INST_BR, CMPLT_BTYPE_COND, p0, 
> targetNode));
> +//node->addInst(new(mm) Inst(mm, INST_BR, CMPLT_BTYPE_COND, 
> CMPLT_WH_SPTK, p0, targetNode));
> +node->addInst(new(mm) Inst(mm, INST_BR, CMPLT_WH_SPTK, CMPLT_PH_FEW, 
> p0, targetNode));
> 
>
> does it make sense to leave this line commented-out? Please, remove it
> completely.
>
> Minor suggestion: please, provide patches for the "working_vm"
> directory, or one level above, otherwise it needs an extra guess where
> to apply it (this time it is vm/jitrino/src/codegenerator/ipf)
>
> RegOpnd constructor signature changed, but no changes followed in the 
> implementation
> (IpfOpnd.cpp). You probably forgot to include the file into the diff. 
> Please,
> update.
>
> Do I get it right that the new CFG verifier is going to be put in the
> IpfCfgVerifier.{cpp|h}? Is it going to be worked out soon? Who is
> working on it?
>
>> "Igor Chebykin" <[EMAIL PROTECTED]> wrote in message
>> news:[EMAIL PROTECTED]
>> Hello all,
>>
>> I suggest a short series of patches for drlvm ipf code generator.
>> We have some improvements for jitrino/ipf
>> and would like to commit its to harmony.
>>
>> All patches will change only vm/jitrino/src/codegenerator/ipf/* files,
>> therefore ia32 remains OK.
>>
>> The first patch is about 67k size and contains following files:
>> IpfCfg.h, IpfCfg.cpp
>>methods added in Edge and Node classes
>> IpfCodeLayouter.h, IpfCodeLayouter.cpp
>>new BotomUp algorithm implementation
>> IpfEmitter.h, IpfEmitter.cpp
>>minor changes in logging, Emitter::registerDirectCall() and
>> debugging support
>> IpfIrPrinter.h, IpfIrPrinter.cpp
>>added method to print Node chains
>> IpfType.h
>>types to support Node chains added
>> IpfCfgVerifier.cpp
>>method cfg.getArgs() deprecated
>> IpfInst.cpp
>>methods to identify inst kind added (isBr, isCall ?)
>> IpfRegisterAllocator.cpp
>>minor changes in logging
>>
>> Thanks,
>> Igor.
>>
>>
>> -- 
>> Igor Chebykin, Intel Middleware Products Division
>>
>> -
>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>>
>>
>>
>
> -- 
> Egor Pasko
>
> 

Re: [jira] Good issue resolution guideline (was: [classlib]volunteer to supply patches for old JIRAs)

[Alexey Petrenko]

I've published "Good issue resolution guideline" on Harmony site:
http://incubator.apache.org/harmony/issue_resolution_guideline.html
(wait for a while for the web site synchronization). It is not linked
to other pages yet.

So comments to guideline and link place suggestions are welcome.

SY, Alexey

2006/9/28, Geir Magnusson Jr. <[EMAIL PROTECTED]>:


On Sep 28, 2006, at 3:21 AM, Alexey Petrenko wrote:

> Guys,
>
> Since there is no additional comments on this guideline...
>
> Let's put it somewhere.
> We got two options: Harmony site and wiki.
> I prefer wiki because it will be easy to edit it and I can put it
> there myself :)

And if you put in a patch for website, we can get it there too :)  if
you put in wiki, I'm going to take and put on site, so maybe save us
some effort? (ok, save me the effort...)

geir

>
> Thoughts?
>
> SY, Alexey
>
> 2006/9/26, Alexey Petrenko <[EMAIL PROTECTED]>:
>> I've combined all the comments again.
>>
>> And here is the last version. I hope... :)
>>
>> === cut ===
>> Preface
>> This guideline covers a wide range of issues but not all of them.
>> If you cannot do one of the steps, then write a comment to the issue.
>> Use your common sense!
>>
>> Issue reporter:
>> 1. Explicitly state the expected behavior and the
>> actual behavior of Harmony code. Use links to specs, rfcs, etc.
>> 2. Try to create as small a test case as possible. A patch
>> to test will be highly appreciated.
>> 3. Provide max. information about steps necessary to recreate the
>> bug.
>> If a patch for the test has not been supplied, provide as much
>> diagnostic information about the failure as possible (stack trace,
>> failure output, expected output etc).
>> 4. Remember to use issue links if applicable.
>> 5. Check the issue resolution when it is committed. Add a comment.
>>
>> Resolution provider :) :
>> Depending on the type of issue, do the following:
>>
>> 1. Issue is probably a non-bug difference, not a bug or invalid:
>>   1.1. Discuss on the dev list.
>>   1.2. Add a link to the discussion thread as a comment to issue.
>> 2. Issue is a bug:
>>   2.1. Notify the community that you started investigation by adding
>> a comment to the issue and send a message to dev list. If you cannot
>> produce a patch, add another comment with the results of your
>> investigation.
>>   2.2. If reporter did not provide a patch to test:
>>   2.2.1. Try to create a patch to test.
>>   2.2.2. If you cannot produce a patch, write a comment about it.
>>   2.3. Create a patch to fix the issue
>>   2.3.1. Any concerns? Discuss on the dev list. Add a link to
>> discussion as a comment.
>>   2.4. All the pacthes (test and fix) should be relative to the
>> directory where the main build.xml is:
>> https://svn.apache.org/repos/asf/incubator/harmony/enhanced/
>> classlib/trunk.
>> Or to the module root directory.
>>   2.5. Test and fix patches should be in different files.
>>   2.6. If the patch requires to add, remove or move some files in the
>> repository, add the appropriate script.
>>   2.6. Check that all unit tests pass.
>>   2.8. If it is an application-oriented issue, check the application.
>>   2.9. Remember to use issue links if applicable.
>>
>> Committer:
>> Depending on the issue type, do:
>> 1. Issue is a non-bug difference, not a bug or invalid:
>> Close the issue.
>> 2. Issue is a bug:
>>   2.1. If a patch to test is available, apply it.
>>   2.2. Check that the test fails.
>>   2.3. Apply the fix for the issue.
>>   2.4. Check that test succeeds now.
>>   2.5. Make sure that all unit tests pass.
>>   2.6. For application-oriented issues, check the application.
>>   2.7. If there are problems on previous steps, post a comment to
>> JIRA and let "resolution provider" to resolve.
>>   2.8. Make sure that the issue reporter is happy with the
>> resolution.
>>   2.9. Add revision info into JIRA issue
>> === cut ===
>>
>
>
> --
> Alexey A. Petrenko
> Intel Middleware Products Division
>
> -
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>


-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [drlvm][jit] Moving jet to the top level of drlvm...

[Xiao-Feng Li]

Ok, thanks for the info. :-) -xiaofeng

On 11/7/06, Mikhail Fursov <[EMAIL PROTECTED]> wrote:

On 11/7/06, Xiao-Feng Li <[EMAIL PROTECTED]> wrote:
>
> 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.
>

Xiao-Feng,
This is offtopic, but I want to notice that EM does not distinguish OPT
instances too: see server.emconf it has 2 Jitrino.OPT JITs. They are all
separate and independent JIT instances for for EM.

--
Mikhail Fursov

Re: Harmony passes 94% on derby tests.

[Alexey Varlamov]

2006/11/7, Nina Rinskaya <[EMAIL PROTECTED]>:

Thanks for your reply! And I agree that the right thing is to file
bugs on EUT. But maybe it is ok to make the patches first as a
temporary workaround just to be able to run EUT on Harmony and not to
wait too long for EUT bugs fixes? Does it make sense?


Sure, the patches would be useful even if just hanging in a JIRA. I
suggest to separate issues intended for commit from temporary stuff,
please file additional JIRA for the last.

--
Best regards,
Alexey



Thanks,
Nina

On 11/3/06, Alexey Varlamov <[EMAIL PROTECTED]> wrote:
> +1 to integration. As for the patches, I'd rather suggest filing bugs
> on EUT and let respective community to resolve those issue for good -
> either find more universal approach (like java.management or JVMTI
> features) or hardcode harmony too :).
>
> Thanks for spending these efforts, anyway!
>
> 03 Nov 2006 14:01:14 +0600, Egor Pasko <[EMAIL PROTECTED]>:
> > On the 0x215 day of Apache Harmony Nina Rinskaya wrote:
> > > Hi,
> > >
> > > I might have chosen the wrong thread for this message, but this is
> > > about another well-known unit tests suite - Eclipse Unit Tests. I've
> > > recently filed new JIRA issue
> > > (https://issues.apache.org/jira/browse/HARMONY-2038) with the ant
> > > script to run EUT on Harmony. Does it make sense to integrate it to
> > > the buildtest module?
> >
> > I think, yes!
> >
> > > For a moment EUT pass rate on Harmony is ~77%. EUT runs results (on
> > > Linux/ia32 and windows/ia32) are being updated on wiki:
> > > http://wiki.apache.org/harmony/Eclipse_Unit_Tests_Pass_on_DRLVM
> > >
> > > A number of EUT test cases fail on Harmony because EUT uses some
> > > hard-coded Sun/Jrockit classlibs names. In particular,
> > > org.eclipse.jdt.core.tests.util.Util class uses specific paths to
> > > class libraries jar files (/lib/rt.jar, for example).
> > > org.eclipse.jdt.core.tests.runtime.*VMLauncher classes use "javaw" as
> > > vm executable name that is missing in Harmony bundle. So what I would
> > > like to do now is to patch EUT to invoke Harmony correctly if it is ok
> > > with everyone here.
> > >
> > > Best regards,
> > > Nina
> > >
> > > On 10/25/06, Vladimir Ivanov <[EMAIL PROTECTED]> wrote:
> > > > Excellent!
> > > >
> > > >
> > > >
> > > > I have one more idea: we already have buildtest module. Some time ago we
> > > > agreed to extends it by coverage and japi scripts (I hope it happens 
soon:)
> > > > ). May be we extend it one more time and store here some scripts for
> > > > automatic run of other-projects unit tests? Seems, in this case we can
> > > > easily reproduce tests run and enable new platforms.
> > > >
> > > > Of cause, we can not cover all application but we can define some list 
of
> > > > 'most important application'.
> > > >
> > > > Is it OK?
> > > >
> > > > Leo, could you share your script for Derby?
> > > >
> > > > Tony, could you share your scripts for ant and log4j?
> > > >
> > > >
> > > >
> > > >  thanks, Vladimir
> > > >
> > > >
> > > > PS. The directory structure may be something like that:
> > > > builtest
> > > > - trunk
> > > > - cc
> > > > - coverage
> > > > - japi
> > > > - application_test
> > > > - derby
> > > > - ant
> > > > - etc
> > > > - misc (some other scripts)
> > > > On 10/25/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
> > > > >
> > > > > Nice work!
> > > > >
> > > > > More inline..
> > > > >
> > > > > Leo Li wrote:
> > > > > > 467 Tests Run
> > > > > > 94% Pass (443 tests passed)
> > > > > > 6% Fail (24 tests failed)
> > > > > > 5 Suites skipped
> > > > > >
> > > > > > The main progress focuses here:
> > > > > > 1. Harmony classlib fails to load class when user-defined security
> > > > > policy
> > > > > > exists. It is due to the sequence of library loading of VM, which 
has
> > > > > been
> > > > > > resolved now.
> > > > > > 2. A new workround for derby tests which allow useprocess to run 
test or
> > > > > > else several testcases might fail due to derby lack these tests when
> > > > > > useprocess = false.
> > > > > > 3. Derby source code uses the version and the name of java vm to 
decide
> > > > > > what
> > > > > > to do, while current IBM VM has the version of "1.4.2" and the name 
of
> > > > > > "j9",
> > > > > > which has different output on the screen from that of standard RI 
1.5.
> > > > > At
> > > > > > the same time Derby test compares the output of the iteractive test
> > > > > scripts
> > > > > > to that of expected. I have made some slight modification in its 
source
> > > > > > code, but I have not throughly change this odd behavior, ...,too 
much:(
> > > > >
> > > > > Have you approached the derby community with the changes?
> > > > >
> > > > > >
> > > > > > Besides, some testcase fails even on RI. I exclude
> > > > > > a "derbynetclientmats" test suit since it will hang both RI and 
Harmony.
> > > > > > Currently all the failure is irrelevant to Harm

Re: [classlib][concurrent] Complete support?

[Nikolay Kuznetsov]

While I'm not familiar with j.u.concurrent build infrastructure, but
the issue about missing native function is known and I'll file a jira
and provide a fix today.

Nik.


1) Natives are missing. In particular,
java.util.concurrent.atomic.AtomicLong.VMSupportsCS8 looks like should  be
implemented on VM side.
2) ant test -Dbuild.module=concurrent does not work. The output is as
follows:

support-jar:
  [jar] Building jar:
C:\_work_\harmony\enhanced\classlib\trunk\deploy\build
\test\support.jar

test-modules:

test:

full-report:

BUILD FAILED
C:\_work_\harmony\enhanced\classlib\trunk\build.xml:167: The following error
occ
urred while executing this line:
C:\_work_\harmony\enhanced\classlib\trunk\make\build-test.xml:58:
C:\_work_\harm
ony\enhanced\classlib\trunk\build\test_report not found.

Do I miss something important?

--
Pavel Pervov,
Intel Enterprise Solutions Software Division

[classlib][concurrent] Complete support?

[Pavel Pervov]

I've found the following issues with this package:

1) Natives are missing. In particular,
java.util.concurrent.atomic.AtomicLong.VMSupportsCS8 looks like should  be
implemented on VM side.
2) ant test -Dbuild.module=concurrent does not work. The output is as
follows:

support-jar:
 [jar] Building jar:
C:\_work_\harmony\enhanced\classlib\trunk\deploy\build
\test\support.jar

test-modules:

test:

full-report:

BUILD FAILED
C:\_work_\harmony\enhanced\classlib\trunk\build.xml:167: The following error
occ
urred while executing this line:
C:\_work_\harmony\enhanced\classlib\trunk\make\build-test.xml:58:
C:\_work_\harm
ony\enhanced\classlib\trunk\build\test_report not found.

Do I miss something important?

--
Pavel Pervov,
Intel Enterprise Solutions Software Division

Re: [drlvm][jit] Moving jet to the top level of drlvm...

[Mikhail Fursov]

On 11/7/06, Xiao-Feng Li <[EMAIL PROTECTED]> wrote:


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.



Xiao-Feng,
This is offtopic, but I want to notice that EM does not distinguish OPT
instances too: see server.emconf it has 2 Jitrino.OPT JITs. They are all
separate and independent JIT instances for for EM.

--
Mikhail Fursov

Re: Harmony passes 94% on derby tests.

[Nina Rinskaya]

Thanks for your reply! And I agree that the right thing is to file
bugs on EUT. But maybe it is ok to make the patches first as a
temporary workaround just to be able to run EUT on Harmony and not to
wait too long for EUT bugs fixes? Does it make sense?

Thanks,
Nina

On 11/3/06, Alexey Varlamov <[EMAIL PROTECTED]> wrote:

+1 to integration. As for the patches, I'd rather suggest filing bugs
on EUT and let respective community to resolve those issue for good -
either find more universal approach (like java.management or JVMTI
features) or hardcode harmony too :).

Thanks for spending these efforts, anyway!

03 Nov 2006 14:01:14 +0600, Egor Pasko <[EMAIL PROTECTED]>:
> On the 0x215 day of Apache Harmony Nina Rinskaya wrote:
> > Hi,
> >
> > I might have chosen the wrong thread for this message, but this is
> > about another well-known unit tests suite - Eclipse Unit Tests. I've
> > recently filed new JIRA issue
> > (https://issues.apache.org/jira/browse/HARMONY-2038) with the ant
> > script to run EUT on Harmony. Does it make sense to integrate it to
> > the buildtest module?
>
> I think, yes!
>
> > For a moment EUT pass rate on Harmony is ~77%. EUT runs results (on
> > Linux/ia32 and windows/ia32) are being updated on wiki:
> > http://wiki.apache.org/harmony/Eclipse_Unit_Tests_Pass_on_DRLVM
> >
> > A number of EUT test cases fail on Harmony because EUT uses some
> > hard-coded Sun/Jrockit classlibs names. In particular,
> > org.eclipse.jdt.core.tests.util.Util class uses specific paths to
> > class libraries jar files (/lib/rt.jar, for example).
> > org.eclipse.jdt.core.tests.runtime.*VMLauncher classes use "javaw" as
> > vm executable name that is missing in Harmony bundle. So what I would
> > like to do now is to patch EUT to invoke Harmony correctly if it is ok
> > with everyone here.
> >
> > Best regards,
> > Nina
> >
> > On 10/25/06, Vladimir Ivanov <[EMAIL PROTECTED]> wrote:
> > > Excellent!
> > >
> > >
> > >
> > > I have one more idea: we already have buildtest module. Some time ago we
> > > agreed to extends it by coverage and japi scripts (I hope it happens 
soon:)
> > > ). May be we extend it one more time and store here some scripts for
> > > automatic run of other-projects unit tests? Seems, in this case we can
> > > easily reproduce tests run and enable new platforms.
> > >
> > > Of cause, we can not cover all application but we can define some list of
> > > 'most important application'.
> > >
> > > Is it OK?
> > >
> > > Leo, could you share your script for Derby?
> > >
> > > Tony, could you share your scripts for ant and log4j?
> > >
> > >
> > >
> > >  thanks, Vladimir
> > >
> > >
> > > PS. The directory structure may be something like that:
> > > builtest
> > > - trunk
> > > - cc
> > > - coverage
> > > - japi
> > > - application_test
> > > - derby
> > > - ant
> > > - etc
> > > - misc (some other scripts)
> > > On 10/25/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
> > > >
> > > > Nice work!
> > > >
> > > > More inline..
> > > >
> > > > Leo Li wrote:
> > > > > 467 Tests Run
> > > > > 94% Pass (443 tests passed)
> > > > > 6% Fail (24 tests failed)
> > > > > 5 Suites skipped
> > > > >
> > > > > The main progress focuses here:
> > > > > 1. Harmony classlib fails to load class when user-defined security
> > > > policy
> > > > > exists. It is due to the sequence of library loading of VM, which has
> > > > been
> > > > > resolved now.
> > > > > 2. A new workround for derby tests which allow useprocess to run test 
or
> > > > > else several testcases might fail due to derby lack these tests when
> > > > > useprocess = false.
> > > > > 3. Derby source code uses the version and the name of java vm to 
decide
> > > > > what
> > > > > to do, while current IBM VM has the version of "1.4.2" and the name of
> > > > > "j9",
> > > > > which has different output on the screen from that of standard RI 1.5.
> > > > At
> > > > > the same time Derby test compares the output of the iteractive test
> > > > scripts
> > > > > to that of expected. I have made some slight modification in its 
source
> > > > > code, but I have not throughly change this odd behavior, ...,too 
much:(
> > > >
> > > > Have you approached the derby community with the changes?
> > > >
> > > > >
> > > > > Besides, some testcase fails even on RI. I exclude
> > > > > a "derbynetclientmats" test suit since it will hang both RI and 
Harmony.
> > > > > Currently all the failure is irrelevant to Harmony. Hope I can find
> > > > > something in the left.
> > > > >
> > > > > I have updated the wiki of derby on Hamony:
> > > > > http://wiki.apache.org/harmony/Apache_Derby.
> > > > >
> > > >
> > >
> > >
> >
>
> --
> Egor Pasko
>
>

FW: [build] Building on Eclipse - FYI

[Konovalova, Svetlana]

Sian,
Sorry for delay in response.
>I'd like to help with documentation but I don't want to duplicate any
work
>that you are in the middle of, so let me know if there's anything
specific >I can do...
Thanks for your desire to help! 
Well, let's work at the page "Developing Apache Harmony Class-library
Code with Eclipse"
[http://incubator.apache.org/harmony/subcomponents/classlibrary/dev_ecli
pse.html] first, if you do not mind. 
AFAIK the majority of items on the page can equally apply to DRLVM and
classlib. IMHO would be great to edit the page to remove unnecessary
focus on classlib, to make the page equally relevant for vm developers.
To my mind, the introductory sections should be removed, as they are
about generalities that do not always relate to the header of the page.
Could you please take a close look at the page and create the patch to
improve the content and to remove all classlib-specific info? You can
use Harmony-2009 for it. It would be a great impact into development of
the site documentation for sure! If you need my help, just let me know.
The second idea is to move the page up, not to store it in
subcomponents/classlib. To make it easily accessible, we can store it in
top xdocs folder and link to the page from documentation.html, quick
helps and other build-development web pages. 
If you do not have any objections, I can create a patch with the
necessary links. 
What do you think?

Best regards,
Sveta

-Original Message-
From: Sian January [mailto:[EMAIL PROTECTED] 
Sent: Thursday, November 02, 2006 2:23 PM
To: harmony-dev@incubator.apache.org
Subject: Re: [build] Building on Eclipse - FYI

Hi Sveta,

Thanks for all your work on this.  I think you're right about the
Eclipse
information - I think most of it is fairly generic and it would be good
to
have it in the "Project Documentation" section.  I believe the new
details
about the ecj jar and the PDE-related settings are classlib-specific (-
Dpde.jreProfile=none etc), but that could probably be mentioned in the
document.

I'd like to help with documentation but I don't want to duplicate any
work
that you are in the middle of, so let me know if there's anything
specific I
can do, or if you're nearly finished then I can leave this area to you
and
get involved in the future.

Regards,

Sian

On 31/10/06, Konovalova, Svetlana <[EMAIL PROTECTED]> wrote:
>
> Sian,
>
> Thank you so much for your positive feedback and appreciating the
page.
>
> This page is only related to classlib. But IMHO many of the things are
> pretty generic, and with minimal edits can be fit
> for VM as well. I suggest that we move this doc up to make it more
> visible and edit it so as to apply to the whole project, rather than
to
> classlib only. To my mind, the "Project Documentation" section is a
good
> place
> for this doc
>
[http://incubator.apache.org/harmony/documentation/documentation.html].
>
> How about that?
>
> As for the "GS with DRLVM" doc, it needs an update, and can be
abridged
> to reduce purely eclipse-oriented content. We can remove unnecessary
> screenshots as well.
>
> Feel free to take an active part in updating the doc, if you have time
> and desire :)
>
> Best regards,
> Sveta
>
> -Original Message-
> From: Sian January [mailto:[EMAIL PROTECTED]
> Sent: Monday, October 30, 2006 8:14 PM
> To: harmony-dev@incubator.apache.org
> Subject: Re: [build] Building on Eclipse - FYI
>
> Hi Sveta,
>
> Thanks for doing that - I have had a look through your patch and it
> looks
> really good.
>
> Your suggestions for changes to the DRLVM document look good too.  I
> couldn't really find any good links for getting started with Java
> programming in Eclipse on their website, the only thing that came
close
> was
> this - http://help.eclipse.org/help32/index.jsp, which has some
getting
> started tutorials within the page.  There might be some better
articles
> out
> there on other sites though, or we could just direct people to the
help
> system or 'cheat sheets' within their Eclipse installation.
>
> Thanks,
>
> Sian

Re: [drlvm][sablevm] Desing of Class Unloading Support

[Egor Pasko]

On the 0x217 day of Apache Harmony Ivan Volosyuk wrote:
> In current GCv4.1 implementation there is an assumption that vtables
> will not move. It is used in compaction algorithm. Strictly speaking,
> the only thing I need is to distinguish objects and vtables during
> allocation. If so, one of GC algorithms may treat vtables as pinned
> objects, while another could make use of the ability to move the
> vtables. 

Ivan, thank you for making it clear!

> I already have one idea how to benefit from movable vtables.

in GCV4.1? :)

> --
> Ivan
> 
> On 03 Nov 2006 14:34:41 +0600, Egor Pasko <[EMAIL PROTECTED]> wrote:
> > On the 0x214 day of Apache Harmony Aleksey Ignatenko wrote:
> > > Egor,
> > >
> > > Vtable objects pinning is required not only by JIT, this is also required 
> > > by
> > > GC, which relies on that VTables are non movable. So this not a way to
> > > disable guarded devirtualization. Pinning is required anyway.
> >
> > Sorry, but I am not aware of places, where pinning is required other
> > than for JIT. If you menttion one or two, that would be great for
> > understanding and the next step to beat my ignorance in this subject :)
> >
> > > On 01 Nov 2006 10:37:41 +0600, Egor Pasko <[EMAIL PROTECTED]> wrote:
> > > >
> > > > On the 0x214 day of Apache Harmony Rana Dasgupta wrote:
> > > > > On 10/31/06, Etienne Gagnon <[EMAIL PROTECTED] > wrote:
> > > > >
> > > > > > >Yet:
> > > > > >
> > > > > > >1- You do need pinning, so you rule out some of the simplest GCs 
> > > > > > >(e.g
> > > > .
> > > > > > >simple, non-generational copying without pinning.)  [Apparently, 
> > > > > > >for
> > > > > > >some very large heaps, simple copying a can be quite difficult to
> > > > beat,
> > > > > > >efficiency wise, if you believe some relatively recent JikesRVM
> > > > related
> > > > > > >paper...]
> > > > >
> > > > >
> > > > > Yes, this was one of my  concerns about the vtable object approach. 
> > > > > This
> > > > is
> > > > > limiting, but this is one specific GC requirement. (Maybe for GC's 
> > > > > that
> > > > > don't support pinning, the JIT can compare object->vtable->class for
> > > > guarded
> > > > > devirtiualization, or even not do guarded devirtualization, sort of
> > > > support
> > > > > the GC in downlevel mode). For the refcounting method we need to hand
> > > > off
> > > > > between  GC and VM before and after processing weak references, update
> > > > the
> > > > > generational or semispace related CL flags, and also use the GC to 
> > > > > undo
> > > > or
> > > > > rescue CL instances that may come alive due to the generational flag
> > > > > processing.
> > > > >
> > > > >
> > > > >
> > > > > > >2- You do have overhead even on minor collections.  With my 
> > > > > > >approach,
> > > > > > >you could limit the (quite similar to yours, if you put a
> > > > > > >class-loader/NULL pointer in the vtable) overhead only to selected 
> > > > > > >GC
> > > > > > >cycles.
> > > > >
> > > > >
> > > > > I think the main advantage of the vtable object approach is that it is
> > > > > somewhat elegant and natural, if one can get past the idea of non C
> > > > vtables
> > > > > :-). Special casing to avoid object->vtable scans during minor
> > > > collections
> > > > > etc. just breaks that. Relying on GC all the way forces a class
> > > > unloading
> > > > > overhead to every GC cycle( even for the young generation collections 
> > > > > ).
> > > > > There is also a space overhead that I can't really estimate(
> > > > proportional to
> > > > > class etc. etc.). As I understood it, there is no impact on MMTk
> > > > based
> > > > > GC's, but I may be wrong.
> > > > > If class unloading is done at specific moments only, the refcounting
> > > > > approach does not add a perf overhead to each GC cycle, there is no 
> > > > > heap
> > > > > overhead of the method either. But the former implies yet another
> > > > > secondary heuristic to optimally choose the class unloading triggers,
> > > > this
> > > > > depends on the application profile and is not really once an hour/day
> > > > etc.
> > > > > My guess( humbly ) would be that the refcounting method "may" be
> > > > somewhat
> > > > > more time/space efficient, but that's probably not the only issue. 
> > > > > There
> > > > is
> > > > > the issue of implementation correctness, existing code, etc. And I 
> > > > > don't
> > > > > know what's the best way to go to the next step.
> > > > > A suggestion could be to take Harmony-2000, review it, put it in a
> > > > > branch,
> > > >
> > > > an alternative: JIT can disable guarded devirtualization via an
> > > > option. Commit the unloading, use/tune GCV5 with that opion until it
> > > > supports pinning. No branch required.
> > > >
> > > > > tune and test it , wait for GCV5 to start supporting pinning, try with
> > > > MMTk,
> > > > > and then integrate. If we do this, the refcounting approach would be a
> > > > > fallback for DRLVM.
> > > > > We need to decide on next steps, we cannot debate t

Re: [DRLVM] General stability

[Vladimir Ivanov]

On 11/7/06, Alexey Varlamov <[EMAIL PROTECTED]> wrote:



But do we have needed scripts/tools readily available to run and
analyze such stability testing? I'm also pretty sure existing c-unit
and smoke tests would help to reveal certain problems if run
repeatedly - just need to add this stuff to CC and run it nightly.
Anybody volunteer?
And yet there are a lot of excluded tests in smoke suite...




Actually, we have one. The task 'ant test' from the drlvm module is running
under CC on linux and windows boxes. Every one can easily reproduce it
(checkout 'buildtest' module and run it, updated version is available in the
issue 995).

The problem is: CC will be useful only to track the regression. While we
have some failed tests it should be fixed asap. At present time some issues
that prevent successful CC runs wait for integration more than 1 month :(

thanks, Vladimir

Re: [doc] What should be improved in DRLVM Doxygen documentation?

[Egor Pasko]

On the 0x216 day of Apache Harmony Alexei A. Fedotov wrote:
> Nadya wrote,
> > we could check for required Doxygen tags in certain elements.
> 
> I wasn't asked, but cannot resist, sorry. You may achieve this right now
> without additional coding. Doxygen warns about many problems you
> describe, when you have the following option set.
> 
> # If WARN_IF_UNDOCUMENTED is set to YES, then doxygen will generate
> warnings
> # for undocumented members. If EXTRACT_ALL is set to YES then this flag
> will
> # automatically be disabled.
> WARN_IF_UNDOCUMENTED   = YES
> 
> The resulting log consists of warning messages about different problems.
> My DoxygenDrlvmLog.txt, for example, contains the following one:
> 
> drlvm/trunk/vm/MMTk/ext/vm/HarmonyDRLVM/org/apache/HarmonyDRLVM/mm/mmtk/
> Scanning.java:47: Warning: The following parameters of
> org::apache::HarmonyDRLVM::mm::mmtk::Scanning::precopyChildren(TraceLoca
> l trace, ObjectReference object) are not documented:
>   parameter trace

does it make sense to convert warnings to quality metrics and put on
harmonytest.org (or even Wiki) regularly? It should encourage people
(like me) to document sources better. Or it is too much effort?

> With best regards,
> Alexei Fedotov,
> Intel Java & XML Engineering
> 
> >-Original Message-
> >From: Morozova, Nadezhda [mailto:[EMAIL PROTECTED]
> >Sent: Friday, November 03, 2006 6:26 PM
> >To: harmony-dev@incubator.apache.org
> >Subject: RE: Re: [doc] What should be improved in DRLVM Doxygen
> >documentation?
> >
> >Egor,
> >I agree with you on the idea of simplicity: documented vs.
> >non-documented.
> >An additional point: do you think we need/want to evaluate quality of
> >comments? we could check for required Doxygen tags in certain elements.
> >For example, a function is almost certain to include @param and
> @return.
> >Surely, this is heuristics and does not solve all our problems. But the
> >Doxygen quality check sometimes shows that the file does have comments,
> >but they are not processed properly by Doxygen - which results in a low
> >rating for an html file. Maybe this is a crazy idea - I'd be glad to
> >know your opinion.
> >
> >Thank you,
> >Nadya Morozova
> >
> >
> >-Original Message-
> >From: news [mailto:[EMAIL PROTECTED] On Behalf Of Egor Pasko
> >Sent: Friday, November 03, 2006 12:18 PM
> >To: harmony-dev@incubator.apache.org
> >Subject: Re: [doc] What should be improved in DRLVM Doxygen
> >documentation?
> >
> >On the 0x216 day of Apache Harmony Alexei Fedotov wrote:
> >> Egor,
> >>
> >> Thank you for your interest.
> >
> >We definitely need to improve our documentation. Necessity is not a
> >real interest :)
> >
> >> Here is an algorithm:
> >>
> >> 1. Create a list of words from HTML files.
> >> 2. Merge a dictionary of all words used in documentation.
> >> 3. Remove a half of the most frequently used words from the
> dictionary
> >> - I believe they do not add much sense.
> >> 4. Remove misspelled words (including identifiers) from the
> >dictionary.
> >> 5. Give a page +1 for each rare, correctly spelled word according to
> >> the dictionary.
> >> 6. Divide to the total number of words on the page.
> >
> >hm, strange heuristic. More unique correctly spelled words is
> >beneficial. It does not give a clue on the overall quality of
> >documentation, which is rather confusing..
> >
> >I thought of something more natural. Number of documented items
> >vs. number of non-documented. Plus a penalty to the relative number of
> >misspelled words.
> >
> >> I've collected nice RFEs from your letter. Most of them make me think
> >> and I like them.
> >> a. Update an ASF block comment
> >> b. Improve readability. Some things are really easy - like removing
> >> awk and rewriting most things in perl. Others are a bit more complex
> -
> >> I targeted script performance when created auto-generated perl
> script.
> >> Also, initial algorithm was a bit more complex - different words had
> a
> >> different cost based on their popularity.
> >> c. Use junit test output format to integrate with
> >> http://harmonytest.org. I believe I need a feature request for that
> >> site as well - we need some way to import performance-like rankings
> to
> >> the site.
> >
> >Yes, I thought of the RFE to harmonytest. At least, put the doc items
> >on a separate page from the build items.
> >
> >> d. I will think of parsing sources. But I don't think we need to
> >> maintain both scripts. The generic rule is simple - improve your .h
> >> and .java files - .cpp files don't count. I suggest better to link
> >> .html files to contributors.
> >
> >can you calculate a list of relevant filenames from a doc page? give
> >filename +1 for each documented item, give a -1 for each undocumented,
> >divide on the number of items. Is it easy to implement?  Maybe doxygen
> >has some features to assist this?
> >
> >> Thank you for ideas. I will certainly update the script. I just want
> >> to wait a bit - many scripts die just because 

Re: [classlib][luni][charset]Strange behavior of UnicodeBig

[Tony Wu]

Different with RI, our io/lang use the same charsets
implementation(ICU) as nio. You know, it is not recommend to modify
ICU's code. To fix this problem under the precondition I mentioned, I
have to write a BOM before every encoding operation and handle BOM
before every decoding, It will obviously broke the structure of our
existing io/lang implementation.
So, I think supplying a harmony SPI is easier and more clear.

On 11/7/06, Andrew Zhang <[EMAIL PROTECTED]> wrote:

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 support any other charsets and fix the bug
> which ICU team hesitated to do this way.  I think it also brings us
> the extensibility, do you have any concern about implementing a
> harmony SPI? I'll go on if no one objects.


Hey Tony, if we only consider io/lang to support UnicodeBig, will the thing
be simpler?

On 10/19/06, Andrew Zhang <[EMAIL PROTECTED]> wrote:
> > On 10/19/06, Tony Wu <[EMAIL PROTECTED]> wrote:
> > >
> > > I think to support UnicodeBig in nio is not a bug but a feature. And
> > > the key point is how can I get UnicodeBig supportted in IO/Lang?
> >
> >
> > If ICU/NIO supports "UnicodeBig", wouldn't IO/LANG support
> "UnicodeBig"  as
> > well?
> >
> > On 10/19/06, Andrew Zhang <[EMAIL PROTECTED]> wrote:
> > > > On 10/19/06, Tony Wu <[EMAIL PROTECTED]> wrote:
> > > > >
> > > > > The implemetion is from ICU, so, I think we'd better not to wrap
> it by
> > > > > ourselves. I'll post to ICU mailing list and ask if they can help
> to
> > > > > supply these legacy charsets.
> > > >
> > > >
> > > > Hey Tony, please keep in mind that following code[1] should print
> false
> > > and
> > > > throw an UnsupportedCharsetException. If ICU provides "UnicodeBig"
> > > support,
> > > > does it mean harmony nio also support "UnicodeBig"?
> > > >
> > > > [1]
> > > > System.out.println(Charset.isSupported("UnicodeBig"));
> > > > Charset.forName("UncodeBig");
> > > >
> > > > On 10/19/06, Andrew Zhang <[EMAIL PROTECTED]> wrote:
> > > > > > On 10/19/06, Tony Wu <[EMAIL PROTECTED]> wrote:
> > > > > > >
> > > > > > > Thank you all,
> > > > > > > It is not just an issue about name.
> > > > > > > The precondition of mapping is that ICU has really supported
> this
> > > > > > > charset. AFAIK UnicodeBig is not implemented by ICU, refer to
> [1].
> > > > > > > Shall we map the UnicodeBit&UnicodeLittle to UTF-16 as work
> > > around[2]?
> > > > > >
> > > > > >
> > > > > > No, I don't think so. The only difference between "UnicodeBig"
> and
> > > > > > "UTF-16BE" is with/without byte-order mark. So it should be easy
> to
> > > wrap
> > > > > > "UTF-16BE"  as "UnicodeBig" for java.io/java.lang. Just put 0xFE
> > > 0xFF at
> > > > > the
> > > > > > begining of the bytes and then encode the buffer as "UTF-16BE".
> Do I
> > > > > miss
> > > > > > something?
> > > > > >
> > > > > > [1]http://dev.icu-
> > > > > > >
> > > > >
> > >
> project.org/cgi-bin/viewcvs.cgi/icu/source/data/mappings/convrtrs.txt?view=co
> > > > > > >
> > > > > > > [2]
> > > > > > > UTF-16
> > > > > > > Sixteen-bit UCS Transformation Format, byte order identified
> by an
> > > > > > > optional byte-order mark
> > > > > > > UnicodeBig
> > > > > > > Sixteen-bit Unicode Transformation Format, big-endian byte
> order,
> > > > > > > with byte-order mark
> > > > > > > UnicodeLittle
> > > > > > > Sixteen-bit Unicode Transformation Format, little-endian byte
> > > order,
> > > > > > > with byte-order mark
> > > > > > >
> > > > > > > On 10/17/06, Paulex Yang <[EMAIL PROTECTED]> wrote:
> > > > > > > > Tony Wu wrote:
> > > > > > > > > Thank you Andrew,
> > > > > > > > > I think I got the point. The j.l.String of RI uses the
> > > encoding of
> > > > > IO
> > > > > > > > > whereas Charset.forName use another of NIO.
> > > > > > > > >
> > > > > > > > > And the new problem is shall we follow the spec[1] to
> support
> > > the
> > > > > two
> > > > > > > > > suites of charset implemetation? I just have a look and
> find
> > > we
> > > > > does
> > > > > > > > > not support some Canonical Name for java.io and java.langAPI
> > > such
> > > > > as
> > > > > > > > >
> > > > >
> UnicodeBigUnmarked,UnicodeLittleUnmarked,UnicodeBig,Unicodelittle,etc.
> > > > > > > > There is such a charset name mapping in InputStreamReader, I
> > > think
> > > > > we
> > > > > > > > have no choice but to support these legacy charset names,
> you
> > > may
> > > > > need
> > > > > > > > some refactory work to make these classes use the same
> mapping
> > > data.
> > > > > > > > >
> > > > > > > > > [1]
> > > > > http://java.sun.com/j2se/1.5.0/docs/guide/intl/encoding.doc.html
> > > > > > > > >
> > > > > > > > > On 10/17/06, Andrew Zhang <[EMAIL PROTECTED]> wrote:
> > > > > > > > >> On 10/17/06, Andrew Zhang <[EMAIL PROT