date:20061115


2006/11/16, Mikhail Loenko <[EMAIL PROTECTED]>:

why not?

But what benefit it would bring? build test in DRLVM takes too much
time already, I'm afraid people will just stop using it :(

This is analogous to enforcing full testing in classlib for every
change regardless of module. Evidently this is too expensive.



2006/11/16, Geir Magnusson Jr. <[EMAIL PROTECTED]>:
>
>
> Pavel Ozhdikhin wrote:
> > On 11/16/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
> >>
> >> Be sure to not miss anyone :)  This was a great community effort, with
> >> everyone pitching in.
> >>
> >> DRLVM is now a full peer  to J9 in Harmony testing.  :)  We still need
> >> to use J9 (and another VM that happens to work with our classlibrary),
> >> as a sanity check, but we should from now on use DRLVM in our CI testing
> >> framework.
> >
> >
> > On the other hand, to make sure DRLVM has no regressions regarding
> > to Classlibrary Unit Tests it makes sense to add these tests to the "test"
> > target of DRLVM build.
> > What do people think?
>
> Adding classlib unit tests to DRLVM test target?  No thanks :)
>
> geir
>
> >
> > Thanks,
> > Pavel
> >
> >
> >
> >> geir
> >>
> >>
> >> Alexei Fedotov wrote:
> >> > Oops, I've missed:
> >> > * Andrew Zhang for reviewing class library patches and helpful
> >> discussions
> >> >
> >> > On 11/16/06, Alexei Fedotov <[EMAIL PROTECTED]> wrote:
> >> >>
> >> >> Folks,
> >> >> According to http://harmonytest.org, today 100% of class library unit
> >> >> tests pass on DRLVM. Thank you all! It takes 44 days for the great
> >> >> team we are. Thanks for your thoughtful, diligent work and deep
> >> >> inspiration. Kudos to you for the following (and not limited to this):
> >> >>
> >> >> * Alexey Varlamov and Elena for driving the whole process
> >> >> * Anton and Vladimir Ivanov for automating test runs
> >> >> * Geir and Gregory for checking and committing related DRLVM patches
> >> >> * Paulex, Tim, Nathan, Stepan and Mikhail Loenko for checking and
> >> >> committing related class library patches
> >> >> * Alexey Petrenko for becoming ICU expert and writing good JIRA issue
> >> >> resolution guidelines
> >> >> * Alexei Zakharov for resolving class library test issues
> >> >> * Ilya Okomin, Denis Kishenko, Oleg Khaschansky and Alexey Ivanov for
> >> >> fixing class library and tests* Ivan, Egor, Mikhail Fursov, Nikolay
> >> >> Sidelnikov and Alexander Astapchuk for making execution engines work
> >> >> * Tatiana and Maxim for filing JIRA issues about test failures
> >> >> * Nikolay Kuznetsov for completing thread interruption handling and
> >> >> reverting consequences of park/unpark integration
> >> >> * Pavel Afremov for fixing exception handling
> >> >> * Boris Kuznetsov for intelligent fixing of security tests
> >> >> * Rana and Salikh for evaluating and discussing problems, reviewing
> >> >> and trying DRLVM patches
> >> >> * Pavel Pervov and Evgueni for help with DRLVM patches
> >> >> * Artem for discovering and fixing weird Windows* behavior
> >> >> * My wife for bringing hot tea to the computer during sleepless nights
> >> >>
> >> >> There are still open issues with reliability, multiprocessor and other
> >> >> special configurations, so the page
> >> >> http://wiki.apache.org/harmony/Unit_Tests_Pass_on_DRLVM  remains
> >> >> active. But this shouldn't prevent us from including class library
> >> >> testing into Harmony "zero regression" policy. What do you think?
> >> >>
> >> >> --
> >> >> Thank you,
> >> >> Alexei
> >> >
> >> >
> >> >
> >>
> >
>

Re: [drlvm] New regression: java.lang.ClassGenericsTest4

Well, we all learned the lesson. Here are my own thoughts, and some
more answers are inlined:
1) Explicit separate testing for all execution engines (JET, OPT,
interpreter) is really valuable; so far we found bugs in many
components including classlib (!), especially due to interpreter. I
bet JIT guys will soon beseech for the same in classlib testing, at
least by CI :)
2) Time required to run all pre-commit tests for DRLVM is near to
inadmissible. I believe this is the main reason why patch submitters
may not exercise them truly. Another reason is poor diagnostic&debug
services of available build infrastructure.
We really need to think how we can improve it - e.g. using "sameVM"
mode as much as possible, provide more reliable and convenient results
reporting, more unified harness, etc.
3) It would be nice to invest some efforts to cleaning & sorting out
available tests, smoke and kernel first of all. I suspect there might
be some duplication in coverage, and it certainly does present between
DRLVM-kernel and classlib-luni suites. Ideally we would merge them
into common VM-kernel.

2006/11/16, Gregory Shimansky <[EMAIL PROTECTED]>:

Alexei Fedotov wrote:
> Guys,
>
> This is a good discussion, and let me praise Alexey for the wonderful fix.
>
> I'm a bit concerned about our accepptance checks. How this could be
> that regression was missed by a committer and an engineer durring
> acceptance test runs?
>
> Bug comments showed that Gregory ran the tests before a commit. Do
> tests report such problems clearly?

I saw that they failed on interpreter and saw an additional failure by
ClassGeneticsTest4, but when I reverted the patch I ran the test
individually (because running kernel tests is quite a long task). I saw
exceptions output from ClassGeneticsTest4 with reverted patch and
decided that it wasn't the one to blame. I tried reverting other patches
but all of them produced the same output. Today Alexey explained to me
that exceptions output was just a verbose test output not to related to
test passed/failed status. So the answer to your question is "not very
clearly" :)

Well, junit always output total status after run, just some practice
is needed to distinguish between noise and vital output :) But me too
dislikes stacktraces in output very much.

After I saw that reverting the patches doesn't help very much I decided
that regression somehow slipped earlier but wasn't noticed. The problem
with kernel tests is that they don't pass stably. Often j.l.ThreadTest
fails and j.l.RuntimeTest2 fails on XP. So I thought that negative
result of kernel tests run was assumed to be ok because
ClassGeneticsTest4 failure was not noticed since some tests which fail
often failed.

Unfortunately yes, drlvm tests and kernel in particular gained some
mournful reputation. But in fact, they (mostly) failed justly. Now
DRLVM becomes more mature and we should adopt "zero regression" policy
soon.

The output of kernel tests is not very good too. They run 3 times on
JET, OPT and interpreter. The last output is for interpreter, and if the
output prints PASSED it is necessary to check result for JET and OPT. I
think the tests should either  after the first test run which
didn't pass (similar to how smoke tests stop tests execution), or print
a summary at the end for all 3 runs with  if case any of them
didn't pass.

1) Fail-fast behaviour is not very informative, especially if
instability faced. It might be useful to enforce "zero regression"
rule, but I vote for "run them all" mode. BTW, this is how classlib
tests behave and this is just convenient. Yet we may want to add a
cmd-line switch ala "haltonfailure" in junit task.
2) I agree about more informative summary, will take care.

[snip]

--
Alexey

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

2006-11-15 Thread Pavel Ozhdikhin


Nadya,

I suggested one minor change to your patch in JIRA. Otherwise the patch
looks fine to me.

Thanks,
Pavel


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


Hi all,
I have attached an updated version of the patch for the getting started
page to the JIRA. If someone knowledgeable takes a look and evaluates,
that would be great.
I am not the reporter of the issue, so I cannot set the 'patch
available' setting. However, if no requests for fixes arrive, I suggest
that we consider the issue ready to be closed.

Thank you,
Nadya Morozova


>-Original Message-
>From: Pavel Ozhdikhin [mailto:[EMAIL PROTECTED]
>Sent: Tuesday, November 14, 2006 9:43 AM
>To: harmony-dev@incubator.apache.org
>Subject: Re: Re: [doc][drlvm] The document "Getting started with DRL"
is
>outdated
>
>OK then for Configuring VM section JIT options proposed by Egor will be
>suitable:
>
>"-Xem:jet <- use only baseline JIT compiler"
>"-Xem:opt <- use only optimising JIT compiler"
>"-Xtrace:em <- print method compilation events"
>
>I'd also add:
>
>"-Xem:server" - enable dynamic optimization mode tuned for long-running
>server-side applications (default optimization mode is tuned for fast
>start-up and client-side applications)
>"-Xem server_static" - enable static optimization mode tuned for
>long-running server-side applications
>
>Thanks,
>Pavel
>
>On 11/14/06, Morozova, Nadezhda <[EMAIL PROTECTED]> wrote:
>>
>> Pavel,
>> Thanks for your comments. I'll work through the examples and post an
>> updated patch soon.
>> As for the Configuring VM operation - can we at least have a couple
of
>> examples in the form of scenarios or something? The wiki page only
gives
>> a reference, an enumeration of available options. Using these might
not
>> always be transparent. I know it's tutorial-level info, but why not
have
>> it? Giving a show-case of customizing vm to a specific need would be
>> great.
>>
>> Thank you,
>> Nadya Morozova
>>
>> >-Original Message-
>> >From: Pavel Ozhdikhin [mailto:[EMAIL PROTECTED]
>> >Sent: Tuesday, November 14, 2006 9:23 AM
>> >To: harmony-dev@incubator.apache.org
>> >Subject: Re: Re: [doc][drlvm] The document "Getting started with
DRL"
>> is
>> >outdated
>> >
>> >Nadya,
>> >
>> >I've looked through your patch. Please see my comments in JIRA:
>> >http://issues.apache.org/jira/browse/HARMONY-2150
>> >
>> >> Do you think we can add a link to debugging vm&jit doc (or to
wiki)?
>> >
>> >I don't think we need it - it is rather info for developers than for
>> users.
>> >
>> >> Any ideas on what to write in Configuring vm operation?
>> >
>> >This section will duplicate the info from the Wiki page. Since we
gave
>> a
>> >link to that page in the "overview" we may skip creation of a
separate
>> >section here.
>> >
>> >Thanks,
>> >Pavel
>> >
>> >
>> >On 11/13/06, Morozova, Nadezhda <[EMAIL PROTECTED]> wrote:
>> >>
>> >> Successfully added a patch to fix getting Started outdated content
to
>> >> http://issues.apache.org/jira/browse/HARMONY-2150.
>> >> The patch is not final - need help to add more content. The
current
>> >> structure is:
>> >> - overview
>> >> - running an app
>> >> - eclipse-related (now much shorter)
>> >>-- running an app
>> >>-- debugging an app
>> >> - configuring vm operation (empty)
>> >>
>> >> Questions: how do you like the current patch? Do you think we can
add
>> a
>> >> link to debugging vm&jit doc (or to wiki)? Any ideas on what to
write
>> in
>> >> Configuring vm operation?
>> >>
>> >> Thank you,
>> >> Nadya Morozova
>> >>
>> >> >-Original Message-
>> >> >From: news [mailto:[EMAIL PROTECTED] On Behalf Of Egor Pasko
>> >> >Sent: Monday, November 13, 2006 1:00 PM
>> >> >To: harmony-dev@incubator.apache.org
>> >> >Subject: Re: [doc][drlvm] The document "Getting started with DRL"
is
>> >> >outdated
>> >> >
>> >> >On the 0x220 day of Apache Harmony Nadezhda Morozova wrote:
>> >> >> >-Original Message-
>> >> >> >From: news [mailto:[EMAIL PROTECTED] On Behalf Of Egor Pasko
>> >> >> >Sent: Monday, November 13, 2006 12:40 PM
>> >> >> >To: harmony-dev@incubator.apache.org
>> >> >> >Subject: Re: [doc][drlvm] The document "Getting started with
DRL"
>> is
>> >> >> >outdated
>> >> >> >
>> >> >> >On the 0x220 day of Apache Harmony Nadezhda Morozova wrote:
>> >> >> >> Ok,
>> >> >> >> I'll use http://issues.apache.org/jira/browse/HARMONY-2150
to
>> get
>> >> an
>> >> >> >> initial patch for the getting started document, and we can
then
>> >> work
>> >> >> to
>> >> >> >> improve it.
>> >> >> >
>> >> >> >OK, I am "watching" it
>> >> >> >
>> >> >> >> Let's make it a short page with links to wiki and maybe some
>> >> how-tos.
>> >> >> >
>> >> >> >To summarize:
>> >> >> >* we agreed that there will be no eclipse screenshots (they
are
>> for
>> >> >> >  eclipse+drlvm page)
>> >> >> >* we agreed that there should be something like "see what kind
of
>> >> >> >  links we have"
>> >> >> >
>> >> >> >Am I right?
>> >> >>
>> >> >> [Nadya]
>> >> >> Yop, quite right. An

Re: [drlvm][unit] 100% of class library tests pass

2006-11-15 Thread Mikhail Loenko


why not?

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



Pavel Ozhdikhin wrote:
> On 11/16/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
>>
>> Be sure to not miss anyone :)  This was a great community effort, with
>> everyone pitching in.
>>
>> DRLVM is now a full peer  to J9 in Harmony testing.  :)  We still need
>> to use J9 (and another VM that happens to work with our classlibrary),
>> as a sanity check, but we should from now on use DRLVM in our CI testing
>> framework.
>
>
> On the other hand, to make sure DRLVM has no regressions regarding
> to Classlibrary Unit Tests it makes sense to add these tests to the "test"
> target of DRLVM build.
> What do people think?

Adding classlib unit tests to DRLVM test target?  No thanks :)

geir

>
> Thanks,
> Pavel
>
>
>
>> geir
>>
>>
>> Alexei Fedotov wrote:
>> > Oops, I've missed:
>> > * Andrew Zhang for reviewing class library patches and helpful
>> discussions
>> >
>> > On 11/16/06, Alexei Fedotov <[EMAIL PROTECTED]> wrote:
>> >>
>> >> Folks,
>> >> According to http://harmonytest.org, today 100% of class library unit
>> >> tests pass on DRLVM. Thank you all! It takes 44 days for the great
>> >> team we are. Thanks for your thoughtful, diligent work and deep
>> >> inspiration. Kudos to you for the following (and not limited to this):
>> >>
>> >> * Alexey Varlamov and Elena for driving the whole process
>> >> * Anton and Vladimir Ivanov for automating test runs
>> >> * Geir and Gregory for checking and committing related DRLVM patches
>> >> * Paulex, Tim, Nathan, Stepan and Mikhail Loenko for checking and
>> >> committing related class library patches
>> >> * Alexey Petrenko for becoming ICU expert and writing good JIRA issue
>> >> resolution guidelines
>> >> * Alexei Zakharov for resolving class library test issues
>> >> * Ilya Okomin, Denis Kishenko, Oleg Khaschansky and Alexey Ivanov for
>> >> fixing class library and tests* Ivan, Egor, Mikhail Fursov, Nikolay
>> >> Sidelnikov and Alexander Astapchuk for making execution engines work
>> >> * Tatiana and Maxim for filing JIRA issues about test failures
>> >> * Nikolay Kuznetsov for completing thread interruption handling and
>> >> reverting consequences of park/unpark integration
>> >> * Pavel Afremov for fixing exception handling
>> >> * Boris Kuznetsov for intelligent fixing of security tests
>> >> * Rana and Salikh for evaluating and discussing problems, reviewing
>> >> and trying DRLVM patches
>> >> * Pavel Pervov and Evgueni for help with DRLVM patches
>> >> * Artem for discovering and fixing weird Windows* behavior
>> >> * My wife for bringing hot tea to the computer during sleepless nights
>> >>
>> >> There are still open issues with reliability, multiprocessor and other
>> >> special configurations, so the page
>> >> http://wiki.apache.org/harmony/Unit_Tests_Pass_on_DRLVM  remains
>> >> active. But this shouldn't prevent us from including class library
>> >> testing into Harmony "zero regression" policy. What do you think?
>> >>
>> >> --
>> >> Thank you,
>> >> Alexei
>> >
>> >
>> >
>>
>

Re: [build-test] Moving from /enhanced to /standard

2006-11-15 Thread Mikhail Loenko


+1

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

Does anyone care?  This way, we can be freer about who and what goes in
there.

Since we don't ship the testing frameworks with anything, this is
completely consistent with our IP policies and goals.

geir

Re: [classlib][testing] Showing test failures (Re: [drlvm] New regression: java.lang.ClassGenericsTest4)

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

Rana Dasgupta wrote:
> I think that a problem with the junit tests is that some failures spit out
> to the console, but show up in the test run results as passed. I find this
> very confusing. So unless you are watching all the time, you can miss them.

Hmm, this doesn't sound right.  I've not seen classlib tests fail but be
reported in the html report as passed.  Is that what you meant? (I
realize your mail subject was [drlvm] but just checking.)

One confusing aspect is that the classlib ant build fails if you run the
tests 'globally', but passes if you run the tests in a single module.

Yes, this was a nasty surprise for me when I saw exactly this
sutiation few days ago; I just had no time to speak up. We definitely
should fix this.

We could fix that by making the current test sequence an internal target
(for the 'global' test), and checking for failures after a 'modular' test.

e.g.

Index: build.xml
===
--- build.xml   (revision 474801)
+++ build.xml   (working copy)
@@ -41,8 +41,19 @@

-
+
+
+
+
+
+
+
+
+
+

+
+

That would be more intuitive to me, so unless anyone objects I'll do it.

Absolutely reasonable solution, please do. Thank you so much!

--
Alexey

Regards,
Tim

--

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

Re: [general] TLP transition - site has been moved, redirect in place

it's on it's way - it needs to propogate from minotaur, the staging 
server, to the production server.  it's automatic on some schedule I 
don't actually remember...



Spark Shen wrote:

Jimmy, Jing Lv 写道:

Geir Magnusson Jr. wrote:

We now have a site

http://harmony.apache.org/

and there's a redirect from

http://incubator.apache.org/harmony/

to there.

Tomorrow sometime we'll do the mail switch - that should be totally 
transparent - new lists will be created, sub lists will be copied, 
and mail going to old will be forwarded to new. I'll have the website 
setup before hand, do the switch, and then update the site.


Also, Friday night eastern we'll do the SVN switch to avoid catching 
people in the middle of work (ok, some will still be caught...). A 
simple svn switch will fix your local copy, so you shouldn't have to 
re-check anything out.


JIRA has been re-categorized, and I'll be asking for a solaris zone 
to play in.






I've found the new page, great! ;)

But still lacks of link on apahce from page.


And do we have to change the mail address 
"harmony-dev@incubator.apache.org" to

"[EMAIL PROTECTED]" or so tomorrow?

Re: [general] TLP transition - site has been moved, redirect in place

2006-11-15 Thread Jimmy, Jing Lv


Geir Magnusson Jr. wrote:

We now have a site

  http://harmony.apache.org/

and there's a redirect from

  http://incubator.apache.org/harmony/

to there.

Tomorrow sometime we'll do the mail switch - that should be totally 
transparent - new lists will be created, sub lists will be copied, and 
mail going to old will be forwarded to new.  I'll have the website setup 
before hand, do the switch, and then update the site.


Also, Friday night eastern we'll do the SVN switch to avoid catching 
people in the middle of work (ok, some will still be caught...).  A 
simple svn switch will fix your local copy, so you shouldn't have to 
re-check anything out.


JIRA has been re-categorized, and I'll be asking for a solaris zone to 
play in.




And hope it will be soon that Harmony appears in the list of "Apache 
Projects" in the homepage "http://www.apache.org/";  :)


--

Best Regards!

Jimmy, Jing Lv
China Software Development Lab, IBM

Re: [general] TLP transition - site has been moved, redirect in place




Jimmy, Jing Lv wrote:

Geir Magnusson Jr. wrote:

We now have a site

  http://harmony.apache.org/

and there's a redirect from

  http://incubator.apache.org/harmony/

to there.

Tomorrow sometime we'll do the mail switch - that should be totally 
transparent - new lists will be created, sub lists will be copied, and 
mail going to old will be forwarded to new.  I'll have the website 
setup before hand, do the switch, and then update the site.


Also, Friday night eastern we'll do the SVN switch to avoid catching 
people in the middle of work (ok, some will still be caught...).  A 
simple svn switch will fix your local copy, so you shouldn't have to 
re-check anything out.


JIRA has been re-categorized, and I'll be asking for a solaris zone to 
play in.






I've found the new page, great! ;)

And do we have to change the mail address 
"harmony-dev@incubator.apache.org" to

"[EMAIL PROTECTED]" or so tomorrow?


Yes - when we make the change, you'll start seeing mail coming from

   [EMAIL PROTECTED]

with reply-to set correctly.  You wont' have to resubscribe or anything.

We'll modify the site info on mail lists as appropriate at that time.

geir

Re: [drlvm] New regression: java.lang.ClassGenericsTest4


2006/11/16, Gregory Shimansky <[EMAIL PROTECTED]>:

Alexey Varlamov wrote:
> Err, what I found is really trivial bug. But it took quite a few time
> to discover - seems today was not my day :(
>
> Index: vm/vmcore/src/exception/exceptions_impl.cpp
> ===
> --- vm/vmcore/src/exception/exceptions_impl.cpp (revision 475132)
> +++ vm/vmcore/src/exception/exceptions_impl.cpp (working copy)
> @@ -281,7 +281,7 @@
>
> if (NULL != exception->exc_cause) {
> tmn_suspend_disable_recursive();
> -jthrowable exc_cause = oh_allocate_local_handle();
> +exc_cause = oh_allocate_local_handle();
> exc_cause->object = exception->exc_cause;
> tmn_suspend_enable_recursive();
> }

Cool. Could you please commit the fix?


Committed along with regression testcase at r475590.



> OK, we definitely need a regression test for this.
>
> 2006/11/15, Gregory Shimansky <[EMAIL PROTECTED]>:
>> Alexey Varlamov wrote:
>> > 2006/11/15, Alexey Varlamov <[EMAIL PROTECTED]>:
>> >> 2006/11/15, Gregory Shimansky <[EMAIL PROTECTED]>:
>> >> > Alexey Varlamov wrote:
>> >> > > The guilty change is the following, which effectively turns on
>> >> > > VM_LAZY_EXCEPTION support in exceptions_impl.cpp:
>> >> >
>> >> > Well this is a patch from HARMONY-2018 which doesn't hide the
>> fact that
>> >> > it enables lazy exceptions. Why shouldn't we enable them?
>> >
>> > Gregory,
>> >
>> > I've just re-read my posts and couldn't find anything critique or
>> > offending - please don't take regressions too personal. I'm sure we
>> > will be able to fix this one quite soon.
>>
>> I wasn't offended in any way. I was just thinking that you know some
>> secret knowledge that lazy exceptions do not work and thus enabling them
>> is wrong.
>>
>> --
>> Gregory
>>
>>
>


--
Gregory

Re: [general] TLP transition - site has been moved, redirect in place

2006-11-15 Thread Spark Shen


Jimmy, Jing Lv 写道:

Geir Magnusson Jr. wrote:

We now have a site

http://harmony.apache.org/

and there's a redirect from

http://incubator.apache.org/harmony/

to there.

Tomorrow sometime we'll do the mail switch - that should be totally 
transparent - new lists will be created, sub lists will be copied, 
and mail going to old will be forwarded to new. I'll have the website 
setup before hand, do the switch, and then update the site.


Also, Friday night eastern we'll do the SVN switch to avoid catching 
people in the middle of work (ok, some will still be caught...). A 
simple svn switch will fix your local copy, so you shouldn't have to 
re-check anything out.


JIRA has been re-categorized, and I'll be asking for a solaris zone 
to play in.






I've found the new page, great! ;)

But still lacks of link on apahce from page.


And do we have to change the mail address 
"harmony-dev@incubator.apache.org" to

"[EMAIL PROTECTED]" or so tomorrow?





--
Spark Shen
China Software Development Lab, IBM

Re: [general] TLP transition - site has been moved, redirect in place

2006-11-15 Thread Jimmy, Jing Lv


Geir Magnusson Jr. wrote:

We now have a site

  http://harmony.apache.org/

and there's a redirect from

  http://incubator.apache.org/harmony/

to there.

Tomorrow sometime we'll do the mail switch - that should be totally 
transparent - new lists will be created, sub lists will be copied, and 
mail going to old will be forwarded to new.  I'll have the website setup 
before hand, do the switch, and then update the site.


Also, Friday night eastern we'll do the SVN switch to avoid catching 
people in the middle of work (ok, some will still be caught...).  A 
simple svn switch will fix your local copy, so you shouldn't have to 
re-check anything out.


JIRA has been re-categorized, and I'll be asking for a solaris zone to 
play in.






I've found the new page, great! ;)

And do we have to change the mail address 
"harmony-dev@incubator.apache.org" to

"[EMAIL PROTECTED]" or so tomorrow?


--

Best Regards!

Jimmy, Jing Lv
China Software Development Lab, IBM

Re: [general] TLP transition - site has been moved, redirect in place


done.  will take a little while to propagate from stage to production...

geir


Geir Magnusson Jr. wrote:

I'm doing that as we, er, speak.

geir

Mikhail Loenko wrote:

Seems like Harmony disappeared from the incubator page
but hasn't yet appeared on the apache.org page

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

We now have a site

  http://harmony.apache.org/

and there's a redirect from

  http://incubator.apache.org/harmony/

to there.

Tomorrow sometime we'll do the mail switch - that should be totally
transparent - new lists will be created, sub lists will be copied, and
mail going to old will be forwarded to new.  I'll have the website setup
before hand, do the switch, and then update the site.

Also, Friday night eastern we'll do the SVN switch to avoid catching
people in the middle of work (ok, some will still be caught...).  A
simple svn switch will fix your local copy, so you shouldn't have to
re-check anything out.

JIRA has been re-categorized, and I'll be asking for a solaris zone to
play in.

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

2006-11-15 Thread Vladimir Ivanov

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

Vladimir Ivanov wrote:
> As part of solution for this issue the
> *HARMONY-2197* was
> created.
>
> I suggest using the separate exclude list for each platform. I hope in
this
> case the test enabling for the different platforms will be easy. Please,
> look at it.
>
> Any comments are welcome :)

Maybe a dumb question by why hard-code

Wouldn't it make more sense to look at the java.vm.name, maybe mapped to
a short form suitable as a directory name?

Actually, this property is defined before the test run by Ant's VM. In my
case it is

'Java HotSpot(TM) Client VM'.

As variant, the java from 'test.jre.home' may be run with "-version" option
and output may be parsed and mapped to some value. In this case all Harmony
VM should support this option and print different messages. Is it OK?

I suggest implementing version with hard coded vm name and than extend it by
auto-detecting capability.

Thanks, Vladimir

Regards,
Tim

--

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

Re: [drlvm][threading] Should hythread_monitor_init() aquire the monitor?

2006-11-15 Thread Evgueni Brevnov


I haven't published it yet...will file a JIRA soon...

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

ah. whew.

can you point me to that change you made?

geir

Evgueni Brevnov wrote:
> I'm not aware if classlib uses SIGUSR2. In this particular case
> classlib (to be more precise it is the portlib module) does sem_wait
> which is interrupted by TM's SIGUSR2 signal. I replaced "hysem_wait"
> with "while (hysem_wait() != 0) {}". It helped to pass all tests.
>
> Evgueni
>
> On 11/16/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
>> um... classlib uses SIGUSR2 as well?  Doesn't our thread manager use it?
>>
>> Evgueni Brevnov wrote:
>> > Hey,
>> >
>> > Seems like the pretty old problem shows itself again. I'm talking
>> > about SIGUSR2 signal :-(...Classlib's asynchronous signal reporter
>> > uses system semaphores for synchronization purposes...and hysem_wait
>> > is interrupted by the signal:
>> >
>> > (gdb) p perror("sym_wait error:")
>> > sym_wait error:: Interrupted system call
>> >
>> > Do we have good (universal) solution for such cases?
>> >
>> > Thanks
>> > Evgueni
>> >
>> > On 11/15/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
>> >>
>> >>
>> >> Gregory Shimansky wrote:
>> >> > Evgueni Brevnov wrote:
>> >> >> hmmm strange. The patch was tested on multi-processor system
>> >> >> running SUSE9. I will check if the patch misses something.
>> Anyway, we
>> >> >> need to wait with the patch submission until we 100% sure how
>> >> >> hythread_monitor_init should behave.
>> >> >>
>> >> >> Thanks
>> >> >> Evgueni
>> >> >>
>> >> >> On 11/11/06, Gregory Shimansky <[EMAIL PROTECTED]> wrote:
>> >> >>> On Friday 10 November 2006 17:45 Evgueni Brevnov wrote:
>> >> >>> > Hi,
>> >> >>> >
>> >> >>> > While investigating deadlock scenario which is described in
>> >> >>> > HARMONY-2006 I found out one interesting thing. It turned out
>> >> that DRL
>> >> >>> > implementation of hythread_monitor_init /
>> >> >>> > hythread_monitor_init_with_name initializes and acquires a
>> monitor.
>> >> >>> > Original spec reads: "Acquire and initialize a new monitor
>> from the
>> >> >>> > threading library" AFAIU that doesn't mean to lock the
>> >> monitor but
>> >> >>> > get it from the threading library. So the hythread_monitor_init
>> >> should
>> >> >>> > not lock the monitor.
>> >> >>> >
>> >> >>> > Could somebody comment on that?
>> >> >>>
>> >> >>> It might be that semantic is different on different platforms
>> >> which is
>> >> >>> probably even worse. Your patch in HARMONY-2149 breaks nearly
>> all of
>> >> >>> acceptance tests on Linux while everything on Windows works (ok I
>> >> >>> tested on
>> >> >>> laptop with 1 processor while Linux was a HT server, sometimes
>> it is
>> >> >>> important for threading).
>> >> >
>> >> > I've tried to investigate the problem but didn't find the end of it
>> >> yet.
>> >> > The bug seems to be ubuntu specific (shall we maybe call this
>> >> > distribution buggy and move on?).
>> >>
>> >> There is something odd about it, I'll admit...  Remember the EOMEM
>> bugs
>> >> I found in forking?
>> >>
>> >>
>> >> I didn't reproduce it on
>> >> > gentoo, all tests work just fine.
>> >> >
>> >> > The bug look likes this, on tests gc.Force, gc.LOS, gc.List, gc.NPE,
>> >> > gc.PhantomReferenceTest, gc.WeakReferenceTest,
>> >> stress.WeakHashMapTest VM
>> >> > segfaults. The stack looks like an infinite recursion of 4 stack
>> >> frames:
>> >> >
>> >> > #0  0xb6dcb814 in null_java_reference_handler (signum=11,
>> >> > info=0xb71a503c, context=0xb71a50bc) at
>> >> >
>> >>
>> /nfs/ims/proj/drl/mrt1/users/gregory/Harmony/enhanced/drlvm/trunk/vm/vmco
>> >> > re/src/util/linux/signals_ia32.cpp:443
>> >> > #1  
>> >> > #2  0xb6dcc20a in get_stack_addr () at
>> >> >
>> >>
>> /nfs/ims/proj/drl/mrt1/users/gregory/Harmony/enhanced/drlvm/trunk/vm/vmco
>> >> > re/src/util/linux/signals_ia32.cpp:293
>> >> > #3  0xb6dcb6cd in check_stack_overflow (info=0xb71a546c,
>> uc=0xb71a54ec)
>> >> > at
>> >> >
>> >>
>> /nfs/ims/proj/drl/mrt1/users/gregory/Harmony/enhanced/drlvm/trunk/vm/vmco
>> >> > re/src/util/linux/signals_ia32.cpp:399
>> >> > #4  0xb6dcb900 in null_java_reference_handler (signum=11,
>> >> > info=0xb71a546c, context=0xb71a54ec) at
>> >> >
>> >>
>> /nfs/ims/proj/drl/mrt1/users/gregory/Harmony/enhanced/drlvm/trunk/vm/vmco
>> >> > re/src/util/linux/signals_ia32.cpp:451
>> >> >
>> >> > and so on. The stack is very long. When I run VM with
>> -Xtrace:signals I
>> >> > get a very long log of messages that "NPE or SOE detected at
>> ...". The
>> >> > first time address always varies, but it appears to be memcpy.
>> The next
>> >> > addresses are always the same, they point to get_stack_addr
>> function.
>> >> >
>> >> > So I tried to find out why memcpy crashes in the first place. It
>> >> appears
>> >> > to be a struct copy called from jsig_handler hysig. The stack looks
>> >> like
>> >> > this (if I can trust gdb on ubuntu):
>> >> >
>> >> > #0  0xb7a9b9dc in memcpy () from /

Re: [general] TLP transition - site has been moved, redirect in place


I'm doing that as we, er, speak.

geir

Mikhail Loenko wrote:

Seems like Harmony disappeared from the incubator page
but hasn't yet appeared on the apache.org page

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

We now have a site

  http://harmony.apache.org/

and there's a redirect from

  http://incubator.apache.org/harmony/

to there.

Tomorrow sometime we'll do the mail switch - that should be totally
transparent - new lists will be created, sub lists will be copied, and
mail going to old will be forwarded to new.  I'll have the website setup
before hand, do the switch, and then update the site.

Also, Friday night eastern we'll do the SVN switch to avoid catching
people in the middle of work (ok, some will still be caught...).  A
simple svn switch will fix your local copy, so you shouldn't have to
re-check anything out.

JIRA has been re-categorized, and I'll be asking for a solaris zone to
play in.

Re: [drlvm][unit] 100% of class library tests pass




Pavel Ozhdikhin wrote:

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


Be sure to not miss anyone :)  This was a great community effort, with
everyone pitching in.

DRLVM is now a full peer  to J9 in Harmony testing.  :)  We still need
to use J9 (and another VM that happens to work with our classlibrary),
as a sanity check, but we should from now on use DRLVM in our CI testing
framework.



On the other hand, to make sure DRLVM has no regressions regarding
to Classlibrary Unit Tests it makes sense to add these tests to the "test"
target of DRLVM build.
What do people think?


Adding classlib unit tests to DRLVM test target?  No thanks :)

geir



Thanks,
Pavel




geir


Alexei Fedotov wrote:
> Oops, I've missed:
> * Andrew Zhang for reviewing class library patches and helpful
discussions
>
> On 11/16/06, Alexei Fedotov <[EMAIL PROTECTED]> wrote:
>>
>> Folks,
>> According to http://harmonytest.org, today 100% of class library unit
>> tests pass on DRLVM. Thank you all! It takes 44 days for the great
>> team we are. Thanks for your thoughtful, diligent work and deep
>> inspiration. Kudos to you for the following (and not limited to this):
>>
>> * Alexey Varlamov and Elena for driving the whole process
>> * Anton and Vladimir Ivanov for automating test runs
>> * Geir and Gregory for checking and committing related DRLVM patches
>> * Paulex, Tim, Nathan, Stepan and Mikhail Loenko for checking and
>> committing related class library patches
>> * Alexey Petrenko for becoming ICU expert and writing good JIRA issue
>> resolution guidelines
>> * Alexei Zakharov for resolving class library test issues
>> * Ilya Okomin, Denis Kishenko, Oleg Khaschansky and Alexey Ivanov for
>> fixing class library and tests* Ivan, Egor, Mikhail Fursov, Nikolay
>> Sidelnikov and Alexander Astapchuk for making execution engines work
>> * Tatiana and Maxim for filing JIRA issues about test failures
>> * Nikolay Kuznetsov for completing thread interruption handling and
>> reverting consequences of park/unpark integration
>> * Pavel Afremov for fixing exception handling
>> * Boris Kuznetsov for intelligent fixing of security tests
>> * Rana and Salikh for evaluating and discussing problems, reviewing
>> and trying DRLVM patches
>> * Pavel Pervov and Evgueni for help with DRLVM patches
>> * Artem for discovering and fixing weird Windows* behavior
>> * My wife for bringing hot tea to the computer during sleepless nights
>>
>> There are still open issues with reliability, multiprocessor and other
>> special configurations, so the page
>> http://wiki.apache.org/harmony/Unit_Tests_Pass_on_DRLVM  remains
>> active. But this shouldn't prevent us from including class library
>> testing into Harmony "zero regression" policy. What do you think?
>>
>> --
>> Thank you,
>> Alexei
>
>
>

Re: [general] TLP transition - site has been moved, redirect in place

2006-11-15 Thread Mikhail Loenko


Seems like Harmony disappeared from the incubator page
but hasn't yet appeared on the apache.org page

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

We now have a site

  http://harmony.apache.org/

and there's a redirect from

  http://incubator.apache.org/harmony/

to there.

Tomorrow sometime we'll do the mail switch - that should be totally
transparent - new lists will be created, sub lists will be copied, and
mail going to old will be forwarded to new.  I'll have the website setup
before hand, do the switch, and then update the site.

Also, Friday night eastern we'll do the SVN switch to avoid catching
people in the middle of work (ok, some will still be caught...).  A
simple svn switch will fix your local copy, so you shouldn't have to
re-check anything out.

JIRA has been re-categorized, and I'll be asking for a solaris zone to
play in.

Re: [drlvm][unit] 100% of class library tests pass

2006-11-15 Thread Pavel Ozhdikhin


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


Be sure to not miss anyone :)  This was a great community effort, with
everyone pitching in.

DRLVM is now a full peer  to J9 in Harmony testing.  :)  We still need
to use J9 (and another VM that happens to work with our classlibrary),
as a sanity check, but we should from now on use DRLVM in our CI testing
framework.



On the other hand, to make sure DRLVM has no regressions regarding
to Classlibrary Unit Tests it makes sense to add these tests to the "test"
target of DRLVM build.
What do people think?

Thanks,
Pavel




geir


Alexei Fedotov wrote:
> Oops, I've missed:
> * Andrew Zhang for reviewing class library patches and helpful
discussions
>
> On 11/16/06, Alexei Fedotov <[EMAIL PROTECTED]> wrote:
>>
>> Folks,
>> According to http://harmonytest.org, today 100% of class library unit
>> tests pass on DRLVM. Thank you all! It takes 44 days for the great
>> team we are. Thanks for your thoughtful, diligent work and deep
>> inspiration. Kudos to you for the following (and not limited to this):
>>
>> * Alexey Varlamov and Elena for driving the whole process
>> * Anton and Vladimir Ivanov for automating test runs
>> * Geir and Gregory for checking and committing related DRLVM patches
>> * Paulex, Tim, Nathan, Stepan and Mikhail Loenko for checking and
>> committing related class library patches
>> * Alexey Petrenko for becoming ICU expert and writing good JIRA issue
>> resolution guidelines
>> * Alexei Zakharov for resolving class library test issues
>> * Ilya Okomin, Denis Kishenko, Oleg Khaschansky and Alexey Ivanov for
>> fixing class library and tests* Ivan, Egor, Mikhail Fursov, Nikolay
>> Sidelnikov and Alexander Astapchuk for making execution engines work
>> * Tatiana and Maxim for filing JIRA issues about test failures
>> * Nikolay Kuznetsov for completing thread interruption handling and
>> reverting consequences of park/unpark integration
>> * Pavel Afremov for fixing exception handling
>> * Boris Kuznetsov for intelligent fixing of security tests
>> * Rana and Salikh for evaluating and discussing problems, reviewing
>> and trying DRLVM patches
>> * Pavel Pervov and Evgueni for help with DRLVM patches
>> * Artem for discovering and fixing weird Windows* behavior
>> * My wife for bringing hot tea to the computer during sleepless nights
>>
>> There are still open issues with reliability, multiprocessor and other
>> special configurations, so the page
>> http://wiki.apache.org/harmony/Unit_Tests_Pass_on_DRLVM  remains
>> active. But this shouldn't prevent us from including class library
>> testing into Harmony "zero regression" policy. What do you think?
>>
>> --
>> Thank you,
>> Alexei
>
>
>

[build-test] Moving from /enhanced to /standard

Does anyone care?  This way, we can be freer about who and what goes in 
there.


Since we don't ship the testing frameworks with anything, this is 
completely consistent with our IP policies and goals.


geir

[general] TLP transition - site has been moved, redirect in place


We now have a site

  http://harmony.apache.org/

and there's a redirect from

  http://incubator.apache.org/harmony/

to there.

Tomorrow sometime we'll do the mail switch - that should be totally 
transparent - new lists will be created, sub lists will be copied, and 
mail going to old will be forwarded to new.  I'll have the website setup 
before hand, do the switch, and then update the site.


Also, Friday night eastern we'll do the SVN switch to avoid catching 
people in the middle of work (ok, some will still be caught...).  A 
simple svn switch will fix your local copy, so you shouldn't have to 
re-check anything out.


JIRA has been re-categorized, and I'll be asking for a solaris zone to 
play in.

Re: [drlvm][threading] Should hythread_monitor_init() aquire the monitor?


ah. whew.

can you point me to that change you made?

geir

Evgueni Brevnov wrote:

I'm not aware if classlib uses SIGUSR2. In this particular case
classlib (to be more precise it is the portlib module) does sem_wait
which is interrupted by TM's SIGUSR2 signal. I replaced "hysem_wait"
with "while (hysem_wait() != 0) {}". It helped to pass all tests.

Evgueni

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

um... classlib uses SIGUSR2 as well?  Doesn't our thread manager use it?

Evgueni Brevnov wrote:
> Hey,
>
> Seems like the pretty old problem shows itself again. I'm talking
> about SIGUSR2 signal :-(...Classlib's asynchronous signal reporter
> uses system semaphores for synchronization purposes...and hysem_wait
> is interrupted by the signal:
>
> (gdb) p perror("sym_wait error:")
> sym_wait error:: Interrupted system call
>
> Do we have good (universal) solution for such cases?
>
> Thanks
> Evgueni
>
> On 11/15/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
>>
>>
>> Gregory Shimansky wrote:
>> > Evgueni Brevnov wrote:
>> >> hmmm strange. The patch was tested on multi-processor system
>> >> running SUSE9. I will check if the patch misses something. 
Anyway, we

>> >> need to wait with the patch submission until we 100% sure how
>> >> hythread_monitor_init should behave.
>> >>
>> >> Thanks
>> >> Evgueni
>> >>
>> >> On 11/11/06, Gregory Shimansky <[EMAIL PROTECTED]> wrote:
>> >>> On Friday 10 November 2006 17:45 Evgueni Brevnov wrote:
>> >>> > Hi,
>> >>> >
>> >>> > While investigating deadlock scenario which is described in
>> >>> > HARMONY-2006 I found out one interesting thing. It turned out
>> that DRL
>> >>> > implementation of hythread_monitor_init /
>> >>> > hythread_monitor_init_with_name initializes and acquires a 
monitor.
>> >>> > Original spec reads: "Acquire and initialize a new monitor 
from the

>> >>> > threading library" AFAIU that doesn't mean to lock the
>> monitor but
>> >>> > get it from the threading library. So the hythread_monitor_init
>> should
>> >>> > not lock the monitor.
>> >>> >
>> >>> > Could somebody comment on that?
>> >>>
>> >>> It might be that semantic is different on different platforms
>> which is
>> >>> probably even worse. Your patch in HARMONY-2149 breaks nearly 
all of

>> >>> acceptance tests on Linux while everything on Windows works (ok I
>> >>> tested on
>> >>> laptop with 1 processor while Linux was a HT server, sometimes 
it is

>> >>> important for threading).
>> >
>> > I've tried to investigate the problem but didn't find the end of it
>> yet.
>> > The bug seems to be ubuntu specific (shall we maybe call this
>> > distribution buggy and move on?).
>>
>> There is something odd about it, I'll admit...  Remember the EOMEM 
bugs

>> I found in forking?
>>
>>
>> I didn't reproduce it on
>> > gentoo, all tests work just fine.
>> >
>> > The bug look likes this, on tests gc.Force, gc.LOS, gc.List, gc.NPE,
>> > gc.PhantomReferenceTest, gc.WeakReferenceTest,
>> stress.WeakHashMapTest VM
>> > segfaults. The stack looks like an infinite recursion of 4 stack
>> frames:
>> >
>> > #0  0xb6dcb814 in null_java_reference_handler (signum=11,
>> > info=0xb71a503c, context=0xb71a50bc) at
>> >
>> 
/nfs/ims/proj/drl/mrt1/users/gregory/Harmony/enhanced/drlvm/trunk/vm/vmco

>> > re/src/util/linux/signals_ia32.cpp:443
>> > #1  
>> > #2  0xb6dcc20a in get_stack_addr () at
>> >
>> 
/nfs/ims/proj/drl/mrt1/users/gregory/Harmony/enhanced/drlvm/trunk/vm/vmco

>> > re/src/util/linux/signals_ia32.cpp:293
>> > #3  0xb6dcb6cd in check_stack_overflow (info=0xb71a546c, 
uc=0xb71a54ec)

>> > at
>> >
>> 
/nfs/ims/proj/drl/mrt1/users/gregory/Harmony/enhanced/drlvm/trunk/vm/vmco

>> > re/src/util/linux/signals_ia32.cpp:399
>> > #4  0xb6dcb900 in null_java_reference_handler (signum=11,
>> > info=0xb71a546c, context=0xb71a54ec) at
>> >
>> 
/nfs/ims/proj/drl/mrt1/users/gregory/Harmony/enhanced/drlvm/trunk/vm/vmco

>> > re/src/util/linux/signals_ia32.cpp:451
>> >
>> > and so on. The stack is very long. When I run VM with 
-Xtrace:signals I
>> > get a very long log of messages that "NPE or SOE detected at 
...". The
>> > first time address always varies, but it appears to be memcpy. 
The next
>> > addresses are always the same, they point to get_stack_addr 
function.

>> >
>> > So I tried to find out why memcpy crashes in the first place. It
>> appears
>> > to be a struct copy called from jsig_handler hysig. The stack looks
>> like
>> > this (if I can trust gdb on ubuntu):
>> >
>> > #0  0xb7a9b9dc in memcpy () from /lib/tls/i686/cmov/libc.so.6
>> > #1  0xb7ba0fa0 in jsig_handler (sig=-1215196204, siginfo=0x0, 
uc=0x0)

>> >  at hysigunix.c:169
>> > #2  0xb7f9ec8b in asynchSignalReporter (userData=0x0) at 
hysignal.c:971
>> > #3  0xb7baa8ef in thread_start_proc (thd=0x807a8e8, 
p_args=0x807a8d8)

>> > at
>> >
>> 
/nfs/ims/proj/drl/mrt1/users/gregory/Harmony/enhanced/drlvm/trunk/vm/thread/src/thread_native_basic.c:712 


>>
>> >
>> > #4  0xb7bb0ed4 in dummy_worker (opaque=0x

[classlib][general]find a more proper folder to put src-jars?

2006-11-15 Thread Jimmy, Jing Lv


Hi All,

Currently Harmony has pack all its source files into jars and put 
them in deploy\jdk\jre\lib\boot, e.g, luni-src.jar, nio-src.jar, etc(I 
don't know when this happens, however they are here now).
In most cases it does not disturb any one. However when I fix 
something in a package(luni) and try to debug in test, eclipse always 
lead me to the source files in the jar, not the file in the workspace I 
currently modify, this do take me into trouble until I find the reason 
and delete luni-src.jar.(My run environment in eclipse 3.2: take Harmony 
as JRE, put main-luni\bin and JRE-System Library[Harmony] into 
clasapath- bootstrap entries; put test-luni\bin, junit and support into 
classpath- User entries. It works well, only some trouble in debugging).
So IMHO Harmony may find another folder to put these src-jars, 
e.g., a "src" folder in deploy\jdk, which can be much clear, and will 
not make trouble in debugging any more.

Any suggestions/options? Thanks!


--

Best Regards!

Jimmy, Jing Lv
China Software Development Lab, IBM

Re: [drlvm][design] class unloading: Secondary root set

2006-11-15 Thread Robin Garner


Salikh Zakirov wrote:

Salikh Zakirov wrote:

I think you have missed one point: after retracing from secondary root
set once,
more classloaders may be found reachable, so this step needs to be
repeated until
convergence (to obtain the closure of reachability with additional
links Object->Class,
served through vtable marks).


Robin Garner wrote:

My proposal doesn't require steps (2) although VM->ClassLaoder
references are weak, and (5), because the trace from the vtable roots is
no different fromthe standard GC trace.


Okay, It looks like you found a way to avoid repetitive retracing from added 
roots,
and doing it in one step. If this is the case, I see how one can do
with just enumerating vtables, and without "unload list".

However, I do not understand how can correctness and completeness can be 
achieved
with just one retracing. Java allows for arbitrary implementation of 
user-defined
class loaders, including chained (think of java application server loaded as an
application to another application server). 


Because: By tracing from the live vtables, you are using the complete 
transitive closure mechanism of the GC.  Once a classloader becomes 
reachable, its pointers will be enumerated, all the classes that belong 
to it will be traced, and anything reachable from them will be live, 
including other classloaders.


Or am I missing something ?

Wait, I suppose if j.l.ClassLoaders can point to ordinary heap objects 
then they in turn could revive vtables which could revive classloaders - 
yes, you might need to iterate until no new vtables are revived.



You could alternately say that I'm simply refining your approach.  Yes,
they are structurally very similar - if you agree with my refinements,
feel free to merge them.


I will gladly merge your ideas as soon as I understand them,
but unfortunately I cannot see how can algorithm be correct without
transitive classloader revival.

It looks to me like one-step approach at deciding whether on unloading a classloader 
can produce incorrect results in the case of multiple chained classloaders.

For example, the test below will unload two of the classloaders incorrectly
at the first System.gc(). Note, that the test works correctly on Sun Hotspot:

$ java -showversion -verbose:gc UnloadTwice
java version "1.5.0_05"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_05-b05)
Java HotSpot(TM) Client VM (build 1.5.0_05-b05, mixed mode)
loading UnloadTwice.class
loading UnloadTwice.class
loading UnloadTwice.class
[Full GC 284K->131K(1984K), 0.0100915 secs]   it does not unload any 
classloader on the first GC
[Full GC[Unloading class UnloadTwice] it unloads all 3 
classloaders at the second GC
[Unloading class UnloadTwice]
[Unloading class UnloadTwice]
 131K->131K(1984K), 0.0092772 secs]
ok



import java.io.*;
import java.lang.reflect.*;

public class UnloadTwice extends ClassLoader {

static Object o;

public static void init() {
try {
UnloadTwice cl1 = new UnloadTwice();
ClassLoader scl = ClassLoader.getSystemClassLoader();
cl1.setParent(scl);
Class c1 = cl1.loadClass("UnloadTwice");
Method sp1 = c1.getMethod("setParent", ClassLoader.class);
ClassLoader cl2 = (ClassLoader)c1.newInstance();
sp1.invoke(cl2, new Object[] { scl });
Class c2 = cl2.loadClass("UnloadTwice");
Method sp2 = c2.getMethod("setParent", ClassLoader.class);
ClassLoader cl3 = (ClassLoader)c2.newInstance();
sp2.invoke(cl3, new Object[] { scl });
Class c3 = cl3.loadClass("UnloadTwice");
o = c3.newInstance();
} catch (Exception e) {
e.printStackTrace();
}
}

public static void main(String[] args) {
init();
System.gc(); // we still have third-level-chained object o live
o = null;
System.gc(); // now o is gone, class unloading should happen
System.out.println("ok");
}

ClassLoader parent;

public void setParent(ClassLoader parent) {
this.parent = parent;
}

public Class loadClass(String name) {
try {
if (!"UnloadTwice".equals(name)) return parent.loadClass(name);
System.out.println("loading " + name + ".class");
InputStream in = parent.getResourceAsStream(name + ".class");
byte bytes[] = new byte[in.available()];
in.read(bytes);
return defineClass(bytes, 0, bytes.length);
} catch (Exception e) { throw new RuntimeException(e); }
}
}





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

Re: [classlib][sql] SerialJavaObject constructor throws SerialException when the object is unserializable?

2006-11-15 Thread Andrew Zhang


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


I guess that Sun has implemented some behavior and some exception
could be thrown by that implementation.



Sorry for my late reply... Just back from travelling. :)

I don't quite get the point. What does "that implementation" mean? Is it
invoked in SerialJavaObject constructor?

Then they wrapped that exception

by SerialException and documented in the spec ;)

You might want to implement it without exception throwing and if we find
an
inconsistency later -- fix it



ya, I'd like to follow this way. If we find any problem, fix it then. :-)

If no one objects, I'll ignore static/transient check in the constructor.
Thanks!

Thanks,

Mikhail

2006/11/12, Andrew Zhang <[EMAIL PROTECTED]>:
> Hi folks,
>
> I'm confused by javax.sql.rowset.serial.SerialJavaObject spec. The spec
of
> SerialJavaObject constructor says "throws SerialException if the object
is
> found to be unserializable". It also mentions "Static or transient
fields
> cannot be serialized; an attempt to serialize them will result in a
> SerialException object being thrown. ". Does it mean to throw
> SerialException if the object doesn't implement Serializable or it
contains
> static/transient fields? I tried some tests[1], but SerialException is
never
> thrown. Am I missing something? Thank you in advance for your help!
>
> [1] SerialJavaObject constructor test case:
>  public void test_Constructor() throws Exception {
>  Object obj = new NonSerializableClass();
>  SerialJavaObject sjo = new SerialJavaObject(obj);
>  }
>
>  static class NonSerializableClass {
>  public static int i;
>  public static Thread t;
>  public transient String s;
>  NonSerializableClass() {
>
>  }
>  }
>
> --
> Best regards,
> Andrew Zhang
>
>





--
Best regards,
Andrew Zhang

Re: [Fwd: Re: [x86_64] problem running DRLVM]


My bad.  Sorry again.  Please ignore.

geir


Geir Magnusson Jr. wrote:

sorry

Gregory Shimansky wrote:

On Thursday 16 November 2006 02:28 Geir Magnusson Jr. wrote:

I think I said I was going to look at it...

An FYI - it's demotivating for people that say they'll do something to
have someone else race and beat them to it...

I'm not mad, but wanted to let you know.


I considered these to be two separate problems. One is that launcher 
crashes in case of no arguments, another is when drlvm throws 
UnsatisfiedLinkError which means that it is actually running, in which 
case newPathToAdd should be initialized in the launcher (but is 
probably initialized in a wrong way).


I did not try to fix the second problem, I don't even know how to 
reproduce it because for me drlvm doesn't give these problems and I 
don't have gump installed to try to see what's happening when it is 
running in gump environment.



 Original Message 
Subject: Re: [x86_64] problem running DRLVM
Date: Thu, 16 Nov 2006 02:16:10 +0300
From: Gregory Shimansky <>
Reply-To: harmony-dev@incubator.apache.org
To: harmony-dev@incubator.apache.org
References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]> <[EMAIL PROTECTED]>

Geir Magnusson Jr. wrote:

Stefano Mazzocchi wrote:

Gregory Shimansky wrote:

Stefano Mazzocchi wrote:

I've tried to run the VM launcher and I get:

[EMAIL PROTECTED]
~/src/harmony/drlvm/build/lnx_em64t_gcc_debug/deploy/jre/bin $ 
./java

Harmony Java launcher
Apache Harmony Launcher : (c) Copyright 1991, 2006 The Apache 
Software

Foundation or its licensors, as applicable.
java [-vm:vmdll -vmdir:dir -D... [-X...]] [args]
*** glibc detected *** free(): invalid pointer: 
0x7fe8aff0 ***

Aborted

any idea?
I've reproduced the crash. It is not exactly drlvm fault. It looks 
like

harmony launcher crashes when it is ran without arguments. If you run
it with some arguments it should work, at least it does work for me.

yeah, it works. 

you mean I'm the first one to run the launcher without parameters...
bizarre.

On 64-bit? :)  Probably.

I fixed the crash at 475483. It happened because of an uninitialized
variable which happened to be non-NULL on x86_64.

Re: svn commit: r475473 - /incubator/harmony/enhanced/drlvm/trunk/vm/tests/smoke/StackTest.java




Gregory Shimansky wrote:

Geir Magnusson Jr. wrote:



Gregory Shimansky wrote:

Geir Magnusson Jr. wrote:

I still think that this is bogus

What if SOE machinery is broken?

 >

We need to make this a predictable test.


Well I don't feel strongly to either side. We can use ulimit -s in 
build.sh script which runs tests (maybe only in case it runs tests).


Meaning you are just as happy if it's *not* a predictable test?


Not very [1]. I just wanted to make this test to pass in a predictable 
way on "normal" distributions which do have stack limit for 
applications, and at least not to misbehave on distributions that don't 
have this default setting.


I think that we learned that depending on the default is dangerous.

Try "ulimit -s unlimited" :)




The fix is still quite questionable either way. In theory an optimizing 
JIT may inline all of the 1000 recursions into adding 1000 to 
the depth with no calls to function, which will produce no SOE.


So maybe we should ensure that we can do something that can't be 
optimized away...





I worry about two things

1. Ulimit is not a shell command, it is a bash setting. Will ulimit 
-s called inside of build.sh affect commands running from it, e.g. 
ant test? I don't want to lose SuSE server again tonight because I 
don't have access to its console, so it will be rebooted only in the 
morning :)


I dunno.  I'll be happy to test on a real^H^H^H^H another distro



2. What if the limit on the system is lower than 8192? Ulimit -s 
allows only lower than current setting in a session (otherwise any 
user could increase their limit to any value). So if it is set to 
something like 4096 the ulimit -s 8192 command will cause an error.


And the test will still work, right?


[1] http://article.gmane.org/gmane.comp.java.harmony.devel/18773
http://article.gmane.org/gmane.comp.java.harmony.devel/18841

Re: [Fwd: Re: [x86_64] problem running DRLVM]


sorry

Gregory Shimansky wrote:

On Thursday 16 November 2006 02:28 Geir Magnusson Jr. wrote:

I think I said I was going to look at it...

An FYI - it's demotivating for people that say they'll do something to
have someone else race and beat them to it...

I'm not mad, but wanted to let you know.


I considered these to be two separate problems. One is that launcher crashes 
in case of no arguments, another is when drlvm throws UnsatisfiedLinkError 
which means that it is actually running, in which case newPathToAdd should be 
initialized in the launcher (but is probably initialized in a wrong way).


I did not try to fix the second problem, I don't even know how to reproduce it 
because for me drlvm doesn't give these problems and I don't have gump 
installed to try to see what's happening when it is running in gump 
environment.



 Original Message 
Subject: Re: [x86_64] problem running DRLVM
Date: Thu, 16 Nov 2006 02:16:10 +0300
From: Gregory Shimansky <>
Reply-To: harmony-dev@incubator.apache.org
To: harmony-dev@incubator.apache.org
References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]> <[EMAIL PROTECTED]>

Geir Magnusson Jr. wrote:

Stefano Mazzocchi wrote:

Gregory Shimansky wrote:

Stefano Mazzocchi wrote:

I've tried to run the VM launcher and I get:

[EMAIL PROTECTED]
~/src/harmony/drlvm/build/lnx_em64t_gcc_debug/deploy/jre/bin $ ./java
Harmony Java launcher
Apache Harmony Launcher : (c) Copyright 1991, 2006 The Apache Software
Foundation or its licensors, as applicable.
java [-vm:vmdll -vmdir:dir -D... [-X...]] [args]
*** glibc detected *** free(): invalid pointer: 0x7fe8aff0 ***
Aborted

any idea?

I've reproduced the crash. It is not exactly drlvm fault. It looks like
harmony launcher crashes when it is ran without arguments. If you run
it with some arguments it should work, at least it does work for me.

yeah, it works. 

you mean I'm the first one to run the launcher without parameters...
bizarre.

On 64-bit? :)  Probably.

I fixed the crash at 475483. It happened because of an uninitialized
variable which happened to be non-NULL on x86_64.

Re: [Fwd: Re: [x86_64] problem running DRLVM]




Gregory Shimansky wrote:

On Thursday 16 November 2006 02:28 Geir Magnusson Jr. wrote:

I think I said I was going to look at it...

An FYI - it's demotivating for people that say they'll do something to
have someone else race and beat them to it...

I'm not mad, but wanted to let you know.


I considered these to be two separate problems. One is that launcher crashes 
in case of no arguments, another is when drlvm throws UnsatisfiedLinkError 
which means that it is actually running, in which case newPathToAdd should be 
initialized in the launcher (but is probably initialized in a wrong way).


Ah



I did not try to fix the second problem, I don't even know how to reproduce it 
because for me drlvm doesn't give these problems and I don't have gump 
installed to try to see what's happening when it is running in gump 
environment.



 Original Message 
Subject: Re: [x86_64] problem running DRLVM
Date: Thu, 16 Nov 2006 02:16:10 +0300
From: Gregory Shimansky <>
Reply-To: harmony-dev@incubator.apache.org
To: harmony-dev@incubator.apache.org
References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]> <[EMAIL PROTECTED]>

Geir Magnusson Jr. wrote:

Stefano Mazzocchi wrote:

Gregory Shimansky wrote:

Stefano Mazzocchi wrote:

I've tried to run the VM launcher and I get:

[EMAIL PROTECTED]
~/src/harmony/drlvm/build/lnx_em64t_gcc_debug/deploy/jre/bin $ ./java
Harmony Java launcher
Apache Harmony Launcher : (c) Copyright 1991, 2006 The Apache Software
Foundation or its licensors, as applicable.
java [-vm:vmdll -vmdir:dir -D... [-X...]] [args]
*** glibc detected *** free(): invalid pointer: 0x7fe8aff0 ***
Aborted

any idea?

I've reproduced the crash. It is not exactly drlvm fault. It looks like
harmony launcher crashes when it is ran without arguments. If you run
it with some arguments it should work, at least it does work for me.

yeah, it works. 

you mean I'm the first one to run the launcher without parameters...
bizarre.

On 64-bit? :)  Probably.

I fixed the crash at 475483. It happened because of an uninitialized
variable which happened to be non-NULL on x86_64.

Re: svn commit: r475473 - /incubator/harmony/enhanced/drlvm/trunk/vm/tests/smoke/StackTest.java


Geir Magnusson Jr. wrote:



Gregory Shimansky wrote:

Geir Magnusson Jr. wrote:

I still think that this is bogus

What if SOE machinery is broken?

 >

We need to make this a predictable test.


Well I don't feel strongly to either side. We can use ulimit -s in 
build.sh script which runs tests (maybe only in case it runs tests).


Meaning you are just as happy if it's *not* a predictable test?


Not very [1]. I just wanted to make this test to pass in a predictable 
way on "normal" distributions which do have stack limit for 
applications, and at least not to misbehave on distributions that don't 
have this default setting.


The fix is still quite questionable either way. In theory an optimizing 
JIT may inline all of the 1000 recursions into adding 1000 to 
the depth with no calls to function, which will produce no SOE.



I worry about two things

1. Ulimit is not a shell command, it is a bash setting. Will ulimit -s 
called inside of build.sh affect commands running from it, e.g. ant 
test? I don't want to lose SuSE server again tonight because I don't 
have access to its console, so it will be rebooted only in the morning :)


I dunno.  I'll be happy to test on a real^H^H^H^H another distro



2. What if the limit on the system is lower than 8192? Ulimit -s 
allows only lower than current setting in a session (otherwise any 
user could increase their limit to any value). So if it is set to 
something like 4096 the ulimit -s 8192 command will cause an error.


And the test will still work, right?


[1] http://article.gmane.org/gmane.comp.java.harmony.devel/18773
http://article.gmane.org/gmane.comp.java.harmony.devel/18841

--
Gregory

Re: [drlvm] New regression: java.lang.ClassGenericsTest4

2006-11-15 Thread Rana Dasgupta

There is something that I am missing here. For example on my Linux build,
running kernel tests with .jet, I see some java.lang tests failures eg.,
SystemExtensionTest fails for me, and in the console summary report I get
"Kernel tests failed using Jitrino.Jet blah blah", but when I go browse
reports/jitrino.jet/html/index.html, there are no errors!

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

Rana Dasgupta wrote:
> I think that a problem with the junit tests is that some failures spit
out
> to the console, but show up in the test run results as passed. I find
this
> very confusing. So unless you are watching all the time, you can miss
them.

We can't depend on this - they have to mechanically resolve as passed or
failed.

Can you give me an example of a test?

Re: [drlvm][unit] 100% of class library tests pass

Alexei Fedotov wrote:
> Folks,
> According to http://harmonytest.org, today 100% of class library unit tests
> pass on DRLVM. Thank you all! It takes 44 days for the great team we
> are. Thanks for your thoughtful, diligent work and deep inspiration.



-- 
Stefano.

Re: [drlvm][unit] 100% of class library tests pass

Be sure to not miss anyone :)  This was a great community effort, with 
everyone pitching in.


DRLVM is now a full peer  to J9 in Harmony testing.  :)  We still need 
to use J9 (and another VM that happens to work with our classlibrary), 
as a sanity check, but we should from now on use DRLVM in our CI testing 
framework.


geir


Alexei Fedotov wrote:

Oops, I've missed:
* Andrew Zhang for reviewing class library patches and helpful discussions

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


Folks,
According to http://harmonytest.org, today 100% of class library unit 
tests pass on DRLVM. Thank you all! It takes 44 days for the great 
team we are. Thanks for your thoughtful, diligent work and deep 
inspiration. Kudos to you for the following (and not limited to this):


* Alexey Varlamov and Elena for driving the whole process
* Anton and Vladimir Ivanov for automating test runs
* Geir and Gregory for checking and committing related DRLVM patches
* Paulex, Tim, Nathan, Stepan and Mikhail Loenko for checking and 
committing related class library patches
* Alexey Petrenko for becoming ICU expert and writing good JIRA issue 
resolution guidelines

* Alexei Zakharov for resolving class library test issues
* Ilya Okomin, Denis Kishenko, Oleg Khaschansky and Alexey Ivanov for 
fixing class library and tests* Ivan, Egor, Mikhail Fursov, Nikolay 
Sidelnikov and Alexander Astapchuk for making execution engines work

* Tatiana and Maxim for filing JIRA issues about test failures
* Nikolay Kuznetsov for completing thread interruption handling and 
reverting consequences of park/unpark integration

* Pavel Afremov for fixing exception handling
* Boris Kuznetsov for intelligent fixing of security tests
* Rana and Salikh for evaluating and discussing problems, reviewing 
and trying DRLVM patches

* Pavel Pervov and Evgueni for help with DRLVM patches
* Artem for discovering and fixing weird Windows* behavior
* My wife for bringing hot tea to the computer during sleepless nights

There are still open issues with reliability, multiprocessor and other 
special configurations, so the page 
http://wiki.apache.org/harmony/Unit_Tests_Pass_on_DRLVM  remains 
active. But this shouldn't prevent us from including class library 
testing into Harmony "zero regression" policy. What do you think?


--
Thank you,
Alexei

Re: svn commit: r475473 - /incubator/harmony/enhanced/drlvm/trunk/vm/tests/smoke/StackTest.java




Gregory Shimansky wrote:

Geir Magnusson Jr. wrote:

I still think that this is bogus

What if SOE machinery is broken?

 >

We need to make this a predictable test.


Well I don't feel strongly to either side. We can use ulimit -s in 
build.sh script which runs tests (maybe only in case it runs tests).


Meaning you are just as happy if it's *not* a predictable test?



I worry about two things

1. Ulimit is not a shell command, it is a bash setting. Will ulimit -s 
called inside of build.sh affect commands running from it, e.g. ant 
test? I don't want to lose SuSE server again tonight because I don't 
have access to its console, so it will be rebooted only in the morning :)


I dunno.  I'll be happy to test on a real^H^H^H^H another distro



2. What if the limit on the system is lower than 8192? Ulimit -s allows 
only lower than current setting in a session (otherwise any user could 
increase their limit to any value). So if it is set to something like 
4096 the ulimit -s 8192 command will cause an error.


And the test will still work, right?


geir




[EMAIL PROTECTED] wrote:

Author: gshimansky
Date: Wed Nov 15 14:38:55 2006
New Revision: 475473

URL: http://svn.apache.org/viewvc?view=rev&rev=475473
Log:
Allow the test to pass even when no SOE happens in max_depth recursions


Modified:
incubator/harmony/enhanced/drlvm/trunk/vm/tests/smoke/StackTest.java

Modified: 
incubator/harmony/enhanced/drlvm/trunk/vm/tests/smoke/StackTest.java
URL: 
http://svn.apache.org/viewvc/incubator/harmony/enhanced/drlvm/trunk/vm/tests/smoke/StackTest.java?view=diff&rev=475473&r1=475472&r2=475473 

== 

--- 
incubator/harmony/enhanced/drlvm/trunk/vm/tests/smoke/StackTest.java 
(original)
+++ 
incubator/harmony/enhanced/drlvm/trunk/vm/tests/smoke/StackTest.java 
Wed Nov 15 14:38:55 2006

@@ -29,11 +29,10 @@
 public static void main(String[] args) {
 try {
 func();
-System.out.println("FAIL");
 } catch (StackOverflowError soe) {
 System.out.println("PASS : First SOE depth = " + depth + 
" : " + soe);

 return;
 }
-System.out.println("FAIL: no SOE in " + max_depth + " 
iterations");
+System.out.println("PASS: no SOE in " + max_depth + " 
iterations");

 }
 }

Re: [x86_64] problem running DRLVM


Geir Magnusson Jr. wrote:



Stefano Mazzocchi wrote:

Gregory Shimansky wrote:

Stefano Mazzocchi wrote:

I've tried to run the VM launcher and I get:

[EMAIL PROTECTED]
~/src/harmony/drlvm/build/lnx_em64t_gcc_debug/deploy/jre/bin $ ./java
Harmony Java launcher
Apache Harmony Launcher : (c) Copyright 1991, 2006 The Apache Software
Foundation or its licensors, as applicable.
java [-vm:vmdll -vmdir:dir -D... [-X...]] [args]
*** glibc detected *** free(): invalid pointer: 0x7fe8aff0 ***
Aborted

any idea?

I've reproduced the crash. It is not exactly drlvm fault. It looks like
harmony launcher crashes when it is ran without arguments. If you run it
with some arguments it should work, at least it does work for me.


yeah, it works. 

you mean I'm the first one to run the launcher without parameters...
bizarre.


On 64-bit? :)  Probably.


I fixed the crash at 475483. It happened because of an uninitialized 
variable which happened to be non-NULL on x86_64.


--
Gregory

Re: [drlvm][unit] 100% of class library tests pass




Alexei Fedotov wrote:

Folks,
According to http://harmonytest.org, today 100% of class library unit tests
pass on DRLVM. 


Yay!



There are still open issues with reliability, multiprocessor and other
special configurations, so the page
http://wiki.apache.org/harmony/Unit_Tests_Pass_on_DRLVM  remains active. 
But

this shouldn't prevent us from including class library testing into Harmony
"zero regression" policy. What do you think?



+1

geir

Re: [drlvm][unit] 100% of class library tests pass

2006-11-15 Thread Alexei Fedotov


Oops, I've missed:
* Andrew Zhang for reviewing class library patches and helpful discussions

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


Folks,
According to http://harmonytest.org, today 100% of class library unit tests 
pass on DRLVM. Thank you all! It takes 44 days for the great team we are. 
Thanks for your thoughtful, diligent work and deep inspiration. Kudos to you 
for the following (and not limited to this):

* Alexey Varlamov and Elena for driving the whole process
* Anton and Vladimir Ivanov for automating test runs
* Geir and Gregory for checking and committing related DRLVM patches
* Paulex, Tim, Nathan, Stepan and Mikhail Loenko for checking and committing 
related class library patches
* Alexey Petrenko for becoming ICU expert and writing good JIRA issue 
resolution guidelines
* Alexei Zakharov for resolving class library test issues
* Ilya Okomin, Denis Kishenko, Oleg Khaschansky and Alexey Ivanov for fixing 
class library and tests* Ivan, Egor, Mikhail Fursov, Nikolay Sidelnikov and 
Alexander Astapchuk for making execution engines work
* Tatiana and Maxim for filing JIRA issues about test failures
* Nikolay Kuznetsov for completing thread interruption handling and reverting 
consequences of park/unpark integration
* Pavel Afremov for fixing exception handling
* Boris Kuznetsov for intelligent fixing of security tests
* Rana and Salikh for evaluating and discussing problems, reviewing and trying 
DRLVM patches
* Pavel Pervov and Evgueni for help with DRLVM patches
* Artem for discovering and fixing weird Windows* behavior
* My wife for bringing hot tea to the computer during sleepless nights

There are still open issues with reliability, multiprocessor and other special 
configurations, so the page http://wiki.apache.org/harmony/Unit_Tests_Pass_on_DRLVM  
remains active. But this shouldn't prevent us from including class library testing into 
Harmony "zero regression" policy. What do you think?

--
Thank you,
Alexei




--
Thank you,
Alexei

Re: svn commit: r475473 - /incubator/harmony/enhanced/drlvm/trunk/vm/tests/smoke/StackTest.java


Geir Magnusson Jr. wrote:

I still think that this is bogus

What if SOE machinery is broken?

>

We need to make this a predictable test.


Well I don't feel strongly to either side. We can use ulimit -s in 
build.sh script which runs tests (maybe only in case it runs tests).


I worry about two things

1. Ulimit is not a shell command, it is a bash setting. Will ulimit -s 
called inside of build.sh affect commands running from it, e.g. ant 
test? I don't want to lose SuSE server again tonight because I don't 
have access to its console, so it will be rebooted only in the morning :)


2. What if the limit on the system is lower than 8192? Ulimit -s allows 
only lower than current setting in a session (otherwise any user could 
increase their limit to any value). So if it is set to something like 
4096 the ulimit -s 8192 command will cause an error.



[EMAIL PROTECTED] wrote:

Author: gshimansky
Date: Wed Nov 15 14:38:55 2006
New Revision: 475473

URL: http://svn.apache.org/viewvc?view=rev&rev=475473
Log:
Allow the test to pass even when no SOE happens in max_depth recursions


Modified:
incubator/harmony/enhanced/drlvm/trunk/vm/tests/smoke/StackTest.java

Modified: 
incubator/harmony/enhanced/drlvm/trunk/vm/tests/smoke/StackTest.java
URL: 
http://svn.apache.org/viewvc/incubator/harmony/enhanced/drlvm/trunk/vm/tests/smoke/StackTest.java?view=diff&rev=475473&r1=475472&r2=475473 

== 

--- 
incubator/harmony/enhanced/drlvm/trunk/vm/tests/smoke/StackTest.java 
(original)
+++ 
incubator/harmony/enhanced/drlvm/trunk/vm/tests/smoke/StackTest.java 
Wed Nov 15 14:38:55 2006

@@ -29,11 +29,10 @@
 public static void main(String[] args) {
 try {
 func();
-System.out.println("FAIL");
 } catch (StackOverflowError soe) {
 System.out.println("PASS : First SOE depth = " + depth + 
" : " + soe);

 return;
 }
-System.out.println("FAIL: no SOE in " + max_depth + " 
iterations");
+System.out.println("PASS: no SOE in " + max_depth + " 
iterations");

 }
 }








--
Gregory

[drlvm][unit] 100% of class library tests pass

2006-11-15 Thread Alexei Fedotov


Folks,
According to http://harmonytest.org, today 100% of class library unit tests
pass on DRLVM. Thank you all! It takes 44 days for the great team we
are. Thanks for your thoughtful, diligent work and deep inspiration. Kudos
to you for the following (and not limited to this):

* Alexey Varlamov and Elena for driving the whole process
* Anton and Vladimir Ivanov for automating test runs
* Geir and Gregory for checking and committing related DRLVM patches
* Paulex, Tim, Nathan, Stepan and Mikhail Loenko for checking and committing
related class library patches
* Alexey Petrenko for becoming ICU expert and writing good JIRA issue
resolution guidelines
* Alexei Zakharov for resolving class library test issues * Ilya Okomin,
Denis Kishenko, Oleg Khaschansky and Alexey Ivanov for fixing class library
and tests
* Ivan, Egor, Mikhail Fursov, Nikolay Sidelnikov and Alexander Astapchuk for
making execution engines work
* Tatiana and Maxim for filing JIRA issues about test failures
* Nikolay Kuznetsov for completing thread interruption handling and
reverting consequences of park/unpark integration
* Pavel Afremov for fixing exception handling
* Boris Kuznetsov for intelligent fixing of security tests
* Rana and Salikh for evaluating and discussing problems, reviewing and
trying DRLVM patches
* Pavel Pervov and Evgueni for help with DRLVM patches
* Artem for discovering and fixing weird Windows* behavior
* My wife for bringing hot tea to the computer during sleepless nights

There are still open issues with reliability, multiprocessor and other
special configurations, so the page
http://wiki.apache.org/harmony/Unit_Tests_Pass_on_DRLVM  remains active. But
this shouldn't prevent us from including class library testing into Harmony
"zero regression" policy. What do you think?

--
Thank you,
Alexei

Re: svn commit: r475473 - /incubator/harmony/enhanced/drlvm/trunk/vm/tests/smoke/StackTest.java


I still think that this is bogus

What if SOE machinery is broken?

We need to make this a predictable test.

[EMAIL PROTECTED] wrote:

Author: gshimansky
Date: Wed Nov 15 14:38:55 2006
New Revision: 475473

URL: http://svn.apache.org/viewvc?view=rev&rev=475473
Log:
Allow the test to pass even when no SOE happens in max_depth recursions


Modified:
incubator/harmony/enhanced/drlvm/trunk/vm/tests/smoke/StackTest.java

Modified: incubator/harmony/enhanced/drlvm/trunk/vm/tests/smoke/StackTest.java
URL: 
http://svn.apache.org/viewvc/incubator/harmony/enhanced/drlvm/trunk/vm/tests/smoke/StackTest.java?view=diff&rev=475473&r1=475472&r2=475473
==
--- incubator/harmony/enhanced/drlvm/trunk/vm/tests/smoke/StackTest.java 
(original)
+++ incubator/harmony/enhanced/drlvm/trunk/vm/tests/smoke/StackTest.java Wed 
Nov 15 14:38:55 2006
@@ -29,11 +29,10 @@
 public static void main(String[] args) {
 try {
 func();
-System.out.println("FAIL");
 } catch (StackOverflowError soe) {
 System.out.println("PASS : First SOE depth = " + depth + " : " + 
soe);
 return;
 }
-System.out.println("FAIL: no SOE in " + max_depth + " iterations");
+System.out.println("PASS: no SOE in " + max_depth + " iterations");
 }
 }

Re: svn commit: r475458 - /incubator/harmony/enhanced/admin/README.txt


maybe we should put this in our regular NOTICE file?

[EMAIL PROTECTED] wrote:

Author: tellison
Date: Wed Nov 15 14:11:04 2006
New Revision: 475458

URL: http://svn.apache.org/viewvc?view=rev&rev=475458
Log:
Add readme with explanation of bis export file.

Added:
incubator/harmony/enhanced/admin/README.txt   (with props)

Added: incubator/harmony/enhanced/admin/README.txt
URL: 
http://svn.apache.org/viewvc/incubator/harmony/enhanced/admin/README.txt?view=auto&rev=475458
==
--- incubator/harmony/enhanced/admin/README.txt (added)
+++ incubator/harmony/enhanced/admin/README.txt Wed Nov 15 14:11:04 2006
@@ -0,0 +1,13 @@
+Apache Harmony Export Notification
+==
+
+The file "bis_HARMONY.rdf" in this directory should not be
+moved/renamed since it is referenced directly from the ASF
+export registry.
+
+Details of the export requirements are given here
+http://www.apache.org/dev/crypto.html
+
+The e-mail sent to the US Government is archived here
+
http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200611.mbox/raw/[EMAIL
 PROTECTED]
+

Propchange: incubator/harmony/enhanced/admin/README.txt
--
svn:eol-style = native

Re: [drlvm][em64t] build fails




Gregory Shimansky wrote:

Geir Magnusson Jr. wrote:



Gregory Shimansky wrote:


-Xss is the lower stack limit, it doesn't specify the maximum stack 
size, doesn't it?


What does "lower stack limit" mean? :)  I think that it's the size of 
the stack, max.


I thought it is a starting stack size, like -Xms for heap size. Now that 
I searched the web it appears that it is the maximum indeed.


"0" is minimum stack size.




I think all you need to do then is set the stack size :

   ulimit -s 8192

or something.  We should probably do this before each run on linux so 
that things are well defined and reproducible.


I think 64-bit SuSE9 is just the only weird distribution which doesn't 
have this limit. In 10th version they fixed this. So ulimit -s is not 
necessary in most cases.


But harmless.  And it makes the test predicable across platforms.  and 
if the StackSize test is forked, we can make it small to make it quick...




I'd still like to have a recursion limit in StackTest but Rana has 
convinced me that no SOE shouldn't mean that test has failed. I'll patch 
it now.




I agree that your fix is utterly bogus :) but we want to test SOE 
machinery, so I think that we should set the ulimit to ensure an 
environment in which the SOE will happen if DRLVM is working right. 
Therefore, we need to set things up such that not getting an SOE is 
indeed a failure.


geir

Re: [drlvm][em64t] build fails




Pavel Afremov wrote:



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


How could there be no limit to stack size??

 
Limit is there but it's too large, like 2 in power 46.
 


Is there a way the test framework could set this?  Does DRLVM support
-Xss yet?

 


No, DRLVM doesn't support –Xss flag. …yet.

I have a question: Is Xss flag significant feature or there are more 
important things?


Probably more important things... but... I would think that -Xss would 
be pretty simple?



I think that the solution is (as I noted in another message) is to 
somehow set the process stack size w/ ulimit


geir



 


Pavel Afremov

Re: [drlvm][em64t] build fails


Geir Magnusson Jr. wrote:



Gregory Shimansky wrote:

Geir Magnusson Jr. wrote:



Gregory Shimansky wrote:

Pavel Afremov wrote:

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


So what is the point to have a test which would pass either way? 
Check

that it doesn't crash the VM, is it the only purpose for it?

I think yes. It should check that test doesn't crash VM if stack 
size isn't

enough.


But we wouldn't know that SOE has happened or not if test passes 
even when SOE was not thrown.


It seems like SuSE9 is the only existing distribution which doesn't 
limit stack size on 64-bit architectures. SuSE10 has this limit and 
Gentoo has it too. Should we care that this test fails on SuSE9 when 
it passes on all other platforms and SOE is known to be thrown?


How could there be no limit to stack size??


Well there is no stack limit imposed by the OS on SuSE9. Maybe it is 
specific to this version because on SuSE10 there is a normal limit of 
8Mb. But when I run ulimit -a on SuSE9 I see this:


core file size(blocks, -c) unlimited
data seg size (kbytes, -d) unlimited
file size (blocks, -f) unlimited
max locked memory (kbytes, -l) unlimited
max memory size   (kbytes, -m) unlimited
open files(-n) 4096
pipe size  (512 bytes, -p) 8
stack size(kbytes, -s) unlimited
cpu time (seconds, -t) unlimited
max user processes(-u) 40960
virtual memory(kbytes, -v) unlimited

So the stack may grow up to the virtual address range which is pretty 
huge on 64-bit platforms. No physical memory is enough to allocate 
stack this big, so the system starts swapping nonstop. Maybe OOM linux 
killer will kill this process after some time, maybe not.


Is there a way the test framework could set this?  Does DRLVM support 
-Xss yet?


-Xss is the lower stack limit, it doesn't specify the maximum stack 
size, doesn't it?


What does "lower stack limit" mean? :)  I think that it's the size of 
the stack, max.


I thought it is a starting stack size, like -Xms for heap size. Now that 
I searched the web it appears that it is the maximum indeed.



I think all you need to do then is set the stack size :

   ulimit -s 8192

or something.  We should probably do this before each run on linux so 
that things are well defined and reproducible.


I think 64-bit SuSE9 is just the only weird distribution which doesn't 
have this limit. In 10th version they fixed this. So ulimit -s is not 
necessary in most cases.


I'd still like to have a recursion limit in StackTest but Rana has 
convinced me that no SOE shouldn't mean that test has failed. I'll patch 
it now.


--
Gregory

Re: [jira] Patch available setting




Egor Pasko wrote:

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

I thought we had it configured that when a JIRA is modified, the
reporter is notified directly...  I'm not sure that really helps
though. I wonder if we should just open things up a bit and let any
user modify a JIRA and see what happens.


reporters are notified, that's right

But what if =? Then someone still needs to
review. Sometimes, reporters are not familiar with the components
fixed, someone needs to pick up a review in this case too.


That's why I watch things I'm interested in.



I just look at all Harmony JIRA notifications. There are a lot, but
most can be safely skipped by subject.


Right - do a watch on the JIRAs you are interested in - they come to you 
directly, not to the project JIRA stream.


geir




geir

Sian January wrote:

Hi,
I have just discovered that it's not possible for a contributor to
set
"Patch available" on a JIRA unless they reported it.  (I'm not sure about
committers as I'm not one...)  I imagine this is to stop people coming in
and editing other details on the JIRA, so I can see that it makes
sense.  My
question is, what is the best thing to do if I attach a patch to a JIRA and
I can't set "Patch available"?  I can think of three alternatives at the
moment:
1. Assume that the reporter will notice and set it themselves (or
commit the
fix if they're also a comitter)
2. E-mail the reporter privately
3. Post to the mailing list
Or a fourth alternative would be a combination of the above where
the person
who contributed the patch waits a few days before doing either 2 or 3.  Any
thoughts on what would be best?
Thanks,
Sian

Re: [drlvm][threading] Should hythread_monitor_init() aquire the monitor?


um... classlib uses SIGUSR2 as well?  Doesn't our thread manager use it?

Evgueni Brevnov wrote:

Hey,

Seems like the pretty old problem shows itself again. I'm talking
about SIGUSR2 signal :-(...Classlib's asynchronous signal reporter
uses system semaphores for synchronization purposes...and hysem_wait
is interrupted by the signal:

(gdb) p perror("sym_wait error:")
sym_wait error:: Interrupted system call

Do we have good (universal) solution for such cases?

Thanks
Evgueni

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



Gregory Shimansky wrote:
> Evgueni Brevnov wrote:
>> hmmm strange. The patch was tested on multi-processor system
>> running SUSE9. I will check if the patch misses something. Anyway, we
>> need to wait with the patch submission until we 100% sure how
>> hythread_monitor_init should behave.
>>
>> Thanks
>> Evgueni
>>
>> On 11/11/06, Gregory Shimansky <[EMAIL PROTECTED]> wrote:
>>> On Friday 10 November 2006 17:45 Evgueni Brevnov wrote:
>>> > Hi,
>>> >
>>> > While investigating deadlock scenario which is described in
>>> > HARMONY-2006 I found out one interesting thing. It turned out 
that DRL

>>> > implementation of hythread_monitor_init /
>>> > hythread_monitor_init_with_name initializes and acquires a monitor.
>>> > Original spec reads: "Acquire and initialize a new monitor from the
>>> > threading library" AFAIU that doesn't mean to lock the 
monitor but
>>> > get it from the threading library. So the hythread_monitor_init 
should

>>> > not lock the monitor.
>>> >
>>> > Could somebody comment on that?
>>>
>>> It might be that semantic is different on different platforms 
which is

>>> probably even worse. Your patch in HARMONY-2149 breaks nearly all of
>>> acceptance tests on Linux while everything on Windows works (ok I
>>> tested on
>>> laptop with 1 processor while Linux was a HT server, sometimes it is
>>> important for threading).
>
> I've tried to investigate the problem but didn't find the end of it 
yet.

> The bug seems to be ubuntu specific (shall we maybe call this
> distribution buggy and move on?).

There is something odd about it, I'll admit...  Remember the EOMEM bugs
I found in forking?


I didn't reproduce it on
> gentoo, all tests work just fine.
>
> The bug look likes this, on tests gc.Force, gc.LOS, gc.List, gc.NPE,
> gc.PhantomReferenceTest, gc.WeakReferenceTest, 
stress.WeakHashMapTest VM
> segfaults. The stack looks like an infinite recursion of 4 stack 
frames:

>
> #0  0xb6dcb814 in null_java_reference_handler (signum=11,
> info=0xb71a503c, context=0xb71a50bc) at
> 
/nfs/ims/proj/drl/mrt1/users/gregory/Harmony/enhanced/drlvm/trunk/vm/vmco

> re/src/util/linux/signals_ia32.cpp:443
> #1  
> #2  0xb6dcc20a in get_stack_addr () at
> 
/nfs/ims/proj/drl/mrt1/users/gregory/Harmony/enhanced/drlvm/trunk/vm/vmco

> re/src/util/linux/signals_ia32.cpp:293
> #3  0xb6dcb6cd in check_stack_overflow (info=0xb71a546c, uc=0xb71a54ec)
> at
> 
/nfs/ims/proj/drl/mrt1/users/gregory/Harmony/enhanced/drlvm/trunk/vm/vmco

> re/src/util/linux/signals_ia32.cpp:399
> #4  0xb6dcb900 in null_java_reference_handler (signum=11,
> info=0xb71a546c, context=0xb71a54ec) at
> 
/nfs/ims/proj/drl/mrt1/users/gregory/Harmony/enhanced/drlvm/trunk/vm/vmco

> re/src/util/linux/signals_ia32.cpp:451
>
> and so on. The stack is very long. When I run VM with -Xtrace:signals I
> get a very long log of messages that "NPE or SOE detected at ...". The
> first time address always varies, but it appears to be memcpy. The next
> addresses are always the same, they point to get_stack_addr function.
>
> So I tried to find out why memcpy crashes in the first place. It 
appears
> to be a struct copy called from jsig_handler hysig. The stack looks 
like

> this (if I can trust gdb on ubuntu):
>
> #0  0xb7a9b9dc in memcpy () from /lib/tls/i686/cmov/libc.so.6
> #1  0xb7ba0fa0 in jsig_handler (sig=-1215196204, siginfo=0x0, uc=0x0)
>  at hysigunix.c:169
> #2  0xb7f9ec8b in asynchSignalReporter (userData=0x0) at hysignal.c:971
> #3  0xb7baa8ef in thread_start_proc (thd=0x807a8e8, p_args=0x807a8d8)
> at
> 
/nfs/ims/proj/drl/mrt1/users/gregory/Harmony/enhanced/drlvm/trunk/vm/thread/src/thread_native_basic.c:712 


>
> #4  0xb7bb0ed4 in dummy_worker (opaque=0x0) at 
threadproc/unix/thread.c:138
> #5  0xb7b65341 in start_thread () from 
lib/tls/i686/cmov/libpthread.so.0

> #6  0xb7af94ee in clone () from /lib/tls/i686/cmov/libc.so.6
>
> In jsig_handler a struct of type sigaction is copied
>
> act = saved_sigaction[sig];
>
> and gcc replaces this statement with a call to memcpy it seems. But the
> parameter sig is quite weird if you look at it. It is 
sig=-1215196204...

> Now if I could only find where and this sig happened there... I cannot
> find it in the depth of classlib native code this late at night.
>

Re: [drlvm][em64t] build fails




Gregory Shimansky wrote:

Geir Magnusson Jr. wrote:



Gregory Shimansky wrote:

Pavel Afremov wrote:

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


So what is the point to have a test which would pass either way? Check
that it doesn't crash the VM, is it the only purpose for it?

I think yes. It should check that test doesn't crash VM if stack 
size isn't

enough.


But we wouldn't know that SOE has happened or not if test passes even 
when SOE was not thrown.


It seems like SuSE9 is the only existing distribution which doesn't 
limit stack size on 64-bit architectures. SuSE10 has this limit and 
Gentoo has it too. Should we care that this test fails on SuSE9 when 
it passes on all other platforms and SOE is known to be thrown?


How could there be no limit to stack size??


Well there is no stack limit imposed by the OS on SuSE9. Maybe it is 
specific to this version because on SuSE10 there is a normal limit of 
8Mb. But when I run ulimit -a on SuSE9 I see this:


core file size(blocks, -c) unlimited
data seg size (kbytes, -d) unlimited
file size (blocks, -f) unlimited
max locked memory (kbytes, -l) unlimited
max memory size   (kbytes, -m) unlimited
open files(-n) 4096
pipe size  (512 bytes, -p) 8
stack size(kbytes, -s) unlimited
cpu time (seconds, -t) unlimited
max user processes(-u) 40960
virtual memory(kbytes, -v) unlimited

So the stack may grow up to the virtual address range which is pretty 
huge on 64-bit platforms. No physical memory is enough to allocate stack 
this big, so the system starts swapping nonstop. Maybe OOM linux killer 
will kill this process after some time, maybe not.


Is there a way the test framework could set this?  Does DRLVM support 
-Xss yet?


-Xss is the lower stack limit, it doesn't specify the maximum stack 
size, doesn't it?


What does "lower stack limit" mean? :)  I think that it's the size of 
the stack, max.


I think all you need to do then is set the stack size :

   ulimit -s 8192

or something.  We should probably do this before each run on linux so 
that things are well defined and reproducible.


geir

Re: [jira] Patch available setting




Tim Ellison wrote:

Geir Magnusson Jr. wrote:

I thought we had it configured that when a JIRA is modified, the
reporter is notified directly...  I'm not sure that really helps though.
 I wonder if we should just open things up a bit and let any user modify
a JIRA and see what happens.


+1  Provided we don't become a spam target, I'm all for letting anyone
who has a JIRA account modify an issue.


Yes - clearly it requires an account.  We'd never leave it open...

geir


Regards,
Tim

[classlib][testing] Showing test failures (Re: [drlvm] New regression: java.lang.ClassGenericsTest4)

Rana Dasgupta wrote:
> I think that a problem with the junit tests is that some failures spit out
> to the console, but show up in the test run results as passed. I find this
> very confusing. So unless you are watching all the time, you can miss them.

Hmm, this doesn't sound right.  I've not seen classlib tests fail but be
reported in the html report as passed.  Is that what you meant? (I
realize your mail subject was [drlvm] but just checking.)

One confusing aspect is that the classlib ant build fails if you run the
tests 'globally', but passes if you run the tests in a single module.

We could fix that by making the current test sequence an internal target
(for the 'global' test), and checking for failures after a 'modular' test.

e.g.

Index: build.xml
===
--- build.xml   (revision 474801)
+++ build.xml   (working copy)
@@ -41,8 +41,19 @@

-
+
+
+
+
+
+
+
+
+
+

+
+

That would be more intuitive to me, so unless anyone objects I'll do it.

Regards,
Tim

-- 

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

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

Vladimir Ivanov wrote:
> As part of solution for this issue the
> *HARMONY-2197* was
> created.
> 
> I suggest using the separate exclude list for each platform. I hope in this
> case the test enabling for the different platforms will be easy. Please,
> look at it.
> 
> Any comments are welcome :)

Maybe a dumb question by why hard-code

Wouldn't it make more sense to look at the java.vm.name, maybe mapped to
a short form suitable as a directory name?

Regards,
Tim

-- 

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

Re: [jira] Patch available setting

Geir Magnusson Jr. wrote:
> I thought we had it configured that when a JIRA is modified, the
> reporter is notified directly...  I'm not sure that really helps though.
>  I wonder if we should just open things up a bit and let any user modify
> a JIRA and see what happens.

+1  Provided we don't become a spam target, I'm all for letting anyone
who has a JIRA account modify an issue.

Regards,
Tim

-- 

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

Re: [gump] Gump running on Harmony!!

That's odd.  The launcher should figure this out.  I'll take a look in a 
sec...


Stefano Mazzocchi wrote:

Gregory Shimansky wrote:

On Wednesday 15 November 2006 19:27 Stefano Mazzocchi wrote:

Great news everyone, I've finally managed to get Gump running with Harmony.

Find it at (the semipermanent URL of Geir's server)

 http://67.86.14.213:1/gump/

and the 'list of todos' with importance priority can be found at

 http://67.86.14.213:1/gump/project_todos.html

The first problem is the lack of "javac" that bootstrap-ant requires.

Do we have a solution for that?
I wonder what is causing those UnsatisfiedLinkErrors at the end of the page. 
What's wrong with loading libhytext.so and how is it related to finding 
javac?


First of all, remember that Gump is written in python and uses 'java'
just like any other command, but the environment around that command
might not exactly be the same as the one from the shell. I'm not sure of
the details of that.

Anyway, when Gump starts up, it tries to fire up a bunch of programs
that it expects. I have added those to the path  and I've tested this by
using the sun jvm and achieved the same score of the official gump run.
This tells me that the gump installation is sane.

Now, the only change between the sun gump run and the harmony one is a
change of where JAVA_HOME points to and I wanted to see what happened.

In a perfect world, the score of the harmony gump run would have been
exactly the same as the score on the sun gump run.

This is an indication that the behavior of harmony is different.

So far it's different in two aspects:

 1) there is no javac process in the JAVA_HOME/bin and the bootstrap-ant
module can't work without it

 2) running the 'maven' or 'mvn' scripts fails to load the JVM due to
linkage problems. So either the those scripts fail to setup some native
library-related environment or harmony expects relative paths and might
get screwed by embedded execution in other scripts.

I've just tried to do

 export JAVA_HOME=~/src/harmony/drlvm/build/lnx_em64t_gcc_debug/deploy/jre/

and call "maven", "mvn" and "ant" and all result in the same error

java/lang/UnsatisfiedLinkError : Failed loading library "libhytext.so":
DSO load failed

so it seems that harmony has a problem being launched inside scripts
which is clearly a bug that needs to be fixed.

Re: [gump] Gump running on Harmony!!

Geir Magnusson Jr. wrote:
> Stefano Mazzocchi wrote:
>> So, if you are curious to see what's the next roadblock, I suggest that
>> one of you starts coding a javac wrapper for ecj (or anything else that
>> would do the job, I don't care) ;-)
> 
> We have one somewhere...

See
http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200605.mbox/[EMAIL
 PROTECTED]

Regards,
Tim

-- 

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

Re: [gump] Gump running on Harmony!!

Sam Ruby wrote:
> Tim Ellison wrote:
>> If Ant depends upon the non-API com.sun packages in tools.jar then I
>> guess we can decide to create an adapter in the suncompat module.
> 
> The compiler is pluggable in Ant, look for the build.compiler option:

Understood, in fact we do that for the Harmony build to use ECJ; but we
will need such an adapter for the users that choose not to use such an
Ant adapter, and expect Ant to work unmodified with the Harmony JRE.

In the future we can all use (and provide) the JSR199 compiler APIs.

Regards,
Tim

-- 

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

Re: [gump] Gump running on Harmony!!

Gregory Shimansky wrote:
> On Wednesday 15 November 2006 19:27 Stefano Mazzocchi wrote:
>> Great news everyone, I've finally managed to get Gump running with Harmony.
>>
>> Find it at (the semipermanent URL of Geir's server)
>>
>>  http://67.86.14.213:1/gump/
>>
>> and the 'list of todos' with importance priority can be found at
>>
>>  http://67.86.14.213:1/gump/project_todos.html
>>
>> The first problem is the lack of "javac" that bootstrap-ant requires.
>>
>> Do we have a solution for that?
> 
> I wonder what is causing those UnsatisfiedLinkErrors at the end of the page. 
> What's wrong with loading libhytext.so and how is it related to finding 
> javac?

First of all, remember that Gump is written in python and uses 'java'
just like any other command, but the environment around that command
might not exactly be the same as the one from the shell. I'm not sure of
the details of that.

Anyway, when Gump starts up, it tries to fire up a bunch of programs
that it expects. I have added those to the path  and I've tested this by
using the sun jvm and achieved the same score of the official gump run.
This tells me that the gump installation is sane.

Now, the only change between the sun gump run and the harmony one is a
change of where JAVA_HOME points to and I wanted to see what happened.

In a perfect world, the score of the harmony gump run would have been
exactly the same as the score on the sun gump run.

This is an indication that the behavior of harmony is different.

So far it's different in two aspects:

 1) there is no javac process in the JAVA_HOME/bin and the bootstrap-ant
module can't work without it

 2) running the 'maven' or 'mvn' scripts fails to load the JVM due to
linkage problems. So either the those scripts fail to setup some native
library-related environment or harmony expects relative paths and might
get screwed by embedded execution in other scripts.

I've just tried to do

 export JAVA_HOME=~/src/harmony/drlvm/build/lnx_em64t_gcc_debug/deploy/jre/

and call "maven", "mvn" and "ant" and all result in the same error

java/lang/UnsatisfiedLinkError : Failed loading library "libhytext.so":
DSO load failed

so it seems that harmony has a problem being launched inside scripts
which is clearly a bug that needs to be fixed.

-- 
Stefano.

Re: [gump] Gump running on Harmony!!

On Wednesday 15 November 2006 19:27 Stefano Mazzocchi wrote:
> Great news everyone, I've finally managed to get Gump running with Harmony.
>
> Find it at (the semipermanent URL of Geir's server)
>
>  http://67.86.14.213:1/gump/
>
> and the 'list of todos' with importance priority can be found at
>
>  http://67.86.14.213:1/gump/project_todos.html
>
> The first problem is the lack of "javac" that bootstrap-ant requires.
>
> Do we have a solution for that?

I wonder what is causing those UnsatisfiedLinkErrors at the end of the page. 
What's wrong with loading libhytext.so and how is it related to finding 
javac?

-- 
Gregory Shimansky, Intel Middleware Products Division

Re: [Japi] stacktraces running japitools on harmony

Pascal Rapicault wrote:
> 
> I have forwarded this message to a member of the compiler team.

Pascal, thanks!

Let us know what they say.

> *Stefano Mazzocchi <[EMAIL PROTECTED]>*
> 
> 11/15/2006 03:02 PM
> Please respond to
> harmony-dev@incubator.apache.org
> 
> 
>   
> To
>   Stuart Ballard <[EMAIL PROTECTED]>
> cc
>   [EMAIL PROTECTED], harmony-dev@incubator.apache.org
> Subject
>   Re: [Japi] stacktraces running japitools on harmony
> 
> 
>   
> 
> 
> 
> 
> 
> Copying Harmony as some of the Eclipse folks might be watching...
> 
> Stuart Ballard wrote:
>> This sounds like a bug in your compiler. The JLS specifies that every
>> constructor of every nonstatic inner class should be compiled as if it
>> has an extra parameter of the type of the outer class, to hold the
>> value for (for example) "BasicSwingTestCase.this".
> 
> I see.
> 
>> What compiler is producing the jar that you're running this against?
> 
> Eclipse ECJ 3.2
> 
> /me wonders if later versions have fixed this problem
> 
>> Also, is BasicSwingTestCase public in the first place?
> 
> checking... yeah it's a 'public abstract' class.
> 
>> Japitools (when
>> run in the harmony-vs-jdk direction) would complain about extra public
>> classes being added to public packages. And rightly so; Javadoc would
>> include them too and they're definitely not part of the public API.
> 
> Agreed.
> 
> the Harmony devs have apparently being paying close attention to the
> forward japi (jdk15 vs harmony) but the reversed one is clearly lagging
> behind.
> 
> Anyway, cool to see it's not a JAPI bug.
> 
> Thanks much!
> 
>> Stuart.
>>
>> On 11/14/06, Stefano Mazzocchi <[EMAIL PROTECTED]> wrote:
>>> I ran japitools (cvs update of a few minutes ago) against the latest
>>> harmony (r474892) and I got this:
>>>
>>> [...]
>>> Failed to Japize javax.swing.BasicSwingTestCase$BadLocationCase:
>>> java.lang.RuntimeException: First parameter of nonstatic inner class
>>> javax.swing.BasicSwingTestCase$ExceptionalCase constructor is
>>> java.lang.String, not javax.swing.BasicSwingTestCase
>>> java.lang.RuntimeException: First parameter of nonstatic inner class
>>> javax.swing.BasicSwingTestCase$ExceptionalCase constructor is
>>> java.lang.String, not javax.swing.BasicSwingTestCase
>>> at
>>>
> net.wuffies.japi.ClassFile$MethodInfoItem.getParameterTypes(ClassFile.java:438)
>>>
>>> at net.wuffies.japi.BoundCall.(BoundCall.java:47)
>>> at net.wuffies.japi.Japize.getFieldsAndCalls(Japize.java:1084)
>>> at net.wuffies.japi.Japize.getFieldsAndCalls(Japize.java:1076)
>>> at net.wuffies.japi.Japize.japizeClass(Japize.java:817)
>>> at net.wuffies.japi.Japize.processPackage(Japize.java:536)
>>> at net.wuffies.japi.Japize.processPackage(Japize.java:556)
>>> at net.wuffies.japi.Japize.processRootSet(Japize.java:471)
>>> at net.wuffies.japi.Japize.doJapize(Japize.java:443)
>>> at net.wuffies.japi.Japize.main(Japize.java:316)
>>> +
>>> Failed to Japize javax.swing.BasicSwingTestCase$ClassCastCase:
>>> java.lang.RuntimeException: First parameter of nonstatic inner class
>>> javax.swing.BasicSwingTestCase$ExceptionalCase constructor is
>>> java.lang.String, not javax.swing.BasicSwingTestCase
>>> java.lang.RuntimeException: First parameter of nonstatic inner class
>>> javax.swing.BasicSwingTestCase$ExceptionalCase constructor is
>>> java.lang.String, not javax.swing.BasicSwingTestCase
>>> at
>>>
> net.wuffies.japi.ClassFile$MethodInfoItem.getParameterTypes(ClassFile.java:438)
>>>
>>> at net.wuffies.japi.BoundCall.(BoundCall.java:47)
>>> at net.wuffies.japi.Japize.getFieldsAndCalls(Japize.java:1084)
>>> at net.wuffies.japi.Japize.getFieldsAndCalls(Japize.java:1076)
>>> at net.wuffies.japi.Japize.japizeClass(Japize.java:817)
>>> at net.wuffies.japi.Japize.processPackage(Japize.java:536)
>>> at net.wuffies.japi.Japize.processPackage(Japize.java:556)
>>> at net.wuffies.japi.Japize.processRootSet(Japize.java:471)
>>> at net.wuffies.japi.Japize.doJapize(Japize.java:443)
>>> at net.wuffies.japi.Japize.main(Japize.java:316)
>>> +
>>> Failed to Japize javax.swing.BasicSwingTestCase$ExceptionalCase:
>>> java.lang.RuntimeException: First parameter of nonstatic inner class
>>> javax.swing.BasicSwingTestCase$ExceptionalCase constructor is
>>> java.lang.String, not javax.swing.BasicSwingTestCase
>>> java.lang.RuntimeException: First parameter of nonstatic inner class
>>> javax.swing.BasicSwingTestCase$ExceptionalCase constructor is
>>> java.lang.String, not javax.swing.BasicSwingTestCase
>>> at
>>>
> net.wuffies.japi.ClassFile$MethodInfoItem.getParameterTypes(ClassFile.java:438)
>>>
>>> at net.wuffies.japi.BoundCall.(BoundCall.java:47)
>>> at net.wuffies.japi.Japize.getFieldsAndCalls(Japize.java:1084)
>>> at net.wuffies.japi.Japize.japizeClass(Japize.java:817)
>>> at net.wuffies.japi.J

Re: [Japi] stacktraces running japitools on harmony

2006-11-15 Thread Stuart Ballard

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

> What compiler is producing the jar that you're running this against?

Eclipse ECJ 3.2

/me wonders if later versions have fixed this problem

> Also, is BasicSwingTestCase public in the first place?

checking... yeah it's a 'public abstract' class.

...

Anyway, cool to see it's not a JAPI bug.

It still could be: perhaps I misunderstood the spec or there's an
exemption for "abstract" that I missed. Or the code that's trying to
detect this case is broken. I haven't investigated in detail, I don't
want to say that it's definitely ecj's bug. Just that that's the area
in which we should be investigating to find out where the problem
really does lie.

Stuart.

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

Re: [Japi] stacktraces running japitools on harmony

2006-11-15 Thread Pascal Rapicault

I have forwarded this message to a member of the compiler team.




Stefano Mazzocchi <[EMAIL PROTECTED]> 
11/15/2006 03:02 PM
Please respond to
harmony-dev@incubator.apache.org


To
Stuart Ballard <[EMAIL PROTECTED]>
cc
[EMAIL PROTECTED], harmony-dev@incubator.apache.org
Subject
Re: [Japi] stacktraces running japitools on harmony






Copying Harmony as some of the Eclipse folks might be watching...

Stuart Ballard wrote:
> This sounds like a bug in your compiler. The JLS specifies that every
> constructor of every nonstatic inner class should be compiled as if it
> has an extra parameter of the type of the outer class, to hold the
> value for (for example) "BasicSwingTestCase.this".

I see.

> What compiler is producing the jar that you're running this against?

Eclipse ECJ 3.2

/me wonders if later versions have fixed this problem

> Also, is BasicSwingTestCase public in the first place?

checking... yeah it's a 'public abstract' class.

> Japitools (when
> run in the harmony-vs-jdk direction) would complain about extra public
> classes being added to public packages. And rightly so; Javadoc would
> include them too and they're definitely not part of the public API.

Agreed.

the Harmony devs have apparently being paying close attention to the
forward japi (jdk15 vs harmony) but the reversed one is clearly lagging
behind.

Anyway, cool to see it's not a JAPI bug.

Thanks much!

> Stuart.
> 
> On 11/14/06, Stefano Mazzocchi <[EMAIL PROTECTED]> wrote:
>> I ran japitools (cvs update of a few minutes ago) against the latest
>> harmony (r474892) and I got this:
>>
>> [...]
>> Failed to Japize javax.swing.BasicSwingTestCase$BadLocationCase:
>> java.lang.RuntimeException: First parameter of nonstatic inner class
>> javax.swing.BasicSwingTestCase$ExceptionalCase constructor is
>> java.lang.String, not javax.swing.BasicSwingTestCase
>> java.lang.RuntimeException: First parameter of nonstatic inner class
>> javax.swing.BasicSwingTestCase$ExceptionalCase constructor is
>> java.lang.String, not javax.swing.BasicSwingTestCase
>> at
>> 
net.wuffies.japi.ClassFile$MethodInfoItem.getParameterTypes(ClassFile.java:438)
>>
>> at net.wuffies.japi.BoundCall.(BoundCall.java:47)
>> at net.wuffies.japi.Japize.getFieldsAndCalls(Japize.java:1084)
>> at net.wuffies.japi.Japize.getFieldsAndCalls(Japize.java:1076)
>> at net.wuffies.japi.Japize.japizeClass(Japize.java:817)
>> at net.wuffies.japi.Japize.processPackage(Japize.java:536)
>> at net.wuffies.japi.Japize.processPackage(Japize.java:556)
>> at net.wuffies.japi.Japize.processRootSet(Japize.java:471)
>> at net.wuffies.japi.Japize.doJapize(Japize.java:443)
>> at net.wuffies.japi.Japize.main(Japize.java:316)
>> +
>> Failed to Japize javax.swing.BasicSwingTestCase$ClassCastCase:
>> java.lang.RuntimeException: First parameter of nonstatic inner class
>> javax.swing.BasicSwingTestCase$ExceptionalCase constructor is
>> java.lang.String, not javax.swing.BasicSwingTestCase
>> java.lang.RuntimeException: First parameter of nonstatic inner class
>> javax.swing.BasicSwingTestCase$ExceptionalCase constructor is
>> java.lang.String, not javax.swing.BasicSwingTestCase
>> at
>> 
net.wuffies.japi.ClassFile$MethodInfoItem.getParameterTypes(ClassFile.java:438)
>>
>> at net.wuffies.japi.BoundCall.(BoundCall.java:47)
>> at net.wuffies.japi.Japize.getFieldsAndCalls(Japize.java:1084)
>> at net.wuffies.japi.Japize.getFieldsAndCalls(Japize.java:1076)
>> at net.wuffies.japi.Japize.japizeClass(Japize.java:817)
>> at net.wuffies.japi.Japize.processPackage(Japize.java:536)
>> at net.wuffies.japi.Japize.processPackage(Japize.java:556)
>> at net.wuffies.japi.Japize.processRootSet(Japize.java:471)
>> at net.wuffies.japi.Japize.doJapize(Japize.java:443)
>> at net.wuffies.japi.Japize.main(Japize.java:316)
>> +
>> Failed to Japize javax.swing.BasicSwingTestCase$ExceptionalCase:
>> java.lang.RuntimeException: First parameter of nonstatic inner class
>> javax.swing.BasicSwingTestCase$ExceptionalCase constructor is
>> java.lang.String, not javax.swing.BasicSwingTestCase
>> java.lang.RuntimeException: First parameter of nonstatic inner class
>> javax.swing.BasicSwingTestCase$ExceptionalCase constructor is
>> java.lang.String, not javax.swing.BasicSwingTestCase
>> at
>> 
net.wuffies.japi.ClassFile$MethodInfoItem.getParameterTypes(ClassFile.java:438)
>>
>> at net.wuffies.japi.BoundCall.(BoundCall.java:47)
>> at net.wuffies.japi.Japize.getFieldsAndCalls(Japize.java:1084)
>> at net.wuffies.japi.Japize.japizeClass(Japize.java:817)
>> at net.wuffies.japi.Japize.processPackage(Japize.java:536)
>> at net.wuffies.japi.Japize.processPackage(Japize.java:556)
>> at net.wuffies.japi.Japize.processRootSet(Japize.java:471)
>> at net.wuffies.japi.Japize.doJapize(Japize.java:443)
>> at net.wuffies.japi.

Re: [Japi] stacktraces running japitools on harmony

Copying Harmony as some of the Eclipse folks might be watching...

Stuart Ballard wrote:
> This sounds like a bug in your compiler. The JLS specifies that every
> constructor of every nonstatic inner class should be compiled as if it
> has an extra parameter of the type of the outer class, to hold the
> value for (for example) "BasicSwingTestCase.this".

I see.

> What compiler is producing the jar that you're running this against?

Eclipse ECJ 3.2

/me wonders if later versions have fixed this problem

> Also, is BasicSwingTestCase public in the first place?

checking... yeah it's a 'public abstract' class.

> Japitools (when
> run in the harmony-vs-jdk direction) would complain about extra public
> classes being added to public packages. And rightly so; Javadoc would
> include them too and they're definitely not part of the public API.

Agreed.

the Harmony devs have apparently being paying close attention to the
forward japi (jdk15 vs harmony) but the reversed one is clearly lagging
behind.

Anyway, cool to see it's not a JAPI bug.

Thanks much!

> Stuart.
> 
> On 11/14/06, Stefano Mazzocchi <[EMAIL PROTECTED]> wrote:
>> I ran japitools (cvs update of a few minutes ago) against the latest
>> harmony (r474892) and I got this:
>>
>> [...]
>> Failed to Japize javax.swing.BasicSwingTestCase$BadLocationCase:
>> java.lang.RuntimeException: First parameter of nonstatic inner class
>> javax.swing.BasicSwingTestCase$ExceptionalCase constructor is
>> java.lang.String, not javax.swing.BasicSwingTestCase
>> java.lang.RuntimeException: First parameter of nonstatic inner class
>> javax.swing.BasicSwingTestCase$ExceptionalCase constructor is
>> java.lang.String, not javax.swing.BasicSwingTestCase
>> at
>> net.wuffies.japi.ClassFile$MethodInfoItem.getParameterTypes(ClassFile.java:438)
>>
>> at net.wuffies.japi.BoundCall.(BoundCall.java:47)
>> at net.wuffies.japi.Japize.getFieldsAndCalls(Japize.java:1084)
>> at net.wuffies.japi.Japize.getFieldsAndCalls(Japize.java:1076)
>> at net.wuffies.japi.Japize.japizeClass(Japize.java:817)
>> at net.wuffies.japi.Japize.processPackage(Japize.java:536)
>> at net.wuffies.japi.Japize.processPackage(Japize.java:556)
>> at net.wuffies.japi.Japize.processRootSet(Japize.java:471)
>> at net.wuffies.japi.Japize.doJapize(Japize.java:443)
>> at net.wuffies.japi.Japize.main(Japize.java:316)
>> +
>> Failed to Japize javax.swing.BasicSwingTestCase$ClassCastCase:
>> java.lang.RuntimeException: First parameter of nonstatic inner class
>> javax.swing.BasicSwingTestCase$ExceptionalCase constructor is
>> java.lang.String, not javax.swing.BasicSwingTestCase
>> java.lang.RuntimeException: First parameter of nonstatic inner class
>> javax.swing.BasicSwingTestCase$ExceptionalCase constructor is
>> java.lang.String, not javax.swing.BasicSwingTestCase
>> at
>> net.wuffies.japi.ClassFile$MethodInfoItem.getParameterTypes(ClassFile.java:438)
>>
>> at net.wuffies.japi.BoundCall.(BoundCall.java:47)
>> at net.wuffies.japi.Japize.getFieldsAndCalls(Japize.java:1084)
>> at net.wuffies.japi.Japize.getFieldsAndCalls(Japize.java:1076)
>> at net.wuffies.japi.Japize.japizeClass(Japize.java:817)
>> at net.wuffies.japi.Japize.processPackage(Japize.java:536)
>> at net.wuffies.japi.Japize.processPackage(Japize.java:556)
>> at net.wuffies.japi.Japize.processRootSet(Japize.java:471)
>> at net.wuffies.japi.Japize.doJapize(Japize.java:443)
>> at net.wuffies.japi.Japize.main(Japize.java:316)
>> +
>> Failed to Japize javax.swing.BasicSwingTestCase$ExceptionalCase:
>> java.lang.RuntimeException: First parameter of nonstatic inner class
>> javax.swing.BasicSwingTestCase$ExceptionalCase constructor is
>> java.lang.String, not javax.swing.BasicSwingTestCase
>> java.lang.RuntimeException: First parameter of nonstatic inner class
>> javax.swing.BasicSwingTestCase$ExceptionalCase constructor is
>> java.lang.String, not javax.swing.BasicSwingTestCase
>> at
>> net.wuffies.japi.ClassFile$MethodInfoItem.getParameterTypes(ClassFile.java:438)
>>
>> at net.wuffies.japi.BoundCall.(BoundCall.java:47)
>> at net.wuffies.japi.Japize.getFieldsAndCalls(Japize.java:1084)
>> at net.wuffies.japi.Japize.japizeClass(Japize.java:817)
>> at net.wuffies.japi.Japize.processPackage(Japize.java:536)
>> at net.wuffies.japi.Japize.processPackage(Japize.java:556)
>> at net.wuffies.japi.Japize.processRootSet(Japize.java:471)
>> at net.wuffies.japi.Japize.doJapize(Japize.java:443)
>> at net.wuffies.japi.Japize.main(Japize.java:316)
>> -
>> Failed to Japize javax.swing.BasicSwingTestCase$IllegalArgumentCase:
>> java.lang.RuntimeException: First parameter of nonstatic inner class
>> javax.swing.BasicSwingTestCase$ExceptionalCase constructor is
>> java.lang.String, not javax.swing.BasicSwingTestCase
>> java.lang.RuntimeException: First parame

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


We should also take a hard look at how to do this in DRLVM as well...

Vladimir Ivanov wrote:

Seems, we says about different things :)

First of all, we have no TestNG (or other harness) yet but we need now
different exclude lists for different platforms.

Also, in my vision these exclude-lists are like a buffer before we mark 
test

by correct tags.
When the test fails on some platform we update the corresponding x-list and
investigate this failure.
As the result of investigation we mark the test or fix it.

Thanks, Vladimir


On 11/15/06, Alexei Zakharov <[EMAIL PROTECTED]> wrote:


Things become more and more complicated. Can anyone say why we
rejected to use TestSuites for this purpose from the very beginning?
Well, I can't say I am against using xml lists here. But the next step
will be to keep list of individual failing test methods in the xml
file. Then to create separate xml lists for api and impl tests and so
on. If we can't run original TestNG on Harmony then we invent it by
ourselves. :-)

Thanks,

2006/11/15, Vladimir Ivanov <[EMAIL PROTECTED]>:
> As part of solution for this issue the
> *HARMONY-2197* was
> created.
>
> I suggest using the separate exclude list for each platform. I hope in
this
> case the test enabling for the different platforms will be easy. 
Please,

> look at it.
>
> Any comments are welcome :)
>
>
>
>  Thanks, Vladimir
>
>
> On 11/15/06, Alexei Fedotov <[EMAIL PROTECTED]> wrote:
> >
> > Pavel, you are correct. Rana, sorry for confusion. Both issues block
> > passing class library unit tests.
> >
> > http://issues.apache.org/jira/browse/HARMONY-2070 [drlvm][thread]
> > Unhandled exception in java.exe while java.util.jar module tests
> > execution
> >
> > http://issues.apache.org/jira/browse/HARMONY-2073 [drlvm][unit]
> > org.apache.harmony.beans.tests.java.beans.PersistenceDelegateTest
> >
> > I've used a debugger and caught an assert in
> > exn_raise_by_name_internal for the second one. The first one contains
> > three diffrent issues, and I cannot say where exactly the problem is.
> >
> > On 11/15/06, Pavel Afremov < [EMAIL PROTECTED]> wrote:
> > > As I understand Alexey means HARMONY-2073, but not HARMONY-2070.
> > >
> > > Alexei, is it correct? If not, could you clarify the point about
> > > exn_raise_by_name_internal in your initial letter, please?
> > >
> > >
> > > Pavel Afremov.
> > >
> > >
> > > On 11/8/06, Rana Dasgupta <[EMAIL PROTECTED]> wrote:
> > > >
> > > > OK thanks Pavel, I'll try the patch today.
> > > >
> > > > Rana
> > > >
> > > >
> > > > On 11/8/06, Pavel Afremov <[EMAIL PROTECTED]> wrote:
> > > > >
> > > > > Hi Rana.
> > > > >
> > > > >
> > > > >
> > > > > I extend guard region as work around. It's only one way, which
"fix"
> > SOE
> > > > > on
> > > > > my SuSE Linux, without potential regression of your fix. On my
Linux
> >
> > > > > machine
> > > > > violation access signals happen one page before protected page
on
> > the
> > > > > stack.
> > > > > It's it.
> > > > >
> > > > >
> > > > >
> > > > > I ran all tests, and everything was OK. But strange misprint 
was

> > fount
> > > > in
> > > > > the new test.
> > > > >
> > > > > So I attach new fixed patch.
> > > > >
> > > > >
> > > > >
> > > > > Pavel Afremov.
> > > > >
> > > > >
> > > > > On 11/8/06, Rana Dasgupta <[EMAIL PROTECTED]> wrote:
> > > > > >
> > > > > > Though I tried several times, I could not repro 2070 or
Alexey's
> > > > > specific
> > > > > > problems. The test attached to 2018 repros, and that I think
is
> > > > enough.
> > > > > >
> > > > > > Pavel,
> > > > > >   1. The patch looks good, but I could not apply and try it
since
> > my
> > > > > Linux
> > > > > > box is down.
> > > > > >   2. Did you run all tests ( smoke, cuint, kernel, and
classlib )?
> >
> > > > Since
> > > > > > this fully turns on lazy exceptions, we need to ensure that
all
> > tests
> > > > > > pass,
> > > > > > or at least have identical behaviour before and after the
pacth.
> > > > > >   3. Adding a finalizer based stack test to smoke is a good
idea.
> > > > > >   4. On Linux you extend the guard region up ( or down
whatever )
> > by a
> > > > > > page. Did you find a good reason for it, or is this just 
being

> > > > careful?
> > > > > >
> > > > > > Rana
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > On 11/7/06, Pavel Afremov < [EMAIL PROTECTED]> wrote:
> > > > > > >
> > > > > > > Rana,
> > > > > > >
> > > > > > > Everything is correct in you description, but it looks like
that
> > *
> > > > > > > HARMONY-2018* <
> > https://issues.apache.org/jira/browse/HARMONY-2018>
> > > > > > should
> > > > > > > fix described bug. I think Alexei will have a chance to
check
> > it.

--
Alexei Zakharov,
Intel Enterprise Solutions Software Division

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


I like this approach.

+1

(it's exactly how I would have done it. :)

Vladimir Ivanov wrote:

As part of solution for this issue the
*HARMONY-2197* was
created.

I suggest using the separate exclude list for each platform. I hope in this
case the test enabling for the different platforms will be easy. Please,
look at it.

Any comments are welcome :)



Thanks, Vladimir


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


Pavel, you are correct. Rana, sorry for confusion. Both issues block
passing class library unit tests.

http://issues.apache.org/jira/browse/HARMONY-2070 [drlvm][thread]
Unhandled exception in java.exe while java.util.jar module tests
execution

http://issues.apache.org/jira/browse/HARMONY-2073 [drlvm][unit]
org.apache.harmony.beans.tests.java.beans.PersistenceDelegateTest

I've used a debugger and caught an assert in
exn_raise_by_name_internal for the second one. The first one contains
three diffrent issues, and I cannot say where exactly the problem is.

On 11/15/06, Pavel Afremov < [EMAIL PROTECTED]> wrote:
> As I understand Alexey means HARMONY-2073, but not HARMONY-2070.
>
> Alexei, is it correct? If not, could you clarify the point about
> exn_raise_by_name_internal in your initial letter, please?
>
>
> Pavel Afremov.
>
>
> On 11/8/06, Rana Dasgupta <[EMAIL PROTECTED]> wrote:
> >
> > OK thanks Pavel, I'll try the patch today.
> >
> > Rana
> >
> >
> > On 11/8/06, Pavel Afremov <[EMAIL PROTECTED]> wrote:
> > >
> > > Hi Rana.
> > >
> > >
> > >
> > > I extend guard region as work around. It's only one way, which 
"fix"

SOE
> > > on
> > > my SuSE Linux, without potential regression of your fix. On my 
Linux


> > > machine
> > > violation access signals happen one page before protected page on
the
> > > stack.
> > > It's it.
> > >
> > >
> > >
> > > I ran all tests, and everything was OK. But strange misprint was
fount
> > in
> > > the new test.
> > >
> > > So I attach new fixed patch.
> > >
> > >
> > >
> > > Pavel Afremov.
> > >
> > >
> > > On 11/8/06, Rana Dasgupta <[EMAIL PROTECTED]> wrote:
> > > >
> > > > Though I tried several times, I could not repro 2070 or Alexey's
> > > specific
> > > > problems. The test attached to 2018 repros, and that I think is
> > enough.
> > > >
> > > > Pavel,
> > > >   1. The patch looks good, but I could not apply and try it since
my
> > > Linux
> > > > box is down.
> > > >   2. Did you run all tests ( smoke, cuint, kernel, and 
classlib )?


> > Since
> > > > this fully turns on lazy exceptions, we need to ensure that all
tests
> > > > pass,
> > > > or at least have identical behaviour before and after the pacth.
> > > >   3. Adding a finalizer based stack test to smoke is a good idea.
> > > >   4. On Linux you extend the guard region up ( or down whatever )
by a
> > > > page. Did you find a good reason for it, or is this just being
> > careful?
> > > >
> > > > Rana
> > > >
> > > >
> > > >
> > > >
> > > > On 11/7/06, Pavel Afremov < [EMAIL PROTECTED]> wrote:
> > > > >
> > > > > Rana,
> > > > >
> > > > > Everything is correct in you description, but it looks like 
that

*
> > > > > HARMONY-2018* <
https://issues.apache.org/jira/browse/HARMONY-2018>
> > > > should
> > > > > fix described bug. I think Alexei will have a chance to check
it.
> > > > >
> > > > >
> > > > >
> > > > > Thank you.
> > > > >
> > > > > Pavel Afremov.
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>


--
Thank you,
Alexei

Re: [jira][attachments] Is it possible to mark attachments as obsolete?

I wonder if there is any harm in deleting them?

geir

Alexey Petrenko wrote:

I'm using "All" issue view. It shows all the comments and attachment
in time ordered way...

This helps. But marking attachments as obsolete will be better :)

SY, Alexey

2006/11/15, Salikh Zakirov <[EMAIL PROTECTED]>:

Alexey Petrenko wrote:
> Is it possible to configure JIRA to let people to mark issue
> attachments as obsolete? Like in Bugzilla?
> This is very useful feature when issue has few iterations of the fix.

Trick: upload the file with exactly the same name,
then the latest one will be marked as "latest" (in mouse-over baloon),
and earlier versions will be shown in gray.

I use this trick for some time. However, I've seen cases when other 
contributors

ignored "gray" color of the attachment and reviewed/tested/committed
incorrect patch. So, probably, some care from the reviewers/committers 
is also needed.

Re: [drlvm] New regression: java.lang.ClassGenericsTest4




Rana Dasgupta wrote:

I think that a problem with the junit tests is that some failures spit out
to the console, but show up in the test run results as passed. I find this
very confusing. So unless you are watching all the time, you can miss them.


We can't depend on this - they have to mechanically resolve as passed or 
failed.


Can you give me an example of a test?




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


Guys,

This is a good discussion, and let me praise Alexey for the wonderful 
fix.


I'm a bit concerned about our accepptance checks. How this could be
that regression was missed by a committer and an engineer durring
acceptance test runs?

Bug comments showed that Gregory ran the tests before a commit. Do
tests report such problems clearly?

Thanks!



On 11/15/06, Pavel Afremov <[EMAIL PROTECTED]> wrote:
> Oh. It's cool fix for my stupid bug.
>
>
>
> Thanks for Alexey very much.
>
> Pavel Afremov.
>
>
> On 11/15/06, Alexey Varlamov <[EMAIL PROTECTED]> wrote:
> >
> > Pardon for my English - a bit sleepy already...
> >
> > 2006/11/15, Alexey Varlamov <[EMAIL PROTECTED]>:
> > > Err, what I found is really trivial bug. But it took quite a few
time
> > > to discover - seems today was not my day :(
> > >
> > > Index: vm/vmcore/src/exception/exceptions_impl.cpp
> > > ===
> > > --- vm/vmcore/src/exception/exceptions_impl.cpp (revision 475132)
> > > +++ vm/vmcore/src/exception/exceptions_impl.cpp (working copy)
> > > @@ -281,7 +281,7 @@
> > >
> > > if (NULL != exception->exc_cause) {
> > > tmn_suspend_disable_recursive();
> > > -jthrowable exc_cause = oh_allocate_local_handle();
> > > +exc_cause = oh_allocate_local_handle();
> > > exc_cause->object = exception->exc_cause;
> > > tmn_suspend_enable_recursive();
> > > }
> > >
> > >
> > > OK, we definitely need a regression test for this.
> > >
> > > 2006/11/15, Gregory Shimansky <[EMAIL PROTECTED]>:
> > > > Alexey Varlamov wrote:
> > > > > 2006/11/15, Alexey Varlamov <[EMAIL PROTECTED]>:
> > > > >> 2006/11/15, Gregory Shimansky <[EMAIL PROTECTED]>:
> > > > >> > Alexey Varlamov wrote:
> > > > >> > > The guilty change is the following, which effectively 
turns

on
> > > > >> > > VM_LAZY_EXCEPTION support in exceptions_impl.cpp:
> > > > >> >
> > > > >> > Well this is a patch from HARMONY-2018 which doesn't hide 
the

> > fact that
> > > > >> > it enables lazy exceptions. Why shouldn't we enable them?
> > > > >
> > > > > Gregory,
> > > > >
> > > > > I've just re-read my posts and couldn't find anything critique
or
> > > > > offending - please don't take regressions too personal. I'm 
sure

we
> > > > > will be able to fix this one quite soon.
> > > >
> > > > I wasn't offended in any way. I was just thinking that you know
some
> > > > secret knowledge that lazy exceptions do not work and thus
enabling
> > them
> > > > is wrong.
> > > >
> > > > --
> > > > Gregory
> > > >
> > > >
> > >
> >
>
>


--
Thank you,
Alexei

Re: [gump] Gump running on Harmony!!




Stefano Mazzocchi wrote:

Tim Ellison wrote:

Stefano Mazzocchi wrote:

The first problem is the lack of "javac" that bootstrap-ant requires.

Can you clarify what 'bootstrap-ant' requires?  Is it running an Ant
 task, or compiling Ant source with javac.exe?  I was assuming
the latter.


bootstrap-ant is a script that builds ant without ant, so it requires
having the javac executable available.

I could cheat and symlink jikes to it, but I don't want to do that: Gump
is an indicator of what people use in real life and this is the first
sign that harmony needs a javac command in order to proceed in real-life
usefulness and I want to keep that signal clear.


We know :)



So, if you are curious to see what's the next roadblock, I suggest that
one of you starts coding a javac wrapper for ecj (or anything else that
would do the job, I don't care) ;-)


We have one somewhere...

Re: [drlvm][em64t] build fails

2006-11-15 Thread Rana Dasgupta

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

>Hello

>I think that Stack test should print pass if no stack overflow error is
>happened.

>Test should check processing of this error but not existing of it.

I think that this makes sense. StackTest should be intended to detect
correct handling of the SOE error only if it happens. That makes it platform
independent.

Re: [gump] Gump running on Harmony!!

Tim Ellison wrote:
> Stefano Mazzocchi wrote:
>> The first problem is the lack of "javac" that bootstrap-ant requires.
> 
> Can you clarify what 'bootstrap-ant' requires?  Is it running an Ant
>  task, or compiling Ant source with javac.exe?  I was assuming
> the latter.

bootstrap-ant is a script that builds ant without ant, so it requires
having the javac executable available.

I could cheat and symlink jikes to it, but I don't want to do that: Gump
is an indicator of what people use in real life and this is the first
sign that harmony needs a javac command in order to proceed in real-life
usefulness and I want to keep that signal clear.

So, if you are curious to see what's the next roadblock, I suggest that
one of you starts coding a javac wrapper for ecj (or anything else that
would do the job, I don't care) ;-)

-- 
Stefano.

Re: [drlvm] New regression: java.lang.ClassGenericsTest4

Alexei Fedotov wrote:

Guys,

This is a good discussion, and let me praise Alexey for the wonderful fix.

I'm a bit concerned about our accepptance checks. How this could be
that regression was missed by a committer and an engineer durring
acceptance test runs?

Bug comments showed that Gregory ran the tests before a commit. Do
tests report such problems clearly?

I saw that they failed on interpreter and saw an additional failure by 
ClassGeneticsTest4, but when I reverted the patch I ran the test 
individually (because running kernel tests is quite a long task). I saw 
exceptions output from ClassGeneticsTest4 with reverted patch and 
decided that it wasn't the one to blame. I tried reverting other patches 
but all of them produced the same output. Today Alexey explained to me 
that exceptions output was just a verbose test output not to related to 
test passed/failed status. So the answer to your question is "not very 
clearly" :)

After I saw that reverting the patches doesn't help very much I decided 
that regression somehow slipped earlier but wasn't noticed. The problem 
with kernel tests is that they don't pass stably. Often j.l.ThreadTest 
fails and j.l.RuntimeTest2 fails on XP. So I thought that negative 
result of kernel tests run was assumed to be ok because 
ClassGeneticsTest4 failure was not noticed since some tests which fail 
often failed.

The output of kernel tests is not very good too. They run 3 times on 
JET, OPT and interpreter. The last output is for interpreter, and if the 
output prints PASSED it is necessary to check result for JET and OPT. I 
think the tests should either  after the first test run which 
didn't pass (similar to how smoke tests stop tests execution), or print 
a summary at the end for all 3 runs with  if case any of them 
didn't pass.

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

Oh. It's cool fix for my stupid bug.

Thanks for Alexey very much.

Pavel Afremov.

On 11/15/06, Alexey Varlamov <[EMAIL PROTECTED]> wrote:
>
> Pardon for my English - a bit sleepy already...
>
> 2006/11/15, Alexey Varlamov <[EMAIL PROTECTED]>:
> > Err, what I found is really trivial bug. But it took quite a few time
> > to discover - seems today was not my day :(
> >
> > Index: vm/vmcore/src/exception/exceptions_impl.cpp
> > ===
> > --- vm/vmcore/src/exception/exceptions_impl.cpp (revision 475132)
> > +++ vm/vmcore/src/exception/exceptions_impl.cpp (working copy)
> > @@ -281,7 +281,7 @@
> >
> > if (NULL != exception->exc_cause) {
> > tmn_suspend_disable_recursive();
> > -jthrowable exc_cause = oh_allocate_local_handle();
> > +exc_cause = oh_allocate_local_handle();
> > exc_cause->object = exception->exc_cause;
> > tmn_suspend_enable_recursive();
> > }
> >
> >
> > OK, we definitely need a regression test for this.
> >
> > 2006/11/15, Gregory Shimansky <[EMAIL PROTECTED]>:
> > > Alexey Varlamov wrote:
> > > > 2006/11/15, Alexey Varlamov <[EMAIL PROTECTED]>:
> > > >> 2006/11/15, Gregory Shimansky <[EMAIL PROTECTED]>:
> > > >> > Alexey Varlamov wrote:
> > > >> > > The guilty change is the following, which effectively 
turns on

> > > >> > > VM_LAZY_EXCEPTION support in exceptions_impl.cpp:
> > > >> >
> > > >> > Well this is a patch from HARMONY-2018 which doesn't hide the
> fact that
> > > >> > it enables lazy exceptions. Why shouldn't we enable them?
> > > >
> > > > Gregory,
> > > >
> > > > I've just re-read my posts and couldn't find anything critique or
> > > > offending - please don't take regressions too personal. I'm 
sure we

> > > > will be able to fix this one quite soon.
> > >
> > > I wasn't offended in any way. I was just thinking that you know 
some

> > > secret knowledge that lazy exceptions do not work and thus enabling
> them
> > > is wrong.
> > >
> > > --
> > > Gregory
> > >
> > >
> >
>

--
Gregory

Re: [general][testing] cruise control on the WinXP and SUSE linux


I've allowed the mail through..

Vladimir Ivanov wrote:

Hello everyone,
I started cruise control (stored in the "buildtest" module with patch from
issue 995) on the Windows XP and SUSE Linux boxes.
Both machines are identical (1 CPU - P4*3GHz, 1GB RAM, 120Gb HDD).

On each platform cruise control runs (as separate projects in СС terms, all
settings have default values):
- build of classlib module (target: 'rebuild');
- classlib tests on J9 VM (target 'test' in the classlib module);
- build of drlvm module (target: 'build');
- vm tests (kernel+smoke+cunit, target: 'test' in the drlvm module);
- classlib tests on DRL VM (target: 'test' in the classlib module with -
Dtest.jre.home=drlvm);

Is it OK to send my cruise control notifications to the harmony-commits 
list

in order to notify about regressions?

I suspect the notifications are not ideal but I will work on their
improvement upon precedents (false alarms) and your feedback

Thanks, Vladimir

Re: [general][testing] cruise control on the WinXP and SUSE linux


Yep!

Will enable the notications...

Vladimir Ivanov wrote:

Hello everyone,
I started cruise control (stored in the "buildtest" module with patch from
issue 995) on the Windows XP and SUSE Linux boxes.
Both machines are identical (1 CPU - P4*3GHz, 1GB RAM, 120Gb HDD).

On each platform cruise control runs (as separate projects in СС terms, all
settings have default values):
- build of classlib module (target: 'rebuild');
- classlib tests on J9 VM (target 'test' in the classlib module);
- build of drlvm module (target: 'build');
- vm tests (kernel+smoke+cunit, target: 'test' in the drlvm module);
- classlib tests on DRL VM (target: 'test' in the classlib module with -
Dtest.jre.home=drlvm);

Is it OK to send my cruise control notifications to the harmony-commits 
list

in order to notify about regressions?

I suspect the notifications are not ideal but I will work on their
improvement upon precedents (false alarms) and your feedback

Thanks, Vladimir

Re: [gump] Gump running on Harmony!!


w00t!

(the server has been heating my office... I can tell when Gump is 
running as the fans spin up...)


geir

Stefano Mazzocchi wrote:

Great news everyone, I've finally managed to get Gump running with Harmony.

Find it at (the semipermanent URL of Geir's server)

 http://67.86.14.213:1/gump/

and the 'list of todos' with importance priority can be found at

 http://67.86.14.213:1/gump/project_todos.html

The first problem is the lack of "javac" that bootstrap-ant requires.

Do we have a solution for that?

Re: [drlvm] New regression: java.lang.ClassGenericsTest4

2006-11-15 Thread Rana Dasgupta


I think that a problem with the junit tests is that some failures spit out
to the console, but show up in the test run results as passed. I find this
very confusing. So unless you are watching all the time, you can miss them.

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


Guys,

This is a good discussion, and let me praise Alexey for the wonderful fix.

I'm a bit concerned about our accepptance checks. How this could be
that regression was missed by a committer and an engineer durring
acceptance test runs?

Bug comments showed that Gregory ran the tests before a commit. Do
tests report such problems clearly?

Thanks!



On 11/15/06, Pavel Afremov <[EMAIL PROTECTED]> wrote:
> Oh. It's cool fix for my stupid bug.
>
>
>
> Thanks for Alexey very much.
>
> Pavel Afremov.
>
>
> On 11/15/06, Alexey Varlamov <[EMAIL PROTECTED]> wrote:
> >
> > Pardon for my English - a bit sleepy already...
> >
> > 2006/11/15, Alexey Varlamov <[EMAIL PROTECTED]>:
> > > Err, what I found is really trivial bug. But it took quite a few
time
> > > to discover - seems today was not my day :(
> > >
> > > Index: vm/vmcore/src/exception/exceptions_impl.cpp
> > > ===
> > > --- vm/vmcore/src/exception/exceptions_impl.cpp (revision 475132)
> > > +++ vm/vmcore/src/exception/exceptions_impl.cpp (working copy)
> > > @@ -281,7 +281,7 @@
> > >
> > > if (NULL != exception->exc_cause) {
> > > tmn_suspend_disable_recursive();
> > > -jthrowable exc_cause = oh_allocate_local_handle();
> > > +exc_cause = oh_allocate_local_handle();
> > > exc_cause->object = exception->exc_cause;
> > > tmn_suspend_enable_recursive();
> > > }
> > >
> > >
> > > OK, we definitely need a regression test for this.
> > >
> > > 2006/11/15, Gregory Shimansky <[EMAIL PROTECTED]>:
> > > > Alexey Varlamov wrote:
> > > > > 2006/11/15, Alexey Varlamov <[EMAIL PROTECTED]>:
> > > > >> 2006/11/15, Gregory Shimansky <[EMAIL PROTECTED]>:
> > > > >> > Alexey Varlamov wrote:
> > > > >> > > The guilty change is the following, which effectively turns
on
> > > > >> > > VM_LAZY_EXCEPTION support in exceptions_impl.cpp:
> > > > >> >
> > > > >> > Well this is a patch from HARMONY-2018 which doesn't hide the
> > fact that
> > > > >> > it enables lazy exceptions. Why shouldn't we enable them?
> > > > >
> > > > > Gregory,
> > > > >
> > > > > I've just re-read my posts and couldn't find anything critique
or
> > > > > offending - please don't take regressions too personal. I'm sure
we
> > > > > will be able to fix this one quite soon.
> > > >
> > > > I wasn't offended in any way. I was just thinking that you know
some
> > > > secret knowledge that lazy exceptions do not work and thus
enabling
> > them
> > > > is wrong.
> > > >
> > > > --
> > > > Gregory
> > > >
> > > >
> > >
> >
>
>


--
Thank you,
Alexei

Re: [drlvm] New regression: java.lang.ClassGenericsTest4

2006-11-15 Thread Alexei Fedotov


Guys,

This is a good discussion, and let me praise Alexey for the wonderful fix.

I'm a bit concerned about our accepptance checks. How this could be
that regression was missed by a committer and an engineer durring
acceptance test runs?

Bug comments showed that Gregory ran the tests before a commit. Do
tests report such problems clearly?

Thanks!



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

Oh. It's cool fix for my stupid bug.



Thanks for Alexey very much.

Pavel Afremov.


On 11/15/06, Alexey Varlamov <[EMAIL PROTECTED]> wrote:
>
> Pardon for my English - a bit sleepy already...
>
> 2006/11/15, Alexey Varlamov <[EMAIL PROTECTED]>:
> > Err, what I found is really trivial bug. But it took quite a few time
> > to discover - seems today was not my day :(
> >
> > Index: vm/vmcore/src/exception/exceptions_impl.cpp
> > ===
> > --- vm/vmcore/src/exception/exceptions_impl.cpp (revision 475132)
> > +++ vm/vmcore/src/exception/exceptions_impl.cpp (working copy)
> > @@ -281,7 +281,7 @@
> >
> > if (NULL != exception->exc_cause) {
> > tmn_suspend_disable_recursive();
> > -jthrowable exc_cause = oh_allocate_local_handle();
> > +exc_cause = oh_allocate_local_handle();
> > exc_cause->object = exception->exc_cause;
> > tmn_suspend_enable_recursive();
> > }
> >
> >
> > OK, we definitely need a regression test for this.
> >
> > 2006/11/15, Gregory Shimansky <[EMAIL PROTECTED]>:
> > > Alexey Varlamov wrote:
> > > > 2006/11/15, Alexey Varlamov <[EMAIL PROTECTED]>:
> > > >> 2006/11/15, Gregory Shimansky <[EMAIL PROTECTED]>:
> > > >> > Alexey Varlamov wrote:
> > > >> > > The guilty change is the following, which effectively turns on
> > > >> > > VM_LAZY_EXCEPTION support in exceptions_impl.cpp:
> > > >> >
> > > >> > Well this is a patch from HARMONY-2018 which doesn't hide the
> fact that
> > > >> > it enables lazy exceptions. Why shouldn't we enable them?
> > > >
> > > > Gregory,
> > > >
> > > > I've just re-read my posts and couldn't find anything critique or
> > > > offending - please don't take regressions too personal. I'm sure we
> > > > will be able to fix this one quite soon.
> > >
> > > I wasn't offended in any way. I was just thinking that you know some
> > > secret knowledge that lazy exceptions do not work and thus enabling
> them
> > > is wrong.
> > >
> > > --
> > > Gregory
> > >
> > >
> >
>





--
Thank you,
Alexei

Re: [drlvm] New regression: java.lang.ClassGenericsTest4


Alexey Varlamov wrote:

Err, what I found is really trivial bug. But it took quite a few time
to discover - seems today was not my day :(

Index: vm/vmcore/src/exception/exceptions_impl.cpp
===
--- vm/vmcore/src/exception/exceptions_impl.cpp (revision 475132)
+++ vm/vmcore/src/exception/exceptions_impl.cpp (working copy)
@@ -281,7 +281,7 @@

if (NULL != exception->exc_cause) {
tmn_suspend_disable_recursive();
-jthrowable exc_cause = oh_allocate_local_handle();
+exc_cause = oh_allocate_local_handle();
exc_cause->object = exception->exc_cause;
tmn_suspend_enable_recursive();
}


Cool. Could you please commit the fix?


OK, we definitely need a regression test for this.

2006/11/15, Gregory Shimansky <[EMAIL PROTECTED]>:

Alexey Varlamov wrote:
> 2006/11/15, Alexey Varlamov <[EMAIL PROTECTED]>:
>> 2006/11/15, Gregory Shimansky <[EMAIL PROTECTED]>:
>> > Alexey Varlamov wrote:
>> > > The guilty change is the following, which effectively turns on
>> > > VM_LAZY_EXCEPTION support in exceptions_impl.cpp:
>> >
>> > Well this is a patch from HARMONY-2018 which doesn't hide the 
fact that

>> > it enables lazy exceptions. Why shouldn't we enable them?
>
> Gregory,
>
> I've just re-read my posts and couldn't find anything critique or
> offending - please don't take regressions too personal. I'm sure we
> will be able to fix this one quite soon.

I wasn't offended in any way. I was just thinking that you know some
secret knowledge that lazy exceptions do not work and thus enabling them
is wrong.

--
Gregory







--
Gregory

Re: [drlvm] New regression: java.lang.ClassGenericsTest4

2006-11-15 Thread Pavel Afremov


Oh. It's cool fix for my stupid bug.



Thanks for Alexey very much.

Pavel Afremov.


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


Pardon for my English - a bit sleepy already...

2006/11/15, Alexey Varlamov <[EMAIL PROTECTED]>:
> Err, what I found is really trivial bug. But it took quite a few time
> to discover - seems today was not my day :(
>
> Index: vm/vmcore/src/exception/exceptions_impl.cpp
> ===
> --- vm/vmcore/src/exception/exceptions_impl.cpp (revision 475132)
> +++ vm/vmcore/src/exception/exceptions_impl.cpp (working copy)
> @@ -281,7 +281,7 @@
>
> if (NULL != exception->exc_cause) {
> tmn_suspend_disable_recursive();
> -jthrowable exc_cause = oh_allocate_local_handle();
> +exc_cause = oh_allocate_local_handle();
> exc_cause->object = exception->exc_cause;
> tmn_suspend_enable_recursive();
> }
>
>
> OK, we definitely need a regression test for this.
>
> 2006/11/15, Gregory Shimansky <[EMAIL PROTECTED]>:
> > Alexey Varlamov wrote:
> > > 2006/11/15, Alexey Varlamov <[EMAIL PROTECTED]>:
> > >> 2006/11/15, Gregory Shimansky <[EMAIL PROTECTED]>:
> > >> > Alexey Varlamov wrote:
> > >> > > The guilty change is the following, which effectively turns on
> > >> > > VM_LAZY_EXCEPTION support in exceptions_impl.cpp:
> > >> >
> > >> > Well this is a patch from HARMONY-2018 which doesn't hide the
fact that
> > >> > it enables lazy exceptions. Why shouldn't we enable them?
> > >
> > > Gregory,
> > >
> > > I've just re-read my posts and couldn't find anything critique or
> > > offending - please don't take regressions too personal. I'm sure we
> > > will be able to fix this one quite soon.
> >
> > I wasn't offended in any way. I was just thinking that you know some
> > secret knowledge that lazy exceptions do not work and thus enabling
them
> > is wrong.
> >
> > --
> > Gregory
> >
> >
>

Re: [gump] Gump running on Harmony!!

2006-11-15 Thread Sam Ruby


Tim Ellison wrote:

Alexey Petrenko wrote:

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

Stefano Mazzocchi wrote:

Do we have a solution for that?

Yes, it is a modicum of work for a C-hacker.

It simply requires extending the tools launcher as described earlier
(I'll hunt down the archive if required).

ant runs java compiler without javac executable...

Or I'm missing something?


If Ant depends upon the non-API com.sun packages in tools.jar then I
guess we can decide to create an adapter in the suncompat module.


The compiler is pluggable in Ant, look for the build.compiler option:

http://ant.apache.org/manual/CoreTasks/javac.html

- Sam Ruby

Re: [drlvm] New regression: java.lang.ClassGenericsTest4


Pardon for my English - a bit sleepy already...

2006/11/15, Alexey Varlamov <[EMAIL PROTECTED]>:

Err, what I found is really trivial bug. But it took quite a few time
to discover - seems today was not my day :(

Index: vm/vmcore/src/exception/exceptions_impl.cpp
===
--- vm/vmcore/src/exception/exceptions_impl.cpp (revision 475132)
+++ vm/vmcore/src/exception/exceptions_impl.cpp (working copy)
@@ -281,7 +281,7 @@

if (NULL != exception->exc_cause) {
tmn_suspend_disable_recursive();
-jthrowable exc_cause = oh_allocate_local_handle();
+exc_cause = oh_allocate_local_handle();
exc_cause->object = exception->exc_cause;
tmn_suspend_enable_recursive();
}


OK, we definitely need a regression test for this.

2006/11/15, Gregory Shimansky <[EMAIL PROTECTED]>:
> Alexey Varlamov wrote:
> > 2006/11/15, Alexey Varlamov <[EMAIL PROTECTED]>:
> >> 2006/11/15, Gregory Shimansky <[EMAIL PROTECTED]>:
> >> > Alexey Varlamov wrote:
> >> > > The guilty change is the following, which effectively turns on
> >> > > VM_LAZY_EXCEPTION support in exceptions_impl.cpp:
> >> >
> >> > Well this is a patch from HARMONY-2018 which doesn't hide the fact that
> >> > it enables lazy exceptions. Why shouldn't we enable them?
> >
> > Gregory,
> >
> > I've just re-read my posts and couldn't find anything critique or
> > offending - please don't take regressions too personal. I'm sure we
> > will be able to fix this one quite soon.
>
> I wasn't offended in any way. I was just thinking that you know some
> secret knowledge that lazy exceptions do not work and thus enabling them
> is wrong.
>
> --
> Gregory
>
>

Re: [gump] Gump running on Harmony!!


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

Alexey Petrenko wrote:
> 2006/11/15, Tim Ellison <[EMAIL PROTECTED]>:
>> Stefano Mazzocchi wrote:
>> > Do we have a solution for that?
>>
>> Yes, it is a modicum of work for a C-hacker.
>>
>> It simply requires extending the tools launcher as described earlier
>> (I'll hunt down the archive if required).
> ant runs java compiler without javac executable...
>
> Or I'm missing something?

If Ant depends upon the non-API com.sun packages in tools.jar

As far as I know yes.


then I guess we can decide to create an adapter in the suncompat module.

Yes, that's also possible.

SY, Alexey

Re: [gump] Gump running on Harmony!!

Stefano Mazzocchi wrote:
> The first problem is the lack of "javac" that bootstrap-ant requires.

Can you clarify what 'bootstrap-ant' requires?  Is it running an Ant
 task, or compiling Ant source with javac.exe?  I was assuming
the latter.

Thanks for getting this going BTW!

Regards,
Tim

-- 

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

Re: [gump] Gump running on Harmony!!

Alexey Petrenko wrote:
> 2006/11/15, Tim Ellison <[EMAIL PROTECTED]>:
>> Stefano Mazzocchi wrote:
>> > Do we have a solution for that?
>>
>> Yes, it is a modicum of work for a C-hacker.
>>
>> It simply requires extending the tools launcher as described earlier
>> (I'll hunt down the archive if required).
> ant runs java compiler without javac executable...
> 
> Or I'm missing something?

If Ant depends upon the non-API com.sun packages in tools.jar then I
guess we can decide to create an adapter in the suncompat module.

Regards,
Tim

-- 

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

Re: [drlvm] New regression: java.lang.ClassGenericsTest4


Err, what I found is really trivial bug. But it took quite a few time
to discover - seems today was not my day :(

Index: vm/vmcore/src/exception/exceptions_impl.cpp
===
--- vm/vmcore/src/exception/exceptions_impl.cpp (revision 475132)
+++ vm/vmcore/src/exception/exceptions_impl.cpp (working copy)
@@ -281,7 +281,7 @@

if (NULL != exception->exc_cause) {
tmn_suspend_disable_recursive();
-jthrowable exc_cause = oh_allocate_local_handle();
+exc_cause = oh_allocate_local_handle();
exc_cause->object = exception->exc_cause;
tmn_suspend_enable_recursive();
}


OK, we definitely need a regression test for this.

2006/11/15, Gregory Shimansky <[EMAIL PROTECTED]>:

Alexey Varlamov wrote:
> 2006/11/15, Alexey Varlamov <[EMAIL PROTECTED]>:
>> 2006/11/15, Gregory Shimansky <[EMAIL PROTECTED]>:
>> > Alexey Varlamov wrote:
>> > > The guilty change is the following, which effectively turns on
>> > > VM_LAZY_EXCEPTION support in exceptions_impl.cpp:
>> >
>> > Well this is a patch from HARMONY-2018 which doesn't hide the fact that
>> > it enables lazy exceptions. Why shouldn't we enable them?
>
> Gregory,
>
> I've just re-read my posts and couldn't find anything critique or
> offending - please don't take regressions too personal. I'm sure we
> will be able to fix this one quite soon.

I wasn't offended in any way. I was just thinking that you know some
secret knowledge that lazy exceptions do not work and thus enabling them
is wrong.

--
Gregory

Re: [gump] Gump running on Harmony!!


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

Stefano Mazzocchi wrote:
> Do we have a solution for that?

Yes, it is a modicum of work for a C-hacker.

It simply requires extending the tools launcher as described earlier
(I'll hunt down the archive if required).

ant runs java compiler without javac executable...

Or I'm missing something?

Re: [gump] Gump running on Harmony!!

Stefano Mazzocchi wrote:
> Do we have a solution for that?

Yes, it is a modicum of work for a C-hacker.

It simply requires extending the tools launcher as described earlier
(I'll hunt down the archive if required).

Regards,
Tim

-- 

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

Re: [gump] Gump running on Harmony!!


Can javac be sustituted by Eclipse compiler as we do for Harmony build?

SY, Alexey

2006/11/15, Stefano Mazzocchi <[EMAIL PROTECTED]>:

Great news everyone, I've finally managed to get Gump running with Harmony.

Find it at (the semipermanent URL of Geir's server)

 http://67.86.14.213:1/gump/

and the 'list of todos' with importance priority can be found at

 http://67.86.14.213:1/gump/project_todos.html

The first problem is the lack of "javac" that bootstrap-ant requires.

Do we have a solution for that?

--
Stefano.

[gump] Gump running on Harmony!!

Great news everyone, I've finally managed to get Gump running with Harmony.

Find it at (the semipermanent URL of Geir's server)

 http://67.86.14.213:1/gump/

and the 'list of todos' with importance priority can be found at

 http://67.86.14.213:1/gump/project_todos.html

The first problem is the lack of "javac" that bootstrap-ant requires.

Do we have a solution for that?

-- 
Stefano.

Re: TSU NOTIFICATION - Encryption


thx

Tim Ellison wrote:

SUBMISSION TYPE:  TSU
SUBMITTED BY: Tim Ellison
SUBMITTED FOR:The Apache Software Foundation
POINT OF CONTACT: Secretary, The Apache Software Foundation
FAX:  +1-410-803-2258
MANUFACTURER(S):  The Apache Software Foundation, The Legion Of The
Bouncy Castle
PRODUCT NAME/MODEL #: Apache Harmony
ECCN: 5D002
NOTIFICATION: http://www.apache.org/licenses/exports/

Re: [drlvm][jvmti] Profiling support - Compiled Method Load event

2006-11-15 Thread Eugene Ostrovsky

Do I understand correctly that per-call-inline-info is a list of inline
chains for every call instruction offset within a code chunk?

If so, think we may replace per-call-inline-info with
per-region-inline-info. Why can't we use per-region-inline-info for stack
tracing.

The other question is: which component should collect and process
inline-info?
The current approach is that JIT collects the data and provides interface
for VM to extract useful information from it.
The other possible approach could be in using JIT to VM notifications about
compiled method (as George proposed). VM can store the inline info by itself
and process it on demand without disturbing JIT.

What do you think about these proposals?

On 10 Nov 2006 20:27:45 +0600, Egor Pasko <[EMAIL PROTECTED]> wrote:

On the 0x21D day of Apache Harmony Eugene Ostrovsky wrote:
> >BTW, I am curious, is it OK for TI when a method is compiled several
times
> and put on different addrs?
>
> Yes, it's ok. All compiled forms of the method must be reported.
> Moreover when compiled form of the method is unloaded from memory it
must be
> reported with Compiled Method Unload event.
> We should to think about this also.
> It seems to me that most natural way to implement CMU
event  is  to  iterate
> over all methods of class being unloaded and all theirs inlined methods.

yes, sure, so we need to store the inlining data from JIT until unloading

> The similar problem is with GenerateEvents function (
>
http://java.sun.com/j2se/1.5.0/docs/guide/jvmti/jvmti.html#GenerateEvents
).
> It should report all already compiled methods at any the time, on
agent's
> request.
> It can be done also by iterating over all loaded class -> their methods
->
> their inlined methods.
>
> What do you think?

The question is where to store this info. AFAIK, there is a special
CodeChunkInfo->_jit_info_block which is OK for that. Some info is
stored there already, i. e. mapping of call instructions into "inline
chain" they are in (so called per-call-inline-info). That's for
precise stack traces (which is a necessity).

Here we have a "region"-inline-info. Which is for TI. We can store it
in the CodeChunkInfo->_jit_info_block, but, unfortunately, it is not
typed, and is just a memory block. JIT is responsible for
serializing/deserializing to/from it. What I am dreaming of is a
tagged _jit_info_block. So "jit info" be a list of mem blocks, each
marked with it's tag, so appropriate info can be found more naturally
(not deserializing all big code block)

Do you have alternative proposals where to store region-inline-info?

There is one more issue, of course. Why not we unify both inline-infos
(per-call and region-based)? IMHO, region-based inline-info is less
precise (because of possible code motion in JIT), TI would not suffer
much of this (I hope), but precise stack traces can suffer. So, I am
for leaving both approaches as-is for now.

It is also interesting how much memory would, for example, Eclipse eat
for region-based inline-info and for per-call-inline-info when
started? I cannot predict what is more compact.

> Thanks,
> Eugene.
>
> On 10 Nov 2006 18:48:43 +0600, Egor Pasko <[EMAIL PROTECTED]> wrote:
> >
> > On the 0x21D day of Apache Harmony Eugene Ostrovsky wrote:
> > > Hello All.
> > >
> > > One more "hole" in current JVMTI Profiling implementation is
Compiled
> > Method
> > > Load event.
> > >
> > > Current VM doesn't report this event for methods that are inlined by
> > JIT.
> > > Though spec requires it to be sent for every compiled method:
> > >
> >
http://java.sun.com/j2se/1.5.0/docs/guide/jvmti/jvmti.html#CompiledMethodLoad
> > >
> > > To support the feature VM need to know about those inlined methods.
> > Right
> > > now I can see two possible approaches:
> > >
> > > 1. When VM initiates method compilation, it can ask the jit about
> > methods
> > > that were inlined to compiled method and report all of them.
> > > 2. JIT itself can notify VM about every compiled method by calling
some
> > > special interface function after the method compilation.
> > >
> > > I'm not sure about which approach is better.
> > > Each of them requires additional interface function (1.- to JIT from
VM;
> > 2.
> > > - from VM to JIT).
> > >
> > > The second approach seems to be more complicated in terms of VM -
JIT
> > > interaction. I mean that the following scheme "VM calls JIT's
function
> > to
> > > compile method. -> JIT's function in it's turn calls VM's function
to
> > notify
> > > about compiled methods. -> VM's function dispatches the event to TI
> > > agents..." introduces additional level of complexity than if "VM
calls
> > JIT's
> > > function to compile method. VM asks JIT about inlined methods. VM
> > dispatches
> > > event to TI agents."
> >
> > Correct me if I am wrong, I see the picture as:
> > (1):
> > 1.1. VM  -call-> JIT (compile a method for me, please)
> > 1.2. VM  -call-> JIT (gimme the list of addresses/functions)
> > 1.3. VM  -call-> JIT (please, free your resourc

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

2006-11-15 Thread Vladimir Ivanov


Seems, we says about different things :)

First of all, we have no TestNG (or other harness) yet but we need now
different exclude lists for different platforms.

Also, in my vision these exclude-lists are like a buffer before we mark test
by correct tags.
When the test fails on some platform we update the corresponding x-list and
investigate this failure.
As the result of investigation we mark the test or fix it.

Thanks, Vladimir


On 11/15/06, Alexei Zakharov <[EMAIL PROTECTED]> wrote:


Things become more and more complicated. Can anyone say why we
rejected to use TestSuites for this purpose from the very beginning?
Well, I can't say I am against using xml lists here. But the next step
will be to keep list of individual failing test methods in the xml
file. Then to create separate xml lists for api and impl tests and so
on. If we can't run original TestNG on Harmony then we invent it by
ourselves. :-)

Thanks,

2006/11/15, Vladimir Ivanov <[EMAIL PROTECTED]>:
> As part of solution for this issue the
> *HARMONY-2197* was
> created.
>
> I suggest using the separate exclude list for each platform. I hope in
this
> case the test enabling for the different platforms will be easy. Please,
> look at it.
>
> Any comments are welcome :)
>
>
>
>  Thanks, Vladimir
>
>
> On 11/15/06, Alexei Fedotov <[EMAIL PROTECTED]> wrote:
> >
> > Pavel, you are correct. Rana, sorry for confusion. Both issues block
> > passing class library unit tests.
> >
> > http://issues.apache.org/jira/browse/HARMONY-2070 [drlvm][thread]
> > Unhandled exception in java.exe while java.util.jar module tests
> > execution
> >
> > http://issues.apache.org/jira/browse/HARMONY-2073 [drlvm][unit]
> > org.apache.harmony.beans.tests.java.beans.PersistenceDelegateTest
> >
> > I've used a debugger and caught an assert in
> > exn_raise_by_name_internal for the second one. The first one contains
> > three diffrent issues, and I cannot say where exactly the problem is.
> >
> > On 11/15/06, Pavel Afremov < [EMAIL PROTECTED]> wrote:
> > > As I understand Alexey means HARMONY-2073, but not HARMONY-2070.
> > >
> > > Alexei, is it correct? If not, could you clarify the point about
> > > exn_raise_by_name_internal in your initial letter, please?
> > >
> > >
> > > Pavel Afremov.
> > >
> > >
> > > On 11/8/06, Rana Dasgupta <[EMAIL PROTECTED]> wrote:
> > > >
> > > > OK thanks Pavel, I'll try the patch today.
> > > >
> > > > Rana
> > > >
> > > >
> > > > On 11/8/06, Pavel Afremov <[EMAIL PROTECTED]> wrote:
> > > > >
> > > > > Hi Rana.
> > > > >
> > > > >
> > > > >
> > > > > I extend guard region as work around. It's only one way, which
"fix"
> > SOE
> > > > > on
> > > > > my SuSE Linux, without potential regression of your fix. On my
Linux
> >
> > > > > machine
> > > > > violation access signals happen one page before protected page
on
> > the
> > > > > stack.
> > > > > It's it.
> > > > >
> > > > >
> > > > >
> > > > > I ran all tests, and everything was OK. But strange misprint was
> > fount
> > > > in
> > > > > the new test.
> > > > >
> > > > > So I attach new fixed patch.
> > > > >
> > > > >
> > > > >
> > > > > Pavel Afremov.
> > > > >
> > > > >
> > > > > On 11/8/06, Rana Dasgupta <[EMAIL PROTECTED]> wrote:
> > > > > >
> > > > > > Though I tried several times, I could not repro 2070 or
Alexey's
> > > > > specific
> > > > > > problems. The test attached to 2018 repros, and that I think
is
> > > > enough.
> > > > > >
> > > > > > Pavel,
> > > > > >   1. The patch looks good, but I could not apply and try it
since
> > my
> > > > > Linux
> > > > > > box is down.
> > > > > >   2. Did you run all tests ( smoke, cuint, kernel, and
classlib )?
> >
> > > > Since
> > > > > > this fully turns on lazy exceptions, we need to ensure that
all
> > tests
> > > > > > pass,
> > > > > > or at least have identical behaviour before and after the
pacth.
> > > > > >   3. Adding a finalizer based stack test to smoke is a good
idea.
> > > > > >   4. On Linux you extend the guard region up ( or down
whatever )
> > by a
> > > > > > page. Did you find a good reason for it, or is this just being
> > > > careful?
> > > > > >
> > > > > > Rana
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > On 11/7/06, Pavel Afremov < [EMAIL PROTECTED]> wrote:
> > > > > > >
> > > > > > > Rana,
> > > > > > >
> > > > > > > Everything is correct in you description, but it looks like
that
> > *
> > > > > > > HARMONY-2018* <
> > https://issues.apache.org/jira/browse/HARMONY-2018>
> > > > > > should
> > > > > > > fix described bug. I think Alexei will have a chance to
check
> > it.

--
Alexei Zakharov,
Intel Enterprise Solutions Software Division

Re: [drlvm][test]Exclude some tests from "build test" target, make 'build test' pass


Elena Semukhina wrote:

I've found one more issue in the kernel ThreadTest. Filed
https://issues.apache.org/jira/browse/HARMONY-2193.

Alexey, please take a look!


I am not an Alexey, but I assigned this JIRA to myself. The testcase 
seems to be working both on linux and windows, I committed the patch.



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


2006/11/14, Gregory Shimansky <[EMAIL PROTECTED]>:
> On Monday 13 November 2006 15:51 Elena Semukhina wrote:
> > On 10/26/06, Elena Semukhina <[EMAIL PROTECTED]> wrote:
> > > After H-1823 has been committed, I still see intermittent failures
of
> > > drlvm kernel ThreadTest. Normally this test passes but today I got
> > > ThreadTest.testInterrupt_Sleeping() and testGetStateBlocked()
failures.
> > > There is H-1789 for the first issue but it is not reprodiced with
the
> > > attached test anymore. For the second test I filed H-1876 to make
the
> > > test more stable. The patch has been committed recently but the 
test
> > > still may fail. I'd like someone to review the above mentioned 
tests

to
> > > be sure they are correct otherwise we need to investigate failures
and
> > > file JIRA's before the tests are exclued.
> >
> > I looked at ThreadTest again and found one more incorrectness in
> > testGetStateBlocked(): it does not wait for the thread's run() method
> > actually starts. I filed
https://issues.apache.org/jira/browse/HARMONY-2166
> > and attached the patch. I ran the test more than 100 times and did 
not

see
> > a failure.
>
> Cool! I'd like to see this patch applied (in case it really helps) 
ASAP.

> Alexey V, please don't hold it for long. I would really like to see all
> acceptance to pass again on all platforms and then we'll maintain no
> regression state.

Verified and applied (at r474672). BTW, seems we are very close to
100% pass rate for classlib tests on DRLVM. The wiki status page [1]
lists just few pending issues, hopefully we'll fix them all in a
couple of days.

[1] http://wiki.apache.org/harmony/Unit_Tests_Pass_on_DRLVM








--
Gregory

Re: [general][testing] cruise control on the WinXP and SUSE linux

2006-11-15 Thread Vladimir Ivanov


Sorry, I can't use the [EMAIL PROTECTED] mail address.

Sorry again, to test it I use the [EMAIL PROTECTED] as for IBM
notifications without ask for permission :(



Could somebody register some fake mail address in the harmony-commits to use
it for my CC notifications or I should use other alias or may be other
options exist?



Thanks, Vladimir

By the way, now my CC reports for both systems:
 Unit Test Error Details: (1)Test:  test_Sign Class:
org.apache.harmony.xnet.tests.provider.jsse.DigitalSignatureTest
junit.framework.AssertionFailedError   at
org.apache.harmony.xnet.tests.provider.jsse.DigitalSignatureTest.test_Sign(
DigitalSignatureTest.java:135)   at
java.lang.reflect.VMReflection.invokeMethod(Native Method)





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


15.11.06, Gregory Shimansky<[EMAIL PROTECTED]> написал(а):
> Vladimir Ivanov wrote:
> > Hello everyone,
> > I started cruise control (stored in the "buildtest" module with patch
from
> > issue 995) on the Windows XP and SUSE Linux boxes.
> > Both machines are identical (1 CPU - P4*3GHz, 1GB RAM, 120Gb HDD).
> >
> > On each platform cruise control runs (as separate projects in СС
terms, all
> > settings have default values):
> > - build of classlib module (target: 'rebuild');
> > - classlib tests on J9 VM (target 'test' in the classlib module);
> > - build of drlvm module (target: 'build');
> > - vm tests (kernel+smoke+cunit, target: 'test' in the drlvm module);
> > - classlib tests on DRL VM (target: 'test' in the classlib module with
-
> > Dtest.jre.home=drlvm);
> >
> > Is it OK to send my cruise control notifications to the
harmony-commits
> > list
> > in order to notify about regressions?
> >
> > I suspect the notifications are not ideal but I will work on their
> > improvement upon precedents (false alarms) and your feedback
>
> I am +1 for cruise control and notifications to harmony-commit.
>
> But I wonder about linux version choice. If it is SuSE9, then could we
> upgrade it to SuSE10 or install another distribution like FC5 with gcc
> 4.1.x? This will help a lot with compilation errors which gcc 3.3.3 on
> SuSE9 doesn't report.
Good point, I support this.
--
Alexey

>
> --
> Gregory
>
>

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

2006-11-15 Thread Ivanov, Alexey A

>-Original Message-
>From: Alexey Petrenko [mailto:[EMAIL PROTECTED]
>Sent: Wednesday, November 15, 2006 5:17 PM
>To: harmony-dev@incubator.apache.org
>Subject: Re: svn commit: r472115 -
>/incubator/harmony/enhanced/classlib/trunk/modules/swing/src/main/java/
comm
>on/javax/swing/text/GapContent.java
>
>2006/11/15, Ivanov, Alexey A <[EMAIL PROTECTED]>:
>> Stepan, all,
>>
>> I've created a JIRA to document the incompatibility of
>> GapContent.replace().
>Great!
>What's the number? :)

Sorry, missed one of the most important things :(

https://issues.apache.org/jira/browse/HARMONY-2198


>
>> There are several test cases added, and some of them are indirectly
>> related to replace(). There's also patch which fixes
incompatibilities
>> of insertString() and remove().
>>
>>
>> By the way, HARMONY-1753 describes related problem which I suggest to
>> resolve as non-bug difference.
>>
>>
>> Regards,
>> --
>> Alexey A. Ivanov
>> Intel Enterprise Solutions Software Division
>>
>> >-Original Message-
>> >From: Ivanov, Alexey A [mailto:[EMAIL PROTECTED]
>> >Sent: Thursday, November 09, 2006 12:44 PM
>> >To: harmony-dev@incubator.apache.org
>> >Subject: RE: svn commit: r472115 -
>>
>/incubator/harmony/enhanced/classlib/trunk/modules/swing/src/main/java/
>> comm
>> >on/javax/swing/text/GapContent.java
>> >
>> >>-Original Message-
>> >>From: Stepan Mishura [mailto:[EMAIL PROTECTED]
>> >>Sent: Thursday, November 09, 2006 9:47 AM
>> >>To: harmony-dev@incubator.apache.org
>> >>Subject: Re: svn commit: r472115 -
>>
>>/incubator/harmony/enhanced/classlib/trunk/modules/swing/src/main/java
>> /
>> >comm
>> >>on/javax/swing/text/GapContent.java
>> >>
>> >>On 11/8/06, Ivanov, Alexey A wrote:
>> >>>
>> >>> >-Original Message-
>> >>> >From: Stepan Mishura
>> >>> >Sent: Wednesday, November 08, 2006 4:09 PM
>> >>> >To: harmony-dev@incubator.apache.org
>> >>> >Subject: Re: svn commit: r472115 -
>> >>>
>>
>>/incubator/harmony/enhanced/classlib/trunk/modules/swing/src/main/java
>> /
>> >>> comm
>> >>> >on/javax/swing/text/GapContent.java
>> >>> >
>> >>> >On 11/8/06, Ivanov, Alexey A wrote:
>> >>> >>
>> >>> >> Stepan,
>> >>> >>
>> >>> >> I must be missing something obvious...
>> >>> >> What kind of regression test do you expect?
>> >>> >
>> >>> >
>> >>> >My logic is quite straightforward: the best way to fix a
decision
>> is
>> >to
>> >>> >create a regression test. For example, if another volunteer find
>> out
>> >>> that
>> >>> >Harmony implementation of GapContent differ from RI's and
propose a
>> >>> patch
>> >>> >to
>> >>> >fix it will any test remind him (or committer) about the
decision?
>> >>
>> >>
>> >>To summarize my position: I see no value in discussing
compatibility
>> >issues
>> >>on harmony-dev if a discussion doesn't have any outcome (JIRA to
>> >document a
>> >>difference or a regression test to fix implementation behavior).
>> >
>> >IMHO, there are two JIRAs which document the issue: HARMONY-1809 and
>> >HARMONY-1975.
>> >
>> >I'll add another one to document the *incompatibility* in behaviour
and
>> >add a small test case which will always fail on the RI (until a
>> >volunteer would make Harmony implementation compatible with RI in
>> >respect to GapContent.replace()).
>> >
>> >
>> >Thanks for your opinion, Stepan.
>> >
>> >
>> >Regards,
>> >Alexey.
>> >
>> >>
>> >>In our case evaluation of HARMONY-1809 and HARMONY-1975 showed a
>> >>difference with RI. So we should fix/document it. Does this fit to
>> >>'Good Issue Resolution Guideline'?
>> >>
>> >>If a volunteer wants to make Harmony implementation of
>> >>> GapContent.replace() compatible with RI, they will provide many
>> tests
>> >-
>> >>> to test all invalid and edge situations to ensure the behaviour
is
>> >>> *compatible* - along with patch. And I see no reason to stop
them.
>> >>
>> >>
>> >>Sure, no reason to stop.
>> >>
>> >>(However, I believe a volunteer will search JIRA for GapContent
before
>> >>> starting this work. And then they face this bug.)
>> >>>
>> >>> On the other hand, I hardly imagine an application depends on
this
>> >>> functionality. That's why I haven't fixed it myself.
>> >>
>> >>
>> >>IMHO, an assumption that there is no such application is not a
reason
>> >for
>> >>not documenting the difference.
>> >>
>> >>>
>> >>> >In our case we decided not to follow RI and do nothing for
invalid
>> >>> >parameters. So a regression test should verify that Harmony
>> silently
>> >>> >ignores
>> >>> >bad parameters.
>> >>>
>> >>> It may make sense.
>> >>
>> >>
>> >>From my experience it always makes sense to add a test (even simple
>> and
>> >>obvious).
>> >>
>> >>Thanks,
>> >>Stepan.
>> >>
>> >>>
>> >>> >BWT, HARMONY-1809 should be marked as "non-bug difference from
RI".
>> >>>
>> >>> I'm against this.
>> >>>
>> >>> >
>> >>> >Thanks,
>> >>> >Stepan.
>> >>> >
>> >>> >What was done is the signature of the GapContent.replace had
been
>> >>> >> changed so that it didn't contain 'throws
BadLocationException'
>> >>> clause.
>>

Re: [classlib] Using Aspects for Tracing

Sian January wrote:
> I wouldn't necessarily recommend doing a lot of this kind of logging with
> aspects as it can make quite a messy aspect and the pointcuts can be quite
> fragile (i.e. minor changes in the code can easily cause a pointcut to stop
> matching).  But it is possible.  My second suggestion is a little more
> robust and you may find that that advice could be applied more
> generally anyway (e.g. 2, 3 and 4 could be logged after all calls to
> performHandshake instead of just calls from MyClass.dataExchange).

I agree, but would also point out that:

 - putting the explicit logging calls in the implementation clutter the
'business end' of the code; keeping logging separate like this makes it
clearer what each part of the code is doing.

 - we can reduce logging code duplication by defining pointcuts that
apply to numerous places.

 - logging becomes trivially turn-off-and-on-able.

 - if you have decent IDE support, like AspectJ, you can see where the
logging calls are being applied and develop them quite 'naturally'.


and the usual caveat, that I'd suggest we only use aspects sparingly
like this, and don't start going crazy.  If a vi user only misses out
seeing a few logging calls (without looking through the aspects list)
that is acceptable IMHO, but if there is any functional change missed
then that is unacceptable.

Regards,
Tim

-- 

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

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


2006/11/15, Ivanov, Alexey A <[EMAIL PROTECTED]>:

Stepan, all,

I've created a JIRA to document the incompatibility of
GapContent.replace().

Great!
What's the number? :)


There are several test cases added, and some of them are indirectly
related to replace(). There's also patch which fixes incompatibilities
of insertString() and remove().


By the way, HARMONY-1753 describes related problem which I suggest to
resolve as non-bug difference.


Regards,
--
Alexey A. Ivanov
Intel Enterprise Solutions Software Division

>-Original Message-
>From: Ivanov, Alexey A [mailto:[EMAIL PROTECTED]
>Sent: Thursday, November 09, 2006 12:44 PM
>To: harmony-dev@incubator.apache.org
>Subject: RE: svn commit: r472115 -
>/incubator/harmony/enhanced/classlib/trunk/modules/swing/src/main/java/
comm
>on/javax/swing/text/GapContent.java
>
>>-Original Message-
>>From: Stepan Mishura [mailto:[EMAIL PROTECTED]
>>Sent: Thursday, November 09, 2006 9:47 AM
>>To: harmony-dev@incubator.apache.org
>>Subject: Re: svn commit: r472115 -
>>/incubator/harmony/enhanced/classlib/trunk/modules/swing/src/main/java
/
>comm
>>on/javax/swing/text/GapContent.java
>>
>>On 11/8/06, Ivanov, Alexey A wrote:
>>>
>>> >-Original Message-
>>> >From: Stepan Mishura
>>> >Sent: Wednesday, November 08, 2006 4:09 PM
>>> >To: harmony-dev@incubator.apache.org
>>> >Subject: Re: svn commit: r472115 -
>>>
>>/incubator/harmony/enhanced/classlib/trunk/modules/swing/src/main/java
/
>>> comm
>>> >on/javax/swing/text/GapContent.java
>>> >
>>> >On 11/8/06, Ivanov, Alexey A wrote:
>>> >>
>>> >> Stepan,
>>> >>
>>> >> I must be missing something obvious...
>>> >> What kind of regression test do you expect?
>>> >
>>> >
>>> >My logic is quite straightforward: the best way to fix a decision
is
>to
>>> >create a regression test. For example, if another volunteer find
out
>>> that
>>> >Harmony implementation of GapContent differ from RI's and propose a
>>> patch
>>> >to
>>> >fix it will any test remind him (or committer) about the decision?
>>
>>
>>To summarize my position: I see no value in discussing compatibility
>issues
>>on harmony-dev if a discussion doesn't have any outcome (JIRA to
>document a
>>difference or a regression test to fix implementation behavior).
>
>IMHO, there are two JIRAs which document the issue: HARMONY-1809 and
>HARMONY-1975.
>
>I'll add another one to document the *incompatibility* in behaviour and
>add a small test case which will always fail on the RI (until a
>volunteer would make Harmony implementation compatible with RI in
>respect to GapContent.replace()).
>
>
>Thanks for your opinion, Stepan.
>
>
>Regards,
>Alexey.
>
>>
>>In our case evaluation of HARMONY-1809 and HARMONY-1975 showed a
>>difference with RI. So we should fix/document it. Does this fit to
>>'Good Issue Resolution Guideline'?
>>
>>If a volunteer wants to make Harmony implementation of
>>> GapContent.replace() compatible with RI, they will provide many
tests
>-
>>> to test all invalid and edge situations to ensure the behaviour is
>>> *compatible* - along with patch. And I see no reason to stop them.
>>
>>
>>Sure, no reason to stop.
>>
>>(However, I believe a volunteer will search JIRA for GapContent before
>>> starting this work. And then they face this bug.)
>>>
>>> On the other hand, I hardly imagine an application depends on this
>>> functionality. That's why I haven't fixed it myself.
>>
>>
>>IMHO, an assumption that there is no such application is not a reason
>for
>>not documenting the difference.
>>
>>>
>>> >In our case we decided not to follow RI and do nothing for invalid
>>> >parameters. So a regression test should verify that Harmony
silently
>>> >ignores
>>> >bad parameters.
>>>
>>> It may make sense.
>>
>>
>>From my experience it always makes sense to add a test (even simple
and
>>obvious).
>>
>>Thanks,
>>Stepan.
>>
>>>
>>> >BWT, HARMONY-1809 should be marked as "non-bug difference from RI".
>>>
>>> I'm against this.
>>>
>>> >
>>> >Thanks,
>>> >Stepan.
>>> >
>>> >What was done is the signature of the GapContent.replace had been
>>> >> changed so that it didn't contain 'throws BadLocationException'
>>> clause.
>>> >>
>>> >> What is a regression test to demonstrate? That
>BadLocationException
>>> is
>>> >> not thrown any more?
>>> >> Or do you insist on setting gapStart to -2 after call replace(-2,
>2,
>>> >> null, 0), so that any subsequent operation on GapContent
generates
>>> >> ArrayIndexOutOfBounds?
>>> >>
>>> >> Regards,
>>> >> Alexey.
>>> >>
>>> >>
>>> >> P.S. The discussion thread:
>>> >>
>>>
>http://thread.gmane.org/gmane.comp.java.harmony.devel/17837/focus=17837
>>> >> The related JIRA issues:
>>> >> https://issues.apache.org/jira/browse/HARMONY-1809
>>> >> https://issues.apache.org/jira/browse/HARMONY-1975
>>> >>
>>> >>
>>> >> --
>>> >> Alexey A. Ivanov
>>> >> Intel Middleware Product Division
>>> >>
>>> >>
>>> >> >-Original Message-
>>> >> >From: Stepan Mishura [mailto: [EMAIL PROTECTED] ]
>>> >> >Sent: Wednesday, November 08,

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

2006-11-15 Thread Ivanov, Alexey A

Stepan, all,

I've created a JIRA to document the incompatibility of
GapContent.replace().
There are several test cases added, and some of them are indirectly
related to replace(). There's also patch which fixes incompatibilities
of insertString() and remove().


By the way, HARMONY-1753 describes related problem which I suggest to
resolve as non-bug difference.


Regards,
--
Alexey A. Ivanov
Intel Enterprise Solutions Software Division

>-Original Message-
>From: Ivanov, Alexey A [mailto:[EMAIL PROTECTED]
>Sent: Thursday, November 09, 2006 12:44 PM
>To: harmony-dev@incubator.apache.org
>Subject: RE: svn commit: r472115 -
>/incubator/harmony/enhanced/classlib/trunk/modules/swing/src/main/java/
comm
>on/javax/swing/text/GapContent.java
>
>>-Original Message-
>>From: Stepan Mishura [mailto:[EMAIL PROTECTED]
>>Sent: Thursday, November 09, 2006 9:47 AM
>>To: harmony-dev@incubator.apache.org
>>Subject: Re: svn commit: r472115 -
>>/incubator/harmony/enhanced/classlib/trunk/modules/swing/src/main/java
/
>comm
>>on/javax/swing/text/GapContent.java
>>
>>On 11/8/06, Ivanov, Alexey A wrote:
>>>
>>> >-Original Message-
>>> >From: Stepan Mishura
>>> >Sent: Wednesday, November 08, 2006 4:09 PM
>>> >To: harmony-dev@incubator.apache.org
>>> >Subject: Re: svn commit: r472115 -
>>>
>>/incubator/harmony/enhanced/classlib/trunk/modules/swing/src/main/java
/
>>> comm
>>> >on/javax/swing/text/GapContent.java
>>> >
>>> >On 11/8/06, Ivanov, Alexey A wrote:
>>> >>
>>> >> Stepan,
>>> >>
>>> >> I must be missing something obvious...
>>> >> What kind of regression test do you expect?
>>> >
>>> >
>>> >My logic is quite straightforward: the best way to fix a decision
is
>to
>>> >create a regression test. For example, if another volunteer find
out
>>> that
>>> >Harmony implementation of GapContent differ from RI's and propose a
>>> patch
>>> >to
>>> >fix it will any test remind him (or committer) about the decision?
>>
>>
>>To summarize my position: I see no value in discussing compatibility
>issues
>>on harmony-dev if a discussion doesn't have any outcome (JIRA to
>document a
>>difference or a regression test to fix implementation behavior).
>
>IMHO, there are two JIRAs which document the issue: HARMONY-1809 and
>HARMONY-1975.
>
>I'll add another one to document the *incompatibility* in behaviour and
>add a small test case which will always fail on the RI (until a
>volunteer would make Harmony implementation compatible with RI in
>respect to GapContent.replace()).
>
>
>Thanks for your opinion, Stepan.
>
>
>Regards,
>Alexey.
>
>>
>>In our case evaluation of HARMONY-1809 and HARMONY-1975 showed a
>>difference with RI. So we should fix/document it. Does this fit to
>>'Good Issue Resolution Guideline'?
>>
>>If a volunteer wants to make Harmony implementation of
>>> GapContent.replace() compatible with RI, they will provide many
tests
>-
>>> to test all invalid and edge situations to ensure the behaviour is
>>> *compatible* - along with patch. And I see no reason to stop them.
>>
>>
>>Sure, no reason to stop.
>>
>>(However, I believe a volunteer will search JIRA for GapContent before
>>> starting this work. And then they face this bug.)
>>>
>>> On the other hand, I hardly imagine an application depends on this
>>> functionality. That's why I haven't fixed it myself.
>>
>>
>>IMHO, an assumption that there is no such application is not a reason
>for
>>not documenting the difference.
>>
>>>
>>> >In our case we decided not to follow RI and do nothing for invalid
>>> >parameters. So a regression test should verify that Harmony
silently
>>> >ignores
>>> >bad parameters.
>>>
>>> It may make sense.
>>
>>
>>From my experience it always makes sense to add a test (even simple
and
>>obvious).
>>
>>Thanks,
>>Stepan.
>>
>>>
>>> >BWT, HARMONY-1809 should be marked as "non-bug difference from RI".
>>>
>>> I'm against this.
>>>
>>> >
>>> >Thanks,
>>> >Stepan.
>>> >
>>> >What was done is the signature of the GapContent.replace had been
>>> >> changed so that it didn't contain 'throws BadLocationException'
>>> clause.
>>> >>
>>> >> What is a regression test to demonstrate? That
>BadLocationException
>>> is
>>> >> not thrown any more?
>>> >> Or do you insist on setting gapStart to -2 after call replace(-2,
>2,
>>> >> null, 0), so that any subsequent operation on GapContent
generates
>>> >> ArrayIndexOutOfBounds?
>>> >>
>>> >> Regards,
>>> >> Alexey.
>>> >>
>>> >>
>>> >> P.S. The discussion thread:
>>> >>
>>>
>http://thread.gmane.org/gmane.comp.java.harmony.devel/17837/focus=17837
>>> >> The related JIRA issues:
>>> >> https://issues.apache.org/jira/browse/HARMONY-1809
>>> >> https://issues.apache.org/jira/browse/HARMONY-1975
>>> >>
>>> >>
>>> >> --
>>> >> Alexey A. Ivanov
>>> >> Intel Middleware Product Division
>>> >>
>>> >>
>>> >> >-Original Message-
>>> >> >From: Stepan Mishura [mailto: [EMAIL PROTECTED] ]
>>> >> >Sent: Wednesday, November 08, 2006 9:12 AM
>>> >> >To: harmony-dev
>>> >> >Subject: Re: svn commit: r472115 -
>>>

TSU NOTIFICATION - Encryption

SUBMISSION TYPE:  TSU
SUBMITTED BY: Tim Ellison
SUBMITTED FOR:The Apache Software Foundation
POINT OF CONTACT: Secretary, The Apache Software Foundation
FAX:  +1-410-803-2258
MANUFACTURER(S):  The Apache Software Foundation, The Legion Of The
Bouncy Castle
PRODUCT NAME/MODEL #: Apache Harmony
ECCN: 5D002
NOTIFICATION: http://www.apache.org/licenses/exports/

[drlvm][jit][ia-32]register-based fast calling convention

2006-11-15 Thread Alex Astapchuk

Hi all,

Among other things listed on the JIT Dev tasks, there is a need for
calling convention (CC) fix-up for IA-32 [1].

Current problems are:

1. The calling convention(s) used are stack-based - this adds a memory
access overhead on calls.
2. The convention currently used for managed code neither allow to pass
float-point values on XMM registers, nor it provides callee-saved XMM
registers.
3. FPU stack is used to return float/double values

Both 2) and 3) affect register allocation for float point values in a
bad manner.
Fixing even the 1) looks promising for hot vm helpers like monitor
enter/exit and resolve_interface_vtable.

So, I'm going to implement register-based calling convention for IA-32.

The current proposal is:
- make it possible to switch between existing and new conventions
for investigation and tuning purposes
- implement 2 calling conventions:
1. well known standard fastcall (fisrt 2 params on ECX+EDX, the
rest is on stack)
2. DRLVM-specific convention: which involves ECX, EDX (and may
be EAX) for integer/parameters passing and also use XMMs for
float-point parameters and produce callee-save XMMs.

The #1 may be used to call internal C-based helpers. It may also be used
to call VM helpers where XMM callee save regs may add unnecessary
overhead on the helper itself. The example I can think of is
resolve_interface helper - preserving XMMs there looks overkill.

#2 will help to speed-up managed code both call-intensive and (I hope)
FP-intesive - together with register allocator tuning.

Any comments are welcome.

[1]
http://wiki.apache.org/harmony/JIT_Development_Tasks#head-bffdfbc80108641ca9a8bc29ea871c67fb3b82b9

--
Thanks,
Alex

Re: [drlvm] New regression: java.lang.ClassGenericsTest4


2006/11/15, Gregory Shimansky <[EMAIL PROTECTED]>:

Alexey Varlamov wrote:
> 2006/11/15, Gregory Shimansky <[EMAIL PROTECTED]>:
>> Alexey Varlamov wrote:
>> > The guilty change is the following, which effectively turns on
>> > VM_LAZY_EXCEPTION support in exceptions_impl.cpp:
>>
>> Well this is a patch from HARMONY-2018 which doesn't hide the fact that
>> it enables lazy exceptions. Why shouldn't we enable them?
>
> The point is not that we should or should not enable them, rather the
> fact that the regression appeared due to this change. I just tried to
> localize the problem hoping it will help to resolve this regression
> soon instead of reverting.
>
>>
>> Actually if you revert the patch (I've tried) this doesn't seem to fix
>> the test. At least the exceptions are still there, not sure about test
>> PASSED status.
>
> Verbose test output is confusing but itself does no harm. I found so

Ah this explains it. When I tried to investigate the regression I've
reverted the patch and tried the test alone. I saw exceptions and
thought that the test failed. I didn't realize that it is just an output.

> far the following:
> 1) the test fails on this assertion (ClassGenericsTest4.java:799):
> if (!(e.getCause() instanceof
> java.lang.reflect.GenericSignatureFormatError)) {
>fail("test_3, case 003 FAILED: GenericSignatureFormatError should
> be risen.");
> }
> because of e.getCause() returns null. That is, lazy machinery drops
> the cause of InvocationTargetException, I did not yet figured out why.

I see. If the problem appears to be hard to solve we should revert the
HARMONY-2018 patch.


What really confuses me, why this failure is interpreter specific?
AFAIU functions for creating exceptions are common, so the root cause
may be in stale exceptions due to improper cleanup somewhere...



> 2) Test report provides the following diagnostics:
> java.lang.NullPointerException at
> junit.framework.TestCase.runTest(TestCase.java:168). This seems to
> point to the same problem: lost cause exception after reflection.

--
Gregory

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

2006-11-15 Thread Morozova, Nadezhda

Hi all,
I have attached an updated version of the patch for the getting started
page to the JIRA. If someone knowledgeable takes a look and evaluates,
that would be great.
I am not the reporter of the issue, so I cannot set the 'patch
available' setting. However, if no requests for fixes arrive, I suggest
that we consider the issue ready to be closed.

Thank you, 
Nadya Morozova
 

>-Original Message-
>From: Pavel Ozhdikhin [mailto:[EMAIL PROTECTED]
>Sent: Tuesday, November 14, 2006 9:43 AM
>To: harmony-dev@incubator.apache.org
>Subject: Re: Re: [doc][drlvm] The document "Getting started with DRL"
is
>outdated
>
>OK then for Configuring VM section JIT options proposed by Egor will be
>suitable:
>
>"-Xem:jet <- use only baseline JIT compiler"
>"-Xem:opt <- use only optimising JIT compiler"
>"-Xtrace:em <- print method compilation events"
>
>I'd also add:
>
>"-Xem:server" - enable dynamic optimization mode tuned for long-running
>server-side applications (default optimization mode is tuned for fast
>start-up and client-side applications)
>"-Xem server_static" - enable static optimization mode tuned for
>long-running server-side applications
>
>Thanks,
>Pavel
>
>On 11/14/06, Morozova, Nadezhda <[EMAIL PROTECTED]> wrote:
>>
>> Pavel,
>> Thanks for your comments. I'll work through the examples and post an
>> updated patch soon.
>> As for the Configuring VM operation - can we at least have a couple
of
>> examples in the form of scenarios or something? The wiki page only
gives
>> a reference, an enumeration of available options. Using these might
not
>> always be transparent. I know it's tutorial-level info, but why not
have
>> it? Giving a show-case of customizing vm to a specific need would be
>> great.
>>
>> Thank you,
>> Nadya Morozova
>>
>> >-Original Message-
>> >From: Pavel Ozhdikhin [mailto:[EMAIL PROTECTED]
>> >Sent: Tuesday, November 14, 2006 9:23 AM
>> >To: harmony-dev@incubator.apache.org
>> >Subject: Re: Re: [doc][drlvm] The document "Getting started with
DRL"
>> is
>> >outdated
>> >
>> >Nadya,
>> >
>> >I've looked through your patch. Please see my comments in JIRA:
>> >http://issues.apache.org/jira/browse/HARMONY-2150
>> >
>> >> Do you think we can add a link to debugging vm&jit doc (or to
wiki)?
>> >
>> >I don't think we need it - it is rather info for developers than for
>> users.
>> >
>> >> Any ideas on what to write in Configuring vm operation?
>> >
>> >This section will duplicate the info from the Wiki page. Since we
gave
>> a
>> >link to that page in the "overview" we may skip creation of a
separate
>> >section here.
>> >
>> >Thanks,
>> >Pavel
>> >
>> >
>> >On 11/13/06, Morozova, Nadezhda <[EMAIL PROTECTED]> wrote:
>> >>
>> >> Successfully added a patch to fix getting Started outdated content
to
>> >> http://issues.apache.org/jira/browse/HARMONY-2150.
>> >> The patch is not final - need help to add more content. The
current
>> >> structure is:
>> >> - overview
>> >> - running an app
>> >> - eclipse-related (now much shorter)
>> >>-- running an app
>> >>-- debugging an app
>> >> - configuring vm operation (empty)
>> >>
>> >> Questions: how do you like the current patch? Do you think we can
add
>> a
>> >> link to debugging vm&jit doc (or to wiki)? Any ideas on what to
write
>> in
>> >> Configuring vm operation?
>> >>
>> >> Thank you,
>> >> Nadya Morozova
>> >>
>> >> >-Original Message-
>> >> >From: news [mailto:[EMAIL PROTECTED] On Behalf Of Egor Pasko
>> >> >Sent: Monday, November 13, 2006 1:00 PM
>> >> >To: harmony-dev@incubator.apache.org
>> >> >Subject: Re: [doc][drlvm] The document "Getting started with DRL"
is
>> >> >outdated
>> >> >
>> >> >On the 0x220 day of Apache Harmony Nadezhda Morozova wrote:
>> >> >> >-Original Message-
>> >> >> >From: news [mailto:[EMAIL PROTECTED] On Behalf Of Egor Pasko
>> >> >> >Sent: Monday, November 13, 2006 12:40 PM
>> >> >> >To: harmony-dev@incubator.apache.org
>> >> >> >Subject: Re: [doc][drlvm] The document "Getting started with
DRL"
>> is
>> >> >> >outdated
>> >> >> >
>> >> >> >On the 0x220 day of Apache Harmony Nadezhda Morozova wrote:
>> >> >> >> Ok,
>> >> >> >> I'll use http://issues.apache.org/jira/browse/HARMONY-2150
to
>> get
>> >> an
>> >> >> >> initial patch for the getting started document, and we can
then
>> >> work
>> >> >> to
>> >> >> >> improve it.
>> >> >> >
>> >> >> >OK, I am "watching" it
>> >> >> >
>> >> >> >> Let's make it a short page with links to wiki and maybe some
>> >> how-tos.
>> >> >> >
>> >> >> >To summarize:
>> >> >> >* we agreed that there will be no eclipse screenshots (they
are
>> for
>> >> >> >  eclipse+drlvm page)
>> >> >> >* we agreed that there should be something like "see what kind
of
>> >> >> >  links we have"
>> >> >> >
>> >> >> >Am I right?
>> >> >>
>> >> >> [Nadya]
>> >> >> Yop, quite right. An additional enhancement would be to comment
>> out
>> >> >> copyrights and update info that is incorrect.
>> >> >
>> >> >remove these annoyed substances? I am not an expert in

Re: [jira][attachments] Is it possible to mark attachments as obsolete?