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

[Alexey Varlamov]

[snip]

Alexey,

it looks like what you are thinking about is *concurrent* collector,
and concurrent garbage collections brings substantial complexity
even without class unloading.


Salikh,

You are correct. Maybe I'm running ahead of the train, but my concern
is that "scalability" of unloading design is not the last criteria.
The decision we'll do now should not strike back at us in some months.


However, the design we were discussing was for *stop-the-world* garbage
collectors, because this is the only thing currently supported by DRLVM,
and all existing GCs are stop-the-world.


I'm kinda optimistic on gcv5 progress, feeling that concurrent
collection is not improbable to be workable before H2/2007 :)



So, the correctness of unloading algorithm can easily be proved if we consider
that the "final unloading" collection is a full heap collection,
i.e. both nursery and mature space is collected.

Yes, things are more or less clear for the case of STW GC so we can
concentrate on scripting more detailed technical proposal...

[skip]

Re: [drlvm] release vs. debug

[Pavel Ozhdikhin]

Sure, contributors should check debug or even both debug and release builds
and comment about this in JIRA.

I'm talking about committers, will they test debug build which takes 5 times
more time? And does it mean they will be able to apply 5 times less patches?


Actually I'm fine if the committers will check both debug and release builds
and I encourage them to check on all supported platforms. But I'm not a
committer. :)

Thanks,
Pavel


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


I can understand that the contributor may not have access to multiple
platforms, but surely he can test using both debug and release builds :-)
What do we gain by asking the contributor to test less?

Rana


On 11/9/06, Pavel Ozhdikhin <[EMAIL PROTECTED]> wrote:
>
> +1 for debug testing before submitting a patch.
>
> But, for pre-commit testing we should be careful saying we'll test all
the
> patches in debug mode. Though it imprves quality of checks, debug build
is
> significantly slower then release, especially when running with
> interpreter
> or Jitrino.OPT. I ran "build test" on the DRLVM built in debug mode and
it
> takes about 5 times more time than release version on my laptop, The
times
> were as follows:
>
> "build test", Windows XP/ IA32:
> DRLVM release: 22 min 55 sec
> DRLVM debug: 99 min 23 sec
>
> So, may be the good choice will be to ask patch submitters to check
their
> patches on the debug build and, if the JIRA issue contains comments that
> this check is passed, committers may test it on release build only.
>
> Thanks,
> Pavel
>
> On 11/10/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
> >
> > Well, since the problem is repeatable :)
> >
> >
> > Gregory Shimansky wrote:
> > > Geir Magnusson Jr. wrote:
> > >>
> > >>
> > >> Alexei Zakharov wrote:
> > >>> Hi DRLVM fans,
> > >>>
> > >>> I encountered a rather strange problem while working on some class
> > >>> library tests. At least two tests from the beans module hang (or
> > >>> crash) while running on DRLVM debug builds but work fine on DRLVM
> > >>> release builds. I thought that debug build is something about
adding
> > >>> debug symbols to VM binaries and this should not affect the
> > >>> functionality. Can someone shed a light on this?
> > >>
> > >> I would think it's just an assertion firing...
> > >
> > > Actually it is more than that. In debug mode TRACE statements are
> > > compiled and therefore produce executable code. There may also be
some
> > > bugs in compiler generating code in different modes (although this
> > > usually happens for release).
> > >
> > > I don't know why hanging happens, but the difference in generated
code
> > > is actually quite big. Also assertions or any crashes go to
> > > exceptions/signal handlers which may happen to loop infinitely,
there
> > > were bugs like this happening on the current version of sources,
look
> at
> > > HARMONY-2018 and HADMONY-2006.
> > >
> > >>> This is the first
> > >>> question. The second question - what we should do with such tests.
> The
> > >>> tests pass on the downloadable HDK and JRE snapshots as well as on
> > >>> classlib + j9. What should be the commit criteria for DRLVM – i.e.
> > >>> what is the *true* build? :) I think many people here currently
use
> > >>> snapshots to test their patches.
> > >>
> > >> debug :)  don't sweep the problems under the rug...
> > >
> > > +1
> > >
> >
>
>

Re: [testing] Tests scores on http://harmonytest.org Was: [DRLVM] General stability

[Anton Luht]

Hello, Alexei,


I have related question. How can we improve http://harmonytest.org to
make it possible to publish not just pass, fail, or error but numeric
test scores?


Easily - test results in JUnit reports have 'time' property -
execution time in seconds. We can import and show them in the results.
What else is needed? Maybe add something like 'show regressions' to
the the 'compare runs' page? For example, show tests that increased
execution time by more than 10% sorted by increase rate desc?

--
Regards,
Anton Luht,
Intel Java & XML Engineering

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

[Konovalova, Svetlana]

Alexey,
Thanks for the patch. I've looked it through and have fixed certain
issues.
The new patch is created (Harmony-2110). It'd be great, if you could
find a chance to review it.

Best regards,
Sveta

-Original Message-
From: Ivanov, Alexey A [mailto:[EMAIL PROTECTED] 
Sent: Thursday, November 09, 2006 5:20 PM
To: harmony-dev@incubator.apache.org
Subject: RE: [jira] Good issue resolution guideline (was:
[classlib]volunteer to supply patches for old JIRAs)

Sveta, all,

I've attached the updated patch to the JIRA.

Please review.

Regards,
Alexey.


P.S. By the way, do we really need to place all the main content into
another table? I've just looked at the source of the generated HTML
file, and found it quite confusing. I agree to have a table to format
the heading of the page and the list of contents on the left, but why
there's another table where the main content is. I am about this one:

 
 




   
 
Good Issue
Resolution Guideline

   
   ... 

The comments here are added by me, and the source is slightly
reformatted.
I believe, the  part of the XML can be placed almost as is in the
content cell of the top-level table without the need for another table
because it's useless here. Or is it just Anakia limitation?

--
Alexey A. Ivanov
Intel Enterprise Solutions Software Division


>-Original Message-
>From: Konovalova, Svetlana [mailto:[EMAIL PROTECTED]
>Sent: Thursday, November 09, 2006 3:50 PM
>To: harmony-dev@incubator.apache.org
>Subject: RE: [jira] Good issue resolution guideline (was:
>[classlib]volunteer to supply patches for old JIRAs)
>
>Alexey,
>
>>>I'd change the heading "Reporting the Issue" to "Reporting an Issue",
>>>or omit article at all.
>>> Well, both articles seem to be fine. Let it be "a/an"
>>Maybe just omit articles then?
>Well, how about the third variant: "Reporting Issues"?
>
>
>>I'm still for 'reproduce' because a bug can be (non-)reproducible but
>>not recreatable.
>>Any other opinions?
>Ok, "reproduce" is fine
>
>>>I'd say: "If you have any questions, discuss them...
>>That's even better :)
>Cool!:)
>
>>>All patches, such as tests and fixes, should be
>>Good! It's clearer.
>Fine!
>
>>OK. I'll prepare patch update then.
>Good luck! I'd be glad to review it, if you do not mind. :)
>
>Cheers,
>Sveta
>
>Thanks,
>Alexey.
>
>>
>>
>>Best regards,
>>Sveta
>>
>>-Original Message-
>>From: Ivanov, Alexey A [mailto:[EMAIL PROTECTED]
>>Sent: Thursday, November 09, 2006 1:33 PM
>>To: harmony-dev@incubator.apache.org
>>Subject: RE: [jira] Good issue resolution guideline (was:
>>[classlib]volunteer to supply patches for old JIRAs)
>>
>>>-Original Message-
>>>From: Konovalova, Svetlana [mailto:[EMAIL PROTECTED]
>>>Sent: Wednesday, November 08, 2006 7:01 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 just submitted a new JIRA
>>>[http://issues.apache.org/jira/browse/HARMONY-2110].
>>>I've added the necessary links from the website to the new page and
>>have
>>>tried to perfect it a little.
>>>It would be great, if you could find a chance to look through the
>>patch.
>>>Thanks in advance.
>>
>>Sveta,
>>
>>I've taken a look and added my comments to the JIRA itself.
>>
>>
>>Regards,
>>Alexey.
>>
>>>
>>>Best regards,
>>>Sveta
>>>
>>>-Original Message-
>>>From: Morozova, Nadezhda [mailto:[EMAIL PROTECTED]
>>>Sent: Wednesday, November 08, 2006 11:18 AM
>>>To: harmony-dev@incubator.apache.org
>>>Subject: RE: [jira] Good issue resolution guideline (was:
>>>[classlib]volunteer to supply patches for old JIRAs)
>>>
>>>Good! Go ahead. Do you need help? I can review the patch - just let
me
>>>know when you submit the JIRA.
>>>
>>>Thank you,
>>>Nadya Morozova
>>>
>>>-Original Message-
>>>From: Konovalova, Svetlana [mailto:[EMAIL PROTECTED]
>>>Sent: Wednesday, November 08, 2006 9:13 AM
>>>To: harmony-dev@incubator.apache.org
>>>Subject: RE: [jira] Good issue resolution guideline (was:
>>>[classlib]volunteer to supply patches for old JIRAs)
>>>
>>>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 lin

RE: Re: [doc][drlvm] The document "Getting started with DRL" is outdated

[Morozova, Nadezhda]

Good day to you, Egor! 
What do you say about the getting started doc?

Thank you, 
Nadya Morozova
 
-Original Message-
From: news [mailto:[EMAIL PROTECTED] On Behalf Of Egor Pasko
Sent: Friday, November 10, 2006 8:55 AM
To: harmony-dev@incubator.apache.org
Subject: Re: [doc][drlvm] The document "Getting started with DRL" is
outdated

On the 0x21D day of Apache Harmony Nadezhda Morozova wrote:
> Egor,
> I generally like the idea of improving navigation over the site -
> there's never too much of that. However, I am not sure whether we need
> yet another separate page for introductory/guidance info. I hope the
> starting page + the generic pages we have are mostly fine. However,
> adding a link here and there to lead site visitors. 
> 
> Getting started could be a more specific project-oriented page. There,
> you can tell people to go download, build
the
> code. After which, they can start using it just as any other
> RI-compatible jdk. With the exceptions, see our
> wiki pages.
> To use the vm, readers might need to use the following options...
> If they want to read more on our VM, they can visit the
> component page. If no website page contains an answer -
> they can read wiki faqa. 
> .. or something like that :) 

Nadya, I really appreciate our efforts :) But this morning I woke up
and looked the site structure with the eye of a beginner. And could
not find any obvius flaws in the main structure. Left-side collection
of links is in a very good shape, good for beginner-level navigation
and contains almost all links you listed here.

This was a really refreshing morning :)

I'll ask some guys who are new to the project, how they feel about the
site. And will report back, if I find something.

Refreshing morning is over, now back to work..

> Thank you, 
> Nadya Morozova
>  
> -Original Message-
> From: news [mailto:[EMAIL PROTECTED] On Behalf Of Egor Pasko
> Sent: Thursday, November 09, 2006 5:33 PM
> To: harmony-dev@incubator.apache.org
> Subject: Re: [doc][drlvm] The document "Getting started with DRL" is
> outdated
> 
> On the 0x21C day of Apache Harmony Pavel Ozhdikhin wrote:
> > On 11/9/06, Morozova, Nadezhda <[EMAIL PROTECTED]> wrote:
> > >
> > > Egor,
> > > +1 for
> > > Just idea: "Getting Started" may contain a collection of links to
> the
> > > main website and other resources with short descriptions ("Site
Map"
> > > or something) so that people are comfortable floating around in
the
> web.
> > 
> > 
> > 
> > We already have one page having links to the resources about DRLVM:
> > http://incubator.apache.org/harmony/subcomponents/drlvm/index.html
> > Why do you think we need another one?
> 
> because it is only DRLVM.
> I think of something like "site map", a collection of links. Short
> descriptions to some basic ones.
> 
> > 
> > +1 for
> > > * preparing the "Commonly Used Options for DRLVM" (omitting the
word
> > > "supported" intentionally)
> > > Question on this one: will the page contain vm-only options? What
> about
> > > JIT, GC, other? I'd have them all in one place, but we have
separate
> > > docs for EM/jit stuff. What do you say?
> > 
> > 
> > I think we can describe basic options for every component there.
Only
> those
> > that might be interesting for any user. The place for other options
is
> in
> > the run-time help or Developer's Guide for a component.
> 
> I thought of "most commonly used" options. They can possibly be
> grouped by components, but not necessary. I would group them by
> use-cases. BTW, "any user" is not an obvious substance for me. 
> 
> So, the list is not obvious, we need to work it out.
> 
> I see it like HOWTOs. For example:
> "-Xem:jet <- use only baseline JIT compiler"
> "-Xem:opt <- use only optimising JIT compiler"
> "-Xtrace:em <- print method compilation events"
> 
> The 'big' question is: "does 'any user' need to know about JITs
> switching?". I say YES, it helps users to investigate problems, which
> helps us, developers, to react on users' input faster.
> 
> Other options? I can enlist the set of most commonly used by me. If
> many of us put their lists here, we can sum them up quickly and make
> a good (really useful) list of popular options. How about that?
> 
> BTW, the list should not be too big. 25 options is a kind of limit
> 
> > Thanks,
> > Pavel
> > 
> > Thank you,
> > > Nadya Morozova
> > >
> > > -Original Message-
> > > From: news [mailto:[EMAIL PROTECTED] On Behalf Of Egor Pasko
> > > Sent: Thursday, November 09, 2006 5:51 AM
> > > To: harmony-dev@incubator.apache.org
> > > Subject: Re: [doc][drlvm] The document "Getting started with DRL"
is
> > > outdated
> > >
> > > On the 0x21B day of Apache Harmony Nadezhda Morozova wrote:
> > > > All,
> > > > I'd like to share everyone's grief at the sight of outdated
> Getting
> > > > Started document. However, I'd not hurry to eliminate the page
as
> > > such.
> > > > We might reconsider some of its contents, change structure, and
> update
> > > > individual bits, but pleas

[testing] harmonytest.org new features

[Anton Luht]

Hello,

Yesterday I've deployed a new version to harmonytest.org

New features include:
- packages/suites/tests tree-like navigation (as in local JUnit html
results).Tree navigation populated to old results, too.
- the first page only includes 50 latest test runs, link to archive
search added (includes search by uploader's name - request by Tony Wu)
- filter diff results by test name (request by Alexei Fedotov)
- detection of crashes - sometimes when suite crashes, there is an
empty TEST-.xml file in the run results. If such file is
found, all tests from this suite (detected from previous runs) are
marked as crashed in this run.


Bugs fixed:
- duplicates in the results (if any) are merged (bug report by Tony Wu
- test count on the site was bigger than real one)
- there was a problem in uploading large files - >~ 5Mb - the results
were not imported - playing with the configuration solved this problem
- at least my test 11Mb file that broke the upload now uploads
correctly.

Please report bugs and send feature requests.

--
Regards,
Anton Luht,
Intel Java & XML Engineering

[general] what's the status of harmony support for em64?

[Stefano Mazzocchi]

I'm asking because finally have a testing system ready to rock the
harmony planet... but it's AMD64 :-( [and it's Geir's machine!?! can you
believe that?]

-- 
Stefano.

Re: [drlvm] release vs. debug

[Rana Dasgupta]

I can understand that the contributor may not have access to multiple
platforms, but surely he can test using both debug and release builds :-)
What do we gain by asking the contributor to test less?

Rana


On 11/9/06, Pavel Ozhdikhin <[EMAIL PROTECTED]> wrote:


+1 for debug testing before submitting a patch.

But, for pre-commit testing we should be careful saying we'll test all the
patches in debug mode. Though it imprves quality of checks, debug build is
significantly slower then release, especially when running with
interpreter
or Jitrino.OPT. I ran "build test" on the DRLVM built in debug mode and it
takes about 5 times more time than release version on my laptop, The times
were as follows:

"build test", Windows XP/ IA32:
DRLVM release: 22 min 55 sec
DRLVM debug: 99 min 23 sec

So, may be the good choice will be to ask patch submitters to check their
patches on the debug build and, if the JIRA issue contains comments that
this check is passed, committers may test it on release build only.

Thanks,
Pavel

On 11/10/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
>
> Well, since the problem is repeatable :)
>
>
> Gregory Shimansky wrote:
> > Geir Magnusson Jr. wrote:
> >>
> >>
> >> Alexei Zakharov wrote:
> >>> Hi DRLVM fans,
> >>>
> >>> I encountered a rather strange problem while working on some class
> >>> library tests. At least two tests from the beans module hang (or
> >>> crash) while running on DRLVM debug builds but work fine on DRLVM
> >>> release builds. I thought that debug build is something about adding
> >>> debug symbols to VM binaries and this should not affect the
> >>> functionality. Can someone shed a light on this?
> >>
> >> I would think it's just an assertion firing...
> >
> > Actually it is more than that. In debug mode TRACE statements are
> > compiled and therefore produce executable code. There may also be some
> > bugs in compiler generating code in different modes (although this
> > usually happens for release).
> >
> > I don't know why hanging happens, but the difference in generated code
> > is actually quite big. Also assertions or any crashes go to
> > exceptions/signal handlers which may happen to loop infinitely, there
> > were bugs like this happening on the current version of sources, look
at
> > HARMONY-2018 and HADMONY-2006.
> >
> >>> This is the first
> >>> question. The second question - what we should do with such tests.
The
> >>> tests pass on the downloadable HDK and JRE snapshots as well as on
> >>> classlib + j9. What should be the commit criteria for DRLVM – i.e.
> >>> what is the *true* build? :) I think many people here currently use
> >>> snapshots to test their patches.
> >>
> >> debug :)  don't sweep the problems under the rug...
> >
> > +1
> >
>

Re: [classlib][sound] Volunteer to implement missing & bad APIs in javax.sound.sampled

[Boris Kuznetsov]

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

On 11/9/06, Boris Kuznetsov <[EMAIL PROTECTED]> wrote:
>
> Hi Andrew,
>
> I'm working on javax.sound.sampled API now.
> I have completed the following classes:
> AudioFileFormat, AudioFormat, AudioInputStream, BooleanControl,
> CompoundControl, Control, DataLine, EnumControl.
> I'll file a JIRA with patch shortly.
>
> Sorry that I didn't notice about this work earlier.
> Let's do it together.


Good. Boris, I'll start to work on sound after applying Harmony-2117. Will
you supply test cases for Harmony-2117 implementation source code soon?


Agree


Thanks!


Thanks,
> Boris
>
> On 11/9/06, Andrew Zhang <[EMAIL PROTECTED]> wrote:
> > On 11/9/06, Nathan Beyer <[EMAIL PROTECTED]> wrote:
> > >
> > > You may want to take a quick scan of JIRA for "sound" items, just to
> > > make sure there aren't any additional patches that haven't been
> > > applied.
> >
> >
> > Thanks Nathan. Seems only Harmony-1644 [1] is not applied yet, which is
> > about SerialVersionUID.
> >
> > [1] http://issues.apache.org/jira/browse/HARMONY-1644
> >
> >
> > > -Nathan
> > >
> > > On 11/8/06, Andrew Zhang <[EMAIL PROTECTED]> wrote:
> > > > Hi folks,
> > > >
> > > > According to the japi result, there're 0.29% bad, and 8.7% missing
> APIs
> > > in
> > > > javax.sound.sampled package. I'd like to work on this package to
> make
> > > the
> > > > statistics look better. :)  Anyone else is interested too?
> > > >
> > > > Please let me know if you have any concern/comment/suggestion. :)
> > > Thanks!
> > > >
> > > > --
> > > > Best regards,
> > > > Andrew Zhang
> > > >
> > > >
> > >
> >
> >
> >
> > --
> > Best regards,
> > Andrew Zhang
> >
> >
>
>
> --
> Best regards,
> Boris Kuznetsov
> Intel Middleware Products Division
>



--
Best regards,
Andrew Zhang





--
Best regards,
Boris Kuznetsov
Intel Middleware Products Division

Re: [general] Sun will take GPL License?

[Dalibor Topic]

Geir Magnusson Jr.  pobox.com> writes:

> Classically, licensors seem to just make a statement about it.  

Yup, authors should know best what terms apply to their works. Practically
speaking, if they went with the GPL, Sun could just say "it's not 'viral' for
all the practical purposes" and that would be the quick end of any scary
problem, I guess.

> For 
> example, see the Hibernate clarification to the LGPL, or how MySQL just 
> basically told the FSF that the GPL *is* compatible with the Apache License.

Judging from the FOSS exception license text[1], what MySQL did was to simply
add an exception to the GPL, that permits software under a set of open source
licenses to create derivative works. I believe that's what you meant, right?

cheers,
dalibor topic

[1] http://www.mysql.com/company/legal/licensing/foss-exception.html ...  it has
the familiar "As a special exception to the terms and conditions of version 2.0
of the GPL" ring.

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

[Robin Garner]

Ivan Volosyuk wrote:

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

Ivan Volosyuk wrote:
> We will get rid of false sharing. That's true. But it still be quite
> expensive to write those '1' values, because of ping-ponging of the
> cache line between processors. I see only one solution to this: use
> separate mark bits in vtable per GC thread which should reside in
> different cache lines and different from that word containing gcmap
> pointer.

The only thing that a GC thread does is write "1" in this slot; it never
writes "0".  So, it is not very important in what order (or even "when")
this word is finally commited to main memory.  As long as there is some
barrier before the "end of epoch collection" insuring that all
processors cache write buffers are commited to memory before tracing
vtables (or gc maps).

You don't need memory coherency on write-without-read. :-)


I don't speak about memory coherency, I speak about bus load with
useless memory traffic between processors and poor CPU cache usage.

Surely this wouldn't happen in a sufficiently weak memory model ?  Lets 
just not support x64 :-)


But I think this false sharing may be what kills this particular idea.
The next cheapest option should be to use a side array of bytes - as 
long as calculating the address of the mark byte can be done without any 
loads or register spills, it should still be cheaper than a full 
test-and-mark operation on the vtable.  I guess there are cache policies 
where this may still be slow on an SMP machine.


Side metadata is easiest to do when objects are in a specific space, and 
has coarse alignment.  Any ideas what the typical size of a DRLVM vtable 
is ?  Would 256 bytes be an excessive alignment boundary ?


I'll try it out in the next day or so.  Unfortunately I don't have 
access to anything with more parallelism than a Pentium D, so it's not 
likely to be conclusive.


--
Robin Garner
Dept. of Computer Science
Australian National University
http://cs.anu.edu.au/people/Robin.Garner/

Re: [drlvm] release vs. debug

[Pavel Ozhdikhin]

+1 for debug testing before submitting a patch.

But, for pre-commit testing we should be careful saying we'll test all the
patches in debug mode. Though it imprves quality of checks, debug build is
significantly slower then release, especially when running with interpreter
or Jitrino.OPT. I ran "build test" on the DRLVM built in debug mode and it
takes about 5 times more time than release version on my laptop, The times
were as follows:

"build test", Windows XP/ IA32:
DRLVM release: 22 min 55 sec
DRLVM debug: 99 min 23 sec

So, may be the good choice will be to ask patch submitters to check their
patches on the debug build and, if the JIRA issue contains comments that
this check is passed, committers may test it on release build only.

Thanks,
Pavel

On 11/10/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:


Well, since the problem is repeatable :)


Gregory Shimansky wrote:
> Geir Magnusson Jr. wrote:
>>
>>
>> Alexei Zakharov wrote:
>>> Hi DRLVM fans,
>>>
>>> I encountered a rather strange problem while working on some class
>>> library tests. At least two tests from the beans module hang (or
>>> crash) while running on DRLVM debug builds but work fine on DRLVM
>>> release builds. I thought that debug build is something about adding
>>> debug symbols to VM binaries and this should not affect the
>>> functionality. Can someone shed a light on this?
>>
>> I would think it's just an assertion firing...
>
> Actually it is more than that. In debug mode TRACE statements are
> compiled and therefore produce executable code. There may also be some
> bugs in compiler generating code in different modes (although this
> usually happens for release).
>
> I don't know why hanging happens, but the difference in generated code
> is actually quite big. Also assertions or any crashes go to
> exceptions/signal handlers which may happen to loop infinitely, there
> were bugs like this happening on the current version of sources, look at
> HARMONY-2018 and HADMONY-2006.
>
>>> This is the first
>>> question. The second question - what we should do with such tests. The
>>> tests pass on the downloadable HDK and JRE snapshots as well as on
>>> classlib + j9. What should be the commit criteria for DRLVM – i.e.
>>> what is the *true* build? :) I think many people here currently use
>>> snapshots to test their patches.
>>
>> debug :)  don't sweep the problems under the rug...
>
> +1
>

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

[Egor Pasko]

On the 0x21D day of Apache Harmony Konstantin Anisimov wrote:
> Hi all,
> 
> I have created new Jira request - HARMONY-2139. It is about:
> 1. Added operand coalescer. It is integrated with register allocator.
> 2. I finished migration on STL with memory manager support.
> 
> Could someone review it?

in my TODO for today

> Thank you,
> Konstantin
> 
> "Konstantin Anisimov" <[EMAIL PROTECTED]> wrote in message 
> news:[EMAIL PROTECTED]
> > 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.
> >
> > Thank you,
> > Konstantin
> >
> > "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: [doc][drlvm] The document "Getting started with DRL" is outdated

[Egor Pasko]

On the 0x21D day of Apache Harmony Nadezhda Morozova wrote:
> Egor,
> I generally like the idea of improving navigation over the site -
> there's never too much of that. However, I am not sure whether we need
> yet another separate page for introductory/guidance info. I hope the
> starting page + the generic pages we have are mostly fine. However,
> adding a link here and there to lead site visitors. 
> 
> Getting started could be a more specific project-oriented page. There,
> you can tell people to go download, build the
> code. After which, they can start using it just as any other
> RI-compatible jdk. With the exceptions, see our
> wiki pages.
> To use the vm, readers might need to use the following options...
> If they want to read more on our VM, they can visit the
> component page. If no website page contains an answer -
> they can read wiki faqa. 
> .. or something like that :) 

Nadya, I really appreciate our efforts :) But this morning I woke up
and looked the site structure with the eye of a beginner. And could
not find any obvius flaws in the main structure. Left-side collection
of links is in a very good shape, good for beginner-level navigation
and contains almost all links you listed here.

This was a really refreshing morning :)

I'll ask some guys who are new to the project, how they feel about the
site. And will report back, if I find something.

Refreshing morning is over, now back to work..

> Thank you, 
> Nadya Morozova
>  
> -Original Message-
> From: news [mailto:[EMAIL PROTECTED] On Behalf Of Egor Pasko
> Sent: Thursday, November 09, 2006 5:33 PM
> To: harmony-dev@incubator.apache.org
> Subject: Re: [doc][drlvm] The document "Getting started with DRL" is
> outdated
> 
> On the 0x21C day of Apache Harmony Pavel Ozhdikhin wrote:
> > On 11/9/06, Morozova, Nadezhda <[EMAIL PROTECTED]> wrote:
> > >
> > > Egor,
> > > +1 for
> > > Just idea: "Getting Started" may contain a collection of links to
> the
> > > main website and other resources with short descriptions ("Site Map"
> > > or something) so that people are comfortable floating around in the
> web.
> > 
> > 
> > 
> > We already have one page having links to the resources about DRLVM:
> > http://incubator.apache.org/harmony/subcomponents/drlvm/index.html
> > Why do you think we need another one?
> 
> because it is only DRLVM.
> I think of something like "site map", a collection of links. Short
> descriptions to some basic ones.
> 
> > 
> > +1 for
> > > * preparing the "Commonly Used Options for DRLVM" (omitting the word
> > > "supported" intentionally)
> > > Question on this one: will the page contain vm-only options? What
> about
> > > JIT, GC, other? I'd have them all in one place, but we have separate
> > > docs for EM/jit stuff. What do you say?
> > 
> > 
> > I think we can describe basic options for every component there. Only
> those
> > that might be interesting for any user. The place for other options is
> in
> > the run-time help or Developer's Guide for a component.
> 
> I thought of "most commonly used" options. They can possibly be
> grouped by components, but not necessary. I would group them by
> use-cases. BTW, "any user" is not an obvious substance for me. 
> 
> So, the list is not obvious, we need to work it out.
> 
> I see it like HOWTOs. For example:
> "-Xem:jet <- use only baseline JIT compiler"
> "-Xem:opt <- use only optimising JIT compiler"
> "-Xtrace:em <- print method compilation events"
> 
> The 'big' question is: "does 'any user' need to know about JITs
> switching?". I say YES, it helps users to investigate problems, which
> helps us, developers, to react on users' input faster.
> 
> Other options? I can enlist the set of most commonly used by me. If
> many of us put their lists here, we can sum them up quickly and make
> a good (really useful) list of popular options. How about that?
> 
> BTW, the list should not be too big. 25 options is a kind of limit
> 
> > Thanks,
> > Pavel
> > 
> > Thank you,
> > > Nadya Morozova
> > >
> > > -Original Message-
> > > From: news [mailto:[EMAIL PROTECTED] On Behalf Of Egor Pasko
> > > Sent: Thursday, November 09, 2006 5:51 AM
> > > To: harmony-dev@incubator.apache.org
> > > Subject: Re: [doc][drlvm] The document "Getting started with DRL" is
> > > outdated
> > >
> > > On the 0x21B day of Apache Harmony Nadezhda Morozova wrote:
> > > > All,
> > > > I'd like to share everyone's grief at the sight of outdated
> Getting
> > > > Started document. However, I'd not hurry to eliminate the page as
> > > such.
> > > > We might reconsider some of its contents, change structure, and
> update
> > > > individual bits, but please think carefully before removing the
> page.
> > > >
> > > > I think Getting Started (as the title shows) is aimed to help a
> newbie
> > > > work with our vm. I know that many primarily interested in other
> > > things
> > > > - conformance, architecture, internal specifics. However, we
> should
> > > also
> > > > think how the vm is used. A

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

[Robin Garner]

Etienne Gagnon wrote:

Aleksey Ignatenko wrote:

So the list is:
[...]
2. per heap space/generation boolean marker on the classloader instance(
Etienne )
3. class reachability marker byte in vtable (Robin )
[...]


Unless Robin disagrees(?), I would say that 2 and 3 have evolved into a
single merged proposal that comes with various minor variations for
different collection needs: simple "stop the world" (stw), generational
stw, concurrent, etc.  You could call it the "epoch-based vtable
marking" approach.

So, that bring us back to 3.

Robin: Do you agree?  :-)

Etienne


I agree.

--
Robin Garner
Dept. of Computer Science
Australian National University
http://cs.anu.edu.au/people/Robin.Garner/

Re: [drlvm] the big soup of VM properties (HARMONY-1626)

[Dmitry Yershov]

Hello All,

  I finished implementation and refactoring described in
Harmony-1925. In H-1925 You can find some details and patch file
(whole_properties_patch.zip). Any comments are welcome.

I observe the following further improvements (Items for other JIRA-s?):
   - In function "read_properties"
(vm/vmcore/src/init/properties.cpp): Property value has limited length
(MAX_PROP_LINE=5120). This function should be rewritten.
   - We should establish order with "vm.boot.library.path",
"vm.boot.class.path" properties. Either we should add api2vm interface
which should bring "INTERNAL_PROPERTIES" to java code or we should
introduce other "JAVA_PROPERTIES" with functionality of properties
described above and rewrite existing kernel classes.

Thanks
Dmitry


2006/10/20, Dmitry Yershov <[EMAIL PROTECTED]>:

Hi All,

   I finished implementation of new properties module for DRL VM.
Also, HARMONY-1925 was created to track the progress. You can
find some details and patch file here. Any comments are welcome

Thanks
Dmitry

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

[Etienne Gagnon]

Aleksey Ignatenko wrote:
> So the list is:
> [...]
> 2. per heap space/generation boolean marker on the classloader instance(
> Etienne )
> 3. class reachability marker byte in vtable (Robin )
> [...]

Unless Robin disagrees(?), I would say that 2 and 3 have evolved into a
single merged proposal that comes with various minor variations for
different collection needs: simple "stop the world" (stw), generational
stw, concurrent, etc.  You could call it the "epoch-based vtable
marking" approach.

So, that bring us back to 3.

Robin: Do you agree?  :-)

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] [ipf] I suggest a series of patches for ipf code generator

[Konstantin Anisimov]

Hi all,

I have created new Jira request - HARMONY-2139. It is about:
1. Added operand coalescer. It is integrated with register allocator.
2. I finished migration on STL with memory manager support.

Could someone review it?

Thank you,
Konstantin

"Konstantin Anisimov" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
> 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.
>
> Thank you,
> Konstantin
>
> "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]
>
>
>
>
> 

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

[Aleksey Ignatenko]

Actually there is one additional 4-th approach:

*Mark and scan based approach *wich I described in the first letter. Java
heap trace is performed by VM Core and GC is not affected at all.

So the list is:
1. vtable objects( Aleksey )
2. per heap space/generation boolean marker on the classloader instance(
Etienne )
3. class reachability marker byte in vtable (Robin )
4. Mark and scan based approach.

I agree that we need to structure all appraches somehow, like description
for every approach in wiki.

Aleksey.

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


Identifying an end to end alogirithm is of course necessary, and the
discussions on the other thread are great. But what were we voting on
here?
My understanding was that we were voting on the approach of using:

1. vtable objects( Aleksey )
2. per heap space/generation boolean marker on the classloader instance(
Etienne )
3. class reachability marker byte in vtable (Robin )

and not on three end-to-end algorithms since Robin's description was not
one. I am OK if we now want to cancel the vote, but next time we vote on a
technical issue it may be a good idea for the caller to summarize the
contending solutions on the thread and then call for the vote.

Thanks,
Rana

On 11/9/06, Weldon Washburn <[EMAIL PROTECTED] > wrote:
>
> It looks like I called for a vote too soon.  The continuing discussion
on
> class unloading design is uncovering many important issues.  This is
> excellent as it is much better to deal with design issues at this stage
> rather than during implementation.
>
> I propose the following:
>
> 1)
> Cancel the current vote on design.
>
> 2)
> Someone put together a complete class unloading design based on
> Etienne/Robin's approach.  Include pseudo code and post to harmony-dev.
>
> 3)
> We call for a new vote once the comments on the documented design
indicate
> it is ready.
>
>
> On 11/8/06, Robin Garner < [EMAIL PROTECTED] > wrote:
> >
> > Pavel Pervov wrote:
> > > Really BIG -1 from me.
> > >
> > > As Aleksey (Ignatenko) described in original thread, j/l/Class'es
and
> > > j/l/ClassLoader's are always available in rootset, so even if no
> objects
> > > of a class exist, this class will be reachable.
> > >
> > > Actually, some sort of class unloading prototype exists in DRLVM
code,
> > > which
> > > implements the scheme, which is very close to what is currently
voted.
>
> > It
> > > was integrated with GC v4 and is not supported by other GCs. This
> > prototype
> > > traces up to class loader. Robin's approach is way faster then
> prorotype
> > > is.
> > >
> > > Unfortunately, that approach requires up to 3 GC cycles to complete
in
> > > DRLVM.
> >
> > In a full-heap STW collector, my proposal would require 1 GC to
collect
> > unused classloaders.  In a generational STW collector, 1 full-heap GC,
> > and would depend on the particular invariants enforced by an
> > incremental/concurrent collector, but would be 1 complete "cycle" of
any
> > of the standard algorithms (I guess up to 3 GCs if the sweeps happened
> > at the wrong places).
> >
> > > BTW, voted approach does not describe "proof-of-full-collection"
> > algorithm
> > > (at least I didn't find one). The only one I think of is
> > > full-heap-collection, which _requires_ STW.
> >
> > My approach simply requires the underlying collector to have a notion
> > that periodically it can say that 'every reachable object allocated
> > since time 't' is now marked reachable.  If the class-unloader can
> > ensure that one full epoch of this invariant has passed, then it can
> > safely perform unloading.
> >
> > > Although "automatic anloading" brings some additional requirements
for
> > GC
> > > (weak roots (references) support and pinned allocation), it is
proven
> to
> > > work (patch available) and, also, is the most natural algorithm for
> > DRLVM.
> >
> > What is the run-time cost of it ?  And where is it described ?  I was
> > only aware of Etienne's proposal as a full class-unloading scheme.
> >
> > > With the best regards,
> >
> >
> > --
> > Robin Garner
> > Dept. of Computer Science
> > Australian National University
> >
>
>
>
> --
> Weldon Washburn
> Intel Enterprise Solutions Software Division
>
>

Re: Japi diffs for harmony

[Nathan Beyer]

Cool, just making sure. Excuse my obvious questions. :)

-Nathan

On 11/9/06, Stuart Ballard <[EMAIL PROTECTED]> wrote:

Nathan Beyer wrote:
> No problem on the name change, but doesn't what Stuart is talking
> about require that methods add this exception to the signature to
> actually show up in the reports?

That's correct. If it's a subclass of RuntimeException (which it ought
to be, otherwise it'd have to be in throws clauses anyway and that'd
show up as errors already) it makes no practical difference to have it
in the throws clause, but it provides a useful way to flag stub
methods in such a way that Japitools can detect them.

But yes, you have to do the work by hand to actually mark the stubs by
setting the throws clause accordingly.

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

Re: [general] Sun will take GPL License?

[Geir Magnusson Jr.]

Dalibor Topic wrote:

Geir Magnusson Jr.  pobox.com> writes:



Alexey Petrenko wrote:

Java under GPL? It is probably bad news for Java developers...

As far as I understand you'll can not create non GPL application on
top of GPL Java...
License gurus, is that right?
GPL proponents claim that there is no problem running under a GPL-ed VM, 
but given aspects such as JNI and such, I do wonder if that's simply 
wishful thinking.


I'd be very surprised, in case that they actually decided to go with the GPL, if
they haven't thought about all that, and have a bunch of good answers that
explain that all the desirable things can happen without leaving any room for
fear, uncertainty or doubt about the effects of the license.



Classically, licensors seem to just make a statement about it.  For 
example, see the Hibernate clarification to the LGPL, or how MySQL just 
basically told the FSF that the GPL *is* compatible with the Apache License.



After all, one should not forget that Sun has managed to get the JDK into
Debian. So they must have more than sufficient experience in dealing with
armchair lawyering about their license choices on the internet. ;)


We'll see.  It will be interesting.

geir

Re: [classlib] Building on x86_64

[Gregory Shimansky]

Geir Magnusson Jr. wrote:

Gregory Shimansky wrote:

Hello

Today I tried to check what happens on x86_64 and I think I've found 
some issues which need discussion


1. When classlib starts its built it tries to link 3 libraries and 
headers to depends/libs/build/{jpeg,lcms,png} directories. On x86_64 
SuSE9 it has failed for me to find lcms and png libraries because they 
happen to be in /usr/lib64. This should not be the case on Gentoo 
because /usr/lib is a link to /usr/lib64, but it looks like not all 
distributions follow this way. So probably searching /usr/lib64 first 
should be done on x86_64.


2. I've linked liblcms.a and libpng.a in /usr/lib64 by hands but then 
linker complained that they cannot be used because relocations have to 
be done. I've replaced links with links to *shared* libs and it seems 
to have worked ok. For some reason libjpeg.a found in /usr/lib didn't 
cause the problems. But anyway, I'd like to ask a question, why do we 
want static linking? Not all distributions supply static versions of 
these libraries, for example I found none in Fedora 5 even on x86. Why 
not switch to shared libraries?


I do think we want to use static compilation to be sure of what we're 
running with.


But what if static library was not compiled with -fpic and just cannot 
be linked to dynamic library of classlib? I didn't imagine the problem, 
it does happen, linker complains that I need to recompile it with -fpic.


When we link against static libraries supplied by the distribution we 
don't control the library as well, it was built somewhere by someone 
with unknown compilation options and the version of package is not 
really known. What is the difference with dynamic libraries here? What 
to do with distributions which no longer supply static libraries for 
needed packages?


We could of course end up checking binaries in into SVN just like we did 
ICU libraries. Now that I think of it, it may be the only option because 
HDK binary snapshot has to work on any linux installation, even one 
which don't have lib{png,jpeg,lcms}.so installed at all.


3. ICU libraries in HARMONY-1678 had to be linked as well because 
build wants libicu*.so.34 while libraries in the archives have 
libicu*.so.34.1 names. Shouldn't they be added to SVN like 
depends/libs/linux.x86 ones with the same names as build wants?


4. Classlib always builds to "deploy" directory. When working with 
different architectures it is good when output directories for all 
files including object files are different. Otherwise it is necessary 
to create separate repositories for every one of them or do clean 
rebuild on every switch and never forget which version of classlib is 
currently built. Could we change classlib build to create object files 
in directories with architecture postfix and final output to something 
like "deploy-x86_64"? Also we could separate debug/release built files 
in the same way.


+1


--
Gregory

Re: [general] Sun will take GPL License?

[Geir Magnusson Jr.]

Dalibor Topic wrote:

Geir Magnusson Jr.  pobox.com> writes:

I think that in order to really work for the "free-as-in-stallman" ;) 
community, someone will have to literally fork sun's GPL-ed 
implementation, as I'm guessing GPL advocates will want to be able to 
contribute / augment / maintain the codebase, but not allow Sun to 
re-license their contributions under commercial terms.


Sounds like a pointless idea to me, as a GPL advocate. ;)


Me too, but if you don't want to contribute under commercial terms... 
BTW, I'm not advocating anyone do that.




Whether I contribute to GNU Classpath, Apache Harmony or Sun's project, the end
result can be used in proprietary runtimes anyway, and in Classpath's & Sun's
case actually is used that way. That doesn't hurt my own use of that code, or
that of my users.


Yep - this is my attitude as well.  There is no loss if someone chooses 
to close source something that is available open elsewhere.





If people chose to license that code under more restrictive terms, than it's
available under, than that's their right, as is mine not to make that choice. As
long as the same code remains available under a licensing choice that allows me
to use it (i.e. GPL-compatible in my GPL advocate case), I'd see no reason to
complain about it, or to refuse to contribute to it.



I'm just not sure if everyone feels that way.  I've heard the standard 
rhetoric about not supporting "code hoarders" and such...


geir


cheers,
dalibor topic

Re: [classlib] Building on x86_64

[Geir Magnusson Jr.]

Gregory Shimansky wrote:

Hello

Today I tried to check what happens on x86_64 and I think I've found some 
issues which need discussion


1. When classlib starts its built it tries to link 3 libraries and headers to 
depends/libs/build/{jpeg,lcms,png} directories. On x86_64 SuSE9 it has failed 
for me to find lcms and png libraries because they happen to be 
in /usr/lib64. This should not be the case on Gentoo because /usr/lib is a 
link to /usr/lib64, but it looks like not all distributions follow this way. 
So probably searching /usr/lib64 first should be done on x86_64.


2. I've linked liblcms.a and libpng.a in /usr/lib64 by hands but then linker 
complained that they cannot be used because relocations have to be done. I've 
replaced links with links to *shared* libs and it seems to have worked ok. 
For some reason libjpeg.a found in /usr/lib didn't cause the problems. But 
anyway, I'd like to ask a question, why do we want static linking? Not all 
distributions supply static versions of these libraries, for example I found 
none in Fedora 5 even on x86. Why not switch to shared libraries?


I do think we want to use static compilation to be sure of what we're 
running with.




3. ICU libraries in HARMONY-1678 had to be linked as well because build wants 
libicu*.so.34 while libraries in the archives have libicu*.so.34.1 names. 
Shouldn't they be added to SVN like depends/libs/linux.x86 ones with the same 
names as build wants?


4. Classlib always builds to "deploy" directory. When working with different 
architectures it is good when output directories for all files including 
object files are different. Otherwise it is necessary to create separate 
repositories for every one of them or do clean rebuild on every switch and 
never forget which version of classlib is currently built. Could we change 
classlib build to create object files in directories with architecture 
postfix and final output to something like "deploy-x86_64"? Also we could 
separate debug/release built files in the same way.


+1

geir

[classlib][pack200] Status update

[Alex Blewitt]

I'm still lurking around in the background, but I'm busier than ever
what with having to keep posting at EclipseZone where I'm editor now
... but I'm still managing to plod along with the Pack200 code. The
last patch (1994, IIRC) went down pretty badly; the subclipse plugin
didn't seem to capture all the newly created classes that I had put
together for a bit of refactoring that I did. It's also a nightmare
submitting newly created files; once they've been uploaded to JIRA
into the patch queue, I effectively have to stop work until they're
applied, because there's no way of getting SVN to figure out that the
file called ClassFile.java is the same as the ClassFile.java that's
been added by someone else on my behalf, and I have to overwrite my
local copy to update. Kinda prevents doing any sensible work on newly
created files between submission and application to be honest.

Instead, I plan to sprint (well, jog, at least) to the next stable
point, and then upload a whole wodge of code and leave it for a week
or two to be applied before picking up again. I'm fairly close to
being at that stage, but not quite. Where I am at is being able to
generate (abstract) methods with exceptions and fields with constant
(integer) values, so a bit further forward than last time. On the one
hand, it means that I understand what needs to be done (no mean feat!)
but on the other hand, there's still a fair bit to go. For a start,
I'm going to need to process the actual bytecode for non-abstract
methods (or indeed, any classes) before there's any point in it trying
to be used for real, and there's still a few missing bits (Longs,
Doubles, Floats) from the constant pools. I'm pretty sure Strings
would work, but I've not tried them yet.

Unfortunately, the code is really awful. The Segment.java is getting
on for 1500 lines of code in a single class; and the attribute parsing
contains both duplicated code and isn't as generic as it needs to be
to handle other attributes; and the (in)visible annotations like
@Overrides and similar are going to be a bit of a nightmare ...

My plan is to get the code to a stage where it can start to be useful
for extracting simple classes from a pack file, and then start
generating test data which can be used for regressions. (There's a bit
there at the moment, but it's not exactly a large coverage.) Once I've
done that, I'll start tackling some of the refactoring which will
result in less duplicated code and hopefully something that will be
easier to look after in the future.

Anyway, excuse the long rambling but I've been a bit quiet for a while
and wanted to let people know I was still alive and kicking the code
:-)

Alex.

Re: [general] Sun will take GPL License?

[Dalibor Topic]

Geir Magnusson Jr.  pobox.com> writes:

> 
> 
> Alexey Petrenko wrote:
> > Java under GPL? It is probably bad news for Java developers...
> > 
> > As far as I understand you'll can not create non GPL application on
> > top of GPL Java...
> > License gurus, is that right?
> 
> GPL proponents claim that there is no problem running under a GPL-ed VM, 
> but given aspects such as JNI and such, I do wonder if that's simply 
> wishful thinking.

I'd be very surprised, in case that they actually decided to go with the GPL, if
they haven't thought about all that, and have a bunch of good answers that
explain that all the desirable things can happen without leaving any room for
fear, uncertainty or doubt about the effects of the license.

After all, one should not forget that Sun has managed to get the JDK into
Debian. So they must have more than sufficient experience in dealing with
armchair lawyering about their license choices on the internet. ;)

cheers,
dalibor topic

Re: [general] Sun will take GPL License?

[Dalibor Topic]

Geir Magnusson Jr.  pobox.com> writes:

> I think that in order to really work for the "free-as-in-stallman" ;) 
> community, someone will have to literally fork sun's GPL-ed 
> implementation, as I'm guessing GPL advocates will want to be able to 
> contribute / augment / maintain the codebase, but not allow Sun to 
> re-license their contributions under commercial terms.

Sounds like a pointless idea to me, as a GPL advocate. ;)

Whether I contribute to GNU Classpath, Apache Harmony or Sun's project, the end
result can be used in proprietary runtimes anyway, and in Classpath's & Sun's
case actually is used that way. That doesn't hurt my own use of that code, or
that of my users.

If people chose to license that code under more restrictive terms, than it's
available under, than that's their right, as is mine not to make that choice. As
long as the same code remains available under a licensing choice that allows me
to use it (i.e. GPL-compatible in my GPL advocate case), I'd see no reason to
complain about it, or to refuse to contribute to it.

cheers,
dalibor topic

Re: [classlib][sound] Volunteer to implement missing & bad APIs in javax.sound.sampled

[Andrew Zhang]

On 11/9/06, Boris Kuznetsov <[EMAIL PROTECTED]> wrote:


Hi Andrew,

I'm working on javax.sound.sampled API now.
I have completed the following classes:
AudioFileFormat, AudioFormat, AudioInputStream, BooleanControl,
CompoundControl, Control, DataLine, EnumControl.
I'll file a JIRA with patch shortly.

Sorry that I didn't notice about this work earlier.
Let's do it together.



Good. Boris, I'll start to work on sound after applying Harmony-2117. Will
you supply test cases for Harmony-2117 implementation source code soon?
Thanks!


Thanks,

Boris

On 11/9/06, Andrew Zhang <[EMAIL PROTECTED]> wrote:
> On 11/9/06, Nathan Beyer <[EMAIL PROTECTED]> wrote:
> >
> > You may want to take a quick scan of JIRA for "sound" items, just to
> > make sure there aren't any additional patches that haven't been
> > applied.
>
>
> Thanks Nathan. Seems only Harmony-1644 [1] is not applied yet, which is
> about SerialVersionUID.
>
> [1] http://issues.apache.org/jira/browse/HARMONY-1644
>
>
> > -Nathan
> >
> > On 11/8/06, Andrew Zhang <[EMAIL PROTECTED]> wrote:
> > > Hi folks,
> > >
> > > According to the japi result, there're 0.29% bad, and 8.7% missing
APIs
> > in
> > > javax.sound.sampled package. I'd like to work on this package to
make
> > the
> > > statistics look better. :)  Anyone else is interested too?
> > >
> > > Please let me know if you have any concern/comment/suggestion. :)
> > Thanks!
> > >
> > > --
> > > Best regards,
> > > Andrew Zhang
> > >
> > >
> >
>
>
>
> --
> Best regards,
> Andrew Zhang
>
>


--
Best regards,
Boris Kuznetsov
Intel Middleware Products Division





--
Best regards,
Andrew Zhang

Re: [drlvm][classlib] DaCapo benchmark regressions

[Geir Magnusson Jr.]

Robin Garner wrote:

Geir Magnusson Jr. wrote:



Robin Garner wrote:

Geir Magnusson Jr. wrote:
Nice - we should put this on the website (maybe same place where we 
point to JAPI results).


Are you tracking performance #'s over time?  You are just tracking 
regression in terms of how much runs, rather than how fast?


geir


Right now it's just regression failures, but I'm working on graphs of 
performance over time, for the non-commercial VMs at least.


Do 'em all!  We need to track ourselves to Sun et al, because that's 
what we're trying to achieve :)


Well ... I thought there were legal issues wrt releasing performance 
numbers of some of these VMs.


That's a good point.  I didn't think there were, but I'll admit I 
havent' read the license for hte Sun binary closely on that issue.  We 
should figure that out...




This is a temporary home, so don't link to it too permanently :)


ok.  We'll use the ...


:-P


geir



cheers



Robin Garner wrote:



Weldon Washburn wrote:

Fantastic!

By the way, the http:// link below did not work for me.


Doh!

  http://cs.anu.edu.au/people/Robin.Garner/dacapo/regression/



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


I've just finished adding drlvm to the nightly DaCapo benchmark
regression tests.  The results are available here:

http://cs/people/Robin.Garner/dacapo/regression/

JikesRVM and DRLVM/Harmony classlib are built from svn checkouts 
taken

when the nightly run kicks off (00:35 Australian Eastern time).

I'm currently working on adding performance stats for DRLVM and
JikesRVM, so some suggestions about the best command line 
parameters to

use would be appreciated.

cheers

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

[classlib] Building on x86_64

[Gregory Shimansky]

Hello

Today I tried to check what happens on x86_64 and I think I've found some 
issues which need discussion

1. When classlib starts its built it tries to link 3 libraries and headers to 
depends/libs/build/{jpeg,lcms,png} directories. On x86_64 SuSE9 it has failed 
for me to find lcms and png libraries because they happen to be 
in /usr/lib64. This should not be the case on Gentoo because /usr/lib is a 
link to /usr/lib64, but it looks like not all distributions follow this way. 
So probably searching /usr/lib64 first should be done on x86_64.

2. I've linked liblcms.a and libpng.a in /usr/lib64 by hands but then linker 
complained that they cannot be used because relocations have to be done. I've 
replaced links with links to *shared* libs and it seems to have worked ok. 
For some reason libjpeg.a found in /usr/lib didn't cause the problems. But 
anyway, I'd like to ask a question, why do we want static linking? Not all 
distributions supply static versions of these libraries, for example I found 
none in Fedora 5 even on x86. Why not switch to shared libraries?

3. ICU libraries in HARMONY-1678 had to be linked as well because build wants 
libicu*.so.34 while libraries in the archives have libicu*.so.34.1 names. 
Shouldn't they be added to SVN like depends/libs/linux.x86 ones with the same 
names as build wants?

4. Classlib always builds to "deploy" directory. When working with different 
architectures it is good when output directories for all files including 
object files are different. Otherwise it is necessary to create separate 
repositories for every one of them or do clean rebuild on every switch and 
never forget which version of classlib is currently built. Could we change 
classlib build to create object files in directories with architecture 
postfix and final output to something like "deploy-x86_64"? Also we could 
separate debug/release built files in the same way.

-- 
Gregory Shimansky, Intel Middleware Products Division

Re: [drlvm][classlib] DaCapo benchmark regressions

[Robin Garner]

Geir Magnusson Jr. wrote:



Robin Garner wrote:

Geir Magnusson Jr. wrote:
Nice - we should put this on the website (maybe same place where we 
point to JAPI results).


Are you tracking performance #'s over time?  You are just tracking 
regression in terms of how much runs, rather than how fast?


geir


Right now it's just regression failures, but I'm working on graphs of 
performance over time, for the non-commercial VMs at least.


Do 'em all!  We need to track ourselves to Sun et al, because that's 
what we're trying to achieve :)


Well ... I thought there were legal issues wrt releasing performance 
numbers of some of these VMs.




This is a temporary home, so don't link to it too permanently :)


ok.  We'll use the ...


:-P


geir



cheers



Robin Garner wrote:



Weldon Washburn wrote:

Fantastic!

By the way, the http:// link below did not work for me.


Doh!

  http://cs.anu.edu.au/people/Robin.Garner/dacapo/regression/



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


I've just finished adding drlvm to the nightly DaCapo benchmark
regression tests.  The results are available here:

http://cs/people/Robin.Garner/dacapo/regression/

JikesRVM and DRLVM/Harmony classlib are built from svn checkouts 
taken

when the nightly run kicks off (00:35 Australian Eastern time).

I'm currently working on adding performance stats for DRLVM and
JikesRVM, so some suggestions about the best command line 
parameters to

use would be appreciated.

cheers

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














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

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

[Geir Magnusson Jr.]

Robin Garner wrote:

Weldon Washburn wrote:

It looks like I called for a vote too soon.  The continuing discussion on
class unloading design is uncovering many important issues.  This is
excellent as it is much better to deal with design issues at this stage
rather than during implementation.

I propose the following:

1)
Cancel the current vote on design.

2)
Someone put together a complete class unloading design based on
Etienne/Robin's approach.  Include pseudo code and post to harmony-dev.

3)
We call for a new vote once the comments on the documented design 
indicate

it is ready.



Could I also suggest that maybe the mailing list isn't the most ideal 
place to keep draft design documents ?  Isn't there a wiki or some other 
web page where it could be kept and referred to ?


Does anyone ever keep design documents on a mail list?

We have wiki, website and svn.  I'd suggest wiki for now until it 
solidifies, and then into SVN w/ a view from the website.


geir

Re: [crypto] SHA-1 not implemented?

[Robin Garner]

Stefano Mazzocchi wrote:

from Robin's latest runs
 
http://cs.anu.edu.au/people/Robin.Garner/dacapo/regression/results-20061110/DRLVM/eclipse.small.log

there are a bunch of log messages that indicate that harmony doesn't
implement SHA-1.

Is that true?



It can't be true, because _all_ the DaCapo benchmarks rely on SHA-1 for 
validation.  I raised JIRA Harmony-2135 on this issue.  Looks like after 
eclipse has run, drlvm forgets how to access the SHA-1 algorithm :(


--
Robin Garner
Dept. of Computer Science
Australian National University
http://cs.anu.edu.au/people/Robin.Garner/

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

[Robin Garner]

Weldon Washburn wrote:

It looks like I called for a vote too soon.  The continuing discussion on
class unloading design is uncovering many important issues.  This is
excellent as it is much better to deal with design issues at this stage
rather than during implementation.

I propose the following:

1)
Cancel the current vote on design.

2)
Someone put together a complete class unloading design based on
Etienne/Robin's approach.  Include pseudo code and post to harmony-dev.

3)
We call for a new vote once the comments on the documented design indicate
it is ready.



Could I also suggest that maybe the mailing list isn't the most ideal 
place to keep draft design documents ?  Isn't there a wiki or some other 
web page where it could be kept and referred to ?


--
Robin Garner
Dept. of Computer Science
Australian National University
http://cs.anu.edu.au/people/Robin.Garner/

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

[Geir Magnusson Jr.]

Yeah, I was going to point that out this morning, but decided to let it go.

There is really nothing technical to vote on here yet.  This is more of 
a "poll" to get discussion going about preferred approaches, and see if 
we can drive to consensus on how to move forward.  So for that, it was 
good that weldon kicked that off


So this is a good discussion, driving us towards an approach, but in the 
end, we'll really be choosing an implementation.


That said, anyone would be free to work on alternatives if they didn't 
agree with the rest of the group, but they would still need to 
demonstrate why that solution was better...


geir


Rana Dasgupta wrote:

Identifying an end to end alogirithm is of course necessary, and the
discussions on the other thread are great. But what were we voting on here?
My understanding was that we were voting on the approach of using:

1. vtable objects( Aleksey )
2. per heap space/generation boolean marker on the classloader instance(
Etienne )
3. class reachability marker byte in vtable (Robin )

and not on three end-to-end algorithms since Robin's description was not
one. I am OK if we now want to cancel the vote, but next time we vote on a
technical issue it may be a good idea for the caller to summarize the
contending solutions on the thread and then call for the vote.

Thanks,
Rana

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


It looks like I called for a vote too soon.  The continuing discussion on
class unloading design is uncovering many important issues.  This is
excellent as it is much better to deal with design issues at this stage
rather than during implementation.

I propose the following:

1)
Cancel the current vote on design.

2)
Someone put together a complete class unloading design based on
Etienne/Robin's approach.  Include pseudo code and post to harmony-dev.

3)
We call for a new vote once the comments on the documented design 
indicate

it is ready.


On 11/8/06, Robin Garner < [EMAIL PROTECTED]> wrote:
>
> Pavel Pervov wrote:
> > Really BIG -1 from me.
> >
> > As Aleksey (Ignatenko) described in original thread, j/l/Class'es and
> > j/l/ClassLoader's are always available in rootset, so even if no
objects
> > of a class exist, this class will be reachable.
> >
> > Actually, some sort of class unloading prototype exists in DRLVM 
code,

> > which
> > implements the scheme, which is very close to what is currently 
voted.


> It
> > was integrated with GC v4 and is not supported by other GCs. This
> prototype
> > traces up to class loader. Robin's approach is way faster then
prorotype
> > is.
> >
> > Unfortunately, that approach requires up to 3 GC cycles to 
complete in

> > DRLVM.
>
> In a full-heap STW collector, my proposal would require 1 GC to collect
> unused classloaders.  In a generational STW collector, 1 full-heap GC,
> and would depend on the particular invariants enforced by an
> incremental/concurrent collector, but would be 1 complete "cycle" of 
any

> of the standard algorithms (I guess up to 3 GCs if the sweeps happened
> at the wrong places).
>
> > BTW, voted approach does not describe "proof-of-full-collection"
> algorithm
> > (at least I didn't find one). The only one I think of is
> > full-heap-collection, which _requires_ STW.
>
> My approach simply requires the underlying collector to have a notion
> that periodically it can say that 'every reachable object allocated
> since time 't' is now marked reachable.  If the class-unloader can
> ensure that one full epoch of this invariant has passed, then it can
> safely perform unloading.
>
> > Although "automatic anloading" brings some additional requirements 
for

> GC
> > (weak roots (references) support and pinned allocation), it is proven
to
> > work (patch available) and, also, is the most natural algorithm for
> DRLVM.
>
> What is the run-time cost of it ?  And where is it described ?  I was
> only aware of Etienne's proposal as a full class-unloading scheme.
>
> > With the best regards,
>
>
> --
> Robin Garner
> Dept. of Computer Science
> Australian National University
>



--
Weldon Washburn
Intel Enterprise Solutions Software Division

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

[Rana Dasgupta]

Identifying an end to end alogirithm is of course necessary, and the
discussions on the other thread are great. But what were we voting on here?
My understanding was that we were voting on the approach of using:

1. vtable objects( Aleksey )
2. per heap space/generation boolean marker on the classloader instance(
Etienne )
3. class reachability marker byte in vtable (Robin )

and not on three end-to-end algorithms since Robin's description was not
one. I am OK if we now want to cancel the vote, but next time we vote on a
technical issue it may be a good idea for the caller to summarize the
contending solutions on the thread and then call for the vote.

Thanks,
Rana

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


It looks like I called for a vote too soon.  The continuing discussion on
class unloading design is uncovering many important issues.  This is
excellent as it is much better to deal with design issues at this stage
rather than during implementation.

I propose the following:

1)
Cancel the current vote on design.

2)
Someone put together a complete class unloading design based on
Etienne/Robin's approach.  Include pseudo code and post to harmony-dev.

3)
We call for a new vote once the comments on the documented design indicate
it is ready.


On 11/8/06, Robin Garner < [EMAIL PROTECTED]> wrote:
>
> Pavel Pervov wrote:
> > Really BIG -1 from me.
> >
> > As Aleksey (Ignatenko) described in original thread, j/l/Class'es and
> > j/l/ClassLoader's are always available in rootset, so even if no
objects
> > of a class exist, this class will be reachable.
> >
> > Actually, some sort of class unloading prototype exists in DRLVM code,
> > which
> > implements the scheme, which is very close to what is currently voted.

> It
> > was integrated with GC v4 and is not supported by other GCs. This
> prototype
> > traces up to class loader. Robin's approach is way faster then
prorotype
> > is.
> >
> > Unfortunately, that approach requires up to 3 GC cycles to complete in
> > DRLVM.
>
> In a full-heap STW collector, my proposal would require 1 GC to collect
> unused classloaders.  In a generational STW collector, 1 full-heap GC,
> and would depend on the particular invariants enforced by an
> incremental/concurrent collector, but would be 1 complete "cycle" of any
> of the standard algorithms (I guess up to 3 GCs if the sweeps happened
> at the wrong places).
>
> > BTW, voted approach does not describe "proof-of-full-collection"
> algorithm
> > (at least I didn't find one). The only one I think of is
> > full-heap-collection, which _requires_ STW.
>
> My approach simply requires the underlying collector to have a notion
> that periodically it can say that 'every reachable object allocated
> since time 't' is now marked reachable.  If the class-unloader can
> ensure that one full epoch of this invariant has passed, then it can
> safely perform unloading.
>
> > Although "automatic anloading" brings some additional requirements for
> GC
> > (weak roots (references) support and pinned allocation), it is proven
to
> > work (patch available) and, also, is the most natural algorithm for
> DRLVM.
>
> What is the run-time cost of it ?  And where is it described ?  I was
> only aware of Etienne's proposal as a full class-unloading scheme.
>
> > With the best regards,
>
>
> --
> Robin Garner
> Dept. of Computer Science
> Australian National University
>



--
Weldon Washburn
Intel Enterprise Solutions Software Division

Re: [drlvm] Class unloading support

[Weldon Washburn]

Aleksey,
I tried to apply native_sources_cleanup_upd.patch.  svn HEAD has changed and
the patch no longer works.  Part of the problem is that JIRA 1558 has been
committed.  In addition to the below issues, I posted comments to
JIRA HARMONY-2000.


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


Aleksey,

Excellent step forward -- breaking the patch into two pieces.   This made
the patch(es) much more readable.

I glanced at native_sources_cleanup.patch.  It looks like code for
alloc/dealloc vtables and jitted code blocks.  The original patch made
vtables into objects.  Will native_sources_cleanup need to change if vtables
are normal C structs instead?  Also, I see reference to path .../gcv4/...  I
guess this will need to change to support gc_gen and gc_cc.

Once you get native_sources_cleanup.patch in good shape, I have no problem
committing it.

If there is no other debate on class unloading design, I will call for a
vote in a seperate email.



On 11/2/06, Aleksey Ignatenko <[EMAIL PROTECTED]> wrote:
>
> Hi, everyone.
>
> I've splitted Harmony-2000 (see details:
> http://issues.apache.org/jira/browse/HARMONY-2000) patch with automatic
> class unloading implementation into 2 independent parts:
> 1. cleaning native resources (native_sources_cleanup.patch).
> 2. automatic unloading design implementation (auto_unloading.patch).
>
> The first part is independent for all class unloading designs and could
> be
> commited. The second part is class unloading design implementation (the
> best
> class unloading approach is discussed now).
>
> I propose to commit native_sources_cleanup.patch and continue class
> unloading development with minimal requirements on drlvm.
>
> Aleksey.
>
>
> On 11/1/06, Aleksey Ignatenko <[EMAIL PROTECTED]> wrote:
> >
> > Oops, sorry, misprinted in my suggestion:
> > if (cl->IsBootstrap() *||
> *env->b_VTable_trace_is_not_supported_by_GC)
> >
> > {
> > vm_enumerate_jlc(c);
> > if (c->vtable)
> > vm_enumerate_root_reference((void**)&c->vtObj,
> > FALSE);
> > }
> >
> > Aleksey.
> >
> >  On 11/1/06, Aleksey Ignatenko < [EMAIL PROTECTED]> wrote:
> > >
> > > Weldon,
> > >
> > > >A question for all involved.  Is it possible to somehow make it
> appear
> > > that
> > > >the new objects related to unloading  (VTable, ClassLoader,
> etc)  are
> > > always
> > > >reachable and thus never collected?  I am trying to figure out a
> way to
> > > make
> > > >integration of class unloading independent of correct support
> inside
> > > the GC
> > > >and JIT.  This option could be a command line switch or compile
> time
> > > option.
> > >
> > > I agree with Robin:
> > > >Simple.  Keep a list or table of these objects as part of the root
> set.
> > > >Enumerate it optionally depending on a command line option.
> > >
> > > Details: you can see from Harmony-2000 patch, that this is done for
> > > Bootstrap classes already. If you look at root_set_enum_common.cpp
> (with the
> > > patch applied) vm_enumerate_static_fields() function, there is line:
> > > if (cl->IsBootstrap())
> > > {
> > > vm_enumerate_jlc(c);
> > > if (c->vtable)
> > >
> vm_enumerate_root_reference((void**)&c->vtObj,
> > > FALSE);
> > > }
> > > else
> > > {
> > > vm_enumerate_jlc(c, true/*weak*/);
> > > }
> > > You can see, that there are strong roots to Bootstrap j.l.Classesand
> > > their VTable objects. So I suppose, that it would be very simple to
> > > propogate strong roots to all other classes (not only Bootstrap),
> something
> > > like:
> > > if (cl->IsBootstrap() *&&
> > > env->b_VTable_trace_is_not_supported_by_GC*)
> > > {
> > > vm_enumerate_jlc(c);
> > > if (c->vtable)
> > >
> vm_enumerate_root_reference((void**)&c->vtObj,
> > > FALSE);
> > > }
> > > where *b_VTable_trace_is_not_supported_by_GC *is flag which is set
> > > according to used GC. This will force switching off any class
> unloading
> > > support.
> > >
> > > Aleksey.
> > >
> > >  On 11/1/06, Robin Garner <[EMAIL PROTECTED] > wrote:
> > > >
> > > > Weldon Washburn wrote:
> > > > > On 10/30/06, Robin Garner < [EMAIL PROTECTED] > wrote:
> > > > >>
> > > > >> Weldon Washburn wrote:
> > > > >> > On 10/27/06, Geir Magnusson Jr. < [EMAIL PROTECTED]> wrote:
> > > > >> >>
> > > > >> >>
> > > > >> >>
> > > > >> >> Weldon Washburn wrote:
> > > > >> >> > Steve Blackburn was in Portland Oregon today.  I mentioned
> the
> > > > idea
> > > > >> of
> > > > >> >> > adding a  reference pointer from object to its
> j.l.Classinstance.
> > > > >> >> MMTk
> > > > >> >> > was
> > > > >> >> > not designed with this idea in mind.  It looks like you
> will
> > > > need to
> > > > >> >> fix
> > > > >> >> > this part of MMTk and ma

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

[Weldon Washburn]

It looks like I called for a vote too soon.  The continuing discussion on
class unloading design is uncovering many important issues.  This is
excellent as it is much better to deal with design issues at this stage
rather than during implementation.

I propose the following:

1)
Cancel the current vote on design.

2)
Someone put together a complete class unloading design based on
Etienne/Robin's approach.  Include pseudo code and post to harmony-dev.

3)
We call for a new vote once the comments on the documented design indicate
it is ready.


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


Pavel Pervov wrote:
> Really BIG -1 from me.
>
> As Aleksey (Ignatenko) described in original thread, j/l/Class'es and
> j/l/ClassLoader's are always available in rootset, so even if no objects
> of a class exist, this class will be reachable.
>
> Actually, some sort of class unloading prototype exists in DRLVM code,
> which
> implements the scheme, which is very close to what is currently voted.
It
> was integrated with GC v4 and is not supported by other GCs. This
prototype
> traces up to class loader. Robin's approach is way faster then prorotype
> is.
>
> Unfortunately, that approach requires up to 3 GC cycles to complete in
> DRLVM.

In a full-heap STW collector, my proposal would require 1 GC to collect
unused classloaders.  In a generational STW collector, 1 full-heap GC,
and would depend on the particular invariants enforced by an
incremental/concurrent collector, but would be 1 complete "cycle" of any
of the standard algorithms (I guess up to 3 GCs if the sweeps happened
at the wrong places).

> BTW, voted approach does not describe "proof-of-full-collection"
algorithm
> (at least I didn't find one). The only one I think of is
> full-heap-collection, which _requires_ STW.

My approach simply requires the underlying collector to have a notion
that periodically it can say that 'every reachable object allocated
since time 't' is now marked reachable.  If the class-unloader can
ensure that one full epoch of this invariant has passed, then it can
safely perform unloading.

> Although "automatic anloading" brings some additional requirements for
GC
> (weak roots (references) support and pinned allocation), it is proven to
> work (patch available) and, also, is the most natural algorithm for
DRLVM.

What is the run-time cost of it ?  And where is it described ?  I was
only aware of Etienne's proposal as a full class-unloading scheme.

> With the best regards,


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





--
Weldon Washburn
Intel Enterprise Solutions Software Division

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

[Geir Magnusson Jr.]

Stuart Ballard wrote:


Japitools isn't affiliated with Classpath btw, I had Classpath in mind
when I originally developed it, yes, and it's GPL licensed because I
have a mild preference for that license, but I don't feel strongly
about it. One of the reasons I started a Japitools list in fact was to
try to have some neutral ground for discussions to avoid any
perception (or, even worse, reality) that Harmony had any kind of
second class status.


For what it's worth, I don't care that it's under the GPL, and I don't 
care where it's hosted, or what community it's associated with.


I'm really glad that you create the program, and really appreciative 
that you generously spend your time also analyzing the harmony code base.


I think of Japitools as one of the first bridges between the two 
communities, and it's encouraging for me that it's there and thriving.




While I admit that coming from the Classpath side of the fence
originally, I have mixed feelings about whether the licensing
differences were actually worth starting a whole separate project for.
But Harmony exists and I hope it succeeds, just as I hope Classpath
succeeds. More interoperable implementations can't hurt. And the
"interoperable" part is where Japitools comes in.


Agreed - more open source java is good!



So can we all play nice? ;)


Yes :)



Stuart.

Re: [drlvm] release vs. debug

[Geir Magnusson Jr.]

Well, since the problem is repeatable :)


Gregory Shimansky wrote:

Geir Magnusson Jr. wrote:



Alexei Zakharov wrote:

Hi DRLVM fans,

I encountered a rather strange problem while working on some class
library tests. At least two tests from the beans module hang (or
crash) while running on DRLVM debug builds but work fine on DRLVM
release builds. I thought that debug build is something about adding
debug symbols to VM binaries and this should not affect the
functionality. Can someone shed a light on this? 


I would think it's just an assertion firing...


Actually it is more than that. In debug mode TRACE statements are 
compiled and therefore produce executable code. There may also be some 
bugs in compiler generating code in different modes (although this 
usually happens for release).


I don't know why hanging happens, but the difference in generated code 
is actually quite big. Also assertions or any crashes go to 
exceptions/signal handlers which may happen to loop infinitely, there 
were bugs like this happening on the current version of sources, look at 
HARMONY-2018 and HADMONY-2006.



This is the first
question. The second question - what we should do with such tests. The
tests pass on the downloadable HDK and JRE snapshots as well as on
classlib + j9. What should be the commit criteria for DRLVM – i.e.
what is the *true* build? :) I think many people here currently use
snapshots to test their patches.


debug :)  don't sweep the problems under the rug...


+1

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

[Geir Magnusson Jr.]

Stuart Ballard wrote:

Geir Magnusson Jr. wrote:

David Gilbert wrote:
> A boon?  Not at all, Classpath will be (mostly) redundant and will fade
> away, replaced by Sun's runtime.

I'm not so convinced of that.  GNU Classpath is under GPL + Exception,
so arguably it's not viral to things that link with it.


I think it's highly unlikely Sun will release their VM without terms
that enable proprietary code to be built on top of it. That'd be
particularly counterproductive of them.

My speculation would be that they'll release it under two licenses,
one similar to the terms they have now, and the GPL as the other. Code
released under those terms is clearly not viral.


Yes, they will clearly do that - offer a license that allows proprietary 
implementation.  However, that license won't be free or open source.





Also, I think the copyright assignment requirement will be a big deal.


If OpenOffice is anything to go by, Sun will require a copyright
assignment to them; Classpath requires a copyright assignment to the
FSF. Yes, that's a little bit different because a lot of developers
will trust the FSF a lot more than they do Sun...


And Sun is a commercial entity, with a responsibility to it's 
shareholders, not to a non-profit charter.




I actually think it'd be really smart of Sun to not require a
copyright assignment at all, but rather require contributing
developers to license their code under *both* sets of terms just as
Sun itself does. That would allow Sun to continue to use the dual
licensing scheme without the stigma of the copyright assignment
requirement. And it's very similar (in spirit, if not in details) to
the model that Mozilla has used for years - originally to allow
Netscape to make proprietary releases based on the contributed code.


Sure - but their second license won't be an open source one.



As far as the suggestion elsewhere in the thread (that I lost, digest
mode subscription is painful ;) ) that the GNU people would feel it
necessary to fork Sun's Java entirely to maintain their sense of
freedom, I don't think this is so. The FSF have fairly strong
philosophical disagreements with Linus but have never forked the
kernel. They have philosophical disagreements with the ASF sometimes
but there isn't a GNU fork of the Apache webserver. I think a GPL'd
Java would be considered acceptable - because the license allows the
*option* of a fork if Sun proves to be a sufficiently poor steward.
But I've never heard of a project being "preemptively" forked on the
offchance the maintainer will make unacceptable decisions in the
future. At least I've never heard of such a fork having even the
slightest success.


Sorry if you misunderstood me.  I didn't meant to suggest that they 
would - I was probably speculating that it was one possible solution - 
someone could fork the codebase if they wanted to avoid having to assign 
joint copyright.




A lot depends, of course, on how Sun actually engages the community -
I'd say that's even more important than the license, as long as the
license isn't *completely* un-work-withable.


yes - agreed




Understood.  For me, an additional requirement is an open and level
community, where all participants are working together under exactly the
same terms. (Which is where GNU Classpath will be different than what I
understand the Sun model will be)


I don't consider it a foregone conclusion either way as to whether
Classpath will or won't continue with any enthusiasm if Sun's
implementation is released under an acceptable license and with an
acceptable process for getting contributions back in. There's a lot of
momentum behind Classpath right now but it might be hard to justify
all the effort to get from (essentially) complete 1.4 and parts of
1.5, to parity with Sun's 6.

Either way we live in interesting times :) And either way Sun's
release under *any* open source license is a very good thing.


Indeed!

geir



Stuart.

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

[Stuart Ballard]

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

Sometimes some climbers manage to get to the other side to find that
some people are very welcoming and appreciative of cultural differences
while others not so much.


Ok, wow, this whole subthread is kind of what I meant by the politics
being scary.

I think we can all agree that among the Classpath devs and among the
Harmony devs there's plenty of goodwill in theory but also a fair
degree of disillusionment that the hoped-for level of cooperation
wasn't able to materialize.

But improving Japitools and having a better understanding of what it
does and doesn't do is in the best interests of both projects - and
other projects that might want to use it.

Japitools isn't affiliated with Classpath btw, I had Classpath in mind
when I originally developed it, yes, and it's GPL licensed because I
have a mild preference for that license, but I don't feel strongly
about it. One of the reasons I started a Japitools list in fact was to
try to have some neutral ground for discussions to avoid any
perception (or, even worse, reality) that Harmony had any kind of
second class status.

While I admit that coming from the Classpath side of the fence
originally, I have mixed feelings about whether the licensing
differences were actually worth starting a whole separate project for.
But Harmony exists and I hope it succeeds, just as I hope Classpath
succeeds. More interoperable implementations can't hurt. And the
"interoperable" part is where Japitools comes in.

So can we all play nice? ;)

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

[crypto] SHA-1 not implemented?

[Stefano Mazzocchi]

from Robin's latest runs
 
http://cs.anu.edu.au/people/Robin.Garner/dacapo/regression/results-20061110/DRLVM/eclipse.small.log

there are a bunch of log messages that indicate that harmony doesn't
implement SHA-1.

Is that true?

-- 
Stefano.

RE: [build] Building on Eclipse - FYI

[Morozova, Nadezhda]

Sian, 
As I understand, thanks to your patches, we now have a nice webpage that
describes generics + classlib specifics, with a few items for drlvm.
This is an achievement as it is, so perhaps, we can hold off rolling
back to classlib only :)
I sent an email just now to ask people whether anybody has anything to
share on eclipse+drlvm. Depending on what comes out of this little poll,
we could decide on distributed content. What do you say?

Thank you, 
Nadya Morozova
 

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

Yes that sounds fine.  Shall I update my patch to remove the DRLVM
references, or would you prefer to?  Since I did not write very much
about
DRLVM we could leave that out for now and then the person who updates
"Getting Started with DRLVM" could choose to add something there if
people
feel it's appropriate.

Regards,

Sian


On 09/11/06, Konovalova, Svetlana <[EMAIL PROTECTED]> wrote:
>
> Folks,
> Looking through the site and figuring out how to improve the docs that
> include info on Eclipse, the following ideas came up to my mind:
> 1) Since the "Developing Apache Harmony Class-library
> Code with Eclipse" page [1] is mostly class-library oriented, I
suggest
> reviewing it to remove purely DRLVM-oriented info and leave the page
> where it is now [subcomponents/classlibrary/dev_eclipse.html].
> 2) Add the link from the Quick Help pages to the "Developing Apache
> Harmony Class-library Code with Eclipse" page [1].
> 3) Gather purely DRLVM-oriented info to store it in the "Getting
Started
> with DRL" doc (hope it won't be wiped off the face of the earth; for
> details, see the discussion thread: [doc][drlvm] The document "Getting
> started with DRL" is outdated)
> In this case, we'll get two docs providing info on developing with
> Eclipse:
> [1] - describing how to develop class-library code with Eclipse, and
"GS
> with DRL"(or whatever it'll be) describing how to develop DRLVM
> application in Eclipse.
> Any objections? What do you think? Please right me if I'm wrong.
>
> Best regards,
> Sveta Konovalova
>
> [1]
>
http://incubator.apache.org/harmony/subcomponents/classlibrary/dev_eclip
> se.html
>
>
> -Original Message-
> From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED]
> Sent: Thursday, November 09, 2006 3:58 PM
> To: harmony-dev@incubator.apache.org
> Subject: Re: FW: [build] Building on Eclipse - FYI
>
>
>
> Egor Pasko wrote:
> > On the 0x21C day of Apache Harmony Sian January wrote:
> >> Hello again,
> >>
> >> I have had a closer look at the  "Developing Apache Harmony
> Class-library
> >> Code with Eclipse" page, and I have noticed that the "Configuring
> Eclipse"
> >> and "Develop and Test Code" sections are quite class-library
> specific.
> >> Would it be better to leave those sections as they are and add a
> "Developing
> >> DRLVM with Eclipse" section on the same page?
> >
> > To the moment I am not aware of anybody who would use Eclipse for
> > DRLVM development. So, it's too early to add a page like this.
>
> This will ensure that no one does then - if it's simple to add, lets
add
>
> it...
>
> geir
>
> >
> >> Thanks,
> >>
> >> Sian
> >>
> >>
> >>
> >> On 07/11/06, Konovalova, Svetlana <[EMAIL PROTECTED]>
> wrote:
> >>>
> >>> 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,
> >>> S

Anybody tried DRLVM+Eclipse and can share? [WAS: Re: FW: [build] Building on Eclipse - FYI]

[Morozova, Nadezhda]

Folks, 

Has anybody tried working with DRLVM in Eclipse? did you have to screw
it before it ran ok? Do you have anything to share? Let's write a doc! 

Background
We've been trying to gather useful info on working with Eclipse and our
code base. Eclipse+classlib page has been updated, see JIRA H2009.
The only drlvm-oriented doc that mentions Eclipse is Getting Started
with DRLVM. The doc is terrifically outdated. 

If anybody has relevant updates, we could update the document/write a
new one/add to eclipse+classlib page to make it cover both vm and
classlib. Volunteers? 

Thank you, 
Nadya Morozova

 
 

-Original Message-
From: news [mailto:[EMAIL PROTECTED] On Behalf Of Egor Pasko
Sent: Thursday, November 09, 2006 7:41 PM
To: harmony-dev@incubator.apache.org
Subject: Re: FW: [build] Building on Eclipse - FYI

On the 0x21C day of Apache Harmony Geir Magnusson, Jr. wrote:
> Egor Pasko wrote:
> > On the 0x21C day of Apache Harmony Geir Magnusson, Jr. wrote:
> >> Egor Pasko wrote:
> >>> On the 0x21C day of Apache Harmony Geir Magnusson, Jr. wrote:
>  Egor Pasko wrote:
> > On the 0x21C day of Apache Harmony Sian January wrote:
> >> Hello again,
> >>
> >> I have had a closer look at the  "Developing Apache Harmony
Class-library
> >> Code with Eclipse" page, and I have noticed that the
"Configuring Eclipse"
> >> and "Develop and Test Code" sections are quite class-library
specific.
> >> Would it be better to leave those sections as they are and add
a "Developing
> >> DRLVM with Eclipse" section on the same page?
> > To the moment I am not aware of anybody who would use Eclipse
for
> > DRLVM development. So, it's too early to add a page like this.
>  This will ensure that no one does then - if it's simple to add,
lets
>  add it...
> >>> Does it help anybody? I see no point in doing redundant work even
if
> >>> it is small.
> >> Why is it redundant?
> > Nobody uses, nobody reads -> redundant. Am I missing something? :)
> 
> if we don't have it, of course nobody uses or reads it...

OK. Let me put it the other way. If someone has something valuable,
not obvious to write about DRLVM+Eclipse, I am for it. If the page is
going to be just a long-living stub, I am not happy.

-- 
Egor Pasko

Re: [drlvm] release vs. debug

[Rana Dasgupta]

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



>Actually it is more than that. In debug mode TRACE statements are
>compiled and therefore produce executable code. There may also be some
>bugs in compiler generating code in different modes (although this
>usually happens for release).

>I don't know why hanging happens, but the difference in generated code
>is actually quite big.



Yes. The code generated differs because the optimization levels are quite
different between debug and release builds. Eg., no code motion happens on
debug build code since the debugger needs to map it back. True, the
generated code size is usually way bigger in debug builds. At least on
Windows, the PE files have more debug info, and actually there is less and
less in the external symbol files ( pdb ) and more and more in the exe's.
It's a trend, and over time, I think pdb's will disappear.

.


>>> This is the first
>>> question. The second question - what we should do with such tests. The
>>> tests pass on the downloadable HDK and JRE snapshots as well as on
>>> classlib + j9. What should be the commit criteria for DRLVM – i.e.
>>> what is the *true* build? :) I think many people here currently use
>>> snapshots to test their patches.
>>
>> debug :)  don't sweep the problems under the rug...

>+1



debug for commit testing, and both release and debug for presubmission
testing hopefully :-)

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

[Daniel Fridlender]

It should be fixed now.

Thanks

Daniel

On 11/8/06, Mikhail Loenko <[EMAIL PROTECTED]> wrote:

Hi Daniel

I've tried the patch you suggested. It causes failure of
org.apache.harmony.tests.java.math.BigDecimalArithmeticTest

Could you please take a look?

Thanks,
Mikhail

2006/11/8, Daniel Fridlender <[EMAIL PROTECTED]>:
> 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: [Fwd: Re: Interesting discoveries playing around with japitools]

[Stefano Mazzocchi]

David Gilbert wrote:
> Geir Magnusson Jr. wrote:
>>
>>
>> The only real issue that we had is license incompatibility, but I
>> thought there was goodwill everywhere to work where we could.
>>
> 
> Why don't we be honest and just admit that there is no goodwill between
> the projects?  It was there, briefly, but now it is gone.  There's no
> collaboration, there's no cooperation...just two separate projects
> implementing the same API.  It is the way it is, and the world is moving
> on...but let's stop pretending.
> 
> Regards,
> 
> Dave Gilbert
> JFreeChart Project Leader
> 
> P.S.  This is a personal opinion, but I'm happy to disclose that I'm an
> occasional contributor to the GNU Classpath project.

Hmmm, let's analyze my 'pretending'...

 1) I started a 'kaffe + classpath' gump run as a way to help myself and
them understand how far along in the 'real world' java implementation
they were.

 2) I spent several hours on the phone and more emails that I can count
over more months that I would like to count discussing ways to change
licensing impedance mismatch in both camps, with several representatives
from the ASF, the FSF and the "free java" community. NOTE: I was an ASF
board member at that time.

 3) Once it was clear that a major change in the GPL was the only viable
alternative, concerned about the fact that continuing harmony might have
impacted Classpath negatively, I asked my "free java" peers for advice
and they *all* suggested me to go ahead, that more free java was always
a good thing. I was ready to drop my mentoring support for Harmony if
that wasn't the case.

 4) I'm subscribed to the japi list to help out (did I mention I didn't
ask for a license change?)

And, last but not least, should I not outline the fact that a licensing
bridge between classpath and harmony would only go *in benefit of
classpath* since there is no way the ASF would allow harmony to be
licensed under the GPL?

In short: there are two valleys and a huge mountain in between.

A tunnel is being built and it's called GPLv3, but it will flow in only
one direction: from our valley to yours. The people of my valley are
happy that the other valley existing and prospering and are even happy
with the fact that the *other* valley will benefit more from the tunnel
than they will. There is competition, but it's healthy and respectful.

We did try to find a pass and build a road, we tried, *hard*, we didn't
find one so we moved on with our lives, wishing each-other best of luck.

Sometimes some climbers manage to get to the other side to find that
some people are very welcoming and appreciative of cultural differences
while others not so much.

-- 
Stefano.

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

[Morozova, Nadezhda]

Alexey,
I agree  that the structure of the resulting HTML website page does not
appear too linear. When editing the structure, I saw the additional
table - and left as is; maybe, because I hoped somebody added it on some
purpose. For me, the only matter of convenience is that all content that
is varied on the page is in a separate table. 
If nobody has an idea why the structure is so complex, we can simplify
it. The structure is defined in file site.vsl in site/xdocs/stylesheets.
A JIRA with patch is welcome as usual.

Thank you, 
Nadya Morozova
 

-Original Message-
From: Ivanov, Alexey A [mailto:[EMAIL PROTECTED] 
Sent: Thursday, November 09, 2006 5:20 PM
To: harmony-dev@incubator.apache.org
Subject: RE: [jira] Good issue resolution guideline (was:
[classlib]volunteer to supply patches for old JIRAs)

Sveta, all,

I've attached the updated patch to the JIRA.

Please review.

Regards,
Alexey.


P.S. By the way, do we really need to place all the main content into
another table? I've just looked at the source of the generated HTML
file, and found it quite confusing. I agree to have a table to format
the heading of the page and the list of contents on the left, but why
there's another table where the main content is. I am about this one:

 
 




   
 
Good Issue
Resolution Guideline

   
   ... 

The comments here are added by me, and the source is slightly
reformatted.
I believe, the  part of the XML can be placed almost as is in the
content cell of the top-level table without the need for another table
because it's useless here. Or is it just Anakia limitation?

--
Alexey A. Ivanov
Intel Enterprise Solutions Software Division


>-Original Message-
>From: Konovalova, Svetlana [mailto:[EMAIL PROTECTED]
>Sent: Thursday, November 09, 2006 3:50 PM
>To: harmony-dev@incubator.apache.org
>Subject: RE: [jira] Good issue resolution guideline (was:
>[classlib]volunteer to supply patches for old JIRAs)
>
>Alexey,
>
>>>I'd change the heading "Reporting the Issue" to "Reporting an Issue",
>>>or omit article at all.
>>> Well, both articles seem to be fine. Let it be "a/an"
>>Maybe just omit articles then?
>Well, how about the third variant: "Reporting Issues"?
>
>
>>I'm still for 'reproduce' because a bug can be (non-)reproducible but
>>not recreatable.
>>Any other opinions?
>Ok, "reproduce" is fine
>
>>>I'd say: "If you have any questions, discuss them...
>>That's even better :)
>Cool!:)
>
>>>All patches, such as tests and fixes, should be
>>Good! It's clearer.
>Fine!
>
>>OK. I'll prepare patch update then.
>Good luck! I'd be glad to review it, if you do not mind. :)
>
>Cheers,
>Sveta
>
>Thanks,
>Alexey.
>
>>
>>
>>Best regards,
>>Sveta
>>
>>-Original Message-
>>From: Ivanov, Alexey A [mailto:[EMAIL PROTECTED]
>>Sent: Thursday, November 09, 2006 1:33 PM
>>To: harmony-dev@incubator.apache.org
>>Subject: RE: [jira] Good issue resolution guideline (was:
>>[classlib]volunteer to supply patches for old JIRAs)
>>
>>>-Original Message-
>>>From: Konovalova, Svetlana [mailto:[EMAIL PROTECTED]
>>>Sent: Wednesday, November 08, 2006 7:01 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 just submitted a new JIRA
>>>[http://issues.apache.org/jira/browse/HARMONY-2110].
>>>I've added the necessary links from the website to the new page and
>>have
>>>tried to perfect it a little.
>>>It would be great, if you could find a chance to look through the
>>patch.
>>>Thanks in advance.
>>
>>Sveta,
>>
>>I've taken a look and added my comments to the JIRA itself.
>>
>>
>>Regards,
>>Alexey.
>>
>>>
>>>Best regards,
>>>Sveta
>>>
>>>-Original Message-
>>>From: Morozova, Nadezhda [mailto:[EMAIL PROTECTED]
>>>Sent: Wednesday, November 08, 2006 11:18 AM
>>>To: harmony-dev@incubator.apache.org
>>>Subject: RE: [jira] Good issue resolution guideline (was:
>>>[classlib]volunteer to supply patches for old JIRAs)
>>>
>>>Good! Go ahead. Do you need help? I can review the patch - just let
me
>>>know when you submit the JIRA.
>>>
>>>Thank you,
>>>Nadya Morozova
>>>
>>>-Original Message-
>>>From: Konovalova, Svetlana [mailto:[EMAIL PROTECTED]
>>>Sent: Wednesday, November 08, 2006 9:13 AM
>>>To: harmony-dev@incubator.apache.org
>>>Subject: RE: [jira] Good issue resolution guideline (was:
>>>[classlib]volunteer to supply patches for old JIRAs)
>>>
>>>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

RE: Re: [doc][drlvm] The document "Getting started with DRL" is outdated

[Morozova, Nadezhda]

Egor,
I generally like the idea of improving navigation over the site -
there's never too much of that. However, I am not sure whether we need
yet another separate page for introductory/guidance info. I hope the
starting page + the generic pages we have are mostly fine. However,
adding a link here and there to lead site visitors. 

Getting started could be a more specific project-oriented page. There,
you can tell people to go download, build the
code. After which, they can start using it just as any other
RI-compatible jdk. With the exceptions, see our
wiki pages.
To use the vm, readers might need to use the following options...
If they want to read more on our VM, they can visit the
component page. If no website page contains an answer -
they can read wiki faqa. 
.. or something like that :) 

Thank you, 
Nadya Morozova
 
-Original Message-
From: news [mailto:[EMAIL PROTECTED] On Behalf Of Egor Pasko
Sent: Thursday, November 09, 2006 5:33 PM
To: harmony-dev@incubator.apache.org
Subject: Re: [doc][drlvm] The document "Getting started with DRL" is
outdated

On the 0x21C day of Apache Harmony Pavel Ozhdikhin wrote:
> On 11/9/06, Morozova, Nadezhda <[EMAIL PROTECTED]> wrote:
> >
> > Egor,
> > +1 for
> > Just idea: "Getting Started" may contain a collection of links to
the
> > main website and other resources with short descriptions ("Site Map"
> > or something) so that people are comfortable floating around in the
web.
> 
> 
> 
> We already have one page having links to the resources about DRLVM:
> http://incubator.apache.org/harmony/subcomponents/drlvm/index.html
> Why do you think we need another one?

because it is only DRLVM.
I think of something like "site map", a collection of links. Short
descriptions to some basic ones.

> 
> +1 for
> > * preparing the "Commonly Used Options for DRLVM" (omitting the word
> > "supported" intentionally)
> > Question on this one: will the page contain vm-only options? What
about
> > JIT, GC, other? I'd have them all in one place, but we have separate
> > docs for EM/jit stuff. What do you say?
> 
> 
> I think we can describe basic options for every component there. Only
those
> that might be interesting for any user. The place for other options is
in
> the run-time help or Developer's Guide for a component.

I thought of "most commonly used" options. They can possibly be
grouped by components, but not necessary. I would group them by
use-cases. BTW, "any user" is not an obvious substance for me. 

So, the list is not obvious, we need to work it out.

I see it like HOWTOs. For example:
"-Xem:jet <- use only baseline JIT compiler"
"-Xem:opt <- use only optimising JIT compiler"
"-Xtrace:em <- print method compilation events"

The 'big' question is: "does 'any user' need to know about JITs
switching?". I say YES, it helps users to investigate problems, which
helps us, developers, to react on users' input faster.

Other options? I can enlist the set of most commonly used by me. If
many of us put their lists here, we can sum them up quickly and make
a good (really useful) list of popular options. How about that?

BTW, the list should not be too big. 25 options is a kind of limit

> Thanks,
> Pavel
> 
> Thank you,
> > Nadya Morozova
> >
> > -Original Message-
> > From: news [mailto:[EMAIL PROTECTED] On Behalf Of Egor Pasko
> > Sent: Thursday, November 09, 2006 5:51 AM
> > To: harmony-dev@incubator.apache.org
> > Subject: Re: [doc][drlvm] The document "Getting started with DRL" is
> > outdated
> >
> > On the 0x21B day of Apache Harmony Nadezhda Morozova wrote:
> > > All,
> > > I'd like to share everyone's grief at the sight of outdated
Getting
> > > Started document. However, I'd not hurry to eliminate the page as
> > such.
> > > We might reconsider some of its contents, change structure, and
update
> > > individual bits, but please think carefully before removing the
page.
> > >
> > > I think Getting Started (as the title shows) is aimed to help a
newbie
> > > work with our vm. I know that many primarily interested in other
> > things
> > > - conformance, architecture, internal specifics. However, we
should
> > also
> > > think how the vm is used. AFAIK, Getting started is now the *only*
doc
> > > that tries to show how to use our vm. You tell people how to
download
> > > and build, but almost nothing about how to run and configure (with
the
> > > exception of EM/JIT).
> > >
> > > My suggestion would be to think of what you want to tell people
about
> > > usage - with or without eclipse specifics. And store this info on
the
> > > page. I know it is hard - and I offer my help and support in this
> > > burdensome initiative. Any thoughts? i might be inobjective and
> > > emotional :)
> >
> > Nadya,
> >
> > I believe, almost everyone coming across Harmony knows how to use
> > J5SE. We are striving for this compatibility, and we are happy that
> > all DRLVM-specific pecularities are gone.
> >
> > So, I vote for:
> > * removing the "Getting Started" (also because of

Re: [drlvm] release vs. debug

[Gregory Shimansky]

Geir Magnusson Jr. wrote:



Alexei Zakharov wrote:

Hi DRLVM fans,

I encountered a rather strange problem while working on some class
library tests. At least two tests from the beans module hang (or
crash) while running on DRLVM debug builds but work fine on DRLVM
release builds. I thought that debug build is something about adding
debug symbols to VM binaries and this should not affect the
functionality. Can someone shed a light on this? 


I would think it's just an assertion firing...


Actually it is more than that. In debug mode TRACE statements are 
compiled and therefore produce executable code. There may also be some 
bugs in compiler generating code in different modes (although this 
usually happens for release).


I don't know why hanging happens, but the difference in generated code 
is actually quite big. Also assertions or any crashes go to 
exceptions/signal handlers which may happen to loop infinitely, there 
were bugs like this happening on the current version of sources, look at 
HARMONY-2018 and HADMONY-2006.



This is the first
question. The second question - what we should do with such tests. The
tests pass on the downloadable HDK and JRE snapshots as well as on
classlib + j9. What should be the commit criteria for DRLVM – i.e.
what is the *true* build? :) I think many people here currently use
snapshots to test their patches.


debug :)  don't sweep the problems under the rug...


+1

--
Gregory

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

[Gregory Shimansky]

Weldon Washburn wrote:
1558 pass the pre-commit "build test" on my windows laptop.  I have not 
done
a post-commit clean "svn checkout", build, build test.  Mostly because 
build
test makes my laptop unusable for over an hour.  It would be good if 
someone

can double verify the windows build is OK since 1558 commit was one hundred
twenty files.


Don't worry, you would've known if you broke win32 by now :)

I've verified the build on winxp laptop and 2003 server with HT. Tests 
seem to be working as before the patch. That is gc.LOS hanging on XP, 
some problems with threading described in HARMONY-2070 and 
java.lang.ThreadTest failing.


--
Gregory

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

[Ivan Volosyuk]

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

Ivan Volosyuk wrote:
> We will get rid of false sharing. That's true. But it still be quite
> expensive to write those '1' values, because of ping-ponging of the
> cache line between processors. I see only one solution to this: use
> separate mark bits in vtable per GC thread which should reside in
> different cache lines and different from that word containing gcmap
> pointer.

The only thing that a GC thread does is write "1" in this slot; it never
writes "0".  So, it is not very important in what order (or even "when")
this word is finally commited to main memory.  As long as there is some
barrier before the "end of epoch collection" insuring that all
processors cache write buffers are commited to memory before tracing
vtables (or gc maps).

You don't need memory coherency on write-without-read. :-)


I don't speak about memory coherency, I speak about bus load with
useless memory traffic between processors and poor CPU cache usage.

--
Ivan
Intel Enterprise Solutions Software Division

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

[Salikh Zakirov]

Etienne Gagnon wrote:
> Salikh Zakirov wrote:
>>   7) let the GC finish collection and reclaim unreachable objects -- this 
>> reclaims java objects
> 
> Just a bit of a warning...  This should be integrated within the
> weak/soft/phantom + finalization framework.  We definitely don't want
> the native resources of a class loader to be freed and later have
> finalization revive the class loader...  :-)

Agreed. "Revival" of classloaders should be done after "revival"
of objects in finalization queue.

I think this scheme can be implemented by introducing one additional GC->VM 
callback (vm_trace_complete),
which would be called right after GC completed the trace. The call sequence 
will be as follows:

   GCVM
|---> vm_enumerate_root_set()
| gc_add_root_set_entry()<---|
| gc_add_root_set_entry()<---|
| gc_add_root_set_entry()<---|
|<- - - - - - - - - - -return from vm_enumerate_root_set()
||
   [trace heap]  |
||
|---> vm_trace_complete()
| gc_add_root_set_entry()<---|
| gc_add_root_set_entry()<---|
|< - - - - - - - - - - - return from vm_trace_complete()-|
||
   [trace heap from new roots,   |
 if there are any]   |
|---> vm_trace_complete()
|< - - - - - - - - - - - return from vm_trace_complete()-|
|
   [no retrace, as no new roots were received]
|
   [reclaim space]
|

Additionally, even finalization itself can be moved out of GC responsibility,
using this interface and one additional function to query if the object
was already reached or not.

> [Luckily, nothing special needs to be done for JNI code;
> CallStaticMethod does require a native reference to a class
> object.  Yay! ]

Unluckily, something needs to be done for JVMTI. It has a function 
IterateOverHeap
which is supposed to iterate over both reachable and unreachable objects by 
scanning
heap linearly.

Thus, if the respective capability (can_tag_objects) has been requested on the 
VM startup,
the GC must run in a special mode and zero out all unreachable objects, because 
the unreachable
object may loose its descriptor (VTable) at any time, and GC will not be able 
even to know its size.

This will prevent some optimizations, like not reclaiming short free areas in 
unmovable space,
and require some special attention from the GC developers. OTOH, gc_cc already 
has a special mode
(-Dgc.heap_iteration=1) to support iteration even before class unloading is 
implemented.

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

[Salikh Zakirov]

Etienne Gagnon wrote:
> Ivan Volosyuk wrote:
>> We will get rid of false sharing. That's true. But it still be quite
>> expensive to write those '1' values, because of ping-ponging of the
>> cache line between processors. I see only one solution to this: use
>> separate mark bits in vtable per GC thread which should reside in
>> different cache lines and different from that word containing gcmap
>> pointer.
> 
> The only thing that a GC thread does is write "1" in this slot; it never
> writes "0".  So, it is not very important in what order (or even "when")
> this word is finally commited to main memory.  As long as there is some
> barrier before the "end of epoch collection" insuring that all
> processors cache write buffers are commited to memory before tracing
> vtables (or gc maps).

The "false sharing" problem occurs whenever one processor writes into
the cache line other processors read from, because it invalidates loaded
copies and makes other processors read it again from main memory.
It doesn't matter if they write 1 or 0

In our case, both gcmap pointer and gcmap itself are likely to be read
by multiple processors, so writing to a location nearby may lead
to false sharing.

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

[Etienne Gagnon]

Ivan Volosyuk wrote:
> We will get rid of false sharing. That's true. But it still be quite
> expensive to write those '1' values, because of ping-ponging of the
> cache line between processors. I see only one solution to this: use
> separate mark bits in vtable per GC thread which should reside in
> different cache lines and different from that word containing gcmap
> pointer.

Thinking about it...  Doesn't the "object vtable" suffer from the same
problem, anyway?  It's probably worse, as it will be quite unfeasible to
try to locate them in the "right" cache lines!  Yep, another point
against object-vtables...

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] Class unloading support - tested one approach

[Etienne Gagnon]

Salikh Zakirov wrote:
>   7) let the GC finish collection and reclaim unreachable objects -- this 
> reclaims java objects

Just a bit of a warning...  This should be integrated within the
weak/soft/phantom + finalization framework.  We definitely don't want
the native resources of a class loader to be freed and later have
finalization revive the class loader...  :-)

[Luckily, nothing special needs to be done for JNI code;
CallStaticMethod does require a native reference to a class
object.  Yay! ]

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] Class unloading support - tested one approach

[Salikh Zakirov]

Etienne Gagnon wrote:
>>   3) trace the heap 
>>   4) scan vtable marks and "revive" marked class unloaders, by adding the 
>> strong root
>>  from the previously collected "unload list". Remove the revived 
>> classloaders from unload list.
>>   5) repeat steps (3) and (4) until there is no classloaders to revive
> 
> As long as it is understood that the repeated (3) is not a full trace.
> It's only a trace starting from the revived roots.  [This is important
> in evaluating the total work done].

Exactly. 

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

[Etienne Gagnon]

Ivan Volosyuk wrote:
> We will get rid of false sharing. That's true. But it still be quite
> expensive to write those '1' values, because of ping-ponging of the
> cache line between processors. I see only one solution to this: use
> separate mark bits in vtable per GC thread which should reside in
> different cache lines and different from that word containing gcmap
> pointer.

The only thing that a GC thread does is write "1" in this slot; it never
writes "0".  So, it is not very important in what order (or even "when")
this word is finally commited to main memory.  As long as there is some
barrier before the "end of epoch collection" insuring that all
processors cache write buffers are commited to memory before tracing
vtables (or gc maps).

You don't need memory coherency on write-without-read. :-)

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: svn commit: r472149 - /incubator/harmony/enhanced/classlib/trunk/modules/beans/src/test/java/org/apache/harmony/beans/tests/java/beans/PersistenceDelegateTest.java

[Alexei Zakharov]

I've reverted my changes and put the whole test back to the exclude list.

Thanks,

2006/11/8, Tim Ellison <[EMAIL PROTECTED]>:

Stepan Mishura wrote:
> 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, I had also intended to point out this commit.  I agree
that it is masking a problem elsewhere which should be fixed, and I'd
also point out that commenting out test code is not the preferred way to
exclude a test since it will be very difficult to find the excluded test
and include it again.  We have been using the build scripts to exclude
test classes.

Regards,
Tim




--
Alexei Zakharov,
Intel Enterprise Solutions Software Division

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

[Ivan Volosyuk]

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

Salikh Zakirov wrote:
> Technically, it should not be too difficult to add an additional field to the 
VTable
> structure, and require GC to write 1 there during object scanning.
> However, if the VTable mark is located in the same cache line as gcmap,
> it may severely hit parallel GC performance on a multiprocessor due to false 
sharing,
> as writing VTable mark will invalidate the gcmap pointers loaded to caches of 
other
> processors.
>
>objectVTable   gcmap
>  +++---++--+
>  | VT ptr |--->| gcmap ptr |--->| offset of ref #1 |
>  |  ...   ||...|| offset of ref #2 |
>  +++---+|   ...|
> |0 |
> +--+

If you go that far for every scanned object (!), then you could simply
place the class unloading bit in the gc map, at index -1) to minimize
disruption of current code...

   objectVTable   gcmap
+--+
 +++---+| cl.un. mark bit  |
 | VT ptr |--->| gcmap ptr |--->| offset of ref #1 |
 |  ...   ||...|| offset of ref #2 |
 +++---+|   ...|
|0 |
+--+

This gets rid of the cache line hazard...


We will get rid of false sharing. That's true. But it still be quite
expensive to write those '1' values, because of ping-ponging of the
cache line between processors. I see only one solution to this: use
separate mark bits in vtable per GC thread which should reside in
different cache lines and different from that word containing gcmap
pointer.

--
Ivan
Intel Enterprise Solutions Software Division

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

[Etienne Gagnon]

Salikh Zakirov wrote:
> Ah, I think I got it.

Yep.

>   3) trace the heap 
>   4) scan vtable marks and "revive" marked class unloaders, by adding the 
> strong root
>  from the previously collected "unload list". Remove the revived 
> classloaders from unload list.
>   5) repeat steps (3) and (4) until there is no classloaders to revive

As long as it is understood that the repeated (3) is not a full trace.
It's only a trace starting from the revived roots.  [This is important
in evaluating the total work done].

> The voting definitely was premature, as it turns out that even the design 
> under discussion
> can be elaborated to multiple substantially different designs.

Yes, you're right.

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] Class unloading support - tested one approach

[Salikh Zakirov]

Etienne Gagnon wrote:

> "Revival" is only needed if you use the finalization-like approach.  If
> you only do class-unloading GC when the nursery is empty, then no
> revival is needed.  

Ah, I think I got it.

You mean running a minor collection, and then "class unloading" full heap 
collection
sequentially, without any mutator work in between?
Then, the correctness is observed easily:

  1) all mature objects has their vtable marks set to 1
  2) after minor collection, the nursery is empty
  => all live objects already have vtable marks == 1
  
  Thus, if we find a classloader with vtable marks == 0, then it has no object 
instances,
  and its reachability is defined solely by reachability of 
java.lang.ClassLoader instance
  and existence of the method frames, which can be checked, respectively, by
  enumerating class loader roots as weak roots, and scanning stacks.

  Note, that the class loader, which became eligible for unloading during epoch 
N,
  will not be unloaded until the end of the epoch N+1.

However, in the case of non-generational collector, the "minor collection 
followed
by unloading collection" becomes effectively two successive garbage collections.

On the other side, "finalization-like" design goes as follows:

  1) clean vtable marks before "class unloading" collection
  2) enumerate classloader roots as weak and collect array of user classloader 
pointers for later use
 -- let's call it "unload list"
  3) trace the heap 
  4) scan vtable marks and "revive" marked class unloaders, by adding the 
strong root
 from the previously collected "unload list". Remove the revived 
classloaders from unload list.
  5) repeat steps (3) and (4) until there is no classloaders to revive
  6) unload the classloaders, pointed by the "unload list" -- this reclaims 
native resources
  7) let the GC finish collection and reclaim unreachable objects -- this 
reclaims java objects

This design unloads classloaders at the end of the very same epoch when they 
became unloadable.

The voting definitely was premature, as it turns out that even the design under 
discussion
can be elaborated to multiple substantially different designs.

Re: FW: [build] Building on Eclipse - FYI

[Egor Pasko]

On the 0x21C day of Apache Harmony Geir Magnusson, Jr. wrote:
> Egor Pasko wrote:
> > On the 0x21C day of Apache Harmony Geir Magnusson, Jr. wrote:
> >> Egor Pasko wrote:
> >>> On the 0x21C day of Apache Harmony Geir Magnusson, Jr. wrote:
>  Egor Pasko wrote:
> > On the 0x21C day of Apache Harmony Sian January wrote:
> >> Hello again,
> >>
> >> I have had a closer look at the  "Developing Apache Harmony 
> >> Class-library
> >> Code with Eclipse" page, and I have noticed that the "Configuring 
> >> Eclipse"
> >> and "Develop and Test Code" sections are quite class-library specific.
> >> Would it be better to leave those sections as they are and add a 
> >> "Developing
> >> DRLVM with Eclipse" section on the same page?
> > To the moment I am not aware of anybody who would use Eclipse for
> > DRLVM development. So, it's too early to add a page like this.
>  This will ensure that no one does then - if it's simple to add, lets
>  add it...
> >>> Does it help anybody? I see no point in doing redundant work even if
> >>> it is small.
> >> Why is it redundant?
> > Nobody uses, nobody reads -> redundant. Am I missing something? :)
> 
> if we don't have it, of course nobody uses or reads it...

OK. Let me put it the other way. If someone has something valuable,
not obvious to write about DRLVM+Eclipse, I am for it. If the page is
going to be just a long-living stub, I am not happy.

-- 
Egor Pasko

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

[Etienne Gagnon]

Etienne Gagnon wrote:
> Salikh Zakirov wrote:
> 
>>I have another concern though: 
>>just before starting "final unloading" collection, we scan vtable marks and 
>>identify
>>the candidates for unloading. During the "final unloading" collection, the
>>candidate classloader roots are reported as week. At the end of the trace,
>>we need to rescan vtable marks and "revive" the classloader which were found
>>in possession of live objects. This techniques is exactly the same as the one
>>used for object finalization. 
>>
>>However, in contrast with finalization, we will need to repeat reviving
>>classloaders which have non-0 vtable marks until the process converges, and no
>>new classloaders are revived. (* in finalization, both dead and live objects 
>>in finalization
>>queue are revived, and thus the revival converges in just 1 step *).

In case you chose the finalization-like + revival way, then I don't see
any significant performance hit of multiple-step convergence!  For one
thing, you'll probably agree with me that it is quite unlikely to take
more than 1 step to converge in most cases, and the additional work in
the other cases is still quite insignificant relative to the remaining
collection work!

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: [Fwd: Re: Interesting discoveries playing around with japitools]

[David Gilbert]

Stuart Ballard wrote:

Geir Magnusson Jr. wrote:

David Gilbert wrote:
> A boon?  Not at all, Classpath will be (mostly) redundant and will 
fade

> away, replaced by Sun's runtime.

I'm not so convinced of that.  GNU Classpath is under GPL + Exception,
so arguably it's not viral to things that link with it.


I think it's highly unlikely Sun will release their VM without terms
that enable proprietary code to be built on top of it. That'd be
particularly counterproductive of them.

My speculation would be that they'll release it under two licenses,
one similar to the terms they have now, and the GPL as the other. Code
released under those terms is clearly not viral.


Also, I think the copyright assignment requirement will be a big deal.


If OpenOffice is anything to go by, Sun will require a copyright
assignment to them; Classpath requires a copyright assignment to the
FSF. Yes, that's a little bit different because a lot of developers
will trust the FSF a lot more than they do Sun...

I actually think it'd be really smart of Sun to not require a
copyright assignment at all, but rather require contributing
developers to license their code under *both* sets of terms just as
Sun itself does. That would allow Sun to continue to use the dual
licensing scheme without the stigma of the copyright assignment
requirement. And it's very similar (in spirit, if not in details) to
the model that Mozilla has used for years - originally to allow
Netscape to make proprietary releases based on the contributed code.

As far as the suggestion elsewhere in the thread (that I lost, digest
mode subscription is painful ;) ) that the GNU people would feel it
necessary to fork Sun's Java entirely to maintain their sense of
freedom, I don't think this is so. The FSF have fairly strong
philosophical disagreements with Linus but have never forked the
kernel. They have philosophical disagreements with the ASF sometimes
but there isn't a GNU fork of the Apache webserver. I think a GPL'd
Java would be considered acceptable - because the license allows the
*option* of a fork if Sun proves to be a sufficiently poor steward.
But I've never heard of a project being "preemptively" forked on the
offchance the maintainer will make unacceptable decisions in the
future. At least I've never heard of such a fork having even the
slightest success.

A lot depends, of course, on how Sun actually engages the community -
I'd say that's even more important than the license, as long as the
license isn't *completely* un-work-withable.


Understood.  For me, an additional requirement is an open and level
community, where all participants are working together under exactly the
same terms. (Which is where GNU Classpath will be different than what I
understand the Sun model will be)


I don't consider it a foregone conclusion either way as to whether
Classpath will or won't continue with any enthusiasm if Sun's
implementation is released under an acceptable license and with an
acceptable process for getting contributions back in. There's a lot of
momentum behind Classpath right now but it might be hard to justify
all the effort to get from (essentially) complete 1.4 and parts of
1.5, to parity with Sun's 6.

Either way we live in interesting times :) And either way Sun's
release under *any* open source license is a very good thing.

Stuart.


+ 1 to all that Stuart just said.

Regards,

Dave Gilbert

Re: [drlvm] release vs. debug

[Egor Pasko]

On the 0x21C day of Apache Harmony Alexei A. Fedotov wrote:
> >> debug :)  don't sweep the problems under the rug...
> +1 
> A special +1 for Jitrino.OPT dll

+1 from me, of course

> 
> >-Original Message-
> >From: Alexei Zakharov [mailto:[EMAIL PROTECTED]
> >Sent: Thursday, November 09, 2006 7:17 PM
> >To: harmony-dev@incubator.apache.org; [EMAIL PROTECTED]
> >Subject: Re: [drlvm] release vs. debug
> >
> >> I would think it's just an assertion firing...
> >
> >Yes, but why it hangs?
> >
> >2006/11/9, Geir Magnusson Jr. <[EMAIL PROTECTED]>:
> >>
> >>
> >> Alexei Zakharov wrote:
> >> > Hi DRLVM fans,
> >> >
> >> > I encountered a rather strange problem while working on some class
> >> > library tests. At least two tests from the beans module hang (or
> >> > crash) while running on DRLVM debug builds but work fine on DRLVM
> >> > release builds. I thought that debug build is something about
> adding
> >> > debug symbols to VM binaries and this should not affect the
> >> > functionality. Can someone shed a light on this?
> >>
> >> I would think it's just an assertion firing...
> >>
> >> > This is the first
> >> > question. The second question - what we should do with such tests.
> The
> >> > tests pass on the downloadable HDK and JRE snapshots as well as on
> >> > classlib + j9. What should be the commit criteria for DRLVM - i.e.
> >> > what is the *true* build? :) I think many people here currently use
> >> > snapshots to test their patches.
> >>
> >> debug :)  don't sweep the problems under the rug...
> >
> >--
> >Alexei Zakharov,
> >Intel Enterprise Solutions Software Division
> 

-- 
Egor Pasko

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

[Etienne Gagnon]

Salikh Zakirov wrote:
> I have another concern though: 
> just before starting "final unloading" collection, we scan vtable marks and 
> identify
> the candidates for unloading. During the "final unloading" collection, the
> candidate classloader roots are reported as week. At the end of the trace,
> we need to rescan vtable marks and "revive" the classloader which were found
> in possession of live objects. This techniques is exactly the same as the one
> used for object finalization. 
> 
> However, in contrast with finalization, we will need to repeat reviving
> classloaders which have non-0 vtable marks until the process converges, and no
> new classloaders are revived. (* in finalization, both dead and live objects 
> in finalization
> queue are revived, and thus the revival converges in just 1 step *).

"Revival" is only needed if you use the finalization-like approach.  If
you only do class-unloading GC when the nursery is empty, then no
revival is needed.  In this case, after GC you only need to revert weak
references to hard ones.  Nulled weak references relate to dead class
loaders for which you can definitely free the native resources.

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: [Fwd: Re: Interesting discoveries playing around with japitools]

[Stuart Ballard]

Geir Magnusson Jr. wrote:

David Gilbert wrote:
> A boon?  Not at all, Classpath will be (mostly) redundant and will fade
> away, replaced by Sun's runtime.

I'm not so convinced of that.  GNU Classpath is under GPL + Exception,
so arguably it's not viral to things that link with it.


I think it's highly unlikely Sun will release their VM without terms
that enable proprietary code to be built on top of it. That'd be
particularly counterproductive of them.

My speculation would be that they'll release it under two licenses,
one similar to the terms they have now, and the GPL as the other. Code
released under those terms is clearly not viral.


Also, I think the copyright assignment requirement will be a big deal.


If OpenOffice is anything to go by, Sun will require a copyright
assignment to them; Classpath requires a copyright assignment to the
FSF. Yes, that's a little bit different because a lot of developers
will trust the FSF a lot more than they do Sun...

I actually think it'd be really smart of Sun to not require a
copyright assignment at all, but rather require contributing
developers to license their code under *both* sets of terms just as
Sun itself does. That would allow Sun to continue to use the dual
licensing scheme without the stigma of the copyright assignment
requirement. And it's very similar (in spirit, if not in details) to
the model that Mozilla has used for years - originally to allow
Netscape to make proprietary releases based on the contributed code.

As far as the suggestion elsewhere in the thread (that I lost, digest
mode subscription is painful ;) ) that the GNU people would feel it
necessary to fork Sun's Java entirely to maintain their sense of
freedom, I don't think this is so. The FSF have fairly strong
philosophical disagreements with Linus but have never forked the
kernel. They have philosophical disagreements with the ASF sometimes
but there isn't a GNU fork of the Apache webserver. I think a GPL'd
Java would be considered acceptable - because the license allows the
*option* of a fork if Sun proves to be a sufficiently poor steward.
But I've never heard of a project being "preemptively" forked on the
offchance the maintainer will make unacceptable decisions in the
future. At least I've never heard of such a fork having even the
slightest success.

A lot depends, of course, on how Sun actually engages the community -
I'd say that's even more important than the license, as long as the
license isn't *completely* un-work-withable.


Understood.  For me, an additional requirement is an open and level
community, where all participants are working together under exactly the
same terms. (Which is where GNU Classpath will be different than what I
understand the Sun model will be)


I don't consider it a foregone conclusion either way as to whether
Classpath will or won't continue with any enthusiasm if Sun's
implementation is released under an acceptable license and with an
acceptable process for getting contributions back in. There's a lot of
momentum behind Classpath right now but it might be hard to justify
all the effort to get from (essentially) complete 1.4 and parts of
1.5, to parity with Sun's 6.

Either way we live in interesting times :) And either way Sun's
release under *any* open source license is a very good thing.

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

RE: [drlvm] release vs. debug

[Fedotov, Alexei A]

>> debug :)  don't sweep the problems under the rug...
+1 
A special +1 for Jitrino.OPT dll


>-Original Message-
>From: Alexei Zakharov [mailto:[EMAIL PROTECTED]
>Sent: Thursday, November 09, 2006 7:17 PM
>To: harmony-dev@incubator.apache.org; [EMAIL PROTECTED]
>Subject: Re: [drlvm] release vs. debug
>
>> I would think it's just an assertion firing...
>
>Yes, but why it hangs?
>
>2006/11/9, Geir Magnusson Jr. <[EMAIL PROTECTED]>:
>>
>>
>> Alexei Zakharov wrote:
>> > Hi DRLVM fans,
>> >
>> > I encountered a rather strange problem while working on some class
>> > library tests. At least two tests from the beans module hang (or
>> > crash) while running on DRLVM debug builds but work fine on DRLVM
>> > release builds. I thought that debug build is something about
adding
>> > debug symbols to VM binaries and this should not affect the
>> > functionality. Can someone shed a light on this?
>>
>> I would think it's just an assertion firing...
>>
>> > This is the first
>> > question. The second question - what we should do with such tests.
The
>> > tests pass on the downloadable HDK and JRE snapshots as well as on
>> > classlib + j9. What should be the commit criteria for DRLVM - i.e.
>> > what is the *true* build? :) I think many people here currently use
>> > snapshots to test their patches.
>>
>> debug :)  don't sweep the problems under the rug...
>
>--
>Alexei Zakharov,
>Intel Enterprise Solutions Software Division

Re: [drlvm] release vs. debug

[Alexei Zakharov]

I would think it's just an assertion firing...


Yes, but why it hangs?

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



Alexei Zakharov wrote:
> Hi DRLVM fans,
>
> I encountered a rather strange problem while working on some class
> library tests. At least two tests from the beans module hang (or
> crash) while running on DRLVM debug builds but work fine on DRLVM
> release builds. I thought that debug build is something about adding
> debug symbols to VM binaries and this should not affect the
> functionality. Can someone shed a light on this?

I would think it's just an assertion firing...

> This is the first
> question. The second question - what we should do with such tests. The
> tests pass on the downloadable HDK and JRE snapshots as well as on
> classlib + j9. What should be the commit criteria for DRLVM – i.e.
> what is the *true* build? :) I think many people here currently use
> snapshots to test their patches.

debug :)  don't sweep the problems under the rug...


--
Alexei Zakharov,
Intel Enterprise Solutions Software Division

Re: [classlib][sound] Volunteer to implement missing & bad APIs in javax.sound.sampled

[Paulex Yang]

Boris Kuznetsov wrote:

ok, let's figure out how many things left.


AudioSystem class and some "not yet implemented" methods like this:
   public final String toString() {
   throw new Error("not yet implemented");
   }
As someone discussing on the other thread about JAPI, how about use 
"NotImplementedException" instead of Error with "not yet implemented" 
messages? so that JAPI can identify them and can create reports more 
precisely.


--
Paulex Yang
China Software Development Lab
IBM

Re: [drlvm] release vs. debug

[Geir Magnusson Jr.]

Alexei Zakharov wrote:

Hi DRLVM fans,

I encountered a rather strange problem while working on some class
library tests. At least two tests from the beans module hang (or
crash) while running on DRLVM debug builds but work fine on DRLVM
release builds. I thought that debug build is something about adding
debug symbols to VM binaries and this should not affect the
functionality. Can someone shed a light on this? 


I would think it's just an assertion firing...


This is the first
question. The second question - what we should do with such tests. The
tests pass on the downloadable HDK and JRE snapshots as well as on
classlib + j9. What should be the commit criteria for DRLVM – i.e.
what is the *true* build? :) I think many people here currently use
snapshots to test their patches.


debug :)  don't sweep the problems under the rug...

geir



Thanks,

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

[Weldon Washburn]

1558 pass the pre-commit "build test" on my windows laptop.  I have not done
a post-commit clean "svn checkout", build, build test.  Mostly because build
test makes my laptop unusable for over an hour.  It would be good if someone
can double verify the windows build is OK since 1558 commit was one hundred
twenty files.



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


Great. Thanks Weldon. Does this mean that it is to be verified on Windows?

On 11/8/06, Weldon Washburn <[EMAIL PROTECTED]> wrote:
>
> 1558 has been committed.  It took two commits since I forgot to "svn
add"
> 4
> files.  All in all, one hundred and twenty one files were committed.
>
> Following the commit(s), I did an "rm -rf trunk", svn update, build.sh,
"
> build.sh test" on my linux box.  Everything seems to work OK.
>
>
>
>
> On 11/8/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
> >
> > so, how did it go?
> >
> > Weldon Washburn wrote:
> > > 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
>
>





--
Weldon Washburn
Intel Enterprise Solutions Software Division

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

[Robin Garner]

Etienne Gagnon wrote:

OK.  My latest proposal (a few messages ago) was assuming that the
nursery was empty when the "end of epoch collection" is launched.

If it is not, you can do 2 things:

a) do a minor collection to empty it, or

b) i  - use a finalization-like list of references to class loader
objects
   ii - launch gc, which might mark a previously unmarked vtable
   iii- do a finalization-like rescuing for resuscitated class loaders

"b)" should really have a minimal performance impact.  As for its
"apparent complexity", I would say that this is a non-issue; similar
code must already exist in drlvm for implementing finalization.


Just for clarification: "b)" implies a combined "nursery + mature space"
collection.

Actually, for the mature space part, you could get away with a smaller
collection if you premature all class loaders and classes to a specific
mature space area; the you only need to collect that space (in addition
to the nursery).

Etienne



This sounds rather 'stop the world' - while the barrier is more 
complicated I think it scales to concurrent collectors.


Also, don't forget an instance of a class in the nursery can pass a 
reference to its classloader to a mature-space object under suitably 
bizarre circumstances.  I guess you could have a write barrier on the 
class metadata space ...


... an XOR barrier could actually be an interesting solution ... but I'm 
sure it won't be necessary.


--
Robin Garner
Dept. of Computer Science
Australian National University
http://cs.anu.edu.au/people/Robin.Garner/

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

[Salikh Zakirov]

>> Etienne Gagnon wrote:
>> > My proposal already argued that vtable bit/byte/word marking is
>> > unnecessary for "nursery allocations".  You only need to mark the
>> vtable
>> > of objects that survive collection and pretenured objects.

Alexey Varlamov wrote:
> I may have missed it, but I only recall you argued that we just need
> to collect mature space for the *final unloading* as CL and classes
> are unlikely to die young, which I agree. But chances that a live
> object of a candidate class appeared in the nursery are higher.
> Otherwise I just do not grok how this algorithm can be proven for
> correctness.

Alexey, 

it looks like what you are thinking about is *concurrent* collector,
and concurrent garbage collections brings substantial complexity
even without class unloading.

However, the design we were discussing was for *stop-the-world* garbage
collectors, because this is the only thing currently supported by DRLVM,
and all existing GCs are stop-the-world.

So, the correctness of unloading algorithm can easily be proved if we consider
that the "final unloading" collection is a full heap collection,
i.e. both nursery and mature space is collected.

I have another concern though: 
just before starting "final unloading" collection, we scan vtable marks and 
identify
the candidates for unloading. During the "final unloading" collection, the
candidate classloader roots are reported as week. At the end of the trace,
we need to rescan vtable marks and "revive" the classloader which were found
in possession of live objects. This techniques is exactly the same as the one
used for object finalization. 

However, in contrast with finalization, we will need to repeat reviving
classloaders which have non-0 vtable marks until the process converges, and no
new classloaders are revived. (* in finalization, both dead and live objects in 
finalization
queue are revived, and thus the revival converges in just 1 step *).

[drlvm] release vs. debug

[Alexei Zakharov]

Hi DRLVM fans,

I encountered a rather strange problem while working on some class
library tests. At least two tests from the beans module hang (or
crash) while running on DRLVM debug builds but work fine on DRLVM
release builds. I thought that debug build is something about adding
debug symbols to VM binaries and this should not affect the
functionality. Can someone shed a light on this? This is the first
question. The second question - what we should do with such tests. The
tests pass on the downloadable HDK and JRE snapshots as well as on
classlib + j9. What should be the commit criteria for DRLVM – i.e.
what is the *true* build? :) I think many people here currently use
snapshots to test their patches.

Thanks,
--
Alexei Zakharov,
Intel Enterprise Solutions Software Division

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

[Etienne Gagnon]

> OK.  My latest proposal (a few messages ago) was assuming that the
> nursery was empty when the "end of epoch collection" is launched.
> 
> If it is not, you can do 2 things:
> 
> a) do a minor collection to empty it, or
> 
> b) i  - use a finalization-like list of references to class loader
> objects
>ii - launch gc, which might mark a previously unmarked vtable
>iii- do a finalization-like rescuing for resuscitated class loaders
> 
> "b)" should really have a minimal performance impact.  As for its
> "apparent complexity", I would say that this is a non-issue; similar
> code must already exist in drlvm for implementing finalization.

Just for clarification: "b)" implies a combined "nursery + mature space"
collection.

Actually, for the mature space part, you could get away with a smaller
collection if you premature all class loaders and classes to a specific
mature space area; the you only need to collect that space (in addition
to the nursery).

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] General stability

[Geir Magnusson Jr.]

Egor Pasko wrote:

On the 0x21C day of Apache Harmony Mikhail Loenko wrote:

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



I do think of us having a 'zero regression' policy except in cases where
we make the explicit decision to break.  (like we did with TM, for example)

+1 for 'zero regression' unless explicitely agreed


I am +1 for "'zero regression' unless explicitely agreed" at least for
(c/jit-)unit, kernel, classlib tests. Do you think of including
Eclipse UT, DaCapo, etc. to the 'zero regression' set? 


That would probably be good, I am afraid of too heavy checks for each
small patch. 


This wouldn't be done by each committer - it's too heavy.  We'd have CI 
running continuously to tell us when we broke something.  Our 
committment would be to fix things that CI found immediately...


geir




Thanks,
Mikhail




I hesitate to say that again, but we also need to decide about VM we
will use for that release. I like the following mission: "Class library
and DRLVM pass TCK on Ubuntu 6". I'm open for any other mission which is
challenging, understandable and short enough.

Well, we'll need Windows XP and RHEL as well.



Writing down this mission certainly shouldn't inhibit individuals from
achieving other goals at Harmony. But it would help the rest of
community to concentrate on the common task.

1.
http://wiki.apache.org/harmony/Platforms_to_Run_Harmony_Development_Kit_
on

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


-Original Message-
From: Alexey Petrenko [mailto:[EMAIL PROTECTED]
Sent: Wednesday, November 08, 2006 10:36 AM
To: harmony-dev@incubator.apache.org
Subject: Re: [DRLVM] General stability

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: FW: [build] Building on Eclipse - FYI

[Geir Magnusson Jr.]

Egor Pasko wrote:

On the 0x21C day of Apache Harmony Geir Magnusson, Jr. wrote:

Egor Pasko wrote:

On the 0x21C day of Apache Harmony Geir Magnusson, Jr. wrote:

Egor Pasko wrote:

On the 0x21C day of Apache Harmony Sian January wrote:

Hello again,

I have had a closer look at the  "Developing Apache Harmony Class-library
Code with Eclipse" page, and I have noticed that the "Configuring Eclipse"
and "Develop and Test Code" sections are quite class-library specific.
Would it be better to leave those sections as they are and add a "Developing
DRLVM with Eclipse" section on the same page?

To the moment I am not aware of anybody who would use Eclipse for
DRLVM development. So, it's too early to add a page like this.

This will ensure that no one does then - if it's simple to add, lets
add it...

Does it help anybody? I see no point in doing redundant work even if
it is small.

Why is it redundant?


Nobody uses, nobody reads -> redundant. Am I missing something? :)


if we don't have it, of course nobody uses or reads it...






Who would give Eclipse a try just to write a redundant doc? I wrote a
GDB howto because I use it and have some helpful things to say. I
would have been glad to know if someone has similar experience with
Eclipse+DRLVM.


geir


Thanks,

Sian



On 07/11/06, Konovalova, Svetlana <[EMAIL PROTECTED]> wrote:

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 

Re: [drlvm][classlib] DaCapo benchmark regressions

[Robin Garner]

Alexey Varlamov wrote:

Robin,

1) it must be debug build of drlvm;
2) syntax is -Xstats:[1|2|3] , the number denotes detalization level.

Actually this options gives various *statistics* for run, rather than
performance data or profile. E.g. number of particular byte ops
performed, exceptions thrown/caugth, most frequently allocated
classes, usage of internal memory pools, etc.

I'm not sure this is what you requested - do you need to tune the VM
for best performance or collect additional info during run or smth
else?


Actually I'm just interested in wall clock time for the purpose of 
direct performance comparisons, but I always have a use for performance 
statistics from JVMs.  Some of the numbers you list are tricky to get 
from my measurement infrastructure :)


thanks!



2006/11/9, Robin Garner <[EMAIL PROTECTED]>:

Hmmm ...

$ $DRLVM_HOME/jre/bin/java -Xbootclasspath/p:antlr.jar -XcleanupOnExit
-Xstats -jar $HOME/dacapo-2006-10.jar antlr
Unknown option -Xstats
Use java -help to get help on command line options

$ $DRLVM_HOME/jre/bin/java -version
Apache Harmony Launcher : (c) Copyright 1991, 2006 The Apache Software
Foundation or its licensors, as applicable.
java version "1.5.0"
pre-alpha : not complete or compatible
svn = r472802, (Nov  9 2006), Linux/ia32/gcc 4.0.3, release build
http://incubator.apache.org/harmony

Anything else I need to add ? :-)

Evgueni Brevnov wrote:
> Unfortunately, YES. It's a known problem. You need to specify
> -XcleanupOnExit as well :-) I'm working in it currently will
> provide a fix soon...
>
> Thanks
> Evgueni
>
> On 11/9/06, Robin Garner <[EMAIL PROTECTED]> wrote:
>> Evgueni Brevnov wrote:
>> > On 11/9/06, Alexey Petrenko <[EMAIL PROTECTED]> wrote:
>> >> The logs for some benchmarks does not have error messages.
>> >> Is this possible to fix?
>> >>
>> >> SY, Alexey
>> >>
>> >> 2006/11/9, Robin Garner <[EMAIL PROTECTED]>:
>> >> > I've just finished adding drlvm to the nightly DaCapo benchmark
>> >> > regression tests.  The results are available here:
>> >> >
>> >> > http://cs/people/Robin.Garner/dacapo/regression/
>> >> >
>> >> > JikesRVM and DRLVM/Harmony classlib are built from svn checkouts
>> taken
>> >> > when the nightly run kicks off (00:35 Australian Eastern time).
>> >> >
>> >> > I'm currently working on adding performance stats for DRLVM and
>> >> > JikesRVM, so some suggestions about the best command line
>> parameters to
>> >> > use would be appreciated.
>> >
>> > DRLVM accepts -Xstats parameter for that purpose.
>>
>> -Xstats doesn't work for me - is there something I need to do
>> specifically to make it work ?
>>
>> > Thanks
>> >
>> >> >
>> >> > cheers
>> >> >
>> >> > --
>> >> > Robin Garner
>> >> > Dept. of Computer Science
>> >> > Australian National University
>> >> >
>> >>
>>
>>
>> --
>> Robin Garner
>> Dept. of Computer Science
>> Australian National University
>>


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




--
Robin Garner
Dept. of Computer Science
Australian National University
http://cs.anu.edu.au/people/Robin.Garner/

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

[Etienne Gagnon]

Alexey Varlamov wrote:
>> > My proposal already argued that vtable bit/byte/word marking is
>> > unnecessary for "nursery allocations".  You only need to mark the
>> vtable
>> > of objects that survive collection and pretenured objects.
> 
> 
> I may have missed it, but I only recall you argued that we just need
> to collect mature space for the *final unloading* as CL and classes
> are unlikely to die young, which I agree. But chances that a live
> object of a candidate class appeared in the nursery are higher.
> Otherwise I just do not grok how this algorithm can be proven for
> correctness.
> 

OK.  My latest proposal (a few messages ago) was assuming that the
nursery was empty when the "end of epoch collection" is launched.

If it is not, you can do 2 things:

a) do a minor collection to empty it, or

b) i  - use a finalization-like list of references to class loader
objects
   ii - launch gc, which might mark a previously unmarked vtable
   iii- do a finalization-like rescuing for resuscitated class loaders

"b)" should really have a minimal performance impact.  As for its
"apparent complexity", I would say that this is a non-issue; similar
code must already exist in drlvm for implementing finalization.

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] questions on class unloading (JIRA H2000) and cleaning class.h (JIRA H1558)

[Rana Dasgupta]

Great. Thanks Weldon. Does this mean that it is to be verified on Windows?

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


1558 has been committed.  It took two commits since I forgot to "svn add"
4
files.  All in all, one hundred and twenty one files were committed.

Following the commit(s), I did an "rm -rf trunk", svn update, build.sh, "
build.sh test" on my linux box.  Everything seems to work OK.




On 11/8/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
>
> so, how did it go?
>
> Weldon Washburn wrote:
> > 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][classlib] DaCapo benchmark regressions

[Alexey Varlamov]

Robin,

1) it must be debug build of drlvm;
2) syntax is -Xstats:[1|2|3] , the number denotes detalization level.

Actually this options gives various *statistics* for run, rather than
performance data or profile. E.g. number of particular byte ops
performed, exceptions thrown/caugth, most frequently allocated
classes, usage of internal memory pools, etc.

I'm not sure this is what you requested - do you need to tune the VM
for best performance or collect additional info during run or smth
else?


2006/11/9, Robin Garner <[EMAIL PROTECTED]>:

Hmmm ...

$ $DRLVM_HOME/jre/bin/java -Xbootclasspath/p:antlr.jar -XcleanupOnExit
-Xstats -jar $HOME/dacapo-2006-10.jar antlr
Unknown option -Xstats
Use java -help to get help on command line options

$ $DRLVM_HOME/jre/bin/java -version
Apache Harmony Launcher : (c) Copyright 1991, 2006 The Apache Software
Foundation or its licensors, as applicable.
java version "1.5.0"
pre-alpha : not complete or compatible
svn = r472802, (Nov  9 2006), Linux/ia32/gcc 4.0.3, release build
http://incubator.apache.org/harmony

Anything else I need to add ? :-)

Evgueni Brevnov wrote:
> Unfortunately, YES. It's a known problem. You need to specify
> -XcleanupOnExit as well :-) I'm working in it currently will
> provide a fix soon...
>
> Thanks
> Evgueni
>
> On 11/9/06, Robin Garner <[EMAIL PROTECTED]> wrote:
>> Evgueni Brevnov wrote:
>> > On 11/9/06, Alexey Petrenko <[EMAIL PROTECTED]> wrote:
>> >> The logs for some benchmarks does not have error messages.
>> >> Is this possible to fix?
>> >>
>> >> SY, Alexey
>> >>
>> >> 2006/11/9, Robin Garner <[EMAIL PROTECTED]>:
>> >> > I've just finished adding drlvm to the nightly DaCapo benchmark
>> >> > regression tests.  The results are available here:
>> >> >
>> >> > http://cs/people/Robin.Garner/dacapo/regression/
>> >> >
>> >> > JikesRVM and DRLVM/Harmony classlib are built from svn checkouts
>> taken
>> >> > when the nightly run kicks off (00:35 Australian Eastern time).
>> >> >
>> >> > I'm currently working on adding performance stats for DRLVM and
>> >> > JikesRVM, so some suggestions about the best command line
>> parameters to
>> >> > use would be appreciated.
>> >
>> > DRLVM accepts -Xstats parameter for that purpose.
>>
>> -Xstats doesn't work for me - is there something I need to do
>> specifically to make it work ?
>>
>> > Thanks
>> >
>> >> >
>> >> > cheers
>> >> >
>> >> > --
>> >> > Robin Garner
>> >> > Dept. of Computer Science
>> >> > Australian National University
>> >> >
>> >>
>>
>>
>> --
>> Robin Garner
>> Dept. of Computer Science
>> Australian National University
>>


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

Re: [doc][drlvm] The document "Getting started with DRL" is outdated

[Salikh Zakirov]

Morozova, Nadezhda wrote:
> * preparing the "Commonly Used Options for DRLVM" (omitting the word
>   "supported" intentionally)
> Question on this one: will the page contain vm-only options? What about
> JIT, GC, other? I'd have them all in one place, but we have separate
> docs for EM/jit stuff. What do you say?

I suggest that the maintainers of the respective components add their favourite
options to the page 

   http://wiki.apache.org/harmony/DrlvmCommandLineOptions

(I've just linked it from the front page, and stuffed some easy stuff I know).

After (and if) the content comes to a reasonable shape, Nadya may consider
rewriting it as a permanent web site page. However, I suspect that rate of 
changing
of command line options is a little bit too fast to be tracked by "hard" 
documentation.

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

[Robin Garner]

Alexey Varlamov wrote:

2006/11/9, Robin Garner <[EMAIL PROTECTED]>:

Etienne Gagnon wrote:
> Alexey Varlamov wrote:
>> Sorry if it was already discussed, but I believe this approach also
>> requires marking vtable bit/byte on each object allocation, unitl the
>> "unloading" GC pass is strictly stop-the-world full-heap collection.
>> Robin, did you include this particular overhead too in your
>> measurements?

I didn't include it - having established that it's cheap during GC where
memory bandwidth is at a premium, I kind of took this for granted.

> My proposal already argued that vtable bit/byte/word marking is
> unnecessary for "nursery allocations".  You only need to mark the 
vtable

> of objects that survive collection and pretenured objects.


I may have missed it, but I only recall you argued that we just need
to collect mature space for the *final unloading* as CL and classes
are unlikely to die young, which I agree. But chances that a live
object of a candidate class appeared in the nursery are higher.
Otherwise I just do not grok how this algorithm can be proven for 
correctness.


There is definitely some kind of barrier required here.  If no 
references to classes belonging to a c/l exist, but references to one of 
the j.l.classloaders exist, classloader may get marked for collection. 
Objects get created (via reflection, in nursery), references to c/l are 
dropped, classloader unloads.


I believe a barrier in one or more of the reflective methods used to 
create objects from j.l.class/j.l.c/loader references is probably necessary.


Weak references can only be collected at the end of a reachability epoch 
in any case, so I think there may be some stronger guarantees that we 
can use, but I'm too sleepy to thing of them right now :)



And this is a persuasive argument.  But I can probably find time to
measure it tomorrow if you aren't convinced.


That would be very kindly, thank you.

--
Alexey


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

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

[Etienne Gagnon]

Salikh Zakirov wrote:
> Technically, it should not be too difficult to add an additional field to the 
> VTable
> structure, and require GC to write 1 there during object scanning.
> However, if the VTable mark is located in the same cache line as gcmap,
> it may severely hit parallel GC performance on a multiprocessor due to false 
> sharing,
> as writing VTable mark will invalidate the gcmap pointers loaded to caches of 
> other
> processors. 
> 
>objectVTable   gcmap
>  +++---++--+
>  | VT ptr |--->| gcmap ptr |--->| offset of ref #1 |
>  |  ...   ||...|| offset of ref #2 |
>  +++---+|   ...|
> |0 |
> +--+

If you go that far for every scanned object (!), then you could simply
place the class unloading bit in the gc map, at index -1) to minimize
disruption of current code...

   objectVTable   gcmap
+--+
 +++---+| cl.un. mark bit  |
 | VT ptr |--->| gcmap ptr |--->| offset of ref #1 |
 |  ...   ||...|| offset of ref #2 |
 +++---+|   ...|
|0 |
+--+

This gets rid of the cache line hazard...

Why don't you also investigate using SableVM's bidirectional object
layout?  Dayong Gu (a Ph.D. student tha I co-supervise) found that it
was quite simple to implement in JikesRVM.  I don't see why it should be
harder to implement in drlvm...  It would save you this nasty
indirection for scanning objects!  [See my Ph.D. thesis for an
explanation of the layout.  You can get in touch with Dayong through the
coordinates at http://www.sable.mcgill.ca/people/ ].

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] building jitrino in release mode

[Fedotov, Alexei A]

As I reported at http://issues.apache.org/jira/browse/HARMONY-1969 I
succeeded by making two changes:
 * Changed build.sh
 * Needed to comment a fatal warning flag
But this was on SuSE, not Ubuntu. 

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

>-Original Message-
>From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED]
>Sent: Thursday, November 09, 2006 4:32 AM
>To: harmony-dev@incubator.apache.org
>Subject: Re: [drlvm] building jitrino in release mode
>
>Well, I have problems.  I was on a short trip this week - I'll be back
>at home tomorrow morning, and can revisit...
>
>geir
>
>
>Mikhail Fursov wrote:
>> 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:
>>>
>>> =
>>>   
>>> -
>>> +
>>>   >> value="extra.apr,vm.vmcore,vm.encoder" />
>>>   
>>>   
>>> @@ -48,7 +48,8 @@
>>>   >> includes="empty_pattern"/>
>>>
>>>   
>>> -
>>> +
>>> =
>>>
>>>
>>> --
>>> Thanks,
>>>Alex
>>>
>>>
>>
>>

Re: [build] Building on Eclipse - FYI

[Sian January]

Yes that sounds fine.  Shall I update my patch to remove the DRLVM
references, or would you prefer to?  Since I did not write very much about
DRLVM we could leave that out for now and then the person who updates
"Getting Started with DRLVM" could choose to add something there if people
feel it's appropriate.

Regards,

Sian


On 09/11/06, Konovalova, Svetlana <[EMAIL PROTECTED]> wrote:


Folks,
Looking through the site and figuring out how to improve the docs that
include info on Eclipse, the following ideas came up to my mind:
1) Since the "Developing Apache Harmony Class-library
Code with Eclipse" page [1] is mostly class-library oriented, I suggest
reviewing it to remove purely DRLVM-oriented info and leave the page
where it is now [subcomponents/classlibrary/dev_eclipse.html].
2) Add the link from the Quick Help pages to the "Developing Apache
Harmony Class-library Code with Eclipse" page [1].
3) Gather purely DRLVM-oriented info to store it in the "Getting Started
with DRL" doc (hope it won't be wiped off the face of the earth; for
details, see the discussion thread: [doc][drlvm] The document "Getting
started with DRL" is outdated)
In this case, we'll get two docs providing info on developing with
Eclipse:
[1] - describing how to develop class-library code with Eclipse, and "GS
with DRL"(or whatever it'll be) describing how to develop DRLVM
application in Eclipse.
Any objections? What do you think? Please right me if I'm wrong.

Best regards,
Sveta Konovalova

[1]
http://incubator.apache.org/harmony/subcomponents/classlibrary/dev_eclip
se.html


-Original Message-
From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED]
Sent: Thursday, November 09, 2006 3:58 PM
To: harmony-dev@incubator.apache.org
Subject: Re: FW: [build] Building on Eclipse - FYI



Egor Pasko wrote:
> On the 0x21C day of Apache Harmony Sian January wrote:
>> Hello again,
>>
>> I have had a closer look at the  "Developing Apache Harmony
Class-library
>> Code with Eclipse" page, and I have noticed that the "Configuring
Eclipse"
>> and "Develop and Test Code" sections are quite class-library
specific.
>> Would it be better to leave those sections as they are and add a
"Developing
>> DRLVM with Eclipse" section on the same page?
>
> To the moment I am not aware of anybody who would use Eclipse for
> DRLVM development. So, it's too early to add a page like this.

This will ensure that no one does then - if it's simple to add, lets add

it...

geir

>
>> Thanks,
>>
>> Sian
>>
>>
>>
>> On 07/11/06, Konovalova, Svetlana <[EMAIL PROTECTED]>
wrote:
>>>
>>> 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 c

Re: [DRLVM] General stability

[Egor Pasko]

On the 0x21C day of Apache Harmony Mikhail Loenko wrote:
> 2006/11/9, Geir Magnusson Jr. <[EMAIL PROTECTED]>:
> >
> >
> > Fedotov, Alexei A wrote:
> > > Alexey Petrenko wrote,
> > >> The only release I can imagine is Harmony Java5SE 100% compatible.
> > >> To be Java5SE 100% compatible we need TCK first.
> > >
> > > +1
> > >
> >
> > Yes - and I still think that talk of a release is a bit premature right now.
> >
> > The key things that I believe we need to focus on are
> >
> >  a) stability and
> >
> >  b) completeness.
> >
> >  c) reliability (which may be 'stability')
> >
> > (and not always in that order :)
> >
> >
> > Things I'd like to see us do :
> >
> > 1)  We need to drive to fully working unit tests for both DRLVM and
> > classlib  (using DRLVM).  Great progress has been made in this area, and
> >  we should probably make this a "campaign" for DRLVM as we did for
> > classlib.
> >
> > 2) Add stress tests
> >
> > 3) Get our CC-based build-test framework patched and running on as many
> > platforms as possible, reporting breakage into the list.
> >
> > 4) Identify problem areas and focus on them.  For example, threading in
> > DRLVM...
> >
> > I do think of us having a 'zero regression' policy except in cases where
> > we make the explicit decision to break.  (like we did with TM, for example)
> 
> +1 for 'zero regression' unless explicitely agreed

I am +1 for "'zero regression' unless explicitely agreed" at least for
(c/jit-)unit, kernel, classlib tests. Do you think of including
Eclipse UT, DaCapo, etc. to the 'zero regression' set? 

That would probably be good, I am afraid of too heavy checks for each
small patch. 

> Thanks,
> Mikhail
> 
> >
> >
> > > I hesitate to say that again, but we also need to decide about VM we
> > > will use for that release. I like the following mission: "Class library
> > > and DRLVM pass TCK on Ubuntu 6". I'm open for any other mission which is
> > > challenging, understandable and short enough.
> >
> > Well, we'll need Windows XP and RHEL as well.
> >
> >
> > >
> > > Writing down this mission certainly shouldn't inhibit individuals from
> > > achieving other goals at Harmony. But it would help the rest of
> > > community to concentrate on the common task.
> > >
> > > 1.
> > > http://wiki.apache.org/harmony/Platforms_to_Run_Harmony_Development_Kit_
> > > on
> > >
> > > With best regards,
> > > Alexei Fedotov,
> > > Intel Java & XML Engineering
> > >
> > >> -Original Message-
> > >> From: Alexey Petrenko [mailto:[EMAIL PROTECTED]
> > >> Sent: Wednesday, November 08, 2006 10:36 AM
> > >> To: harmony-dev@incubator.apache.org
> > >> Subject: Re: [DRLVM] General stability
> > >>
> > >> 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
> > >
> >
> >
> 

-- 
Egor Pasko

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

[Alexey Varlamov]

2006/11/9, Robin Garner <[EMAIL PROTECTED]>:

Etienne Gagnon wrote:
> Alexey Varlamov wrote:
>> Sorry if it was already discussed, but I believe this approach also
>> requires marking vtable bit/byte on each object allocation, unitl the
>> "unloading" GC pass is strictly stop-the-world full-heap collection.
>> Robin, did you include this particular overhead too in your
>> measurements?

I didn't include it - having established that it's cheap during GC where
memory bandwidth is at a premium, I kind of took this for granted.

> My proposal already argued that vtable bit/byte/word marking is
> unnecessary for "nursery allocations".  You only need to mark the vtable
> of objects that survive collection and pretenured objects.


I may have missed it, but I only recall you argued that we just need
to collect mature space for the *final unloading* as CL and classes
are unlikely to die young, which I agree. But chances that a live
object of a candidate class appeared in the nursery are higher.
Otherwise I just do not grok how this algorithm can be proven for correctness.


And this is a persuasive argument.  But I can probably find time to
measure it tomorrow if you aren't convinced.


That would be very kindly, thank you.

--
Alexey


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

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

[Salikh Zakirov]

Robin Garner wrote:
> Etienne Gagnon wrote:
>> 3- Why would it be so hard to add an unconditional write operation
>> during collection (e.g. during copying or marking of an object) in
>> drlvm?  A detailed technical explanation is welcome. :-)
> 
> I actually believe that this should be implementable in a GC-neutral
> way, whether vtables are objects or not.  The GC will at some point ask
> the VM for the GC map of the object it is about to scan.  At this point
> the VM can write the mark of the vtable.
> 
> I guess I'm making an assumption about the GC -> VM interface here, but
> if it doesn't exist, it should :)

In the current GC-VM interface, which is used in DRLVM
(see vm/include/open/gc.h and vm/include/open/vm_gc.h),
the GC never asks VM about gcmap; instead, it is building a gcmap
itself as one of the class loading steps. VM calls gc_class_prepared()
for each loaded class, and GC uses various query functions to learn
about types and offsets of object fields.

The gcmap pointer is stored in the VTable, in the several bytes reserved 
specifically
for the GC use.

Technically, it should not be too difficult to add an additional field to the 
VTable
structure, and require GC to write 1 there during object scanning.
However, if the VTable mark is located in the same cache line as gcmap,
it may severely hit parallel GC performance on a multiprocessor due to false 
sharing,
as writing VTable mark will invalidate the gcmap pointers loaded to caches of 
other
processors. 

   objectVTable   gcmap
 +++---++--+
 | VT ptr |--->| gcmap ptr |--->| offset of ref #1 |
 |  ...   ||...|| offset of ref #2 |
 +++---+|   ...|
|0 |
+--+

(* actually, in the current default collector "gc_cc",
 gcmap ptr also has some flags in lower 3 bits, and gcmap has some fields
before offsets array as well *)

That's why we probably would want to have the VTable mark be separated enough
from both gcmap pointer and the gcmap itself. 

>> By the way, what are the currently competing proposals?
>> 1- object vtables
>> 2- Robin/Gagnon proposal  (still finishing up some details ;-)
>> 3- Is there a 3rd?

yes, as far as I heard from Aleksey Ignatenko, there was 3rd prototype in works,
which worked as a completely independent from the GC stop-the-world phase,
tracing the heap and marking classes and classloaders specially.
The tracing functionality was reimplemented within VM without any GC changes.
The stop-the-world phase was piggy-backed into some collections.

And yet before the 3rd prototype, there was one more, which was different
in the tracing implementation. It used GC->VM callback on each object scan.

Re: [drlvm][jvmti] Heap iteration bugfix in HARMONY-2112

[Salikh Zakirov]

Gregory Shimansky wrote:
> I've applied your patch in HARMONY-2112 but I have a question to you. There 
> is 
> a new condition in jvmti_capability.cpp with the following comment:
> 
> // if the global capability can_tag_objects has already been enabled,
> // requested by this environment, but not yet posessed by this 
> environment,
> // reject the request
> if (ti->get_global_capability(DebugUtilsTI::TI_GC_ENABLE_TAG_OBJECTS)
> && !posessed.can_tag_objects && capabilities_ptr->can_tag_objects)
> return JVMTI_ERROR_NOT_AVAILABLE;
> 
> Does it mean that only one environment at a time can hold and use tag objects 
> functionality? Is it a temporary limitation or inherent design restriction? 

Yes, your understanding is correct. The design to store tag pointer into each 
object
implies that object cannot be tagged by more than one environment.
Thus the restriction of only one environment possessing can_tag_objects 
capability.

I've added a note to KnownNonBugIssuesAndLimitations wiki page.

Re: FW: [build] Building on Eclipse - FYI

[Egor Pasko]

On the 0x21C day of Apache Harmony Geir Magnusson, Jr. wrote:
> Egor Pasko wrote:
> > On the 0x21C day of Apache Harmony Geir Magnusson, Jr. wrote:
> >> Egor Pasko wrote:
> >>> On the 0x21C day of Apache Harmony Sian January wrote:
>  Hello again,
> 
>  I have had a closer look at the  "Developing Apache Harmony Class-library
>  Code with Eclipse" page, and I have noticed that the "Configuring 
>  Eclipse"
>  and "Develop and Test Code" sections are quite class-library specific.
>  Would it be better to leave those sections as they are and add a 
>  "Developing
>  DRLVM with Eclipse" section on the same page?
> >>> To the moment I am not aware of anybody who would use Eclipse for
> >>> DRLVM development. So, it's too early to add a page like this.
> >> This will ensure that no one does then - if it's simple to add, lets
> >> add it...
> > Does it help anybody? I see no point in doing redundant work even if
> > it is small.
> 
> Why is it redundant?

Nobody uses, nobody reads -> redundant. Am I missing something? :)

> > Who would give Eclipse a try just to write a redundant doc? I wrote a
> > GDB howto because I use it and have some helpful things to say. I
> > would have been glad to know if someone has similar experience with
> > Eclipse+DRLVM.
> >
> >> geir
> >>
>  Thanks,
> 
>  Sian
> 
> 
> 
>  On 07/11/06, Konovalova, Svetlana <[EMAIL PROTECTED]> wrote:
> > 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,

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

[Weldon Washburn]

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


Geir Magnusson Jr. wrote:
>
>
> Weldon Washburn wrote:
>>
>>
>> On 11/8/06, *Geir Magnusson Jr.* <[EMAIL PROTECTED]
>> > wrote:
>>
>>
>>
>> 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.
>>
>> How would a business workload need this directly?
>>
>> That's the point.  I can't figure out any compelling story for moving
>> vtables.  As far as I can tell, its over-engineering.   I would love
>> to be proven wrong.
>
> But isn't this simply an implementation detail of something that is
> important, namely the class unloading?
>
> geir



I have no problem calling it an implementation detail.  Its an important
implementation detail that somehow got mixed into the design conversation.
Worth noting is that ultimately the committer is on the hook for committing
an implementation.  It would be good to have the discussion on moving vtable
implementation before someone spends a bunch of time on it.

While it did come up as an issue in the class-unloading talks I think

most of us believe it to be orthogonal.

cheers

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





--
Weldon Washburn
Intel Enterprise Solutions Software Division

Re: [drlvm][threading][build] HARMONY-1907 commit (r472524) breaks the build on SUSE9

[Geir Magnusson Jr.]

Worked fine for me on Ubuntu 6 using gcc 3.4.3

Gregory Shimansky wrote:
Thanks for spotting this. I'll check on SUSE and if reverting this patch 
helps, I'll revert it. I wonder why this doesn't break on more modern 
linuxes.


Egor Pasko wrote:

Guys,

after commit of HARMONY-1907 (r472524) by Gregory .. * Good news: 
builds OK :)
* Bad news: I am observing HelloWorld to fall into SEGV on SUSE9   
(yes, old gcc-3.3.3 again:)


788 methods compiled successfully, last are:

EM: compile start:[JET_DPGO n=782] 
java/lang/FinalizerThread$FinalizerStartLock::(Ljava/lang/FinalizerThread;)V 

EM: compile done:[JET_DPGO n=782: OK] 
java/lang/FinalizerThread$FinalizerStartLock::(Ljava/lang/FinalizerThread;)V 


EM: compile start:[JET_DPGO n=783] java/lang/Thread::setDaemon(Z)V
EM: compile done:[JET_DPGO n=783: OK] java/lang/Thread::setDaemon(Z)V
EM: compile start:[JET_DPGO n=784] java/lang/Thread::isAlive()Z
EM: compile done:[JET_DPGO n=784: OK] java/lang/Thread::isAlive()Z
EM: compile start:[JET_DPGO n=785] java/lang/Thread::start()V
EM: compile done:[JET_DPGO n=785: OK] java/lang/Thread::start()V
EM: compile start:[JET_DPGO n=786] java/lang/Object::wait()V
EM: compile done:[JET_DPGO n=786: OK] java/lang/Object::wait()V
EM: compile start:[JET_DPGO n=787] java/lang/Thread::runImpl()V
EM: compile done:[JET_DPGO n=787: OK] java/lang/Thread::runImpl()V
EM: compile start:[JET_DPGO n=788] java/lang/Object::notifyAll()V
EM: compile done:[JET_DPGO n=788: OK] java/lang/Object::notifyAll()V

most likely, threading library failed to load, because:
(gdb) bt 20
#0  0x40007de5 in do_lookup_x () from /lib/ld-linux.so.2
#1  0x400080dc in _dl_lookup_symbol_x () from /lib/ld-linux.so.2
#2  0x40558f16 in do_sym () from /lib/tls/libc.so.6
#3  0x4055904a in _dl_sym () from /lib/tls/libc.so.6
#4  0x40586158 in dlsym_doit () from /lib/libdl.so.2
#5  0x4000cf86 in _dl_catch_error () from /lib/ld-linux.so.2
#6  0x40586415 in _dlerror_run () from /lib/libdl.so.2
#7  0x40586101 in dlsym () from /lib/libdl.so.2
#8  0x40c998f7 in apr_dso_sym (ressym=0x5288f0f0, handle=0x80b4530, 
symname=0x52a80410 "Java_java_lang_VMThreadManager_notifyAll")

at dso.c:227
#9  0x40b9665a in natives_lookup_symbol (libraries=0x84e88e8, 
symbol=0x52a80410 "Java_java_lang_VMThreadManager_notifyAll")
at 
/export/users/evpasko/svn/3/trunk/working_vm/vm/vmcore/src/util/natives_support.cpp:629 

#10 0x40b96882 in natives_lookup_method (libraries=0x84e88e8, 
class_name=0x807b520 "java/lang/VMThreadManager",
method_name=0x807b0f0 "notifyAll", method_desc=0x807b3b0 
"(Ljava/lang/Object;)I")
at 
/export/users/evpasko/svn/3/trunk/working_vm/vm/vmcore/src/util/natives_support.cpp:669 

#11 0x40af9d80 in ClassLoader::LookupNative (this=0x8082dc0, 
method=0x83f62d4)
at 
/export/users/evpasko/svn/3/trunk/working_vm/vm/vmcore/src/class_support/classloader.cpp:1330 


#12 0x40afc2ad in classloader_find_native (method=0x83f62d4)
at 
/export/users/evpasko/svn/3/trunk/working_vm/vm/vmcore/src/class_support/classloader.cpp:2061 

#13 0x40b05441 in compile_prepare_native_method (method=0x83f62d4, 
flags={insert_write_barriers = 0, opt_level = 8, dynamic_profile = 0})
at 
/export/users/evpasko/svn/3/trunk/working_vm/vm/vmcore/src/jit/compile.cpp:652 

#14 0x40b05979 in compile_do_compilation (method=0x83f62d4, 
flags={insert_write_barriers = 0, opt_level = 8, dynamic_profile = 0})
at 
/export/users/evpasko/svn/3/trunk/working_vm/vm/vmcore/src/jit/compile.cpp:771 

#15 0x40b05d99 in compile_jit_a_method (method=0x83f62d4) at 
/export/users/evpasko/svn/3/trunk/working_vm/vm/vmcore/src/jit/compile.cpp:832 



If nobody has a quick idea how to fix it, I'll take a look today

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

[Geir Magnusson Jr.]

David Gilbert wrote:

Geir Magnusson Jr. wrote:



Sun using the GPL is a boon for Classpath, so good for them - I'm not 
sure how they can actually use the Sun code, as Sun won't be granting 
copyright assignment to the FSF as GNU Classpath requires, and it's 
under a different license (not the GPL + Exception), but I'm sure 
they'll work something out.


geir

A boon?  Not at all, Classpath will be (mostly) redundant and will fade 
away, replaced by Sun's runtime. 


I'm not so convinced of that.  GNU Classpath is under GPL + Exception, 
so arguably it's not viral to things that link with it.


While this is sheer speculation because we haven't seen anything yet, if 
Sun goes with the GPL, they won't have such feature in the license.


Also, I think the copyright assignment requirement will be a big deal.

But as I said elsewhere, that's a good 
outcome if all you are interested in is a good quality free / open 
source runtime to run Java applications on...and I'm not after anything 
more than that.


Understood.  For me, an additional requirement is an open and level 
community, where all participants are working together under exactly the 
same terms. (Which is where GNU Classpath will be different than what I 
understand the Sun model will be)


geir



Regards,

Dave Gilbert

Re: [doc][drlvm] The document "Getting started with DRL" is outdated

[Egor Pasko]

On the 0x21C day of Apache Harmony Pavel Ozhdikhin wrote:
> On 11/9/06, Morozova, Nadezhda <[EMAIL PROTECTED]> wrote:
> >
> > Egor,
> > +1 for
> > Just idea: "Getting Started" may contain a collection of links to the
> > main website and other resources with short descriptions ("Site Map"
> > or something) so that people are comfortable floating around in the web.
> 
> 
> 
> We already have one page having links to the resources about DRLVM:
> http://incubator.apache.org/harmony/subcomponents/drlvm/index.html
> Why do you think we need another one?

because it is only DRLVM.
I think of something like "site map", a collection of links. Short
descriptions to some basic ones.

> 
> +1 for
> > * preparing the "Commonly Used Options for DRLVM" (omitting the word
> > "supported" intentionally)
> > Question on this one: will the page contain vm-only options? What about
> > JIT, GC, other? I'd have them all in one place, but we have separate
> > docs for EM/jit stuff. What do you say?
> 
> 
> I think we can describe basic options for every component there. Only those
> that might be interesting for any user. The place for other options is in
> the run-time help or Developer's Guide for a component.

I thought of "most commonly used" options. They can possibly be
grouped by components, but not necessary. I would group them by
use-cases. BTW, "any user" is not an obvious substance for me. 

So, the list is not obvious, we need to work it out.

I see it like HOWTOs. For example:
"-Xem:jet <- use only baseline JIT compiler"
"-Xem:opt <- use only optimising JIT compiler"
"-Xtrace:em <- print method compilation events"

The 'big' question is: "does 'any user' need to know about JITs
switching?". I say YES, it helps users to investigate problems, which
helps us, developers, to react on users' input faster.

Other options? I can enlist the set of most commonly used by me. If
many of us put their lists here, we can sum them up quickly and make
a good (really useful) list of popular options. How about that?

BTW, the list should not be too big. 25 options is a kind of limit

> Thanks,
> Pavel
> 
> Thank you,
> > Nadya Morozova
> >
> > -Original Message-
> > From: news [mailto:[EMAIL PROTECTED] On Behalf Of Egor Pasko
> > Sent: Thursday, November 09, 2006 5:51 AM
> > To: harmony-dev@incubator.apache.org
> > Subject: Re: [doc][drlvm] The document "Getting started with DRL" is
> > outdated
> >
> > On the 0x21B day of Apache Harmony Nadezhda Morozova wrote:
> > > All,
> > > I'd like to share everyone's grief at the sight of outdated Getting
> > > Started document. However, I'd not hurry to eliminate the page as
> > such.
> > > We might reconsider some of its contents, change structure, and update
> > > individual bits, but please think carefully before removing the page.
> > >
> > > I think Getting Started (as the title shows) is aimed to help a newbie
> > > work with our vm. I know that many primarily interested in other
> > things
> > > - conformance, architecture, internal specifics. However, we should
> > also
> > > think how the vm is used. AFAIK, Getting started is now the *only* doc
> > > that tries to show how to use our vm. You tell people how to download
> > > and build, but almost nothing about how to run and configure (with the
> > > exception of EM/JIT).
> > >
> > > My suggestion would be to think of what you want to tell people about
> > > usage - with or without eclipse specifics. And store this info on the
> > > page. I know it is hard - and I offer my help and support in this
> > > burdensome initiative. Any thoughts? i might be inobjective and
> > > emotional :)
> >
> > Nadya,
> >
> > I believe, almost everyone coming across Harmony knows how to use
> > J5SE. We are striving for this compatibility, and we are happy that
> > all DRLVM-specific pecularities are gone.
> >
> > So, I vote for:
> > * removing the "Getting Started" (also because of irritating windows
> > screenshots:)
> > * preparing the "Commonly Used Options for DRLVM" (omitting the word
> > "supported" intentionally)
> >
> > Just idea: "Getting Started" may contain a collection of links to the
> > main website and other resources with short descriptions ("Site Map"
> > or something) so that people are comfortable floating around in the web.
> >
> > > -Original Message-
> > > From: Mikhail Fursov [mailto:[EMAIL PROTECTED]
> > > Sent: Wednesday, November 08, 2006 6:03 PM
> > > To: harmony-dev@incubator.apache.org
> > > Subject: Re: [doc][drlvm] The document "Getting started with DRL" is
> > > outdated
> > >
> > > It's not a hard to write a documenation once, it's hard to support it
> > :)
> > > More problems:
> > > 1) -Xem options are obsolete.
> > > 2) -Xjit options are also obsolete.
> > > 3) Do we really need this page today? AFAIU users expect Harmony VM is
> > > able
> > > to run the same apps as RI..
> > > ?
> > >
> > > On 11/8/06, Pavel Ozhdikhin <[EMAIL PROTECTED]> wrote:
> > > >
> > > > Hello all,
> > > > I've read through t

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

[David Gilbert]

Geir Magnusson Jr. wrote:



Sun using the GPL is a boon for Classpath, so good for them - I'm not 
sure how they can actually use the Sun code, as Sun won't be granting 
copyright assignment to the FSF as GNU Classpath requires, and it's 
under a different license (not the GPL + Exception), but I'm sure 
they'll work something out.


geir

A boon?  Not at all, Classpath will be (mostly) redundant and will fade 
away, replaced by Sun's runtime.  But as I said elsewhere, that's a good 
outcome if all you are interested in is a good quality free / open 
source runtime to run Java applications on...and I'm not after anything 
more than that.


Regards,

Dave Gilbert

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

[Ivanov, Alexey A]

Sveta, all,

I've attached the updated patch to the JIRA.

Please review.

Regards,
Alexey.


P.S. By the way, do we really need to place all the main content into
another table? I've just looked at the source of the generated HTML
file, and found it quite confusing. I agree to have a table to format
the heading of the page and the list of contents on the left, but why
there's another table where the main content is. I am about this one:

 
 




   
 
Good Issue
Resolution Guideline

   
   ... 

The comments here are added by me, and the source is slightly
reformatted.
I believe, the  part of the XML can be placed almost as is in the
content cell of the top-level table without the need for another table
because it's useless here. Or is it just Anakia limitation?

--
Alexey A. Ivanov
Intel Enterprise Solutions Software Division


>-Original Message-
>From: Konovalova, Svetlana [mailto:[EMAIL PROTECTED]
>Sent: Thursday, November 09, 2006 3:50 PM
>To: harmony-dev@incubator.apache.org
>Subject: RE: [jira] Good issue resolution guideline (was:
>[classlib]volunteer to supply patches for old JIRAs)
>
>Alexey,
>
>>>I'd change the heading "Reporting the Issue" to "Reporting an Issue",
>>>or omit article at all.
>>> Well, both articles seem to be fine. Let it be "a/an"
>>Maybe just omit articles then?
>Well, how about the third variant: "Reporting Issues"?
>
>
>>I'm still for 'reproduce' because a bug can be (non-)reproducible but
>>not recreatable.
>>Any other opinions?
>Ok, "reproduce" is fine
>
>>>I'd say: "If you have any questions, discuss them...
>>That's even better :)
>Cool!:)
>
>>>All patches, such as tests and fixes, should be
>>Good! It's clearer.
>Fine!
>
>>OK. I'll prepare patch update then.
>Good luck! I'd be glad to review it, if you do not mind. :)
>
>Cheers,
>Sveta
>
>Thanks,
>Alexey.
>
>>
>>
>>Best regards,
>>Sveta
>>
>>-Original Message-
>>From: Ivanov, Alexey A [mailto:[EMAIL PROTECTED]
>>Sent: Thursday, November 09, 2006 1:33 PM
>>To: harmony-dev@incubator.apache.org
>>Subject: RE: [jira] Good issue resolution guideline (was:
>>[classlib]volunteer to supply patches for old JIRAs)
>>
>>>-Original Message-
>>>From: Konovalova, Svetlana [mailto:[EMAIL PROTECTED]
>>>Sent: Wednesday, November 08, 2006 7:01 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 just submitted a new JIRA
>>>[http://issues.apache.org/jira/browse/HARMONY-2110].
>>>I've added the necessary links from the website to the new page and
>>have
>>>tried to perfect it a little.
>>>It would be great, if you could find a chance to look through the
>>patch.
>>>Thanks in advance.
>>
>>Sveta,
>>
>>I've taken a look and added my comments to the JIRA itself.
>>
>>
>>Regards,
>>Alexey.
>>
>>>
>>>Best regards,
>>>Sveta
>>>
>>>-Original Message-
>>>From: Morozova, Nadezhda [mailto:[EMAIL PROTECTED]
>>>Sent: Wednesday, November 08, 2006 11:18 AM
>>>To: harmony-dev@incubator.apache.org
>>>Subject: RE: [jira] Good issue resolution guideline (was:
>>>[classlib]volunteer to supply patches for old JIRAs)
>>>
>>>Good! Go ahead. Do you need help? I can review the patch - just let
me
>>>know when you submit the JIRA.
>>>
>>>Thank you,
>>>Nadya Morozova
>>>
>>>-Original Message-
>>>From: Konovalova, Svetlana [mailto:[EMAIL PROTECTED]
>>>Sent: Wednesday, November 08, 2006 9:13 AM
>>>To: harmony-dev@incubator.apache.org
>>>Subject: RE: [jira] Good issue resolution guideline (was:
>>>[classlib]volunteer to supply patches for old JIRAs)
>>>
>>>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: ha