Re: [classlib][sql] package javax.sql.rowset.serial is missing in Harmony

[Mikhail Loenko]

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

Hi folks,

I noticed that package javax.sql.rowset.serial is missing in Harmony.

Has anybody already been working on it? If no one holds implemented code in
his hand, I'd like to start on this package.


cool!




Any suggestions/concerns/patches :-) ? Thanks!

--
Best regards,
Andrew Zhang

Re: [classlib][swing] Serialization of Swing classes

[Nathan Beyer]

If there's no need for serialization compatability between VMs and
versions of a VM, then is there any harm in adding explicit
serialVersionUID fields?

On 11/10/06, Ivanov, Alexey A <[EMAIL PROTECTED]> wrote:

Nathan, all,

You shouldn't add explicit serialVersionUID because Sun explicitly states that 
serialized form of Swing classes maybe incompatible with future Swing releases. 
And there's no description of serialized form for any Swing class.

I'm pretty sure Harmony is not compatible with Sun classes with regard to 
serialized from of Swing classes. And new fields can be added to a class or 
removed, which will break the serialized form.

See the Warning in JTree JavaDoc: 
http://java.sun.com/j2se/1.5.0/docs/api/javax/swing/JTree.html

The serialVersionUID declarations were intentionally missed.

Regards,
Alexey.


P.S. Thanks for cleaning up the code to use parameterized types where possible.
I've looked through j.s.BasicSwingTestCase and restricted the type parameter, 
as well as refactored the code accessing Swing components so that it always 
runs on the Event Dispatch Thread. See 
https://issues.apache.org/jira/browse/HARMONY-2078.

Also I've cleaned up some classes where I fixed bugs:
https://issues.apache.org/jira/browse/HARMONY-2089
https://issues.apache.org/jira/browse/HARMONY-2119
https://issues.apache.org/jira/browse/HARMONY-2121

--
Alexey A. Ivanov
Intel EnterpriseSolutions SoftwareDivision

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

[Dalibor Topic]

Stefano Mazzocchi  apache.org> writes:
 
> Don't know about you, I would call that a resounding success for those
> like us who wanted the ability to see the results of the FOSS
> development and innovation model applied to the inner workings of a Java
> virtual machine.
> 
> And, if in doing so, a more compatible GPLv3 comes along, helped by
> those like us who would enjoy more license compatibility between the ASF
> and the FSF, I call that a success as well.
> 
> So, yes, maybe we could have done it differently, in a more neutral
> ground. But even so, it wasn't so bad after all 

Absolutely. I think we've all won. Not in the way we expected, I guess, but
nevertheless, we've managed to change several important things substantially for
the better.

keep up the good work,
dalibor topic

Re: svn commit: r473588 - in /incubator/harmony/enhanced/drlvm/trunk/vm: interpreter/src/ port/src/lil/em64t/pim/ vmcore/include/ vmcore/src/util/em64t/base/

[Stefano Mazzocchi]

[EMAIL PROTECTED] wrote:
> Author: gshimansky
> Date: Fri Nov 10 16:17:50 2006
> New Revision: 473588
> 
> URL: http://svn.apache.org/viewvc?view=rev&rev=473588
> Log:
> Applied HARMONY-2152 [drlvm][em64t] build is broken after 1558 have been 
> committed
> 
> Since x86_64 is not yet fully supported and patch touched only x86_64 files no
> tests were ran. When I tried acceptance tests on em64t server I effectively
> shut it down.


> Modified: 
> incubator/harmony/enhanced/drlvm/trunk/vm/vmcore/include/version_svn_tag.h
> URL: 
> http://svn.apache.org/viewvc/incubator/harmony/enhanced/drlvm/trunk/vm/vmcore/include/version_svn_tag.h?view=diff&rev=473588&r1=473587&r2=473588
> ==
> --- 
> incubator/harmony/enhanced/drlvm/trunk/vm/vmcore/include/version_svn_tag.h 
> (original)
> +++ 
> incubator/harmony/enhanced/drlvm/trunk/vm/vmcore/include/version_svn_tag.h 
> Fri Nov 10 16:17:50 2006
> @@ -18,6 +18,6 @@
>  #ifndef _VERSION_SVN_TAG_
>  #define _VERSION_SVN_TAG_
>  
> -#define VERSION_SVN_TAG  "473506"
> +#define VERSION_SVN_TAG  "svn: This client is too old to work with working 
> copy '.'; please get a newer Subversion client"

uh?

-- 
Stefano.

Re: [drlvm][em64t] build fails

[Stefano Mazzocchi]

Gregory Shimansky wrote:
> On Saturday 11 November 2006 02:36 Pavel Pervov wrote:
>> Gregory,
>>
>> Could you look at https://issues.apache.org/jira/browse/HARMONY-2152. I
>> believe it'll fix the build.
> 
> Thank you for a quick fix. The build works now. Don't try to run acceptance 
> tests though. The StackTest is a machine killer. It eats all of the virtual 
> memory in a moment because it cannot find any stack limit ("ulimit -s 8192" 
> may be used as a workaround) and maps all of 2^48 (or whatever number of bits 
> are configured in kernel for virtual address space) bytes of virtual memory. 
> After that only reset helps.

Cool, that worked (you guys rock, btw!), I'm going much farther ahead
now. I got a -lxml2 not found, so I apt-get libxml2-dev (would be cool
to have a list of needed packages to apt-get for, btw) and I got past
that as well but now I get

build.native.link:
   [cc] 0 total files to be compiled.
   [cc] Starting link
   [cc] /usr/bin/ld: cannot find -lhyzip
   [cc] collect2: ld returned 1 exit status

BUILD FAILED

and googling for hyzip doesn't yield anything interesting.

Suggestions?

-- 
Stefano.

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

[Gregory Shimansky]

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 think we need more investigation on whether or not the monitor has to be 
locked in init.

-- 
Gregory Shimansky, Intel Middleware Products Division

Re: [drlvm][em64t] build fails

[Gregory Shimansky]

On Saturday 11 November 2006 02:36 Pavel Pervov wrote:
> Gregory,
>
> Could you look at https://issues.apache.org/jira/browse/HARMONY-2152. I
> believe it'll fix the build.

Thank you for a quick fix. The build works now. Don't try to run acceptance 
tests though. The StackTest is a machine killer. It eats all of the virtual 
memory in a moment because it cannot find any stack limit ("ulimit -s 8192" 
may be used as a workaround) and maps all of 2^48 (or whatever number of bits 
are configured in kernel for virtual address space) bytes of virtual memory. 
After that only reset helps.

> On 11/11/06, Gregory Shimansky <[EMAIL PROTECTED]> wrote:
> > On Saturday 11 November 2006 01:43 Weldon Washburn wrote:
> > > On 11/10/06, Gregory Shimansky <[EMAIL PROTECTED]> wrote:
> > > > Same for me. I saw this yesterday. It is because HARMONY-1558 has
> >
> > changed
> >
> > > Sorry about that.  I looked at Stefano's error messages.  They are very
> > > similar to the ones we battled a few days ago on linux 32-bit platform.
> > > Pavel Pervov can probably tell you exactly what needs to be fixed.
> >
> > I think I can figure out myself just looking at what changes in the patch
> > were
> > done to Class::managed_null and Class::name.
> >
> > There is no reason for excuses. You did a very good job with a patch that
> > big,
> > it is good enough we didn't break anything on ia32 with it :)
> >
> > > I probably need access to a Linux 64-bit machine so that build problems
> > > like this get fixed *before* committing.
> >
> > I'll try to check my commits on x86_64 too once in a while.

-- 
Gregory Shimansky, Intel Middleware Products Division

Re: [drlvm][em64t] build fails

[Pavel Pervov]

Gregory,

Could you look at https://issues.apache.org/jira/browse/HARMONY-2152. I
believe it'll fix the build.


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


On Saturday 11 November 2006 01:43 Weldon Washburn wrote:
> On 11/10/06, Gregory Shimansky <[EMAIL PROTECTED]> wrote:
> > Same for me. I saw this yesterday. It is because HARMONY-1558 has
changed
>
> Sorry about that.  I looked at Stefano's error messages.  They are very
> similar to the ones we battled a few days ago on linux 32-bit platform.
> Pavel Pervov can probably tell you exactly what needs to be fixed.

I think I can figure out myself just looking at what changes in the patch
were
done to Class::managed_null and Class::name.

There is no reason for excuses. You did a very good job with a patch that
big,
it is good enough we didn't break anything on ia32 with it :)

> I probably need access to a Linux 64-bit machine so that build problems
> like this get fixed *before* committing.

I'll try to check my commits on x86_64 too once in a while.

--
Gregory Shimansky, Intel Middleware Products Division





--
Pavel Pervov,
Intel Enterprise Solutions Software Division

Re: [drlvm][jvmti][testing] I want to add JVMTI tests to drlvm commit checks

[Gregory Shimansky]

On Thursday 02 November 2006 23:24 Geir Magnusson Jr. wrote:
> That's an understatement.  Don't feel bad.  I've never seen anything
> like it before.  The idea of generating ant scripts on teh fly is very
> unconventional.

.

> You don't have enough cuts and bruises from working with the DRLVM build :)

Ok I think I've come up with a reasonable compromise. I still used the whole 
system of converting XML and all the stuff. It does quite a lot of things in 
setup and init targets and using  is convenient. I don't know how to 
untangle all of the setup and not do a lot of duplication in ant scripting 
which I am not big expert in.

But I managed to cut away the loop over components looking at how "test" 
target in build.xml is written. I've also converted smoke.test target to the 
same way because both jvmti and smoke tests are meant for a whole VM, not 
some component of it. This also made a weird bug go away when of smoke tests 
were built and run in some random subdirectory of "semis" instead of being 
in "vm" when they were ran separately as "build smoke.test".

Tests should be in their own subdirectories (main test inclusion/exclusion 
loop is done over them), main Java class for application has to be equal to 
have package and name equal to its subdirectory. Otherwise the build system 
won't know what to run. Other files may have any kind of names.

I wrote one simple JVMTI test to start the suite. Other tests which I've 
experimented with I cannot submit because I didn't write them. I think 
they'll appear later from JIRAs like one in HARMONY-2143 which were submitted 
to ASF. Take a look at HARMONY-2151 and say what you think. If I don't get 
much opposition I'll commit the patch on this weekend.

Don't shoot me. Writing even that much of Ant took a lot of time, beer and 
hair on my head. I said I am not an ant guru, didn't I?

-- 
Gregory Shimansky, Intel Middleware Products Division

Re: [drlvm][em64t] build fails

[Pavel Pervov]

It looks like I'll have the patch ready in a few minutes.
Sorry for breaking this.

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


On Saturday 11 November 2006 01:43 Weldon Washburn wrote:
> On 11/10/06, Gregory Shimansky <[EMAIL PROTECTED]> wrote:
> > Same for me. I saw this yesterday. It is because HARMONY-1558 has
changed
>
> Sorry about that.  I looked at Stefano's error messages.  They are very
> similar to the ones we battled a few days ago on linux 32-bit platform.
> Pavel Pervov can probably tell you exactly what needs to be fixed.

I think I can figure out myself just looking at what changes in the patch
were
done to Class::managed_null and Class::name.

There is no reason for excuses. You did a very good job with a patch that
big,
it is good enough we didn't break anything on ia32 with it :)

> I probably need access to a Linux 64-bit machine so that build problems
> like this get fixed *before* committing.

I'll try to check my commits on x86_64 too once in a while.

--
Gregory Shimansky, Intel Middleware Products Division





--
Pavel Pervov,
Intel Enterprise Solutions Software Division

Re: [drlvm][em64t] build fails

[Gregory Shimansky]

On Saturday 11 November 2006 01:43 Weldon Washburn wrote:
> On 11/10/06, Gregory Shimansky <[EMAIL PROTECTED]> wrote:
> > Same for me. I saw this yesterday. It is because HARMONY-1558 has changed
>
> Sorry about that.  I looked at Stefano's error messages.  They are very
> similar to the ones we battled a few days ago on linux 32-bit platform.
> Pavel Pervov can probably tell you exactly what needs to be fixed.

I think I can figure out myself just looking at what changes in the patch were 
done to Class::managed_null and Class::name.

There is no reason for excuses. You did a very good job with a patch that big, 
it is good enough we didn't break anything on ia32 with it :)

> I probably need access to a Linux 64-bit machine so that build problems
> like this get fixed *before* committing.

I'll try to check my commits on x86_64 too once in a while.

-- 
Gregory Shimansky, Intel Middleware Products Division

Re: [drlvm][threading module] a question about jthread_raw_monitor_create()

[Gregory Shimansky]

On Saturday 11 November 2006 01:36 Weldon Washburn wrote:
> I might be misunderstanding the code but the local variable,
> "hythread_monitor_t monitor;" is used as a parameter to a call to
> array_add(jvmti_monitor_table, monitor);.  It seems that once
> jthread_raw_monitor_create() returns, the jvmti_monitor_table will end up
> with an invalid pointer.  Is this correct?

It looks more like monitor value which is initialized in hythread_monitor_init 
is passed to array_add and there it is remembered. It is not a problem that 
monitor is a local variable since hythread_monitor_init provides a pointer to 
a data allocated somewhere not on the stack.

-- 
Gregory Shimansky, Intel Middleware Products Division

Re: [drlvm][em64t] build fails

[Weldon Washburn]

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


Same for me. I saw this yesterday. It is because HARMONY-1558 has changed



Sorry about that.  I looked at Stefano's error messages.  They are very
similar to the ones we battled a few days ago on linux 32-bit platform.
Pavel Pervov can probably tell you exactly what needs to be fixed.

I probably need access to a Linux 64-bit machine so that build problems like
this get fixed *before* committing.

Class interfaces but didn't change x86_64 specific files. Now that I look at

the error messages, I think it is quite easy to fix the build. I'll take
care
of weekend.

I wonder how did you get to building drlvm if classlib didn't build for
you
because of -fpic problem? DRLVM build always requires prebuilt classlib...

On Friday 10 November 2006 23:53 Stefano Mazzocchi wrote:
> I've managed to get everything in place for a DRLVM build.. it runs for
> a while and then it fails with these errors:
>
>[cc]
>
/home/stefano/src/harmony/drlvm/vm/vmcore/src/util/em64t/base/jit_lock_rt_s
>upport_em64t.cpp: In function 'void* rth_get_lil_monitor_enter()':
>[cc]
>
/home/stefano/src/harmony/drlvm/vm/vmcore/src/util/em64t/base/jit_lock_rt_s
>upport_em64t.cpp:127: error: 'managed_null' is not a member of 'Class'
>[cc]
>
/home/stefano/src/harmony/drlvm/vm/vmcore/src/util/em64t/base/jit_lock_rt_s
>upport_em64t.cpp: In function 'void* rth_get_lil_monitor_exit()':
>[cc]
>
/home/stefano/src/harmony/drlvm/vm/vmcore/src/util/em64t/base/jit_lock_rt_s
>upport_em64t.cpp:265: error: 'managed_null' is not a member of 'Class'
>[cc]
>
/home/stefano/src/harmony/drlvm/vm/vmcore/src/util/em64t/base/ini_em64t.cpp
>: In function 'void JIT_execute_method_default(void*, _jmethodID*,
> jvalue*, jvalue*)':
>[cc]
>
/home/stefano/src/harmony/drlvm/vm/vmcore/src/util/em64t/base/ini_em64t.cpp
>:201: error: 'struct Class' has no member named 'name'
>[cc]
>
/home/stefano/src/harmony/drlvm/vm/vmcore/src/util/em64t/base/ini_em64t.cpp
>:229: error: 'managed_null' is not a member of 'Class'
>[cc]
>
/home/stefano/src/harmony/drlvm/vm/vmcore/src/util/em64t/base/ini_em64t.cpp
>:326: error: 'managed_null' is not a member of 'Class'
>[cc]
>
/home/stefano/src/harmony/drlvm/vm/vmcore/src/util/em64t/base/ini_em64t.cpp
>:359: error: 'struct Class' has no member named 'name'
>
> Suggestions?

--
Gregory Shimansky, Intel Middleware Products Division





--
Weldon Washburn
Intel Enterprise Solutions Software Division

Re: [drlvm][build] everyday SVN conflict on the version_svn_tag.h file

[Gregory Shimansky]

On Saturday 11 November 2006 01:12 Alexei Fedotov wrote:
> > generate this file as part of the build process?
>
> +1 for autogeneration of version_svn_tag.h

It is kind of autogenerated already. To get rid of conflicts I think we should 
remove this file from revision control.

> On 11/10/06, Vladimir Ivanov <[EMAIL PROTECTED]> wrote:
> > Hello everyone,
> >
> > When I do my morning SVN update of drlvm module I see the permanent
> > conflict on the version_svn_tag.h file because this file is updated by
> > build.
> >
> > Actually, it is not a big problem while it not breaks vm build. But it
> > will be more convenient if these conflicts go out.
> >
> > Could we generate this file as part of the build process (it has only 4
> > strings)? May be some other solutions exists?
> >
> >
> >
> > I'm not too familiar with VM build so I'll be glad if somebody takes care
> > about it :)

-- 
Gregory Shimansky, Intel Middleware Products Division

[drlvm][threading module] a question about jthread_raw_monitor_create()

[Weldon Washburn]

I might be misunderstanding the code but the local variable,
"hythread_monitor_t monitor;" is used as a parameter to a call to
array_add(jvmti_monitor_table, monitor);.  It seems that once
jthread_raw_monitor_create() returns, the jvmti_monitor_table will end up
with an invalid pointer.  Is this correct?

--
Weldon Washburn
Intel Enterprise Solutions Software Division

Re: Re: [classlib][pack200] Status update

[Alex Blewitt]

A call of frustration at times perhaps :-)

It's going along. I'm hoping to get to a stage where I can get a
better patch together and get it into the harmony subversion codebase
in the near future. But sometimes it's just slow progress.

One thing I'd like to get sorted is moving the pack200 code into its
own module in the near future, perhaps after the next patch bomb.

Oh, and I've discovered that the default Sun implementation doesn't
actually allow you to replace it with another implementation unless
it's on the boot classpath. D'oh! Fortunately, I've raised it as a bug
with Sun:

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6489723

We should ensure that it doesn't happen with Harmony too :-)

Alex.

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

Thanks for the update Alex.  I assume from this description (and please
don't take this the wrong way) that you are happy to be left alone to
work on this for the moment, rather than it be read as a call for help?

Keep up the good work.
Tim

Alex Blewitt wrote:
> I'm still lurking around in the background, but I'm busier than ever
> what with having to keep posting at EclipseZone where I'm editor now
> ... but I'm still managing to plod along with the Pack200 code. The
> last patch (1994, IIRC) went down pretty badly; the subclipse plugin
> didn't seem to capture all the newly created classes that I had put
> together for a bit of refactoring that I did. It's also a nightmare
> submitting newly created files; once they've been uploaded to JIRA
> into the patch queue, I effectively have to stop work until they're
> applied, because there's no way of getting SVN to figure out that the
> file called ClassFile.java is the same as the ClassFile.java that's
> been added by someone else on my behalf, and I have to overwrite my
> local copy to update. Kinda prevents doing any sensible work on newly
> created files between submission and application to be honest.
>
> Instead, I plan to sprint (well, jog, at least) to the next stable
> point, and then upload a whole wodge of code and leave it for a week
> or two to be applied before picking up again. I'm fairly close to
> being at that stage, but not quite. Where I am at is being able to
> generate (abstract) methods with exceptions and fields with constant
> (integer) values, so a bit further forward than last time. On the one
> hand, it means that I understand what needs to be done (no mean feat!)
> but on the other hand, there's still a fair bit to go. For a start,
> I'm going to need to process the actual bytecode for non-abstract
> methods (or indeed, any classes) before there's any point in it trying
> to be used for real, and there's still a few missing bits (Longs,
> Doubles, Floats) from the constant pools. I'm pretty sure Strings
> would work, but I've not tried them yet.
>
> Unfortunately, the code is really awful. The Segment.java is getting
> on for 1500 lines of code in a single class; and the attribute parsing
> contains both duplicated code and isn't as generic as it needs to be
> to handle other attributes; and the (in)visible annotations like
> @Overrides and similar are going to be a bit of a nightmare ...
>
> My plan is to get the code to a stage where it can start to be useful
> for extracting simple classes from a pack file, and then start
> generating test data which can be used for regressions. (There's a bit
> there at the moment, but it's not exactly a large coverage.) Once I've
> done that, I'll start tackling some of the refactoring which will
> result in less duplicated code and hopefully something that will be
> easier to look after in the future.
>
> Anyway, excuse the long rambling but I've been a bit quiet for a while
> and wanted to let people know I was still alive and kicking the code
> :-)
>
> Alex.
>

--

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

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

[Alexei Fedotov]

Anton,

I like your approach to result comparison. 10% can be default value
for some form field - anyone can change it if needed.

As for test execution time reported by JUnit, it is applicable for
stress tests as well if we gradually increase a load over time. Though
using ttime field for stress tests and documentation rankings is not
quite conventional.

Probably more conventional would be to parse
 for some metric. Does the site
already parse TEST-* files?

Thank you, Alexei

On 11/10/06, Anton Luht <[EMAIL PROTECTED]> wrote:

Hello, Alexei,

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

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

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




--
Thank you,
Alexei

Re: [drlvm][build] everyday SVN conflict on the version_svn_tag.h file

[Alexei Fedotov]

generate this file as part of the build process?

+1 for autogeneration of version_svn_tag.h


On 11/10/06, Vladimir Ivanov <[EMAIL PROTECTED]> wrote:

Hello everyone,

When I do my morning SVN update of drlvm module I see the permanent conflict
on the version_svn_tag.h file because this file is updated by build.

Actually, it is not a big problem while it not breaks vm build. But it will
be more convenient if these conflicts go out.

Could we generate this file as part of the build process (it has only 4
strings)? May be some other solutions exists?



I'm not too familiar with VM build so I'll be glad if somebody takes care
about it :)



 Thanks, Vladimir





--
Thank you,
Alexei

Re: [drlvm][em64t] build fails

[Alexei Fedotov]

DRLVM build always requires prebuilt classlib...

I believe ia32 classlib is ok until linking happens.

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

Same for me. I saw this yesterday. It is because HARMONY-1558 has changed
Class interfaces but didn't change x86_64 specific files. Now that I look at
the error messages, I think it is quite easy to fix the build. I'll take care
of weekend.

I wonder how did you get to building drlvm if classlib didn't build for you
because of -fpic problem? DRLVM build always requires prebuilt classlib...

On Friday 10 November 2006 23:53 Stefano Mazzocchi wrote:
> I've managed to get everything in place for a DRLVM build.. it runs for
> a while and then it fails with these errors:
>
>[cc]
> /home/stefano/src/harmony/drlvm/vm/vmcore/src/util/em64t/base/jit_lock_rt_s
>upport_em64t.cpp: In function 'void* rth_get_lil_monitor_enter()':
>[cc]
> /home/stefano/src/harmony/drlvm/vm/vmcore/src/util/em64t/base/jit_lock_rt_s
>upport_em64t.cpp:127: error: 'managed_null' is not a member of 'Class'
>[cc]
> /home/stefano/src/harmony/drlvm/vm/vmcore/src/util/em64t/base/jit_lock_rt_s
>upport_em64t.cpp: In function 'void* rth_get_lil_monitor_exit()':
>[cc]
> /home/stefano/src/harmony/drlvm/vm/vmcore/src/util/em64t/base/jit_lock_rt_s
>upport_em64t.cpp:265: error: 'managed_null' is not a member of 'Class'
>[cc]
> /home/stefano/src/harmony/drlvm/vm/vmcore/src/util/em64t/base/ini_em64t.cpp
>: In function 'void JIT_execute_method_default(void*, _jmethodID*,
> jvalue*, jvalue*)':
>[cc]
> /home/stefano/src/harmony/drlvm/vm/vmcore/src/util/em64t/base/ini_em64t.cpp
>:201: error: 'struct Class' has no member named 'name'
>[cc]
> /home/stefano/src/harmony/drlvm/vm/vmcore/src/util/em64t/base/ini_em64t.cpp
>:229: error: 'managed_null' is not a member of 'Class'
>[cc]
> /home/stefano/src/harmony/drlvm/vm/vmcore/src/util/em64t/base/ini_em64t.cpp
>:326: error: 'managed_null' is not a member of 'Class'
>[cc]
> /home/stefano/src/harmony/drlvm/vm/vmcore/src/util/em64t/base/ini_em64t.cpp
>:359: error: 'struct Class' has no member named 'name'
>
> Suggestions?

--
Gregory Shimansky, Intel Middleware Products Division




--
Thank you,
Alexei

Re: [drlvm][em64t] build fails

[Gregory Shimansky]

Same for me. I saw this yesterday. It is because HARMONY-1558 has changed 
Class interfaces but didn't change x86_64 specific files. Now that I look at 
the error messages, I think it is quite easy to fix the build. I'll take care 
of weekend.

I wonder how did you get to building drlvm if classlib didn't build for you 
because of -fpic problem? DRLVM build always requires prebuilt classlib...

On Friday 10 November 2006 23:53 Stefano Mazzocchi wrote:
> I've managed to get everything in place for a DRLVM build.. it runs for
> a while and then it fails with these errors:
>
>[cc]
> /home/stefano/src/harmony/drlvm/vm/vmcore/src/util/em64t/base/jit_lock_rt_s
>upport_em64t.cpp: In function ‘void* rth_get_lil_monitor_enter()’:
>[cc]
> /home/stefano/src/harmony/drlvm/vm/vmcore/src/util/em64t/base/jit_lock_rt_s
>upport_em64t.cpp:127: error: ‘managed_null’ is not a member of ‘Class’
>[cc]
> /home/stefano/src/harmony/drlvm/vm/vmcore/src/util/em64t/base/jit_lock_rt_s
>upport_em64t.cpp: In function ‘void* rth_get_lil_monitor_exit()’:
>[cc]
> /home/stefano/src/harmony/drlvm/vm/vmcore/src/util/em64t/base/jit_lock_rt_s
>upport_em64t.cpp:265: error: ‘managed_null’ is not a member of ‘Class’
>[cc]
> /home/stefano/src/harmony/drlvm/vm/vmcore/src/util/em64t/base/ini_em64t.cpp
>: In function ‘void JIT_execute_method_default(void*, _jmethodID*,
> jvalue*, jvalue*)’:
>[cc]
> /home/stefano/src/harmony/drlvm/vm/vmcore/src/util/em64t/base/ini_em64t.cpp
>:201: error: ‘struct Class’ has no member named ‘name’
>[cc]
> /home/stefano/src/harmony/drlvm/vm/vmcore/src/util/em64t/base/ini_em64t.cpp
>:229: error: ‘managed_null’ is not a member of ‘Class’
>[cc]
> /home/stefano/src/harmony/drlvm/vm/vmcore/src/util/em64t/base/ini_em64t.cpp
>:326: error: ‘managed_null’ is not a member of ‘Class’
>[cc]
> /home/stefano/src/harmony/drlvm/vm/vmcore/src/util/em64t/base/ini_em64t.cpp
>:359: error: ‘struct Class’ has no member named ‘name’
>
> Suggestions?

-- 
Gregory Shimansky, Intel Middleware Products Division

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

[Alexei Fedotov]

Nadya,
I think fixing a tutorial is a nice task for a newbie. I have filed a
JIRA about it:
http://issues.apache.org/jira/browse/HARMONY-2150

All,
Please check that I've correctly added your corrections to the document.

Alexei

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

Alexei,
Tutorials might be fine for mature projects, but I do not think ours is
ready for a big flow of users yet, that would require a tutorial.
So +1 for having a nice good  tutorial ... one day.
If there are volunteers to write the tutorial now, I'd be happy to help
though.

Thank you,
Nadya Morozova

-Original Message-
From: Fedotov, Alexei A [mailto:[EMAIL PROTECTED]
Sent: Friday, November 10, 2006 1:40 PM
To: harmony-dev@incubator.apache.org
Subject: RE: Re: [doc][drlvm] The document "Getting started with DRL" is
outdated

Guys,

I like good tutorials. I learned VIM using a tutorial. I don't need the
VIM tutorial any longer, but at the beginning it was useful.

   +1 for maintain Getting Started as is with minor changes

Why Eclipse was chosen for the tutorial? Our goal was to use Harmony for
Harmony development. I liked that idea.

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

>-Original Message-
>From: news [mailto:[EMAIL PROTECTED] On Behalf Of Egor Pasko
>Sent: Friday, November 10, 2006 1:29 PM
>To: harmony-dev@incubator.apache.org
>Subject: Re: [doc][drlvm] The document "Getting started with DRL" is
>outdated
>
>On the 0x21D day of Apache Harmony Pavel Ozhdikhin wrote:
>> Nadya,
>>
>> One more proposal about "Getting Started": let's remove all current
>content
>> and write something like following:
>>
>> "To the moment we got rid of all major differences from other Java
>> implementations, so to use DRLVM you can just build it (here goes
link to
>> readme with build instructions) and run as any other Java VM. For
>commonly
>> used command-line options please look into the Wiki page (link to
>Salikh's
>> page or to the document)."
>>
>> What do you think?
>
>1 page to hold only 4 lines of text? :)
>
>> Thanks,
>> Pavel
>>
>>
>> On 10 Nov 2006 14:29:59 +0600, Egor Pasko <[EMAIL PROTECTED]>
wrote:
>> >
>> > On the 0x21D day of Apache Harmony Nadezhda Morozova wrote:
>> > > Good day to you, Egor!
>> >
>> > evening, dark and snowy evening :)
>> >
>> > > What do you say about the getting started doc?
>> >
>> > I expressed it recently. General idea is that Harmony operates near
>> > the same as other JSE implementations. Almost all specifics is in
>> > extra options which we started collecting on Wiki for an extra
>> > HOWTO-like page (BTW, thanks to Salikh for starting the page).
>> >
>> > I believe, it is time to remove the "Getting Started". So, +1 to
Pavel
>> > Ozhdikhin here.
>> >
>> > BTW, I asked my dad to look at the website. Ideas for improvement
from
>> > him:
>> > 1) site-local search is useful for a beginner. Hm, Tomcat has it
with
>> > links to google search. We can have something as soon as we get to
the
>> > desired TLP :)
>> > 2) it is not obvious that site misprints/problems should be
reported
>> > to the mailing list. Commercial websites have something like
>> > "support/suggestions mailto". We can point mailto to the mailing
list
>:)
>> >
>> > > Thank you,
>> > > Nadya Morozova
>> > >
>> > > -Original Message-
>> > > From: news [mailto:[EMAIL PROTECTED] On Behalf Of Egor Pasko
>> > > Sent: Friday, November 10, 2006 8:55 AM
>> > > To: harmony-dev@incubator.apache.org
>> > > Subject: Re: [doc][drlvm] The document "Getting started with DRL"
is
>> > > outdated
>> > >
>> > > On the 0x21D day of Apache Harmony Nadezhda Morozova wrote:
>> > > > Egor,
>> > > > I generally like the idea of improving navigation over the site
-
>> > > > there's never too much of that. However, I am not sure whether
we
>need
>> > > > yet another separate page for introductory/guidance info. I
hope
>the
>> > > > starting page + the generic pages we have are mostly fine.
However,
>> > > > adding a link here and there to lead site visitors.
>> > > >
>> > > > Getting started could be a more specific project-oriented page.
>There,
>> > > > you can tell people to go download,
build
>> > > the
>> > > > code. After which, they can start using it just as any other
>> > > > RI-compatible jdk. With the exceptions, see our
>> > > > wiki pages.
>> > > > To use the vm, readers might need to use the following
options...
>> > > > If they want to read more on our VM, they can visit the
>> > > > component page. If no website page contains an
answer
>-
>> > > > they can read wiki faqa.
>> > > > .. or something like that :)
>> > >
>> > > Nadya, I really appreciate our efforts :) But this morning I woke
up
>> > > and looked the site structure with the eye of a beginner. And
could
>> > > not find any obvius flaws in the main structure. Left-side
collection
>> > > of links is in a very good shape, good for beginner-level
navigation
>> > > and contains almost all links you listed here.
>> > >
>> > > This

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

[Stefano Mazzocchi]

Gregory Shimansky wrote:
> Stefano Mazzocchi wrote:
>> Gregory Shimansky wrote:
>>> Stefano Mazzocchi wrote:
 Geir Magnusson Jr. wrote:
 anyway, I can't build the native part of harmony/classlib

 doing "ant build-native" results in

   classlib/depends/libs/linux.x86_64

 not being found.
>>> There should be prebuilt ICU binaries. You can build them yourself or
>>> you can take them from HARMONY-1678. Note, for me those libraries had
>>> libicu*.so.34.1 names while our build wants libicu*.so.34. So I had to
>>> set up links from *34.1 to *34.
>>
>> Ok, I've done this. But I still get the same error
>>
>>  [exec] cc -shared -Wl,--version-script,libhythr.exp \
>>  [exec] -Wl,-soname=libhythr.so  -o ../libhythr.so \
>>  [exec] ../shared/thread_copyright.o x86_64/thrhelp.o
>> x86_64/thrspinlock.o hythread.o ../shared/hythreadinspect.o
>> linuxonexit.o priority.o rasthrsup.o ../shared/rwmutex.o thrcreate.o
>> thrdsup.o ../shared/thrprof.o -lpthread \
>>  [exec] -Xlinker --start-group
>> /home/stefano/src/harmony/classlib/deploy/lib/libhypool.a
>> /home/stefano/src/harmony/classlib/deploy/lib/libhycommon.a -Xlinker
>> --end-group \
>>  [exec] -lc -lm -ldl
>>  [exec] /usr/bin/ld: x86_64/thrspinlock.o: relocation R_X86_64_PC32
>> against `hythread_yield' can not be used when making a shared object;
>> recompile with -fPIC
>>  [exec] /usr/bin/ld: final link failed: Bad value
>>  [exec] collect2: ld returned 1 exit status
>>  [exec] make: *** [../libhythr.so] Error 1
>>
>>
>> I've also tried to change make/properties.xml into
>>
>> --- properties.xml  (revision 472739)
>> +++ properties.xml  (working copy)
>> @@ -116,7 +116,7 @@
>>  
>>  
>>
>> -
>> +
>>  
>>  
>>  
>>
>> to see if case makes any difference (and 'ant rebuild-native') but it
>> didn't.
> 
> Did the -fPIC flag appear in compilation flags of hythread sources? I
> think ANT files is not the correct place to set C compilation flags.
> They are set somewhere in depends/build/make.include and
> depends/build/rules.mk.

Yup.

 [exec] cc -O1 -fPIC -DLINUX -D_REENTRANT -DIPv6_FUNCTION_SUPPORT
-DHYX86_64  -I/home/stefano/src/harmony/classlib/deploy/include
-I/home/stefano/src/harmony/classlib/deploy/jdk/include -I. -I../shared/
-fpic   -c -o ../shared/hythreadinspect.o ../shared/hythreadinspect.c

it appears *twice* actually, so maybe the cancel each-other out? ;-)

-- 
Stefano.

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

[Gregory Shimansky]

Stefano Mazzocchi wrote:

Gregory Shimansky wrote:

Stefano Mazzocchi wrote:

Geir Magnusson Jr. wrote:
anyway, I can't build the native part of harmony/classlib

doing "ant build-native" results in

  classlib/depends/libs/linux.x86_64

not being found.

There should be prebuilt ICU binaries. You can build them yourself or
you can take them from HARMONY-1678. Note, for me those libraries had
libicu*.so.34.1 names while our build wants libicu*.so.34. So I had to
set up links from *34.1 to *34.


Ok, I've done this. But I still get the same error

 [exec] cc -shared -Wl,--version-script,libhythr.exp \
 [exec] -Wl,-soname=libhythr.so  -o ../libhythr.so \
 [exec] ../shared/thread_copyright.o x86_64/thrhelp.o
x86_64/thrspinlock.o hythread.o ../shared/hythreadinspect.o
linuxonexit.o priority.o rasthrsup.o ../shared/rwmutex.o thrcreate.o
thrdsup.o ../shared/thrprof.o -lpthread \
 [exec] -Xlinker --start-group
/home/stefano/src/harmony/classlib/deploy/lib/libhypool.a
/home/stefano/src/harmony/classlib/deploy/lib/libhycommon.a -Xlinker
--end-group \
 [exec] -lc -lm -ldl
 [exec] /usr/bin/ld: x86_64/thrspinlock.o: relocation R_X86_64_PC32
against `hythread_yield' can not be used when making a shared object;
recompile with -fPIC
 [exec] /usr/bin/ld: final link failed: Bad value
 [exec] collect2: ld returned 1 exit status
 [exec] make: *** [../libhythr.so] Error 1


I've also tried to change make/properties.xml into

--- properties.xml  (revision 472739)
+++ properties.xml  (working copy)
@@ -116,7 +116,7 @@
 
 

-
+
 
 
 

to see if case makes any difference (and 'ant rebuild-native') but it
didn't.


Did the -fPIC flag appear in compilation flags of hythread sources? I 
think ANT files is not the correct place to set C compilation flags. 
They are set somewhere in depends/build/make.include and 
depends/build/rules.mk.


--
Gregory

[drlvm][em64t] build fails

[Stefano Mazzocchi]

I've managed to get everything in place for a DRLVM build.. it runs for
a while and then it fails with these errors:

   [cc]
/home/stefano/src/harmony/drlvm/vm/vmcore/src/util/em64t/base/jit_lock_rt_support_em64t.cpp:
In function ‘void* rth_get_lil_monitor_enter()’:
   [cc]
/home/stefano/src/harmony/drlvm/vm/vmcore/src/util/em64t/base/jit_lock_rt_support_em64t.cpp:127:
error: ‘managed_null’ is not a member of ‘Class’
   [cc]
/home/stefano/src/harmony/drlvm/vm/vmcore/src/util/em64t/base/jit_lock_rt_support_em64t.cpp:
In function ‘void* rth_get_lil_monitor_exit()’:
   [cc]
/home/stefano/src/harmony/drlvm/vm/vmcore/src/util/em64t/base/jit_lock_rt_support_em64t.cpp:265:
error: ‘managed_null’ is not a member of ‘Class’
   [cc]
/home/stefano/src/harmony/drlvm/vm/vmcore/src/util/em64t/base/ini_em64t.cpp:
In function ‘void JIT_execute_method_default(void*, _jmethodID*,
jvalue*, jvalue*)’:
   [cc]
/home/stefano/src/harmony/drlvm/vm/vmcore/src/util/em64t/base/ini_em64t.cpp:201:
error: ‘struct Class’ has no member named ‘name’
   [cc]
/home/stefano/src/harmony/drlvm/vm/vmcore/src/util/em64t/base/ini_em64t.cpp:229:
error: ‘managed_null’ is not a member of ‘Class’
   [cc]
/home/stefano/src/harmony/drlvm/vm/vmcore/src/util/em64t/base/ini_em64t.cpp:326:
error: ‘managed_null’ is not a member of ‘Class’
   [cc]
/home/stefano/src/harmony/drlvm/vm/vmcore/src/util/em64t/base/ini_em64t.cpp:359:
error: ‘struct Class’ has no member named ‘name’

Suggestions?

-- 
Stefano.

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

[Stefano Mazzocchi]

Gregory Shimansky wrote:
> Stefano Mazzocchi wrote:
>> Geir Magnusson Jr. wrote:
>> anyway, I can't build the native part of harmony/classlib
>>
>> doing "ant build-native" results in
>>
>>   classlib/depends/libs/linux.x86_64
>>
>> not being found.
> 
> There should be prebuilt ICU binaries. You can build them yourself or
> you can take them from HARMONY-1678. Note, for me those libraries had
> libicu*.so.34.1 names while our build wants libicu*.so.34. So I had to
> set up links from *34.1 to *34.

Ok, I've done this. But I still get the same error

 [exec] cc -shared -Wl,--version-script,libhythr.exp \
 [exec] -Wl,-soname=libhythr.so  -o ../libhythr.so \
 [exec] ../shared/thread_copyright.o x86_64/thrhelp.o
x86_64/thrspinlock.o hythread.o ../shared/hythreadinspect.o
linuxonexit.o priority.o rasthrsup.o ../shared/rwmutex.o thrcreate.o
thrdsup.o ../shared/thrprof.o -lpthread \
 [exec] -Xlinker --start-group
/home/stefano/src/harmony/classlib/deploy/lib/libhypool.a
/home/stefano/src/harmony/classlib/deploy/lib/libhycommon.a -Xlinker
--end-group \
 [exec] -lc -lm -ldl
 [exec] /usr/bin/ld: x86_64/thrspinlock.o: relocation R_X86_64_PC32
against `hythread_yield' can not be used when making a shared object;
recompile with -fPIC
 [exec] /usr/bin/ld: final link failed: Bad value
 [exec] collect2: ld returned 1 exit status
 [exec] make: *** [../libhythr.so] Error 1


I've also tried to change make/properties.xml into

--- properties.xml  (revision 472739)
+++ properties.xml  (working copy)
@@ -116,7 +116,7 @@
 
 

-
+
 
 
 

to see if case makes any difference (and 'ant rebuild-native') but it
didn't.

Suggestions?

-- 
Stefano.

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

[Gregory Shimansky]

Gregory Shimansky wrote:

Stefano Mazzocchi wrote:

Geir Magnusson Jr. wrote:
anyway, I can't build the native part of harmony/classlib

doing "ant build-native" results in

  classlib/depends/libs/linux.x86_64

not being found.


There should be prebuilt ICU binaries. You can build them yourself or 
you can take them from HARMONY-1678. Note, for me those libraries had 


Oops. It should be HARMONY-1676

libicu*.so.34.1 names while our build wants libicu*.so.34. So I had to 
set up links from *34.1 to *34.



If I try to make a symlink between linux.x86_64 and linux.x86_32 (no
idea what I'm doing here, just trying things out), I get


I think this is a wrong thing to do. You cannot link together code built 
for different architectures. Linker should have told you that but 
apparently it encountered an internal error.


Also don't use x86 versions of lib*.a for libraries in 
depends/libs/build/{jpeg,lcms,png}/. That shouldn't work. You need to 
find 64-bit versions on your system or build them yourself.


Yesterday I built classlib native stuff successfully (see [classlib] 
Building on x86_64 thread) but it wasn't easy. Somehow lib*.a static 
libraries weren't meant to be linked to shared libraries on SUSE9, so I 
had to replace links in depends/libs/build/{jpeg,lcms,png}/ with links 
to shared ones. It seem to have worked, but I couldn't check how well 
classlib works since drlvm build on x86_64 is now broken, most likely by 
HARMONY-1558.



build-native:
 [exec] make: Nothing to be done for `all'.
 [exec] make: Nothing to be done for `all'.
 [exec] make: Nothing to be done for `all'.
 [copy] Copying 1 file to
/home/stefano/src/harmony/classlib/deploy/jdk/jre/bin
 [exec] cc -shared -Wl,--version-script,libhythr.exp \
 [exec] -Wl,-soname=libhythr.so  -o ../libhythr.so \
 [exec] ../shared/thread_copyright.o x86_64/thrhelp.o
x86_64/thrspinlock.o hythread.o ../shared/hythreadinspect.o
linuxonexit.o priority.o rasthrsup.o ../shared/rwmutex.o thrcreate.o
thrdsup.o ../shared/thrprof.o -lpthread \
 [exec] -Xlinker --start-group
/home/stefano/src/harmony/classlib/deploy/lib/libhypool.a
/home/stefano/src/harmony/classlib/deploy/lib/libhycommon.a -Xlinker
--end-group \
 [exec] -lc -lm -ldl
 [exec] /usr/bin/ld: x86_64/thrspinlock.o: relocation R_X86_64_PC32
against `hythread_yield' can not be used when making a shared object;
recompile with -fPIC
 [exec] /usr/bin/ld: final link failed: Bad value
 [exec] collect2: ld returned 1 exit status
 [exec] make: *** [../libhythr.so] Error 1

googling it up a little finds

 http://sources.redhat.com/ml/binutils/2005-04/msg00649.html

which is a reference to a GCC bug that was apparently fixed a long 
time go.


Ah btw,

[EMAIL PROTECTED] ~/src/harmony/classlib $ gcc --version
gcc (GCC) 4.0.3 (Ubuntu 4.0.3-1ubuntu5)

[EMAIL PROTECTED] ~/src/harmony/classlib $ ld --version
GNU ld version 2.16.91 20060118 Debian GNU/Linux

[EMAIL PROTECTED] ~/src/harmony/classlib $ uname -a
Linux harmony-em64t 2.6.15-27-amd64-generic #1 SMP PREEMPT Sat Sep 16
01:50:50 UTC 2006 x86_64 GNU

Please, bare with my ignorance, I have *zero* knowledge on native stuff
(I moved from x86 assembly on windows to java without going thru C ;-)

No idea what to do now, please help and I can reward you with a freshly
juiced gump run :-)







--
Gregory

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

[Gregory Shimansky]

Stefano Mazzocchi wrote:

Geir Magnusson Jr. wrote:
anyway, I can't build the native part of harmony/classlib

doing "ant build-native" results in

  classlib/depends/libs/linux.x86_64

not being found.


There should be prebuilt ICU binaries. You can build them yourself or 
you can take them from HARMONY-1678. Note, for me those libraries had 
libicu*.so.34.1 names while our build wants libicu*.so.34. So I had to 
set up links from *34.1 to *34.



If I try to make a symlink between linux.x86_64 and linux.x86_32 (no
idea what I'm doing here, just trying things out), I get


I think this is a wrong thing to do. You cannot link together code built 
for different architectures. Linker should have told you that but 
apparently it encountered an internal error.


Also don't use x86 versions of lib*.a for libraries in 
depends/libs/build/{jpeg,lcms,png}/. That shouldn't work. You need to 
find 64-bit versions on your system or build them yourself.


Yesterday I built classlib native stuff successfully (see [classlib] 
Building on x86_64 thread) but it wasn't easy. Somehow lib*.a static 
libraries weren't meant to be linked to shared libraries on SUSE9, so I 
had to replace links in depends/libs/build/{jpeg,lcms,png}/ with links 
to shared ones. It seem to have worked, but I couldn't check how well 
classlib works since drlvm build on x86_64 is now broken, most likely by 
HARMONY-1558.



build-native:
 [exec] make: Nothing to be done for `all'.
 [exec] make: Nothing to be done for `all'.
 [exec] make: Nothing to be done for `all'.
 [copy] Copying 1 file to
/home/stefano/src/harmony/classlib/deploy/jdk/jre/bin
 [exec] cc -shared -Wl,--version-script,libhythr.exp \
 [exec] -Wl,-soname=libhythr.so  -o ../libhythr.so \
 [exec] ../shared/thread_copyright.o x86_64/thrhelp.o
x86_64/thrspinlock.o hythread.o ../shared/hythreadinspect.o
linuxonexit.o priority.o rasthrsup.o ../shared/rwmutex.o thrcreate.o
thrdsup.o ../shared/thrprof.o -lpthread \
 [exec] -Xlinker --start-group
/home/stefano/src/harmony/classlib/deploy/lib/libhypool.a
/home/stefano/src/harmony/classlib/deploy/lib/libhycommon.a -Xlinker
--end-group \
 [exec] -lc -lm -ldl
 [exec] /usr/bin/ld: x86_64/thrspinlock.o: relocation R_X86_64_PC32
against `hythread_yield' can not be used when making a shared object;
recompile with -fPIC
 [exec] /usr/bin/ld: final link failed: Bad value
 [exec] collect2: ld returned 1 exit status
 [exec] make: *** [../libhythr.so] Error 1

googling it up a little finds

 http://sources.redhat.com/ml/binutils/2005-04/msg00649.html

which is a reference to a GCC bug that was apparently fixed a long time go.

Ah btw,

[EMAIL PROTECTED] ~/src/harmony/classlib $ gcc --version
gcc (GCC) 4.0.3 (Ubuntu 4.0.3-1ubuntu5)

[EMAIL PROTECTED] ~/src/harmony/classlib $ ld --version
GNU ld version 2.16.91 20060118 Debian GNU/Linux

[EMAIL PROTECTED] ~/src/harmony/classlib $ uname -a
Linux harmony-em64t 2.6.15-27-amd64-generic #1 SMP PREEMPT Sat Sep 16
01:50:50 UTC 2006 x86_64 GNU

Please, bare with my ignorance, I have *zero* knowledge on native stuff
(I moved from x86 assembly on windows to java without going thru C ;-)

No idea what to do now, please help and I can reward you with a freshly
juiced gump run :-)




--
Gregory

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

[Stefano Mazzocchi]

Geir Magnusson Jr. wrote:
> Get ahold of yourself, man!  You're going to get me fired! :)

> model name  :   Intel(R) Pentium(R) D CPU 3.20GHz

ohhh, sorry about that :-)

anyway, I can't build the native part of harmony/classlib

doing "ant build-native" results in

  classlib/depends/libs/linux.x86_64

not being found.

If I try to make a symlink between linux.x86_64 and linux.x86_32 (no
idea what I'm doing here, just trying things out), I get

build-native:
 [exec] make: Nothing to be done for `all'.
 [exec] make: Nothing to be done for `all'.
 [exec] make: Nothing to be done for `all'.
 [copy] Copying 1 file to
/home/stefano/src/harmony/classlib/deploy/jdk/jre/bin
 [exec] cc -shared -Wl,--version-script,libhythr.exp \
 [exec] -Wl,-soname=libhythr.so  -o ../libhythr.so \
 [exec] ../shared/thread_copyright.o x86_64/thrhelp.o
x86_64/thrspinlock.o hythread.o ../shared/hythreadinspect.o
linuxonexit.o priority.o rasthrsup.o ../shared/rwmutex.o thrcreate.o
thrdsup.o ../shared/thrprof.o -lpthread \
 [exec] -Xlinker --start-group
/home/stefano/src/harmony/classlib/deploy/lib/libhypool.a
/home/stefano/src/harmony/classlib/deploy/lib/libhycommon.a -Xlinker
--end-group \
 [exec] -lc -lm -ldl
 [exec] /usr/bin/ld: x86_64/thrspinlock.o: relocation R_X86_64_PC32
against `hythread_yield' can not be used when making a shared object;
recompile with -fPIC
 [exec] /usr/bin/ld: final link failed: Bad value
 [exec] collect2: ld returned 1 exit status
 [exec] make: *** [../libhythr.so] Error 1

googling it up a little finds

 http://sources.redhat.com/ml/binutils/2005-04/msg00649.html

which is a reference to a GCC bug that was apparently fixed a long time go.

Ah btw,

[EMAIL PROTECTED] ~/src/harmony/classlib $ gcc --version
gcc (GCC) 4.0.3 (Ubuntu 4.0.3-1ubuntu5)

[EMAIL PROTECTED] ~/src/harmony/classlib $ ld --version
GNU ld version 2.16.91 20060118 Debian GNU/Linux

[EMAIL PROTECTED] ~/src/harmony/classlib $ uname -a
Linux harmony-em64t 2.6.15-27-amd64-generic #1 SMP PREEMPT Sat Sep 16
01:50:50 UTC 2006 x86_64 GNU

Please, bare with my ignorance, I have *zero* knowledge on native stuff
(I moved from x86 assembly on windows to java without going thru C ;-)

No idea what to do now, please help and I can reward you with a freshly
juiced gump run :-)

-- 
Stefano.

Re: [drlvm][classlib] thread library - let there be one!

[Weldon Washburn]

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


2006/11/10, Weldon Washburn <[EMAIL PROTECTED]>:
> hmm it seems that we need to create "kernel natives", the C version
> of java kernel classes.  The expectation is that the JVM supplier would
> write their own kernel natives.  And the classlib native code would only
> call kernel natives.  Thoughts?

I don't understand this. We already have VMI (for common purposes),
and even if hythread shed implementation, it preserves functioning as
interface to threading nevertheless. If this means we should somehow
restructure portlib module - please add some more reasoning?



Actually Andrey Chernyshev already stated the case in this thread about 8
hours ago.  Since its nicely articulated, I won't repeat.  Maybe you can ask
questions about Andrey's statement?

I am just now starting to look at threading design of DRLVM.  What I see is
a rather large number of threading APIs that are adding confusion.  There is
portlib/hythread/hy, Apache Portable Runtime in addition to windowsxp
and posix/linux.  I have heard that VMI is in the mix somewhere.  I just
haven't stumbled on it yet.




>
>
> On 11/10/06, Andrey Chernyshev <[EMAIL PROTECTED]> wrote:
> >
> > On 10/26/06, Angela Lin <[EMAIL PROTECTED]> wrote:
> > > On 10/24/06, Weldon Washburn <[EMAIL PROTECTED]> wrote:
> > > >
> > > > If an arbitrary commercial JVM decided to use classlib, will it
need
> > to be
> > > > modified to reflect the existing Harmony Classlib threading model?
> > >
> > > This is the case no matter how you split the thread library.
Whatever
> > > interface you specify for the classlib will need to be supported by
> > > the VM.
> > >
> > > > Also, does this mean VM design is constrained by classlib
design?  And
> > > > classlib  design is constrained by J9 design?
> > >
> > > The classlib and the VM have certain dependencies on each other.
This
> > > is not a J9-specific issue.
> > >
> > > I would aim for a thread API that is generic enough to support
> > > multiple implementations.
> >
> > I think it may be hard (if possible at all) to create high-level
> > threading library which would make just every VM happy. For instance,
> > DRLVM has a complex synchronization scheme with garbage collector
> > which is built into the threading library (for example, each time
> > thread goes into wait state, it must instruct the GC that the thread
> > can be garbage collected). There also could be VM-specific
> > optimizations for monitors which are tied to the object layout used in
> > a particular VM.
> >
> > Finally, there might be pure-Java written VM's which may choose to
> > implement threading library almost entirely in Java (may be on top of
> > j.u.concurrent API ?), borrowing probably only park/unpark, atomic and
> > may be sort of fork operations from the native code. How could we have
> > a threading library which will work equally for all VM's?
> >
> > I agree that bypassing layer (2) by the classlib can be undesirable
> > because of loosing track for thread/lock states. So it seems that:
> > - both VM and classlib need to use single thread library, and at the
> > same level (or, saying that differently, Java code and native code
> > from classlib should use same threading lib);
> > -  threading lib is likely be VM-specific (consider DRLVM as an
example)
> >
> > If we agree with the above, doesn't it just mean that the hythr must
> > be declared as a part of VM? Classlib may probably continue to keep a
> > "stub" library for the compilation purposes. But there must be the
> > possibility for other VM's to easily replace it with it's own version.
> > I guess we do something similar with the luni-kernel-stubs.jar.
> >
> > >
> > > Mature VMs that switch to the Harmony classlib would probably
> > > implement a portability layer between the existing VM's thread model
> > > and the Harmony thread API.
> >
> > I guess mature VM's would likely to have their own very carefully
> > written and optimized threading libraries, integrated with GC, JIT
> > e.t.c. It will be easier for them to provide a suitable interface for
> > classlib rather than rewrite VM on top of hythread, no matter how
> > perfect is it.
> >
> >
> > >
> > > Has anyone considered how ThreadMXBean would be supported by the
> > > proposed classlib thread API subset?
> >
> > May be ThreadMXBean is just a good candidate for the kernel class set?
> > At least the spec says "interface for the thread system of the Java
> > virtual machine". I guess other MXBeans are also interfaces to some of
> > VM services.
> >
> >
> > Thanks,
> > Andrey.
> >
> >
> > >
> > > > On 10/24/06, Angela Lin <[EMAIL PROTECTED]> wrote:
> > > > >
> > > > > Consider the group of monitor-related functionality: enter/exit,
> > > > > wait/notify, and interrupt. The implementations of these
functions
> > are
> > > > > closely related in the J9-derived hythread, particularly for
3-tier
> > > > > locking. We need to coordinate when we lock the thread mutex,
w

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

[Stefano Mazzocchi]

Dalibor Topic wrote:
> Stefano Mazzocchi  apache.org> writes:
> 
>> Sometimes some climbers manage to get to the other side to find that
>> some people are very welcoming and appreciative of cultural differences
>> while others not so much.
> 
> What killed Harmony as the project it was planned to be wasn't people, in my
> opinion. Everyone put a lot of effort into it.
> 
> It was stuck in time for months, betwen a non-existent GPLv3, and a 
> non-existant
> ASF third party license policy, without either the ASF having the ability to
> accept code under anything other then the apache license, and the FSF having 
> the
> ability to relicense Classpath to apache license exclusively, without screwing
> developers of GPLd VMs out of a class library. Everyone was running in 
> circles.
> 
> Both the ASF and FSF have learned from that failure. ASF figured out that 
> having
> a third party license policy would work greatly in their favour, the FSF 
> figured
> out that they'd better listen to ASF's ideas and make sure GPLv3 and all that
> stuff is actually fine.
> 
> Structurally, I'd say that the ASF was not the right place at the right time 
> to
> pull such a project off, since we got stuck so hard on apparently 
> insurmountable
> issues of policy. Same would have most likely happened with the FSF, though, 
> so
> with the hindsight, I think a third party, neutral ground without policies
> already cast in stone would have worked out much better. I guess Sun figured
> that out, too, and I hope they are successful.
> 
> After the Harmony experience, I don't think that ASF or FSF are the perfect
> place for a project that goes wildly beyond their respective constituencies
> (i.e. the people who really, really like the one true apache way or the one 
> true
> FSF way). On the other hand, the split has worked in each project's favor, to
> some degree. It has also left a lot of people who put their heart in it rather
> bitter about the failure to make it all work as planned.
> 
> Maybe one day we'll all meet together and exchange those war stories over
> beverages in bar. It's been a great pleasure to help get all of this rolling
> with you, Geir, Leo, Davanum, and the other guys, and watch Geir and the team
> make Harmony rock.

+100!

But there is one thing to be said: I still believe that both the ASF and
the FSF have much stronger community nurturing skills than Sun.

Sun going GPL is not going to change that *and* will allow "free java"
to get to certification faster.

So, pretty soon, there will be three, not one, certified FOSS java
virtual machines.

Don't know about you, I would call that a resounding success for those
like us who wanted the ability to see the results of the FOSS
development and innovation model applied to the inner workings of a Java
virtual machine.

And, if in doing so, a more compatible GPLv3 comes along, helped by
those like us who would enjoy more license compatibility between the ASF
and the FSF, I call that a success as well.

So, yes, maybe we could have done it differently, in a more neutral
ground. But even so, it wasn't so bad after all :-)

-- 
Stefano.

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

[Morozova, Nadezhda]

See below.

Thank you, 
Nadya Morozova
 

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

On the 0x21D day of Apache Harmony Nadezhda Morozova wrote:
> +1 for having some getting started info on a separate page. 
> There are some things that need to stand out promptly, and probably
> newbie info is one of them (I mean, I'd want to have such a page when
I
> got started with this project). 

you mean, the left-side collection _does not suit_ as "getting started"
info? To me it is fine, I am a bad judge here though (far from beginner)

[nm] the navigation is fine for a contributor to the project, but might
not be friendly for someone starting with using our vm. The navigation
leads to many places, including the ones such a reader needs. But I have
had a feeling that I understand how the developer's project works
without having a clear idea of how to start using what they are
producing. It's a personal experience only - and of a time long gone :) 

> We can expand the text suggested by Pavel by adding:
> * links to nice tutorials for other vms

volunteers to make the list are welcome. I cannot remember a single
example, sorry.

[nm] that's bad. If we don't know good detailed tutorials that equally
apply to us, we'd have to write one ourselves!

> * a short section to say how is a vm used with a couple of examples;
> this won't take too much effort/maintenance but would be a nice clear
> intro, that's not another click away on some site of another project

do "Harmony in Eclipse" and "DRLVM Command-line Tutorial" solve the
problem?

[nm] see my other response to you on the same thread.

> Thank you, 
> Nadya Morozova
>  
> 
> -Original Message-
> From: news [mailto:[EMAIL PROTECTED] On Behalf Of Egor Pasko
> Sent: Friday, November 10, 2006 1:29 PM
> To: harmony-dev@incubator.apache.org
> Subject: Re: [doc][drlvm] The document "Getting started with DRL" is
> outdated
> 
> On the 0x21D day of Apache Harmony Pavel Ozhdikhin wrote:
> > Nadya,
> > 
> > One more proposal about "Getting Started": let's remove all current
> content
> > and write something like following:
> > 
> > "To the moment we got rid of all major differences from other Java
> > implementations, so to use DRLVM you can just build it (here goes
link
> to
> > readme with build instructions) and run as any other Java VM. For
> commonly
> > used command-line options please look into the Wiki page (link to
> Salikh's
> > page or to the document)."
> > 
> > What do you think?
> 
> 1 page to hold only 4 lines of text? :)
> 
> > Thanks,
> > Pavel
> > 
> > 
> > On 10 Nov 2006 14:29:59 +0600, Egor Pasko <[EMAIL PROTECTED]>
> wrote:
> > >
> > > On the 0x21D day of Apache Harmony Nadezhda Morozova wrote:
> > > > Good day to you, Egor!
> > >
> > > evening, dark and snowy evening :)
> > >
> > > > What do you say about the getting started doc?
> > >
> > > I expressed it recently. General idea is that Harmony operates
near
> > > the same as other JSE implementations. Almost all specifics is in
> > > extra options which we started collecting on Wiki for an extra
> > > HOWTO-like page (BTW, thanks to Salikh for starting the page).
> > >
> > > I believe, it is time to remove the "Getting Started". So, +1 to
> Pavel
> > > Ozhdikhin here.
> > >
> > > BTW, I asked my dad to look at the website. Ideas for improvement
> from
> > > him:
> > > 1) site-local search is useful for a beginner. Hm, Tomcat has it
> with
> > > links to google search. We can have something as soon as we get to
> the
> > > desired TLP :)
> > > 2) it is not obvious that site misprints/problems should be
reported
> > > to the mailing list. Commercial websites have something like
> > > "support/suggestions mailto". We can point mailto to the mailing
> list :)
> > >
> > > > Thank you,
> > > > Nadya Morozova
> > > >
> > > > -Original Message-
> > > > From: news [mailto:[EMAIL PROTECTED] On Behalf Of Egor Pasko
> > > > Sent: Friday, November 10, 2006 8:55 AM
> > > > To: harmony-dev@incubator.apache.org
> > > > Subject: Re: [doc][drlvm] The document "Getting started with
DRL"
> is
> > > > outdated
> > > >
> > > > On the 0x21D day of Apache Harmony Nadezhda Morozova wrote:
> > > > > Egor,
> > > > > I generally like the idea of improving navigation over the
site
> -
> > > > > there's never too much of that. However, I am not sure whether
> we need
> > > > > yet another separate page for introductory/guidance info. I
hope
> the
> > > > > starting page + the generic pages we have are mostly fine.
> However,
> > > > > adding a link here and there to lead site visitors.
> > > > >
> > > > > Getting started could be a more specific project-oriented
page.
> There,
> > > > > you can tell people to go download,
> build
> > > > the
> > > > > code. After which, they can start using it just as any other
> > > > 

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

[Morozova, Nadezhda]

Egor, 
I think we're mixing things up a bit, or at least our perceptions of
various docs. I'd not call what you're suggesting a tutorial - it's more
of a howto doc, right? We are lucky to have Salikh write this "How to
write a GC?" Doc - do you mean something similar for "DRLVM Command-line
Args Tutorial"?

As suggested earlier, we can store drlvm+eclipse specifics on another
page = see JIRA 2009. cmd options reference is on wiki, but a short
howto will be marvelous - illustrating usage of common options, solving
typical problems by using our vm correctly, etc. 
Does anybody volunteer to help?

Thank you, 
Nadya Morozova
 

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

On the 0x21D day of Apache Harmony Nadezhda Morozova wrote:
> Alexei,
> Tutorials might be fine for mature projects, but I do not think ours
is
> ready for a big flow of users yet, that would require a tutorial.

we _are_ mature for a small tutorial :)

> So +1 for having a nice good  tutorial ... one day. 
> If there are volunteers to write the tutorial now, I'd be happy to
help
> though.

well, actually, I love tutorials too, especially the one for VIM :)
some contraversal inside me..fighting..done

let's then say "A Short Eclipse Tutorial with Harmony", and then
"DRLVM Command-line Args Tutorial". Howabout that?

> Thank you, 
> Nadya Morozova
>  
> -Original Message-
> From: Fedotov, Alexei A [mailto:[EMAIL PROTECTED] 
> Sent: Friday, November 10, 2006 1:40 PM
> To: harmony-dev@incubator.apache.org
> Subject: RE: Re: [doc][drlvm] The document "Getting started with DRL"
is
> outdated
> 
> Guys,
> 
> I like good tutorials. I learned VIM using a tutorial. I don't need
the
> VIM tutorial any longer, but at the beginning it was useful.
> 
>   +1 for maintain Getting Started as is with minor changes
> 
> Why Eclipse was chosen for the tutorial? Our goal was to use Harmony
for
> Harmony development. I liked that idea.
> 
> With best regards,
> Alexei Fedotov,
> Intel Java & XML Engineering
> 
> >-Original Message-
> >From: news [mailto:[EMAIL PROTECTED] On Behalf Of Egor Pasko
> >Sent: Friday, November 10, 2006 1:29 PM
> >To: harmony-dev@incubator.apache.org
> >Subject: Re: [doc][drlvm] The document "Getting started with DRL" is
> >outdated
> >
> >On the 0x21D day of Apache Harmony Pavel Ozhdikhin wrote:
> >> Nadya,
> >>
> >> One more proposal about "Getting Started": let's remove all current
> >content
> >> and write something like following:
> >>
> >> "To the moment we got rid of all major differences from other Java
> >> implementations, so to use DRLVM you can just build it (here goes
> link to
> >> readme with build instructions) and run as any other Java VM. For
> >commonly
> >> used command-line options please look into the Wiki page (link to
> >Salikh's
> >> page or to the document)."
> >>
> >> What do you think?
> >
> >1 page to hold only 4 lines of text? :)
> >
> >> Thanks,
> >> Pavel
> >>
> >>
> >> On 10 Nov 2006 14:29:59 +0600, Egor Pasko <[EMAIL PROTECTED]>
> wrote:
> >> >
> >> > On the 0x21D day of Apache Harmony Nadezhda Morozova wrote:
> >> > > Good day to you, Egor!
> >> >
> >> > evening, dark and snowy evening :)
> >> >
> >> > > What do you say about the getting started doc?
> >> >
> >> > I expressed it recently. General idea is that Harmony operates
near
> >> > the same as other JSE implementations. Almost all specifics is in
> >> > extra options which we started collecting on Wiki for an extra
> >> > HOWTO-like page (BTW, thanks to Salikh for starting the page).
> >> >
> >> > I believe, it is time to remove the "Getting Started". So, +1 to
> Pavel
> >> > Ozhdikhin here.
> >> >
> >> > BTW, I asked my dad to look at the website. Ideas for improvement
> from
> >> > him:
> >> > 1) site-local search is useful for a beginner. Hm, Tomcat has it
> with
> >> > links to google search. We can have something as soon as we get
to
> the
> >> > desired TLP :)
> >> > 2) it is not obvious that site misprints/problems should be
> reported
> >> > to the mailing list. Commercial websites have something like
> >> > "support/suggestions mailto". We can point mailto to the mailing
> list
> >:)
> >> >
> >> > > Thank you,
> >> > > Nadya Morozova
> >> > >
> >> > > -Original Message-
> >> > > From: news [mailto:[EMAIL PROTECTED] On Behalf Of Egor Pasko
> >> > > Sent: Friday, November 10, 2006 8:55 AM
> >> > > To: harmony-dev@incubator.apache.org
> >> > > Subject: Re: [doc][drlvm] The document "Getting started with
DRL"
> is
> >> > > outdated
> >> > >
> >> > > On the 0x21D day of Apache Harmony Nadezhda Morozova wrote:
> >> > > > Egor,
> >> > > > I generally like the idea of improving navigation over the
site
> -
> >> > > > there's never too much of that. However, I am not sure
whether
> we
> >need
> >> > > > yet another separate 

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

[Morozova, Nadezhda]

Geir, all,
I did not mean to delete info that is relevant. It's just that the old
getting started is old and not so good. Specifics: 
- all cmd options are out of date; recent options are stored on wiki and
explained in jit-related docs (we'll seem them once the unresolved jiras
are applied); old stuff should be deleted
- working with eclipse scenarios are now huge (too many screenshots with
little value) and give info not related to our project; we decided to
remove the bulk of screenshots and info that is about eclipse and not
about us; the drlvm+eclipse specifics will be stored on the page devoted
to eclipse - so we keep the important stuff and send readers to
eclipse.org for eclipse generics - a patch is now available and I also
launched a poll to see if anyone has info to share.
- many specific items are out of date 

If you go over the content of the old getting started doc and flesh out
all the unneeded stuff, it only leaves a small heap of useful info. We
shall try not to lose those bits. 
I also got it that we'll have some getting started info, but probably
different from what we used to have. I'd try my best to produce a draft
next week, but I'm not a guru to know what a tutorial for beginners
should include :(

Thank you, 
Nadya Morozova
 
-Original Message-
From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED] 
Sent: Friday, November 10, 2006 5:55 PM
To: harmony-dev@incubator.apache.org
Subject: Re: [doc][drlvm] The document "Getting started with DRL" is
outdated



Morozova, Nadezhda wrote:
> Alexei,
> Tutorials might be fine for mature projects, but I do not think ours
is
> ready for a big flow of users yet, that would require a tutorial.
> So +1 for having a nice good  tutorial ... one day. 
> If there are volunteers to write the tutorial now, I'd be happy to
help
> though.

Isn't that what the getting started page for DRLVM is?  why take 
information away?  I agre, we should clean things up if they are wrong, 
but as long as it's organized, we should keep stuff.

geir

> 
> Thank you, 
> Nadya Morozova
>  
> -Original Message-
> From: Fedotov, Alexei A [mailto:[EMAIL PROTECTED] 
> Sent: Friday, November 10, 2006 1:40 PM
> To: harmony-dev@incubator.apache.org
> Subject: RE: Re: [doc][drlvm] The document "Getting started with DRL"
is
> outdated
> 
> Guys,
> 
> I like good tutorials. I learned VIM using a tutorial. I don't need
the
> VIM tutorial any longer, but at the beginning it was useful.
> 
>   +1 for maintain Getting Started as is with minor changes
> 
> Why Eclipse was chosen for the tutorial? Our goal was to use Harmony
for
> Harmony development. I liked that idea.
> 
> With best regards,
> Alexei Fedotov,
> Intel Java & XML Engineering
> 
>> -Original Message-
>> From: news [mailto:[EMAIL PROTECTED] On Behalf Of Egor Pasko
>> Sent: Friday, November 10, 2006 1:29 PM
>> To: harmony-dev@incubator.apache.org
>> Subject: Re: [doc][drlvm] The document "Getting started with DRL" is
>> outdated
>>
>> On the 0x21D day of Apache Harmony Pavel Ozhdikhin wrote:
>>> Nadya,
>>>
>>> One more proposal about "Getting Started": let's remove all current
>> content
>>> and write something like following:
>>>
>>> "To the moment we got rid of all major differences from other Java
>>> implementations, so to use DRLVM you can just build it (here goes
> link to
>>> readme with build instructions) and run as any other Java VM. For
>> commonly
>>> used command-line options please look into the Wiki page (link to
>> Salikh's
>>> page or to the document)."
>>>
>>> What do you think?
>> 1 page to hold only 4 lines of text? :)
>>
>>> Thanks,
>>> Pavel
>>>
>>>
>>> On 10 Nov 2006 14:29:59 +0600, Egor Pasko <[EMAIL PROTECTED]>
> wrote:
 On the 0x21D day of Apache Harmony Nadezhda Morozova wrote:
> Good day to you, Egor!
 evening, dark and snowy evening :)

> What do you say about the getting started doc?
 I expressed it recently. General idea is that Harmony operates near
 the same as other JSE implementations. Almost all specifics is in
 extra options which we started collecting on Wiki for an extra
 HOWTO-like page (BTW, thanks to Salikh for starting the page).

 I believe, it is time to remove the "Getting Started". So, +1 to
> Pavel
 Ozhdikhin here.

 BTW, I asked my dad to look at the website. Ideas for improvement
> from
 him:
 1) site-local search is useful for a beginner. Hm, Tomcat has it
> with
 links to google search. We can have something as soon as we get to
> the
 desired TLP :)
 2) it is not obvious that site misprints/problems should be
> reported
 to the mailing list. Commercial websites have something like
 "support/suggestions mailto". We can point mailto to the mailing
> list
>> :)
> Thank you,
> Nadya Morozova
>
> -Original Message-
> From: news [mailto:[EMAIL PROTECTED] On Behalf Of Egor Pasko
> Sent: Friday, November 10, 2006 8:55 AM
> To: harmony-dev@

Re: [drlvm][classlib] thread library - let there be one!

[Alexey Varlamov]

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

hmm it seems that we need to create "kernel natives", the C version
of java kernel classes.  The expectation is that the JVM supplier would
write their own kernel natives.  And the classlib native code would only
call kernel natives.  Thoughts?


I don't understand this. We already have VMI (for common purposes),
and even if hythread shed implementation, it preserves functioning as
interface to threading nevertheless. If this means we should somehow
restructure portlib module - please add some more reasoning?






On 11/10/06, Andrey Chernyshev <[EMAIL PROTECTED]> wrote:
>
> On 10/26/06, Angela Lin <[EMAIL PROTECTED]> wrote:
> > On 10/24/06, Weldon Washburn <[EMAIL PROTECTED]> wrote:
> > >
> > > If an arbitrary commercial JVM decided to use classlib, will it need
> to be
> > > modified to reflect the existing Harmony Classlib threading model?
> >
> > This is the case no matter how you split the thread library. Whatever
> > interface you specify for the classlib will need to be supported by
> > the VM.
> >
> > > Also, does this mean VM design is constrained by classlib design?  And
> > > classlib  design is constrained by J9 design?
> >
> > The classlib and the VM have certain dependencies on each other. This
> > is not a J9-specific issue.
> >
> > I would aim for a thread API that is generic enough to support
> > multiple implementations.
>
> I think it may be hard (if possible at all) to create high-level
> threading library which would make just every VM happy. For instance,
> DRLVM has a complex synchronization scheme with garbage collector
> which is built into the threading library (for example, each time
> thread goes into wait state, it must instruct the GC that the thread
> can be garbage collected). There also could be VM-specific
> optimizations for monitors which are tied to the object layout used in
> a particular VM.
>
> Finally, there might be pure-Java written VM's which may choose to
> implement threading library almost entirely in Java (may be on top of
> j.u.concurrent API ?), borrowing probably only park/unpark, atomic and
> may be sort of fork operations from the native code. How could we have
> a threading library which will work equally for all VM's?
>
> I agree that bypassing layer (2) by the classlib can be undesirable
> because of loosing track for thread/lock states. So it seems that:
> - both VM and classlib need to use single thread library, and at the
> same level (or, saying that differently, Java code and native code
> from classlib should use same threading lib);
> -  threading lib is likely be VM-specific (consider DRLVM as an example)
>
> If we agree with the above, doesn't it just mean that the hythr must
> be declared as a part of VM? Classlib may probably continue to keep a
> "stub" library for the compilation purposes. But there must be the
> possibility for other VM's to easily replace it with it's own version.
> I guess we do something similar with the luni-kernel-stubs.jar.
>
> >
> > Mature VMs that switch to the Harmony classlib would probably
> > implement a portability layer between the existing VM's thread model
> > and the Harmony thread API.
>
> I guess mature VM's would likely to have their own very carefully
> written and optimized threading libraries, integrated with GC, JIT
> e.t.c. It will be easier for them to provide a suitable interface for
> classlib rather than rewrite VM on top of hythread, no matter how
> perfect is it.
>
>
> >
> > Has anyone considered how ThreadMXBean would be supported by the
> > proposed classlib thread API subset?
>
> May be ThreadMXBean is just a good candidate for the kernel class set?
> At least the spec says "interface for the thread system of the Java
> virtual machine". I guess other MXBeans are also interfaces to some of
> VM services.
>
>
> Thanks,
> Andrey.
>
>
> >
> > > On 10/24/06, Angela Lin <[EMAIL PROTECTED]> wrote:
> > > >
> > > > Consider the group of monitor-related functionality: enter/exit,
> > > > wait/notify, and interrupt. The implementations of these functions
> are
> > > > closely related in the J9-derived hythread, particularly for 3-tier
> > > > locking. We need to coordinate when we lock the thread mutex, when
> we
> > > > lock the monitor mutex, how we use spinlocks, etc. It would be
> > > > unnatural to split out enter/exit from this group.
> > >
> > >
> > > >
> > > > On 10/24/06, Weldon Washburn <[EMAIL PROTECTED]> wrote:
> > > > > On 10/23/06, Angela Lin <[EMAIL PROTECTED]> wrote:
> > > > > >
> > > > > > What is the goal here?
> > > > > >
> > > > > > 1. If the goal is to create a single thread library that can be
> used
> > > > > > by multiple VM and classlib implementations, then the unified
> thread
> > > > > > lib should contain everything needed to support a VM
> implementation.
> > > > > >
> > > > > > 2. If the goal is to simply define the interface between the
> classlib
> > > > > > and the VM, then the 3rd option may be acceptable. Th

Re: [drlvm] Class unloading support

[Weldon Washburn]

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


I wonder if you might want to create a new JIRA that's clear about what
the point is, and close the class unload JIRa for now.




I was hoping someone would suggest closing HARMONY-2000.  Unless there are
objections in the next 24 hours, consider it done.


geir



Pavel Pervov wrote:
> On 11/10/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
>>
>> Hang on - we aren't going to consider this patch quite yet, are we?  We
>> have a very active and fruitful discussion going on regarding alternate
>> approaches?
>>
>> geir
>
>
> This part of the patch does not contain class unloading implementation
> but instead contain native resources cleanup code, which is required by
any
> choosen class unloading design to be implemented in DRLVM.
> So, my +1 to commit this part, and hold on with the second, until
> harmony-dev derives the decision.
>
> Regards





--
Weldon Washburn
Intel Enterprise Solutions Software Division

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

[Weldon Washburn]

Salikh,
I read the wiki page.  Good summary.  Regarding writes to the mark bit in
vtable.  I think there was also conversation on cache line invalidate
traffic causing a problem on SMP.  That is, the mark bit of a popular class
(like maybe String?) bouncing between caches.  I recall someone suggesting a
thread-specific data struct to hold the mark bits.


On 11/10/06, Salikh Zakirov <[EMAIL PROTECTED]> wrote:


Aleksey Ignatenko wrote:
> Actually there is one additional 4-th approach:
>
> *Mark and scan based approach *wich I described in the first letter.
Java
> heap trace is performed by VM Core and GC is not affected at all.
>
> So the list is:
> 1. vtable objects( Aleksey )
> 2. per heap space/generation boolean marker on the classloader instance(
> Etienne )
> 3. class reachability marker byte in vtable (Robin )
> 4. Mark and scan based approach.
>
> I agree that we need to structure all appraches somehow, like
description
> for every approach in wiki.

I've started a wiki page http://wiki.apache.org/harmony/ClassUnloading
to summarize all discussed approaches. I hope we will eventually come
up with the detailed end-to-end design description.

I'm going now to fill in all ideas that I can pick up from the discussion,
but I encourage all interested parties to review and correct if I get
something incorrectly.





--
Weldon Washburn
Intel Enterprise Solutions Software Division

Re: [legal] Export controls

[Geir Magnusson Jr.]

have fun! thanks for doing this.

geir


Tim Ellison wrote:

I believe that Harmony should be complying with the US export controls
for our JSE crypto enablement code, since it is 'specifically designed
to enable cryptography' [1] and our developer releases contain the
bouncy castle algorithm providers.

FYI I'll go through the required steps in the ASF document to ensure we
are 'on-side', but I expect it to be an admin issue that doesn't
materially affect our day to day activities.

Of course, I'll bring anything of interest back to the list.

[1] http://www.apache.org/dev/crypto.html

Regards,
Tim

[legal] Export controls

[Tim Ellison]

I believe that Harmony should be complying with the US export controls
for our JSE crypto enablement code, since it is 'specifically designed
to enable cryptography' [1] and our developer releases contain the
bouncy castle algorithm providers.

FYI I'll go through the required steps in the ASF document to ensure we
are 'on-side', but I expect it to be an admin issue that doesn't
materially affect our day to day activities.

Of course, I'll bring anything of interest back to the list.

[1] http://www.apache.org/dev/crypto.html

Regards,
Tim

-- 

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

Re: [drlvm] Class unloading support

[Geir Magnusson Jr.]

I wonder if you might want to create a new JIRA that's clear about what 
the point is, and close the class unload JIRa for now.


geir


Pavel Pervov wrote:

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


Hang on - we aren't going to consider this patch quite yet, are we?  We
have a very active and fruitful discussion going on regarding alternate
approaches?

geir



This part of the patch does not contain class unloading implementation
but instead contain native resources cleanup code, which is required by any
choosen class unloading design to be implemented in DRLVM.
So, my +1 to commit this part, and hold on with the second, until
harmony-dev derives the decision.

Regards

Re: [drlvm] Class unloading support

[Weldon Washburn]

Sorry for the confusion.  We are getting ourselves all tangled up with
subconversations in this thread.  There have been 90+ replies to the
original posting.

No patch containing class unloading will be committed until Harmony has a
design and the design has been implemented.

What is being discussed is a patch that cleans up the malloc/free of C
structs that are currently used for class loading.  I have looked at the
proposed patch.  It looks to have low impact on stability.  It contains no
class unloading code.  Its not urgent to apply this patch.  I will hold off
doing anything until the confusion clears.  It might even be better to open
a new JIRA titled something like, "classloader malloc/free cleanup".  Note
there are currently 12 files attached to HARMONY-2000.

The patch at issue was split out of the original class unloading patch to
isolate independent problems.


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


Hang on - we aren't going to consider this patch quite yet, are we?  We
have a very active and fruitful discussion going on regarding alternate
approaches?

geir


Aleksey Ignatenko wrote:
> Weldon, I have attached updated patch to H-2000:
> cleanup_sources_1558_merged.patch.
> Please, see comments.
>
> Aleksey.
>
>
> On 11/10/06, Weldon Washburn <[EMAIL PROTECTED]> wrote:
>>
>> Aleksey,
>> I tried to apply native_sources_cleanup_upd.patch.  svn HEAD has
changed
>> and
>> the patch no longer works.  Part of the problem is that JIRA 1558 has
>> been
>> committed.  In addition to the below issues, I posted comments to
>> JIRA HARMONY-2000.
>>
>>
>> On 11/2/06, Weldon Washburn <[EMAIL PROTECTED]> wrote:
>> >
>> > Aleksey,
>> >
>> > Excellent step forward -- breaking the patch into two pieces.   This
>> made
>> > the patch(es) much more readable.
>> >
>> > I glanced at native_sources_cleanup.patch.  It looks like code for
>> > alloc/dealloc vtables and jitted code blocks.  The original patch
made
>> > vtables into objects.  Will native_sources_cleanup need to change if
>> vtables
>> > are normal C structs instead?  Also, I see reference to path
>> .../gcv4/...  I
>> > guess this will need to change to support gc_gen and gc_cc.
>> >
>> > Once you get native_sources_cleanup.patch in good shape, I have no
>> problem
>> > committing it.
>> >
>> > If there is no other debate on class unloading design, I will call
>> for a
>> > vote in a seperate email.
>> >
>> >
>> >
>> > On 11/2/06, Aleksey Ignatenko <[EMAIL PROTECTED]> wrote:
>> > >
>> > > Hi, everyone.
>> > >
>> > > I've splitted Harmony-2000 (see details:
>> > > http://issues.apache.org/jira/browse/HARMONY-2000) patch with
>> automatic
>> > > class unloading implementation into 2 independent parts:
>> > > 1. cleaning native resources (native_sources_cleanup.patch).
>> > > 2. automatic unloading design implementation
(auto_unloading.patch).
>> > >
>> > > The first part is independent for all class unloading designs and
>> could
>> > > be
>> > > commited. The second part is class unloading design implementation
>> (the
>> > > best
>> > > class unloading approach is discussed now).
>> > >
>> > > I propose to commit native_sources_cleanup.patch and continue class
>> > > unloading development with minimal requirements on drlvm.
>> > >
>> > > Aleksey.
>> > >
>> > >
>> > > On 11/1/06, Aleksey Ignatenko <[EMAIL PROTECTED]> wrote:
>> > > >
>> > > > Oops, sorry, misprinted in my suggestion:
>> > > > if (cl->IsBootstrap() *||
>> > > *env->b_VTable_trace_is_not_supported_by_GC)
>> > > >
>> > > > {
>> > > > vm_enumerate_jlc(c);
>> > > > if (c->vtable)
>> > > >
>> vm_enumerate_root_reference((void**)&c->vtObj,
>> > > > FALSE);
>> > > > }
>> > > >
>> > > > Aleksey.
>> > > >
>> > > >  On 11/1/06, Aleksey Ignatenko < [EMAIL PROTECTED]>
>> wrote:
>> > > > >
>> > > > > Weldon,
>> > > > >
>> > > > > >A question for all involved.  Is it possible to somehow make
it
>> > > appear
>> > > > > that
>> > > > > >the new objects related to unloading  (VTable, ClassLoader,
>> > > etc)  are
>> > > > > always
>> > > > > >reachable and thus never collected?  I am trying to figure out
a
>> > > way to
>> > > > > make
>> > > > > >integration of class unloading independent of correct support
>> > > inside
>> > > > > the GC
>> > > > > >and JIT.  This option could be a command line switch or
compile
>> > > time
>> > > > > option.
>> > > > >
>> > > > > I agree with Robin:
>> > > > > >Simple.  Keep a list or table of these objects as part of the
>> root
>> > > set.
>> > > > > >Enumerate it optionally depending on a command line option.
>> > > > >
>> > > > > Details: you can see from Harmony-2000 patch, that this is done
>> for
>> > > > > Bootstrap classes already. If you look at
>> root_set_enum_common.cpp
>> > > (with the
>> > > > > patch applied) vm_enumerate_static_fields() function, there is
>> line:
>> > > > > if (cl->IsBootstrap())
>> > > > > {
>> 

[classlib][sql] package javax.sql.rowset.serial is missing in Harmony

[Andrew Zhang]

Hi folks,

I noticed that package javax.sql.rowset.serial is missing in Harmony.

Has anybody already been working on it? If no one holds implemented code in
his hand, I'd like to start on this package.

Any suggestions/concerns/patches :-) ? Thanks!

--
Best regards,
Andrew Zhang

Re: [classlib][pack200] Status update

[Tim Ellison]

Thanks for the update Alex.  I assume from this description (and please
don't take this the wrong way) that you are happy to be left alone to
work on this for the moment, rather than it be read as a call for help?

Keep up the good work.
Tim

Alex Blewitt wrote:
> I'm still lurking around in the background, but I'm busier than ever
> what with having to keep posting at EclipseZone where I'm editor now
> ... but I'm still managing to plod along with the Pack200 code. The
> last patch (1994, IIRC) went down pretty badly; the subclipse plugin
> didn't seem to capture all the newly created classes that I had put
> together for a bit of refactoring that I did. It's also a nightmare
> submitting newly created files; once they've been uploaded to JIRA
> into the patch queue, I effectively have to stop work until they're
> applied, because there's no way of getting SVN to figure out that the
> file called ClassFile.java is the same as the ClassFile.java that's
> been added by someone else on my behalf, and I have to overwrite my
> local copy to update. Kinda prevents doing any sensible work on newly
> created files between submission and application to be honest.
> 
> Instead, I plan to sprint (well, jog, at least) to the next stable
> point, and then upload a whole wodge of code and leave it for a week
> or two to be applied before picking up again. I'm fairly close to
> being at that stage, but not quite. Where I am at is being able to
> generate (abstract) methods with exceptions and fields with constant
> (integer) values, so a bit further forward than last time. On the one
> hand, it means that I understand what needs to be done (no mean feat!)
> but on the other hand, there's still a fair bit to go. For a start,
> I'm going to need to process the actual bytecode for non-abstract
> methods (or indeed, any classes) before there's any point in it trying
> to be used for real, and there's still a few missing bits (Longs,
> Doubles, Floats) from the constant pools. I'm pretty sure Strings
> would work, but I've not tried them yet.
> 
> Unfortunately, the code is really awful. The Segment.java is getting
> on for 1500 lines of code in a single class; and the attribute parsing
> contains both duplicated code and isn't as generic as it needs to be
> to handle other attributes; and the (in)visible annotations like
> @Overrides and similar are going to be a bit of a nightmare ...
> 
> My plan is to get the code to a stage where it can start to be useful
> for extracting simple classes from a pack file, and then start
> generating test data which can be used for regressions. (There's a bit
> there at the moment, but it's not exactly a large coverage.) Once I've
> done that, I'll start tackling some of the refactoring which will
> result in less duplicated code and hopefully something that will be
> easier to look after in the future.
> 
> Anyway, excuse the long rambling but I've been a bit quiet for a while
> and wanted to let people know I was still alive and kicking the code
> :-)
> 
> Alex.
> 

-- 

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

Re: [crypto] SHA-1 not implemented?

[Tim Ellison]

Good catch Yuri -- please log it into JIRA.

Regards,
Tim

Yuri Dolgov wrote:
> Hello,
> 
> I've made an  investigation and found out the root of the problem.
> 
> It seems that "eclipse" test in DaCapo benchmarks canges value of *
> java.home* system property to ".\scratch\dummyjre". It affects
> initialization of Security class in java.security module which loads
> java.security file from *java.home*/lib/security directory.
> 
> This is potential security gap since a person could change *java.home*
> value
> before Security class initialization and load malicious java.security file.
> 
> The following test demonstrates the described behavior:
> 
> 
> import java.security.MessageDigest;
> public class Test {
>public static void main (String[] args) {
>try {
>System.setProperty("java.home", "foo/path");
>MessageDigest md = MessageDigest.getInstance ("SHA-1");
>} catch (Exception e) {
>e.printStackTrace();
>}
>}
> }
> 
> Yuri Dolgov
> 
> 
> On 11/10/06, Tim Ellison <[EMAIL PROTECTED]> wrote:
>>
>> Robin Garner wrote:
>> > Stefano Mazzocchi wrote:
>> >> from Robin's latest runs
>> >> 
>> http://cs.anu.edu.au/people/Robin.Garner/dacapo/regression/results-20061110/DRLVM/eclipse.small.log
>>
>> >>
>> >>
>> >> there are a bunch of log messages that indicate that harmony doesn't
>> >> implement SHA-1.
>> >>
>> >> Is that true?
>> >>
>> >
>> > It can't be true, because _all_ the DaCapo benchmarks rely on SHA-1 for
>> > validation.  I raised JIRA Harmony-2135 on this issue.  Looks like
>> after
>> > eclipse has run, drlvm forgets how to access the SHA-1 algorithm :(
>>
>> Yep, the SHA-1 code is still there [1].
>>
>> [1]
>>
>> http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/modules/security/src/main/java/common/org/apache/harmony/security/provider/crypto/SHA1Impl.java?view=markup
>>
>>
>> Regards,
>> Tim
>>
>> -- 
>>
>> Tim Ellison ([EMAIL PROTECTED])
>> IBM Java technology centre, UK.
>>
> 

-- 

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

Re: [drlvm] Class unloading support

[Pavel Pervov]

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


Hang on - we aren't going to consider this patch quite yet, are we?  We
have a very active and fruitful discussion going on regarding alternate
approaches?

geir



This part of the patch does not contain class unloading implementation
but instead contain native resources cleanup code, which is required by any
choosen class unloading design to be implemented in DRLVM.
So, my +1 to commit this part, and hold on with the second, until
harmony-dev derives the decision.

Regards
--
Pavel Pervov,
Intel Enterprise Solutions Software Division

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

[Geir Magnusson Jr.]

Etienne Gagnon wrote:

Salikh Zakirov wrote:

Etienne Gagnon wrote:

The http://wiki.apache.org/harmony/ClassUnloading wiki page is
"Immutable".  How can I contribute to it?

It is immutable for "anonymous" guests, you need to register and login 
somewhere.
All pages are editable by all registered users.


Silly me!  I must have missed some FM (as in RTFM) where this is written...


it's a fairly common model for wikis



Thanks,

Etienne

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

[Geir Magnusson Jr.]

Etienne Gagnon wrote:

The http://wiki.apache.org/harmony/ClassUnloading wiki page is
"Immutable".  How can I contribute to it?


Do you have a login to the wiki?



[Among other things, I'd like to add that the design can also
potentially apply to SableVM and , and make other suggestions / changes.]

Do I have to submit JIRA bugs?  If yes, how do I make the patches? (svn
diff?)


svn diff please :)



Thanks for helping me!
Etienne

Aleksey Ignatenko wrote:

Actually there is one additional 4-th approach:

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

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

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

Aleksey.

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


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

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

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

Thanks,
Rana

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

It looks like I called for a vote too soon.  The continuing discussion

on

class unloading design is uncovering many important issues.  This is
excellent as it is much better to deal with design issues at this stage
rather than during implementation.

I propose the following:

1)
Cancel the current vote on design.

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

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

indicate

it is ready.


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

Pavel Pervov wrote:

Really BIG -1 from me.

As Aleksey (Ignatenko) described in original thread, j/l/Class'es

and

j/l/ClassLoader's are always available in rootset, so even if no

objects

of a class exist, this class will be reachable.

Actually, some sort of class unloading prototype exists in DRLVM

code,

which
implements the scheme, which is very close to what is currently

voted.

It

was integrated with GC v4 and is not supported by other GCs. This

prototype

traces up to class loader. Robin's approach is way faster then

prorotype

is.

Unfortunately, that approach requires up to 3 GC cycles to complete

in

DRLVM.

In a full-heap STW collector, my proposal would require 1 GC to

collect

unused classloaders.  In a generational STW collector, 1 full-heap

GC,

and would depend on the particular invariants enforced by an
incremental/concurrent collector, but would be 1 complete "cycle" of

any

of the standard algorithms (I guess up to 3 GCs if the sweeps

happened

at the wrong places).


BTW, voted approach does not describe "proof-of-full-collection"

algorithm

(at least I didn't find one). The only one I think of is
full-heap-collection, which _requires_ STW.

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


Although "automatic anloading" brings some additional requirements

for

GC

(weak roots (references) support and pinned allocation), it is

proven

to

work (patch available) and, also, is the most natural algorithm for

DRLVM.

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


With the best regards,


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




--
Weldon Washburn
Intel Enterprise Solutions Software Division

Re: [general] Sun will take GPL License?

[Geir Magnusson Jr.]

Ivan Volosyuk wrote:

On 11/10/06, Dalibor Topic <[EMAIL PROTECTED]> wrote:

Geir Magnusson Jr.  pobox.com> writes:

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

Yup, authors should know best what terms apply to their works. 
Practically
speaking, if they went with the GPL, Sun could just say "it's not 
'viral' for

all the practical purposes" and that would be the quick end of any scary
problem, I guess.


IMHO, there can be still scary problems if some parts of the code are
covered by patents even if the code is licensed by GPL v2. Am I
correct?


http://blogs.codehaus.org/people/geir/archives/001433_open_source_java_v_gpl_and_patents.html

However, once you pass the TCK, you do receive all necessary IP from the 
members of the EG.


This isn't a worry for us at all, but it will be interesting to see - 
once we know the definite details - how this will work out.  Clearly Sun 
has thought hard about this.  I don't expect them to make any mistakes 
here - all implications will be intentional.


geir

Re: [drlvm][classlib] thread library - let there be one!

[Weldon Washburn]

hmm it seems that we need to create "kernel natives", the C version
of java kernel classes.  The expectation is that the JVM supplier would
write their own kernel natives.  And the classlib native code would only
call kernel natives.  Thoughts?




On 11/10/06, Andrey Chernyshev <[EMAIL PROTECTED]> wrote:


On 10/26/06, Angela Lin <[EMAIL PROTECTED]> wrote:
> On 10/24/06, Weldon Washburn <[EMAIL PROTECTED]> wrote:
> >
> > If an arbitrary commercial JVM decided to use classlib, will it need
to be
> > modified to reflect the existing Harmony Classlib threading model?
>
> This is the case no matter how you split the thread library. Whatever
> interface you specify for the classlib will need to be supported by
> the VM.
>
> > Also, does this mean VM design is constrained by classlib design?  And
> > classlib  design is constrained by J9 design?
>
> The classlib and the VM have certain dependencies on each other. This
> is not a J9-specific issue.
>
> I would aim for a thread API that is generic enough to support
> multiple implementations.

I think it may be hard (if possible at all) to create high-level
threading library which would make just every VM happy. For instance,
DRLVM has a complex synchronization scheme with garbage collector
which is built into the threading library (for example, each time
thread goes into wait state, it must instruct the GC that the thread
can be garbage collected). There also could be VM-specific
optimizations for monitors which are tied to the object layout used in
a particular VM.

Finally, there might be pure-Java written VM's which may choose to
implement threading library almost entirely in Java (may be on top of
j.u.concurrent API ?), borrowing probably only park/unpark, atomic and
may be sort of fork operations from the native code. How could we have
a threading library which will work equally for all VM's?

I agree that bypassing layer (2) by the classlib can be undesirable
because of loosing track for thread/lock states. So it seems that:
- both VM and classlib need to use single thread library, and at the
same level (or, saying that differently, Java code and native code
from classlib should use same threading lib);
-  threading lib is likely be VM-specific (consider DRLVM as an example)

If we agree with the above, doesn't it just mean that the hythr must
be declared as a part of VM? Classlib may probably continue to keep a
"stub" library for the compilation purposes. But there must be the
possibility for other VM's to easily replace it with it's own version.
I guess we do something similar with the luni-kernel-stubs.jar.

>
> Mature VMs that switch to the Harmony classlib would probably
> implement a portability layer between the existing VM's thread model
> and the Harmony thread API.

I guess mature VM's would likely to have their own very carefully
written and optimized threading libraries, integrated with GC, JIT
e.t.c. It will be easier for them to provide a suitable interface for
classlib rather than rewrite VM on top of hythread, no matter how
perfect is it.


>
> Has anyone considered how ThreadMXBean would be supported by the
> proposed classlib thread API subset?

May be ThreadMXBean is just a good candidate for the kernel class set?
At least the spec says "interface for the thread system of the Java
virtual machine". I guess other MXBeans are also interfaces to some of
VM services.


Thanks,
Andrey.


>
> > On 10/24/06, Angela Lin <[EMAIL PROTECTED]> wrote:
> > >
> > > Consider the group of monitor-related functionality: enter/exit,
> > > wait/notify, and interrupt. The implementations of these functions
are
> > > closely related in the J9-derived hythread, particularly for 3-tier
> > > locking. We need to coordinate when we lock the thread mutex, when
we
> > > lock the monitor mutex, how we use spinlocks, etc. It would be
> > > unnatural to split out enter/exit from this group.
> >
> >
> > >
> > > On 10/24/06, Weldon Washburn <[EMAIL PROTECTED]> wrote:
> > > > On 10/23/06, Angela Lin <[EMAIL PROTECTED]> wrote:
> > > > >
> > > > > What is the goal here?
> > > > >
> > > > > 1. If the goal is to create a single thread library that can be
used
> > > > > by multiple VM and classlib implementations, then the unified
thread
> > > > > lib should contain everything needed to support a VM
implementation.
> > > > >
> > > > > 2. If the goal is to simply define the interface between the
classlib
> > > > > and the VM, then the 3rd option may be acceptable. This option
seems
> > > > > to imply splitting up functionality that requires deep knowledge
of
> > > > > the threading implementation, which I don't like. Each VM
> > > > > implementation would need to implement both the VM and classlib
sides
> > > > > of the API.
> > > >
> > > > Is this really the situation?  If Classlib only needs
monenter/exit, TLS
> > > and
> > > > thread_create(), the "deep knowledge" required is probably only
> > > > monitorenter/exit which seems like a managable situation.
> > > >
> > > 

Re: [testing] harmonytest.org new features

[Alexei Fedotov]

I like it! Thanks, Anton!

On 11/10/06, Anton Luht <[EMAIL PROTECTED]> wrote:

Hello,

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

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


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

Please report bugs and send feature requests.

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




--
Thank you,
Alexei

Re: [crypto] SHA-1 not implemented?

[Yuri Dolgov]

Hello,

I've made an  investigation and found out the root of the problem.

It seems that "eclipse" test in DaCapo benchmarks canges value of *
java.home* system property to ".\scratch\dummyjre". It affects
initialization of Security class in java.security module which loads
java.security file from *java.home*/lib/security directory.

This is potential security gap since a person could change *java.home* value
before Security class initialization and load malicious java.security file.

The following test demonstrates the described behavior:


import java.security.MessageDigest;
public class Test {
   public static void main (String[] args) {
   try {
   System.setProperty("java.home", "foo/path");
   MessageDigest md = MessageDigest.getInstance ("SHA-1");
   } catch (Exception e) {
   e.printStackTrace();
   }
   }
}

Yuri Dolgov


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


Robin Garner wrote:
> Stefano Mazzocchi wrote:
>> from Robin's latest runs
>>  
http://cs.anu.edu.au/people/Robin.Garner/dacapo/regression/results-20061110/DRLVM/eclipse.small.log
>>
>>
>> there are a bunch of log messages that indicate that harmony doesn't
>> implement SHA-1.
>>
>> Is that true?
>>
>
> It can't be true, because _all_ the DaCapo benchmarks rely on SHA-1 for
> validation.  I raised JIRA Harmony-2135 on this issue.  Looks like after
> eclipse has run, drlvm forgets how to access the SHA-1 algorithm :(

Yep, the SHA-1 code is still there [1].

[1]

http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/modules/security/src/main/java/common/org/apache/harmony/security/provider/crypto/SHA1Impl.java?view=markup

Regards,
Tim

--

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

Re: [drlvm] Class unloading support

[Geir Magnusson Jr.]

Hang on - we aren't going to consider this patch quite yet, are we?  We 
have a very active and fruitful discussion going on regarding alternate 
approaches?


geir


Aleksey Ignatenko wrote:

Weldon, I have attached updated patch to H-2000:
cleanup_sources_1558_merged.patch.
Please, see comments.

Aleksey.


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


Aleksey,
I tried to apply native_sources_cleanup_upd.patch.  svn HEAD has changed
and
the patch no longer works.  Part of the problem is that JIRA 1558 has 
been

committed.  In addition to the below issues, I posted comments to
JIRA HARMONY-2000.


On 11/2/06, Weldon Washburn <[EMAIL PROTECTED]> wrote:
>
> Aleksey,
>
> Excellent step forward -- breaking the patch into two pieces.   This
made
> the patch(es) much more readable.
>
> I glanced at native_sources_cleanup.patch.  It looks like code for
> alloc/dealloc vtables and jitted code blocks.  The original patch made
> vtables into objects.  Will native_sources_cleanup need to change if
vtables
> are normal C structs instead?  Also, I see reference to path
.../gcv4/...  I
> guess this will need to change to support gc_gen and gc_cc.
>
> Once you get native_sources_cleanup.patch in good shape, I have no
problem
> committing it.
>
> If there is no other debate on class unloading design, I will call 
for a

> vote in a seperate email.
>
>
>
> On 11/2/06, Aleksey Ignatenko <[EMAIL PROTECTED]> wrote:
> >
> > Hi, everyone.
> >
> > I've splitted Harmony-2000 (see details:
> > http://issues.apache.org/jira/browse/HARMONY-2000) patch with
automatic
> > class unloading implementation into 2 independent parts:
> > 1. cleaning native resources (native_sources_cleanup.patch).
> > 2. automatic unloading design implementation (auto_unloading.patch).
> >
> > The first part is independent for all class unloading designs and
could
> > be
> > commited. The second part is class unloading design implementation
(the
> > best
> > class unloading approach is discussed now).
> >
> > I propose to commit native_sources_cleanup.patch and continue class
> > unloading development with minimal requirements on drlvm.
> >
> > Aleksey.
> >
> >
> > On 11/1/06, Aleksey Ignatenko <[EMAIL PROTECTED]> wrote:
> > >
> > > Oops, sorry, misprinted in my suggestion:
> > > if (cl->IsBootstrap() *||
> > *env->b_VTable_trace_is_not_supported_by_GC)
> > >
> > > {
> > > vm_enumerate_jlc(c);
> > > if (c->vtable)
> > >
vm_enumerate_root_reference((void**)&c->vtObj,
> > > FALSE);
> > > }
> > >
> > > Aleksey.
> > >
> > >  On 11/1/06, Aleksey Ignatenko < [EMAIL PROTECTED]> 
wrote:

> > > >
> > > > Weldon,
> > > >
> > > > >A question for all involved.  Is it possible to somehow make it
> > appear
> > > > that
> > > > >the new objects related to unloading  (VTable, ClassLoader,
> > etc)  are
> > > > always
> > > > >reachable and thus never collected?  I am trying to figure out a
> > way to
> > > > make
> > > > >integration of class unloading independent of correct support
> > inside
> > > > the GC
> > > > >and JIT.  This option could be a command line switch or compile
> > time
> > > > option.
> > > >
> > > > I agree with Robin:
> > > > >Simple.  Keep a list or table of these objects as part of the
root
> > set.
> > > > >Enumerate it optionally depending on a command line option.
> > > >
> > > > Details: you can see from Harmony-2000 patch, that this is done
for
> > > > Bootstrap classes already. If you look at 
root_set_enum_common.cpp

> > (with the
> > > > patch applied) vm_enumerate_static_fields() function, there is
line:
> > > > if (cl->IsBootstrap())
> > > > {
> > > > vm_enumerate_jlc(c);
> > > > if (c->vtable)
> > > >
> > vm_enumerate_root_reference((void**)&c->vtObj,
> > > > FALSE);
> > > > }
> > > > else
> > > > {
> > > > vm_enumerate_jlc(c, true/*weak*/);
> > > > }
> > > > You can see, that there are strong roots to Bootstrap
j.l.Classesand
> > > > their VTable objects. So I suppose, that it would be very simple
to
> > > > propogate strong roots to all other classes (not only Bootstrap),
> > something
> > > > like:
> > > > if (cl->IsBootstrap() *&&
> > > > env->b_VTable_trace_is_not_supported_by_GC*)
> > > > {
> > > > vm_enumerate_jlc(c);
> > > > if (c->vtable)
> > > >
> > vm_enumerate_root_reference((void**)&c->vtObj,
> > > > FALSE);
> > > > }
> > > > where *b_VTable_trace_is_not_supported_by_GC *is flag which is 
set

> > > > according to used GC. This will force switching off any class
> > unloading
> > > > support.
> > > >
> > > > Aleksey.
> > > >
> > > >  On 11/1/06, Robin Garner <[EMAIL PROTECTED] > wrote:
> > > > >
> > > > > Weldon Washburn wrote:
> > > > > > On 10/30/06, Robin Garner < [EMAIL PROTECTED]

Re: Harmony passes all tests of Maven 2.0.4

[Geir Magnusson Jr.]

w00t!

Log it on the wiki!

(and please prefix your subject lines with ???  right now, we have 
[testing] listed on


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

but maybe we need to add [app-testing] ?

geir

Leo Li wrote:

Hi, all:
Harmony classlib at revision 473150 passes all tests of Maven 2.0.4 on
windows xp, redhat enterprise 4, unbuntu 6.0.6 and suse 10.
As for drlvm, it passes on windows xp but fails on redhat linux
enterprise 4. If somebody can reproduce it, I will report it as a
application-oriented bug to jira.
For detailed information, pls refer to
http://wiki.apache.org/harmony/Apache_Maven.

Re: [testing] harmonytest.org new features

[Geir Magnusson Jr.]

Nice!

Anton Luht wrote:

Hello,

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

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


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

Please report bugs and send feature requests.

[drlvm][build] everyday SVN conflict on the version_svn_tag.h file

[Vladimir Ivanov]

Hello everyone,

When I do my morning SVN update of drlvm module I see the permanent conflict
on the version_svn_tag.h file because this file is updated by build.

Actually, it is not a big problem while it not breaks vm build. But it will
be more convenient if these conflicts go out.

Could we generate this file as part of the build process (it has only 4
strings)? May be some other solutions exists?



I'm not too familiar with VM build so I'll be glad if somebody takes care
about it :)



Thanks, Vladimir

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

[Geir Magnusson Jr.]

Get ahold of yourself, man!  You're going to get me fired! :)

[EMAIL PROTECTED]:/proc$ more cpuinfo
processor   : 0
vendor_id   : GenuineIntel
cpu family  : 15
model   : 4
model name  :   Intel(R) Pentium(R) D CPU 3.20GHz
stepping: 4
cpu MHz : 3200.279
cache size  : 1024 KB
physical id : 0
siblings: 2
core id : 0
cpu cores   : 2
fpu : yes
fpu_exception   : yes
cpuid level : 5
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge 
mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx l

m constant_tsc pni monitor ds_cpl cid cx16 xtpr
bogomips: 6410.31
clflush size: 64
cache_alignment : 128
address sizes   : 36 bits physical, 48 bits virtual
power management:

processor   : 1
vendor_id   : GenuineIntel
cpu family  : 15
model   : 4
model name  :   Intel(R) Pentium(R) D CPU 3.20GHz
stepping: 4
cpu MHz : 3200.279
cache size  : 1024 KB
physical id : 0
siblings: 2
core id : 1
cpu cores   : 2
fpu : yes
fpu_exception   : yes
cpuid level : 5
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge 
mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx l

m constant_tsc pni monitor ds_cpl cid cx16 xtpr
bogomips: 6400.81
clflush size: 64
cache_alignment : 128
address sizes   : 36 bits physical, 48 bits virtual
power management:




Stefano Mazzocchi wrote:

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

Re: [general] Sun will take GPL License?

[Geir Magnusson Jr.]

Dalibor Topic wrote:

Geir Magnusson Jr.  pobox.com> writes:

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


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

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


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


That wasn't my read - I read it that you can now combine software from 
MySQL that is under the GPL with software under the Apache License (for 
example), which is something that the FSF has explicitly prohibited.


geir




cheers,
dalibor topic

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

Re: [drlvm] release vs. debug

[Geir Magnusson Jr.]

I do the same - I tend to only generally test in debug mode when doing 
series of things, and then doing a release for fun later.


I expect this to be much less of an issue when build-test is up and 
running with debug + release + .


geir


Gregory Shimansky wrote:
Well I am always testing patches in _default_ mode which debug for VM, 
release for JIT and whatever it is for classlib. If defaults change then 
 it will be some other conditions. Average time to run build test is ~60 
minutes.


Pavel Ozhdikhin wrote:
Sure, contributors should check debug or even both debug and release 
builds

and comment about this in JIRA.

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



Actually I'm fine if the committers will check both debug and release 
builds

and I encourage them to check on all supported platforms. But I'm not a
committer. :)

Thanks,
Pavel


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


I can understand that the contributor may not have access to multiple
platforms, but surely he can test using both debug and release builds 
:-)

What do we gain by asking the contributor to test less?

Rana


On 11/9/06, Pavel Ozhdikhin <[EMAIL PROTECTED]> wrote:
>
> +1 for debug testing before submitting a patch.
>
> But, for pre-commit testing we should be careful saying we'll test all
the
> patches in debug mode. Though it imprves quality of checks, debug 
build

is
> significantly slower then release, especially when running with
> interpreter
> or Jitrino.OPT. I ran "build test" on the DRLVM built in debug mode 
and

it
> takes about 5 times more time than release version on my laptop, The
times
> were as follows:
>
> "build test", Windows XP/ IA32:
> DRLVM release: 22 min 55 sec
> DRLVM debug: 99 min 23 sec
>
> So, may be the good choice will be to ask patch submitters to check
their
> patches on the debug build and, if the JIRA issue contains comments 
that

> this check is passed, committers may test it on release build only.
>
> Thanks,
> Pavel
>
> On 11/10/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
> >
> > Well, since the problem is repeatable :)
> >
> >
> > Gregory Shimansky wrote:
> > > Geir Magnusson Jr. wrote:
> > >>
> > >>
> > >> Alexei Zakharov wrote:
> > >>> Hi DRLVM fans,
> > >>>
> > >>> I encountered a rather strange problem while working on some 
class

> > >>> library tests. At least two tests from the beans module hang (or
> > >>> crash) while running on DRLVM debug builds but work fine on 
DRLVM

> > >>> release builds. I thought that debug build is something about
adding
> > >>> debug symbols to VM binaries and this should not affect the
> > >>> functionality. Can someone shed a light on this?
> > >>
> > >> I would think it's just an assertion firing...
> > >
> > > Actually it is more than that. In debug mode TRACE statements are
> > > compiled and therefore produce executable code. There may also be
some
> > > bugs in compiler generating code in different modes (although this
> > > usually happens for release).
> > >
> > > I don't know why hanging happens, but the difference in generated
code
> > > is actually quite big. Also assertions or any crashes go to
> > > exceptions/signal handlers which may happen to loop infinitely,
there
> > > were bugs like this happening on the current version of sources,
look
> at
> > > HARMONY-2018 and HADMONY-2006.
> > >
> > >>> This is the first
> > >>> question. The second question - what we should do with such 
tests.

> The
> > >>> tests pass on the downloadable HDK and JRE snapshots as well 
as on
> > >>> classlib + j9. What should be the commit criteria for DRLVM – 
i.e.

> > >>> what is the *true* build? :) I think many people here currently
use
> > >>> snapshots to test their patches.
> > >>
> > >> debug :)  don't sweep the problems under the rug...
> > >
> > > +1

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

[Geir Magnusson Jr.]

can you please put comments like this on the JIRA itself [also]?  it 
makes it easier for a committer when looking to apply the patch


geir

Egor Pasko wrote:

On the 0x21D day of Apache Harmony Konstantin Anisimov wrote:

Hi all,

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

Could someone review it?


here is my review:

(1)
patch applies well, does not affect IA-32, x86_64 builds

(2)
Migration to MemoryManager based STL is of special goodness. Thank you!
But some of not MemManaged usages are not wiped out yet:
IpfType.h: multimap
IpfEmitter.{h|cpp}: vector bitset
could you eliminate them for unification, please?

(3)
some logging code is commented-out, but this should be OK for now


Thank you,
Konstantin

"Konstantin Anisimov" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]

Hi all,

I suggest new patch from the series Igor introdusced.
1. To move direct predicated calls in separete node. It allows to have 
under

predicate short branch instruction instead of call and thus
  reduce possible misprediction penalty.
2. I have implemented new node merging algorithm. It is more effective 
than

previouc one and besides purging empty nodes.

All changes made in Code layouting and I suggest integrate them in one
patch.

Thank you,
Konstantin

"Igor Chebykin" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]

Hello all,

I suggest a short series of patches for drlvm ipf code generator.
We have some improvements for jitrino/ipf
and would like to commit its to harmony.

All patches will change only vm/jitrino/src/codegenerator/ipf/* files,
therefore ia32 remains OK.

The first patch is about 67k size and contains following files:
IpfCfg.h, IpfCfg.cpp
  methods added in Edge and Node classes
IpfCodeLayouter.h, IpfCodeLayouter.cpp
  new BotomUp algorithm implementation
IpfEmitter.h, IpfEmitter.cpp
  minor changes in logging, Emitter::registerDirectCall() and
debugging support
IpfIrPrinter.h, IpfIrPrinter.cpp
  added method to print Node chains
IpfType.h
  types to support Node chains added
IpfCfgVerifier.cpp
  method cfg.getArgs() deprecated
IpfInst.cpp
  methods to identify inst kind added (isBr, isCall …)
IpfRegisterAllocator.cpp
  minor changes in logging

Thanks,
Igor.


--
Igor Chebykin, Intel Middleware Products Division

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

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

[Geir Magnusson Jr.]

Morozova, Nadezhda wrote:

Alexei,
Tutorials might be fine for mature projects, but I do not think ours is
ready for a big flow of users yet, that would require a tutorial.
So +1 for having a nice good  tutorial ... one day. 
If there are volunteers to write the tutorial now, I'd be happy to help

though.


Isn't that what the getting started page for DRLVM is?  why take 
information away?  I agre, we should clean things up if they are wrong, 
but as long as it's organized, we should keep stuff.


geir



Thank you, 
Nadya Morozova
 
-Original Message-
From: Fedotov, Alexei A [mailto:[EMAIL PROTECTED] 
Sent: Friday, November 10, 2006 1:40 PM

To: harmony-dev@incubator.apache.org
Subject: RE: Re: [doc][drlvm] The document "Getting started with DRL" is
outdated

Guys,

I like good tutorials. I learned VIM using a tutorial. I don't need the
VIM tutorial any longer, but at the beginning it was useful.

+1 for maintain Getting Started as is with minor changes

Why Eclipse was chosen for the tutorial? Our goal was to use Harmony for
Harmony development. I liked that idea.

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


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

On the 0x21D day of Apache Harmony Pavel Ozhdikhin wrote:

Nadya,

One more proposal about "Getting Started": let's remove all current

content

and write something like following:

"To the moment we got rid of all major differences from other Java
implementations, so to use DRLVM you can just build it (here goes

link to

readme with build instructions) and run as any other Java VM. For

commonly

used command-line options please look into the Wiki page (link to

Salikh's

page or to the document)."

What do you think?

1 page to hold only 4 lines of text? :)


Thanks,
Pavel


On 10 Nov 2006 14:29:59 +0600, Egor Pasko <[EMAIL PROTECTED]>

wrote:

On the 0x21D day of Apache Harmony Nadezhda Morozova wrote:

Good day to you, Egor!

evening, dark and snowy evening :)


What do you say about the getting started doc?

I expressed it recently. General idea is that Harmony operates near
the same as other JSE implementations. Almost all specifics is in
extra options which we started collecting on Wiki for an extra
HOWTO-like page (BTW, thanks to Salikh for starting the page).

I believe, it is time to remove the "Getting Started". So, +1 to

Pavel

Ozhdikhin here.

BTW, I asked my dad to look at the website. Ideas for improvement

from

him:
1) site-local search is useful for a beginner. Hm, Tomcat has it

with

links to google search. We can have something as soon as we get to

the

desired TLP :)
2) it is not obvious that site misprints/problems should be

reported

to the mailing list. Commercial websites have something like
"support/suggestions mailto". We can point mailto to the mailing

list

:)

Thank you,
Nadya Morozova

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

is

outdated

On the 0x21D day of Apache Harmony Nadezhda Morozova wrote:

Egor,
I generally like the idea of improving navigation over the site

-

there's never too much of that. However, I am not sure whether

we

need

yet another separate page for introductory/guidance info. I

hope

the

starting page + the generic pages we have are mostly fine.

However,

adding a link here and there to lead site visitors.

Getting started could be a more specific project-oriented page.

There,

you can tell people to go download,

build

the

code. After which, they can start using it just as any other
RI-compatible jdk. With the exceptions, see our
wiki pages.
To use the vm, readers might need to use the following

options...

If they want to read more on our VM, they can visit the
component page. If no website page contains an

answer

-

they can read wiki faqa.
.. or something like that :)

Nadya, I really appreciate our efforts :) But this morning I woke

up

and looked the site structure with the eye of a beginner. And

could

not find any obvius flaws in the main structure. Left-side

collection

of links is in a very good shape, good for beginner-level

navigation

and contains almost all links you listed here.

This was a really refreshing morning :)

I'll ask some guys who are new to the project, how they feel

about

the

site. And will report back, if I find something.

Refreshing morning is over, now back to work..


Thank you,
Nadya Morozova

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

DRL

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

[Geir Magnusson Jr.]

We did put *some* thought into it ;)

geir

Egor Pasko wrote:

On the 0x21D day of Apache Harmony Nadezhda Morozova wrote:

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


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


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

This was a really refreshing morning :)

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

Refreshing morning is over, now back to work..

Thank you, 
Nadya Morozova
 
-Original Message-

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

On the 0x21C day of Apache Harmony Pavel Ozhdikhin wrote:

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

Egor,
+1 for
Just idea: "Getting Started" may contain a collection of links to

the

main website and other resources with short descriptions ("Site Map"
or something) so that people are comfortable floating around in the

web.



We already have one page having links to the resources about DRLVM:
http://incubator.apache.org/harmony/subcomponents/drlvm/index.html
Why do you think we need another one?

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


+1 for

* preparing the "Commonly Used Options for DRLVM" (omitting the word
"supported" intentionally)
Question on this one: will the page contain vm-only options? What

about

JIT, GC, other? I'd have them all in one place, but we have separate
docs for EM/jit stuff. What do you say?


I think we can describe basic options for every component there. Only

those

that might be interesting for any user. The place for other options is

in

the run-time help or Developer's Guide for a component.

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


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

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

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

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

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


Thanks,
Pavel

Thank you,

Nadya Morozova

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

On the 0x21B day of Apache Harmony Nadezhda Morozova wrote:

All,
I'd like to share everyone's grief at the sight of outdated

Getting

Started document. However, I'd not hurry to eliminate the page as

such.

We might reconsider some of its contents, change structure, and

update

individual bits, but please think carefully before removing the

page.

I think Getting Started (as the title shows) is aimed to help a

newbie

work with our vm. I know that many primarily interested in other

things

- conformance, architecture, internal specifics. However, we

should

also

think how the vm is used. AFAIK, Getting started is now the *only*

doc

that tries to show how to use our vm. You tell people how to

download

and build, but almost nothing about how to run and configure (with

the

exception of EM/JIT).

My suggestion would be to think of what you want to tell people

about

usage - with or without eclipse specifi

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

[Evgueni Brevnov]

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?

Thanks
Evgueni

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

[Etienne Gagnon]

Salikh Zakirov wrote:
> Etienne Gagnon wrote:
>>The http://wiki.apache.org/harmony/ClassUnloading wiki page is
>>"Immutable".  How can I contribute to it?
> 
> It is immutable for "anonymous" guests, you need to register and login 
> somewhere.
> All pages are editable by all registered users.

Silly me!  I must have missed some FM (as in RTFM) where this is written...

Thanks,

Etienne

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


signature.asc
Description: OpenPGP digital signature

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

[Egor Pasko]

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 resources allocated for these
> > addrs)
> >
> > (2):
> > 2.1. VM  -call-> JIT (compile a method for me, please)
> > 2.2. JIT -call-> VM  (I generated code from addr X to addr Y, look at this
> > one)
> > 2.3. VM  -call-> TI  (here is the code for you)
> >
> > (1) has a disadvantage in case one JIT instance compiles different
> > methods in parallel. And we should have a synchronized method addr
> > repository, which is not easy to wipe out in the right way.
> >
> > (2) seems more straightforward from the JIT side because JIT can
> > report method boundary addresses as soon as it determines them on
> > emitting. That simplifies JIT impl (no allocating/freeng/synch).
> >
> > BTW, I am curious, is it OK for TI when a method is compiled several
> > times and put on different addrs?
> >

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

[Salikh Zakirov]

Etienne Gagnon wrote:
> The http://wiki.apache.org/harmony/ClassUnloading wiki page is
> "Immutable".  How can I contribute to it?

It is immutable for "anonymous" guests, you need to register and login 
somewhere.
All pages are editable by all registered users.

 > Do I have to submit JIRA bugs?  If yes, how do I make the patches? (svn
> diff?)

We use JIRA to submit code patches.
'svn diff from the root of the workspace' is a (one of) correct way to create a 
patch.
(Root of the workspace is one of the enhanced/drlvm/trunk, 
enhanced/classlib/trunk etc.)

Some hints for contributors, including patch creation, are available at
http://incubator.apache.org/harmony/get-involved.html

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

[Salikh Zakirov]

Aleksey Ignatenko wrote:
> Actually there is one additional 4-th approach:
> 
> *Mark and scan based approach *wich I described in the first letter. Java
> heap trace is performed by VM Core and GC is not affected at all.
> 
> So the list is:
> 1. vtable objects( Aleksey )
> 2. per heap space/generation boolean marker on the classloader instance(
> Etienne )
> 3. class reachability marker byte in vtable (Robin )
> 4. Mark and scan based approach.
> 
> I agree that we need to structure all appraches somehow, like description
> for every approach in wiki.

I've started a wiki page http://wiki.apache.org/harmony/ClassUnloading
to summarize all discussed approaches. I hope we will eventually come
up with the detailed end-to-end design description.

I'm going now to fill in all ideas that I can pick up from the discussion,
but I encourage all interested parties to review and correct if I get
something incorrectly.

Re: [testing] harmonytest.org new features

[Alexei Zakharov]

Works fine now. Thanks!

Regards,

2006/11/10, Anton Luht <[EMAIL PROTECTED]>:

Hello, Alexei,

> One little remark: I've got the following screen after trying to
> search for "beans" and clicking the first link:

It was because of bad/broken data - I've removed it and now the link works.



--
Alexei Zakharov,
Intel Enterprise Solutions Software Division

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

[Etienne Gagnon]

The http://wiki.apache.org/harmony/ClassUnloading wiki page is
"Immutable".  How can I contribute to it?

[Among other things, I'd like to add that the design can also
potentially apply to SableVM and , and make other suggestions / changes.]

Do I have to submit JIRA bugs?  If yes, how do I make the patches? (svn
diff?)

Thanks for helping me!
Etienne

Aleksey Ignatenko wrote:
> Actually there is one additional 4-th approach:
> 
> *Mark and scan based approach *wich I described in the first letter. Java
> heap trace is performed by VM Core and GC is not affected at all.
> 
> So the list is:
> 1. vtable objects( Aleksey )
> 2. per heap space/generation boolean marker on the classloader instance(
> Etienne )
> 3. class reachability marker byte in vtable (Robin )
> 4. Mark and scan based approach.
> 
> I agree that we need to structure all appraches somehow, like description
> for every approach in wiki.
> 
> Aleksey.
> 
> On 11/10/06, Rana Dasgupta <[EMAIL PROTECTED]> wrote:
> 
>>
>> Identifying an end to end alogirithm is of course necessary, and the
>> discussions on the other thread are great. But what were we voting on
>> here?
>> My understanding was that we were voting on the approach of using:
>>
>> 1. vtable objects( Aleksey )
>> 2. per heap space/generation boolean marker on the classloader instance(
>> Etienne )
>> 3. class reachability marker byte in vtable (Robin )
>>
>> and not on three end-to-end algorithms since Robin's description was not
>> one. I am OK if we now want to cancel the vote, but next time we vote
>> on a
>> technical issue it may be a good idea for the caller to summarize the
>> contending solutions on the thread and then call for the vote.
>>
>> Thanks,
>> Rana
>>
>> On 11/9/06, Weldon Washburn <[EMAIL PROTECTED] > wrote:
>> >
>> > It looks like I called for a vote too soon.  The continuing discussion
>> on
>> > class unloading design is uncovering many important issues.  This is
>> > excellent as it is much better to deal with design issues at this stage
>> > rather than during implementation.
>> >
>> > I propose the following:
>> >
>> > 1)
>> > Cancel the current vote on design.
>> >
>> > 2)
>> > Someone put together a complete class unloading design based on
>> > Etienne/Robin's approach.  Include pseudo code and post to harmony-dev.
>> >
>> > 3)
>> > We call for a new vote once the comments on the documented design
>> indicate
>> > it is ready.
>> >
>> >
>> > On 11/8/06, Robin Garner < [EMAIL PROTECTED] > wrote:
>> > >
>> > > Pavel Pervov wrote:
>> > > > Really BIG -1 from me.
>> > > >
>> > > > As Aleksey (Ignatenko) described in original thread, j/l/Class'es
>> and
>> > > > j/l/ClassLoader's are always available in rootset, so even if no
>> > objects
>> > > > of a class exist, this class will be reachable.
>> > > >
>> > > > Actually, some sort of class unloading prototype exists in DRLVM
>> code,
>> > > > which
>> > > > implements the scheme, which is very close to what is currently
>> voted.
>> >
>> > > It
>> > > > was integrated with GC v4 and is not supported by other GCs. This
>> > > prototype
>> > > > traces up to class loader. Robin's approach is way faster then
>> > prorotype
>> > > > is.
>> > > >
>> > > > Unfortunately, that approach requires up to 3 GC cycles to complete
>> in
>> > > > DRLVM.
>> > >
>> > > In a full-heap STW collector, my proposal would require 1 GC to
>> collect
>> > > unused classloaders.  In a generational STW collector, 1 full-heap
>> GC,
>> > > and would depend on the particular invariants enforced by an
>> > > incremental/concurrent collector, but would be 1 complete "cycle" of
>> any
>> > > of the standard algorithms (I guess up to 3 GCs if the sweeps
>> happened
>> > > at the wrong places).
>> > >
>> > > > BTW, voted approach does not describe "proof-of-full-collection"
>> > > algorithm
>> > > > (at least I didn't find one). The only one I think of is
>> > > > full-heap-collection, which _requires_ STW.
>> > >
>> > > My approach simply requires the underlying collector to have a notion
>> > > that periodically it can say that 'every reachable object allocated
>> > > since time 't' is now marked reachable.  If the class-unloader can
>> > > ensure that one full epoch of this invariant has passed, then it can
>> > > safely perform unloading.
>> > >
>> > > > Although "automatic anloading" brings some additional requirements
>> for
>> > > GC
>> > > > (weak roots (references) support and pinned allocation), it is
>> proven
>> > to
>> > > > work (patch available) and, also, is the most natural algorithm for
>> > > DRLVM.
>> > >
>> > > What is the run-time cost of it ?  And where is it described ?  I was
>> > > only aware of Etienne's proposal as a full class-unloading scheme.
>> > >
>> > > > With the best regards,
>> > >
>> > >
>> > > --
>> > > Robin Garner
>> > > Dept. of Computer Science
>> > > Australian National University
>> > >
>> >
>> >
>> >
>> > --
>> > Weldon Washburn
>> > Intel Enterprise Solutions Software Division
>> >
>> >
>>
>>
> 

Re: [testing] harmonytest.org new features

[Anton Luht]

Hello, Alexei,


One little remark: I've got the following screen after trying to
search for "beans" and clicking the first link:


It was because of bad/broken data - I've removed it and now the link works.

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

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

[Egor Pasko]

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

here is my review:

(1)
patch applies well, does not affect IA-32, x86_64 builds

(2)
Migration to MemoryManager based STL is of special goodness. Thank you!
But some of not MemManaged usages are not wiped out yet:
IpfType.h: multimap
IpfEmitter.{h|cpp}: vector bitset
could you eliminate them for unification, please?

(3)
some logging code is commented-out, but this should be OK for now

> 
> Thank you,
> Konstantin
> 
> "Konstantin Anisimov" <[EMAIL PROTECTED]> wrote in message 
> news:[EMAIL PROTECTED]
> > Hi all,
> >
> > I suggest new patch from the series Igor introdusced.
> > 1. To move direct predicated calls in separete node. It allows to have 
> > under
> > predicate short branch instruction instead of call and thus
> >   reduce possible misprediction penalty.
> > 2. I have implemented new node merging algorithm. It is more effective 
> > than
> > previouc one and besides purging empty nodes.
> >
> > All changes made in Code layouting and I suggest integrate them in one
> > patch.
> >
> > Thank you,
> > Konstantin
> >
> > "Igor Chebykin" <[EMAIL PROTECTED]> wrote in message 
> > news:[EMAIL PROTECTED]
> > Hello all,
> >
> > I suggest a short series of patches for drlvm ipf code generator.
> > We have some improvements for jitrino/ipf
> > and would like to commit its to harmony.
> >
> > All patches will change only vm/jitrino/src/codegenerator/ipf/* files,
> > therefore ia32 remains OK.
> >
> > The first patch is about 67k size and contains following files:
> > IpfCfg.h, IpfCfg.cpp
> >   methods added in Edge and Node classes
> > IpfCodeLayouter.h, IpfCodeLayouter.cpp
> >   new BotomUp algorithm implementation
> > IpfEmitter.h, IpfEmitter.cpp
> >   minor changes in logging, Emitter::registerDirectCall() and
> > debugging support
> > IpfIrPrinter.h, IpfIrPrinter.cpp
> >   added method to print Node chains
> > IpfType.h
> >   types to support Node chains added
> > IpfCfgVerifier.cpp
> >   method cfg.getArgs() deprecated
> > IpfInst.cpp
> >   methods to identify inst kind added (isBr, isCall …)
> > IpfRegisterAllocator.cpp
> >   minor changes in logging
> >
> > Thanks,
> > Igor.
> >
> >
> > -- 
> > Igor Chebykin, Intel Middleware Products Division
> >
> > -
> > Terms of use : http://incubator.apache.org/harmony/mailing.html
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> >
> >
> > 
> 
> 
> 
> 

-- 
Egor Pasko

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

[Eugene Ostrovsky]

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.

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?

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 resources allocated for these
addrs)

(2):
2.1. VM  -call-> JIT (compile a method for me, please)
2.2. JIT -call-> VM  (I generated code from addr X to addr Y, look at this
one)
2.3. VM  -call-> TI  (here is the code for you)

(1) has a disadvantage in case one JIT instance compiles different
methods in parallel. And we should have a synchronized method addr
repository, which is not easy to wipe out in the right way.

(2) seems more straightforward from the JIT side because JIT can
report method boundary addresses as soon as it determines them on
emitting. That simplifies JIT impl (no allocating/freeng/synch).

BTW, I am curious, is it OK for TI when a method is compiled several
times and put on different addrs?

> Ideas & suggestions are welcome.
>
> Thanks,
> Eugene.
>
> On 10/24/06, Eugene Ostrovsky <[EMAIL PROTECTED]> wrote:
> >
> > Hi all.
> >
> > It seems that we have most of JVMTI implemented in drlvm. Still some
of
> > profiling support features is left.
> > I'm going to take a look on "VM Object Allocation" event.
> > I'll try to come up with design tomorrow.
> >
> > Thanks,
> > Eugene.
> >
> >

--
Egor Pasko

Re: [testing] harmonytest.org new features

[Alexei Zakharov]

Hi Anton,

Good job! :)
One little remark: I've got the following screen after trying to
search for "beans" and clicking the first link:

<---
HTTP Status 500 - Internal Server Error

type Exception report

message Internal Server Error

description The server encountered an internal error (Internal Server
Error) that prevented it from fulfilling this request.

exception

javax.servlet.ServletException: Exception thrown by getter for
property: "run.os" of bean: "result"
at 
org.apache.harmony.testinfra.filters.HibernateSessionRequestFilter.doFilter(HibernateSessionRequestFilter.java:87)
at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:166)
at 
org.apache.catalina.core.ApplicationFilterChain.access$000(ApplicationFilterChain.java:51)
at 
org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:129)
at java.security.AccessController.doPrivileged(Native Method)
at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:125)
at 
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:209)
at 
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:596)
at 
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:433)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:948)
at 
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:144)
at 
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:596)
at 
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:433)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:948)
at 
org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2358)
at 
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:133)
at 
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:596)
at 
org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve.java:118)
at 
7org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:594)
at 
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:116)
at 
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:594)
at 
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:433)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:948)
at 
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:127)
at 
org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:596)
at 
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:433)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:948)
at 
org.apache.ajp.tomcat4.Ajp13Processor.process(Ajp13Processor.java:409)
at org.apache.ajp.tomcat4.Ajp13Processor.run(Ajp13Processor.java:528)
at java.lang.Thread.run(Thread.java:534)

root cause

javax.servlet.ServletException: Exception thrown by getter for
property: "run.os" of bean: "result"
at 
org.apache.jasper.runtime.PageContextImpl.handlePageException(PageContextImpl.java:495)
at org.apache.jsp.showtest_jsp._jspService(showtest_jsp.java:199)
at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:92)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:809)
at 
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:162)
at 
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:240)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:187)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:809)
at 
org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:627)
at 
org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:382)
at 
org.apache.catalina.core.ApplicationDispatcher.access$000(ApplicationDispatcher.java:66)
at 
org.apache.catalina.core.ApplicationDispatcher$PrivilegedForward.run(ApplicationDispatcher.java:81)
at java.security.AccessController.doPrivileged(Native Method)
at 
org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:298)
at 
org.apache.struts.action.RequestProcessor.doForward(RequestProcessor.java:1085)
at 
org.apache.struts.action.RequestProcessor.processForwardConfig(RequestProcessor.java:398)
at 
org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:241)
at 
org.apach

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

[Egor Pasko]

On the 0x21D day of Apache Harmony Nadezhda Morozova wrote:
> +1 for having some getting started info on a separate page. 
> There are some things that need to stand out promptly, and probably
> newbie info is one of them (I mean, I'd want to have such a page when I
> got started with this project). 

you mean, the left-side collection _does not suit_ as "getting started"
info? To me it is fine, I am a bad judge here though (far from beginner)

> We can expand the text suggested by Pavel by adding:
> * links to nice tutorials for other vms

volunteers to make the list are welcome. I cannot remember a single
example, sorry.

> * a short section to say how is a vm used with a couple of examples;
> this won't take too much effort/maintenance but would be a nice clear
> intro, that's not another click away on some site of another project

do "Harmony in Eclipse" and "DRLVM Command-line Tutorial" solve the problem?

> Thank you, 
> Nadya Morozova
>  
> 
> -Original Message-
> From: news [mailto:[EMAIL PROTECTED] On Behalf Of Egor Pasko
> Sent: Friday, November 10, 2006 1:29 PM
> To: harmony-dev@incubator.apache.org
> Subject: Re: [doc][drlvm] The document "Getting started with DRL" is
> outdated
> 
> On the 0x21D day of Apache Harmony Pavel Ozhdikhin wrote:
> > Nadya,
> > 
> > One more proposal about "Getting Started": let's remove all current
> content
> > and write something like following:
> > 
> > "To the moment we got rid of all major differences from other Java
> > implementations, so to use DRLVM you can just build it (here goes link
> to
> > readme with build instructions) and run as any other Java VM. For
> commonly
> > used command-line options please look into the Wiki page (link to
> Salikh's
> > page or to the document)."
> > 
> > What do you think?
> 
> 1 page to hold only 4 lines of text? :)
> 
> > Thanks,
> > Pavel
> > 
> > 
> > On 10 Nov 2006 14:29:59 +0600, Egor Pasko <[EMAIL PROTECTED]>
> wrote:
> > >
> > > On the 0x21D day of Apache Harmony Nadezhda Morozova wrote:
> > > > Good day to you, Egor!
> > >
> > > evening, dark and snowy evening :)
> > >
> > > > What do you say about the getting started doc?
> > >
> > > I expressed it recently. General idea is that Harmony operates near
> > > the same as other JSE implementations. Almost all specifics is in
> > > extra options which we started collecting on Wiki for an extra
> > > HOWTO-like page (BTW, thanks to Salikh for starting the page).
> > >
> > > I believe, it is time to remove the "Getting Started". So, +1 to
> Pavel
> > > Ozhdikhin here.
> > >
> > > BTW, I asked my dad to look at the website. Ideas for improvement
> from
> > > him:
> > > 1) site-local search is useful for a beginner. Hm, Tomcat has it
> with
> > > links to google search. We can have something as soon as we get to
> the
> > > desired TLP :)
> > > 2) it is not obvious that site misprints/problems should be reported
> > > to the mailing list. Commercial websites have something like
> > > "support/suggestions mailto". We can point mailto to the mailing
> list :)
> > >
> > > > Thank you,
> > > > Nadya Morozova
> > > >
> > > > -Original Message-
> > > > From: news [mailto:[EMAIL PROTECTED] On Behalf Of Egor Pasko
> > > > Sent: Friday, November 10, 2006 8:55 AM
> > > > To: harmony-dev@incubator.apache.org
> > > > Subject: Re: [doc][drlvm] The document "Getting started with DRL"
> is
> > > > outdated
> > > >
> > > > On the 0x21D day of Apache Harmony Nadezhda Morozova wrote:
> > > > > Egor,
> > > > > I generally like the idea of improving navigation over the site
> -
> > > > > there's never too much of that. However, I am not sure whether
> we need
> > > > > yet another separate page for introductory/guidance info. I hope
> the
> > > > > starting page + the generic pages we have are mostly fine.
> However,
> > > > > adding a link here and there to lead site visitors.
> > > > >
> > > > > Getting started could be a more specific project-oriented page.
> There,
> > > > > you can tell people to go download,
> build
> > > > the
> > > > > code. After which, they can start using it just as any other
> > > > > RI-compatible jdk. With the exceptions, see our
> > > > > wiki pages.
> > > > > To use the vm, readers might need to use the following
> options...
> > > > > If they want to read more on our VM, they can visit the
> > > > > component page. If no website page contains an
> answer -
> > > > > they can read wiki faqa.
> > > > > .. or something like that :)
> > > >
> > > > Nadya, I really appreciate our efforts :) But this morning I woke
> up
> > > > and looked the site structure with the eye of a beginner. And
> could
> > > > not find any obvius flaws in the main structure. Left-side
> collection
> > > > of links is in a very good shape, good for beginner-level
> navigation
> > > > and contains almost all links you listed here.
> > > >
> > > > This was a really refreshing morning :)
> > > >
> > > > I'll ask some guys who are new to the project, how they feel about
> th

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

[Egor Pasko]

On the 0x21D day of Apache Harmony Nadezhda Morozova wrote:
> Alexei,
> Tutorials might be fine for mature projects, but I do not think ours is
> ready for a big flow of users yet, that would require a tutorial.

we _are_ mature for a small tutorial :)

> So +1 for having a nice good  tutorial ... one day. 
> If there are volunteers to write the tutorial now, I'd be happy to help
> though.

well, actually, I love tutorials too, especially the one for VIM :)
some contraversal inside me..fighting..done

let's then say "A Short Eclipse Tutorial with Harmony", and then
"DRLVM Command-line Args Tutorial". Howabout that?

> Thank you, 
> Nadya Morozova
>  
> -Original Message-
> From: Fedotov, Alexei A [mailto:[EMAIL PROTECTED] 
> Sent: Friday, November 10, 2006 1:40 PM
> To: harmony-dev@incubator.apache.org
> Subject: RE: Re: [doc][drlvm] The document "Getting started with DRL" is
> outdated
> 
> Guys,
> 
> I like good tutorials. I learned VIM using a tutorial. I don't need the
> VIM tutorial any longer, but at the beginning it was useful.
> 
>   +1 for maintain Getting Started as is with minor changes
> 
> Why Eclipse was chosen for the tutorial? Our goal was to use Harmony for
> Harmony development. I liked that idea.
> 
> With best regards,
> Alexei Fedotov,
> Intel Java & XML Engineering
> 
> >-Original Message-
> >From: news [mailto:[EMAIL PROTECTED] On Behalf Of Egor Pasko
> >Sent: Friday, November 10, 2006 1:29 PM
> >To: harmony-dev@incubator.apache.org
> >Subject: Re: [doc][drlvm] The document "Getting started with DRL" is
> >outdated
> >
> >On the 0x21D day of Apache Harmony Pavel Ozhdikhin wrote:
> >> Nadya,
> >>
> >> One more proposal about "Getting Started": let's remove all current
> >content
> >> and write something like following:
> >>
> >> "To the moment we got rid of all major differences from other Java
> >> implementations, so to use DRLVM you can just build it (here goes
> link to
> >> readme with build instructions) and run as any other Java VM. For
> >commonly
> >> used command-line options please look into the Wiki page (link to
> >Salikh's
> >> page or to the document)."
> >>
> >> What do you think?
> >
> >1 page to hold only 4 lines of text? :)
> >
> >> Thanks,
> >> Pavel
> >>
> >>
> >> On 10 Nov 2006 14:29:59 +0600, Egor Pasko <[EMAIL PROTECTED]>
> wrote:
> >> >
> >> > On the 0x21D day of Apache Harmony Nadezhda Morozova wrote:
> >> > > Good day to you, Egor!
> >> >
> >> > evening, dark and snowy evening :)
> >> >
> >> > > What do you say about the getting started doc?
> >> >
> >> > I expressed it recently. General idea is that Harmony operates near
> >> > the same as other JSE implementations. Almost all specifics is in
> >> > extra options which we started collecting on Wiki for an extra
> >> > HOWTO-like page (BTW, thanks to Salikh for starting the page).
> >> >
> >> > I believe, it is time to remove the "Getting Started". So, +1 to
> Pavel
> >> > Ozhdikhin here.
> >> >
> >> > BTW, I asked my dad to look at the website. Ideas for improvement
> from
> >> > him:
> >> > 1) site-local search is useful for a beginner. Hm, Tomcat has it
> with
> >> > links to google search. We can have something as soon as we get to
> the
> >> > desired TLP :)
> >> > 2) it is not obvious that site misprints/problems should be
> reported
> >> > to the mailing list. Commercial websites have something like
> >> > "support/suggestions mailto". We can point mailto to the mailing
> list
> >:)
> >> >
> >> > > Thank you,
> >> > > Nadya Morozova
> >> > >
> >> > > -Original Message-
> >> > > From: news [mailto:[EMAIL PROTECTED] On Behalf Of Egor Pasko
> >> > > Sent: Friday, November 10, 2006 8:55 AM
> >> > > To: harmony-dev@incubator.apache.org
> >> > > Subject: Re: [doc][drlvm] The document "Getting started with DRL"
> is
> >> > > outdated
> >> > >
> >> > > On the 0x21D day of Apache Harmony Nadezhda Morozova wrote:
> >> > > > Egor,
> >> > > > I generally like the idea of improving navigation over the site
> -
> >> > > > there's never too much of that. However, I am not sure whether
> we
> >need
> >> > > > yet another separate page for introductory/guidance info. I
> hope
> >the
> >> > > > starting page + the generic pages we have are mostly fine.
> However,
> >> > > > adding a link here and there to lead site visitors.
> >> > > >
> >> > > > Getting started could be a more specific project-oriented page.
> >There,
> >> > > > you can tell people to go download,
> build
> >> > > the
> >> > > > code. After which, they can start using it just as any other
> >> > > > RI-compatible jdk. With the exceptions, see our
> >> > > > wiki pages.
> >> > > > To use the vm, readers might need to use the following
> options...
> >> > > > If they want to read more on our VM, they can visit the
> >> > > > component page. If no website page contains an
> answer
> >-
> >> > > > they can read wiki faqa.
> >> > > > .. or something like that :)
> >> > >
> >> > > Nadya, I really appreciate our efforts :) But thi

Re: [drlvm] release vs. debug

[Gregory Shimansky]

Well I am always testing patches in _default_ mode which debug for VM, 
release for JIT and whatever it is for classlib. If defaults change then 
 it will be some other conditions. Average time to run build test is 
~60 minutes.


Pavel Ozhdikhin wrote:

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

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



Actually I'm fine if the committers will check both debug and release 
builds

and I encourage them to check on all supported platforms. But I'm not a
committer. :)

Thanks,
Pavel


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


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

Rana


On 11/9/06, Pavel Ozhdikhin <[EMAIL PROTECTED]> wrote:
>
> +1 for debug testing before submitting a patch.
>
> But, for pre-commit testing we should be careful saying we'll test all
the
> patches in debug mode. Though it imprves quality of checks, debug build
is
> significantly slower then release, especially when running with
> interpreter
> or Jitrino.OPT. I ran "build test" on the DRLVM built in debug mode and
it
> takes about 5 times more time than release version on my laptop, The
times
> were as follows:
>
> "build test", Windows XP/ IA32:
> DRLVM release: 22 min 55 sec
> DRLVM debug: 99 min 23 sec
>
> So, may be the good choice will be to ask patch submitters to check
their
> patches on the debug build and, if the JIRA issue contains comments 
that

> this check is passed, committers may test it on release build only.
>
> Thanks,
> Pavel
>
> On 11/10/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
> >
> > Well, since the problem is repeatable :)
> >
> >
> > Gregory Shimansky wrote:
> > > Geir Magnusson Jr. wrote:
> > >>
> > >>
> > >> Alexei Zakharov wrote:
> > >>> Hi DRLVM fans,
> > >>>
> > >>> I encountered a rather strange problem while working on some 
class

> > >>> library tests. At least two tests from the beans module hang (or
> > >>> crash) while running on DRLVM debug builds but work fine on DRLVM
> > >>> release builds. I thought that debug build is something about
adding
> > >>> debug symbols to VM binaries and this should not affect the
> > >>> functionality. Can someone shed a light on this?
> > >>
> > >> I would think it's just an assertion firing...
> > >
> > > Actually it is more than that. In debug mode TRACE statements are
> > > compiled and therefore produce executable code. There may also be
some
> > > bugs in compiler generating code in different modes (although this
> > > usually happens for release).
> > >
> > > I don't know why hanging happens, but the difference in generated
code
> > > is actually quite big. Also assertions or any crashes go to
> > > exceptions/signal handlers which may happen to loop infinitely,
there
> > > were bugs like this happening on the current version of sources,
look
> at
> > > HARMONY-2018 and HADMONY-2006.
> > >
> > >>> This is the first
> > >>> question. The second question - what we should do with such 
tests.

> The
> > >>> tests pass on the downloadable HDK and JRE snapshots as well 
as on
> > >>> classlib + j9. What should be the commit criteria for DRLVM – 
i.e.

> > >>> what is the *true* build? :) I think many people here currently
use
> > >>> snapshots to test their patches.
> > >>
> > >> debug :)  don't sweep the problems under the rug...
> > >
> > > +1


--
Gregory

Re: [drlvm] release vs. debug

[Alexei Zakharov]

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


As far as I understand the only person who answers for the commit is a
committer. So I don't think that establishing a policy that shifts a
part of responsibility from the committer is a good idea.

Well, I have another silly question to gurus indeed. Is there any
possibility that some piece of code can break / hang the release build
if it passes ok on the debug build?

Thanks,

2006/11/10, Pavel Ozhdikhin <[EMAIL PROTECTED]>:

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

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


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

Thanks,
Pavel


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




--
Alexei Zakharov,
Intel Enterprise Solutions Software Division

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

[Egor Pasko]

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 resources allocated for these addrs)

(2):
2.1. VM  -call-> JIT (compile a method for me, please)
2.2. JIT -call-> VM  (I generated code from addr X to addr Y, look at this one)
2.3. VM  -call-> TI  (here is the code for you)

(1) has a disadvantage in case one JIT instance compiles different
methods in parallel. And we should have a synchronized method addr
repository, which is not easy to wipe out in the right way.

(2) seems more straightforward from the JIT side because JIT can
report method boundary addresses as soon as it determines them on
emitting. That simplifies JIT impl (no allocating/freeng/synch).

BTW, I am curious, is it OK for TI when a method is compiled several
times and put on different addrs?

> Ideas & suggestions are welcome.
> 
> Thanks,
> Eugene.
> 
> On 10/24/06, Eugene Ostrovsky <[EMAIL PROTECTED]> wrote:
> >
> > Hi all.
> >
> > It seems that we have most of JVMTI implemented in drlvm. Still some of
> > profiling support features is left.
> > I'm going to take a look on "VM Object Allocation" event.
> > I'll try to come up with design tomorrow.
> >
> > Thanks,
> > Eugene.
> >
> >

-- 
Egor Pasko

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

[Morozova, Nadezhda]

+1 to write a new getting started page. 

Distribution of its old content:
- start an application: same as in other vms, might not need it
- start an app in eclipse, 
- debug an app in eclipse: nowhere, need to expand the Working with
Eclipse page instead
- cmd options: wiki page 
Did I miss anything? 

Thank you, 
Nadya Morozova
 

-Original Message-
From: Pavel Ozhdikhin [mailto:[EMAIL PROTECTED] 
Sent: Friday, November 10, 2006 12:19 PM
To: harmony-dev@incubator.apache.org
Subject: Re: [doc][drlvm] The document "Getting started with DRL" is
outdated

Nadya,

One more proposal about "Getting Started": let's remove all current
content
and write something like following:

"To the moment we got rid of all major differences from other Java
implementations, so to use DRLVM you can just build it (here goes link
to
readme with build instructions) and run as any other Java VM. For
commonly
used command-line options please look into the Wiki page (link to
Salikh's
page or to the document)."

What do you think?

Thanks,
Pavel


On 10 Nov 2006 14:29:59 +0600, Egor Pasko <[EMAIL PROTECTED]> wrote:
>
> On the 0x21D day of Apache Harmony Nadezhda Morozova wrote:
> > Good day to you, Egor!
>
> evening, dark and snowy evening :)
>
> > What do you say about the getting started doc?
>
> I expressed it recently. General idea is that Harmony operates near
> the same as other JSE implementations. Almost all specifics is in
> extra options which we started collecting on Wiki for an extra
> HOWTO-like page (BTW, thanks to Salikh for starting the page).
>
> I believe, it is time to remove the "Getting Started". So, +1 to Pavel
> Ozhdikhin here.
>
> BTW, I asked my dad to look at the website. Ideas for improvement from
> him:
> 1) site-local search is useful for a beginner. Hm, Tomcat has it with
> links to google search. We can have something as soon as we get to the
> desired TLP :)
> 2) it is not obvious that site misprints/problems should be reported
> to the mailing list. Commercial websites have something like
> "support/suggestions mailto". We can point mailto to the mailing list
:)
>
> > Thank you,
> > Nadya Morozova
> >
> > -Original Message-
> > From: news [mailto:[EMAIL PROTECTED] On Behalf Of Egor Pasko
> > Sent: Friday, November 10, 2006 8:55 AM
> > To: harmony-dev@incubator.apache.org
> > Subject: Re: [doc][drlvm] The document "Getting started with DRL" is
> > outdated
> >
> > On the 0x21D day of Apache Harmony Nadezhda Morozova wrote:
> > > Egor,
> > > I generally like the idea of improving navigation over the site -
> > > there's never too much of that. However, I am not sure whether we
need
> > > yet another separate page for introductory/guidance info. I hope
the
> > > starting page + the generic pages we have are mostly fine.
However,
> > > adding a link here and there to lead site visitors.
> > >
> > > Getting started could be a more specific project-oriented page.
There,
> > > you can tell people to go download,
build
> > the
> > > code. After which, they can start using it just as any other
> > > RI-compatible jdk. With the exceptions, see our
> > > wiki pages.
> > > To use the vm, readers might need to use the following options...
> > > If they want to read more on our VM, they can visit the
> > > component page. If no website page contains an answer
-
> > > they can read wiki faqa.
> > > .. or something like that :)
> >
> > Nadya, I really appreciate our efforts :) But this morning I woke up
> > and looked the site structure with the eye of a beginner. And could
> > not find any obvius flaws in the main structure. Left-side
collection
> > of links is in a very good shape, good for beginner-level navigation
> > and contains almost all links you listed here.
> >
> > This was a really refreshing morning :)
> >
> > I'll ask some guys who are new to the project, how they feel about
the
> > site. And will report back, if I find something.
> >
> > Refreshing morning is over, now back to work..
> >
> > > Thank you,
> > > Nadya Morozova
> > >
> > > -Original Message-
> > > From: news [mailto:[EMAIL PROTECTED] On Behalf Of Egor Pasko
> > > Sent: Thursday, November 09, 2006 5:33 PM
> > > To: harmony-dev@incubator.apache.org
> > > Subject: Re: [doc][drlvm] The document "Getting started with DRL"
is
> > > outdated
> > >
> > > On the 0x21C day of Apache Harmony Pavel Ozhdikhin wrote:
> > > > On 11/9/06, Morozova, Nadezhda <[EMAIL PROTECTED]>
wrote:
> > > > >
> > > > > Egor,
> > > > > +1 for
> > > > > Just idea: "Getting Started" may contain a collection of links
to
> > > the
> > > > > main website and other resources with short descriptions
("Site
> > Map"
> > > > > or something) so that people are comfortable floating around
in
> > the
> > > web.
> > > >
> > > >
> > > >
> > > > We already have one page having links to the resources about
DRLVM:
> > > >
http://incubator.apache.org/harmony/subcomponents/drlvm/index.html
> > > > Why do you think we need another one?
> > >
> > > because it is only 

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

[Morozova, Nadezhda]

+1 for having some getting started info on a separate page. 
There are some things that need to stand out promptly, and probably
newbie info is one of them (I mean, I'd want to have such a page when I
got started with this project). 

We can expand the text suggested by Pavel by adding:
* links to nice tutorials for other vms
* a short section to say how is a vm used with a couple of examples;
this won't take too much effort/maintenance but would be a nice clear
intro, that's not another click away on some site of another project

Thank you, 
Nadya Morozova
 

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

On the 0x21D day of Apache Harmony Pavel Ozhdikhin wrote:
> Nadya,
> 
> One more proposal about "Getting Started": let's remove all current
content
> and write something like following:
> 
> "To the moment we got rid of all major differences from other Java
> implementations, so to use DRLVM you can just build it (here goes link
to
> readme with build instructions) and run as any other Java VM. For
commonly
> used command-line options please look into the Wiki page (link to
Salikh's
> page or to the document)."
> 
> What do you think?

1 page to hold only 4 lines of text? :)

> Thanks,
> Pavel
> 
> 
> On 10 Nov 2006 14:29:59 +0600, Egor Pasko <[EMAIL PROTECTED]>
wrote:
> >
> > On the 0x21D day of Apache Harmony Nadezhda Morozova wrote:
> > > Good day to you, Egor!
> >
> > evening, dark and snowy evening :)
> >
> > > What do you say about the getting started doc?
> >
> > I expressed it recently. General idea is that Harmony operates near
> > the same as other JSE implementations. Almost all specifics is in
> > extra options which we started collecting on Wiki for an extra
> > HOWTO-like page (BTW, thanks to Salikh for starting the page).
> >
> > I believe, it is time to remove the "Getting Started". So, +1 to
Pavel
> > Ozhdikhin here.
> >
> > BTW, I asked my dad to look at the website. Ideas for improvement
from
> > him:
> > 1) site-local search is useful for a beginner. Hm, Tomcat has it
with
> > links to google search. We can have something as soon as we get to
the
> > desired TLP :)
> > 2) it is not obvious that site misprints/problems should be reported
> > to the mailing list. Commercial websites have something like
> > "support/suggestions mailto". We can point mailto to the mailing
list :)
> >
> > > Thank you,
> > > Nadya Morozova
> > >
> > > -Original Message-
> > > From: news [mailto:[EMAIL PROTECTED] On Behalf Of Egor Pasko
> > > Sent: Friday, November 10, 2006 8:55 AM
> > > To: harmony-dev@incubator.apache.org
> > > Subject: Re: [doc][drlvm] The document "Getting started with DRL"
is
> > > outdated
> > >
> > > On the 0x21D day of Apache Harmony Nadezhda Morozova wrote:
> > > > Egor,
> > > > I generally like the idea of improving navigation over the site
-
> > > > there's never too much of that. However, I am not sure whether
we need
> > > > yet another separate page for introductory/guidance info. I hope
the
> > > > starting page + the generic pages we have are mostly fine.
However,
> > > > adding a link here and there to lead site visitors.
> > > >
> > > > Getting started could be a more specific project-oriented page.
There,
> > > > you can tell people to go download,
build
> > > the
> > > > code. After which, they can start using it just as any other
> > > > RI-compatible jdk. With the exceptions, see our
> > > > wiki pages.
> > > > To use the vm, readers might need to use the following
options...
> > > > If they want to read more on our VM, they can visit the
> > > > component page. If no website page contains an
answer -
> > > > they can read wiki faqa.
> > > > .. or something like that :)
> > >
> > > Nadya, I really appreciate our efforts :) But this morning I woke
up
> > > and looked the site structure with the eye of a beginner. And
could
> > > not find any obvius flaws in the main structure. Left-side
collection
> > > of links is in a very good shape, good for beginner-level
navigation
> > > and contains almost all links you listed here.
> > >
> > > This was a really refreshing morning :)
> > >
> > > I'll ask some guys who are new to the project, how they feel about
the
> > > site. And will report back, if I find something.
> > >
> > > Refreshing morning is over, now back to work..
> > >
> > > > Thank you,
> > > > Nadya Morozova
> > > >
> > > > -Original Message-
> > > > From: news [mailto:[EMAIL PROTECTED] On Behalf Of Egor Pasko
> > > > Sent: Thursday, November 09, 2006 5:33 PM
> > > > To: harmony-dev@incubator.apache.org
> > > > Subject: Re: [doc][drlvm] The document "Getting started with
DRL" is
> > > > outdated
> > > >
> > > > On the 0x21C day of Apache Harmony Pavel Ozhdikhin wrote:
> > > > > On 11/9/06, Morozova, Nadezhda <[EMAIL PROTECTED]>
wrote:
> > > > > >
> > > > >

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

[Morozova, Nadezhda]

Alexei,
Tutorials might be fine for mature projects, but I do not think ours is
ready for a big flow of users yet, that would require a tutorial.
So +1 for having a nice good  tutorial ... one day. 
If there are volunteers to write the tutorial now, I'd be happy to help
though.

Thank you, 
Nadya Morozova
 
-Original Message-
From: Fedotov, Alexei A [mailto:[EMAIL PROTECTED] 
Sent: Friday, November 10, 2006 1:40 PM
To: harmony-dev@incubator.apache.org
Subject: RE: Re: [doc][drlvm] The document "Getting started with DRL" is
outdated

Guys,

I like good tutorials. I learned VIM using a tutorial. I don't need the
VIM tutorial any longer, but at the beginning it was useful.

+1 for maintain Getting Started as is with minor changes

Why Eclipse was chosen for the tutorial? Our goal was to use Harmony for
Harmony development. I liked that idea.

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

>-Original Message-
>From: news [mailto:[EMAIL PROTECTED] On Behalf Of Egor Pasko
>Sent: Friday, November 10, 2006 1:29 PM
>To: harmony-dev@incubator.apache.org
>Subject: Re: [doc][drlvm] The document "Getting started with DRL" is
>outdated
>
>On the 0x21D day of Apache Harmony Pavel Ozhdikhin wrote:
>> Nadya,
>>
>> One more proposal about "Getting Started": let's remove all current
>content
>> and write something like following:
>>
>> "To the moment we got rid of all major differences from other Java
>> implementations, so to use DRLVM you can just build it (here goes
link to
>> readme with build instructions) and run as any other Java VM. For
>commonly
>> used command-line options please look into the Wiki page (link to
>Salikh's
>> page or to the document)."
>>
>> What do you think?
>
>1 page to hold only 4 lines of text? :)
>
>> Thanks,
>> Pavel
>>
>>
>> On 10 Nov 2006 14:29:59 +0600, Egor Pasko <[EMAIL PROTECTED]>
wrote:
>> >
>> > On the 0x21D day of Apache Harmony Nadezhda Morozova wrote:
>> > > Good day to you, Egor!
>> >
>> > evening, dark and snowy evening :)
>> >
>> > > What do you say about the getting started doc?
>> >
>> > I expressed it recently. General idea is that Harmony operates near
>> > the same as other JSE implementations. Almost all specifics is in
>> > extra options which we started collecting on Wiki for an extra
>> > HOWTO-like page (BTW, thanks to Salikh for starting the page).
>> >
>> > I believe, it is time to remove the "Getting Started". So, +1 to
Pavel
>> > Ozhdikhin here.
>> >
>> > BTW, I asked my dad to look at the website. Ideas for improvement
from
>> > him:
>> > 1) site-local search is useful for a beginner. Hm, Tomcat has it
with
>> > links to google search. We can have something as soon as we get to
the
>> > desired TLP :)
>> > 2) it is not obvious that site misprints/problems should be
reported
>> > to the mailing list. Commercial websites have something like
>> > "support/suggestions mailto". We can point mailto to the mailing
list
>:)
>> >
>> > > Thank you,
>> > > Nadya Morozova
>> > >
>> > > -Original Message-
>> > > From: news [mailto:[EMAIL PROTECTED] On Behalf Of Egor Pasko
>> > > Sent: Friday, November 10, 2006 8:55 AM
>> > > To: harmony-dev@incubator.apache.org
>> > > Subject: Re: [doc][drlvm] The document "Getting started with DRL"
is
>> > > outdated
>> > >
>> > > On the 0x21D day of Apache Harmony Nadezhda Morozova wrote:
>> > > > Egor,
>> > > > I generally like the idea of improving navigation over the site
-
>> > > > there's never too much of that. However, I am not sure whether
we
>need
>> > > > yet another separate page for introductory/guidance info. I
hope
>the
>> > > > starting page + the generic pages we have are mostly fine.
However,
>> > > > adding a link here and there to lead site visitors.
>> > > >
>> > > > Getting started could be a more specific project-oriented page.
>There,
>> > > > you can tell people to go download,
build
>> > > the
>> > > > code. After which, they can start using it just as any other
>> > > > RI-compatible jdk. With the exceptions, see our
>> > > > wiki pages.
>> > > > To use the vm, readers might need to use the following
options...
>> > > > If they want to read more on our VM, they can visit the
>> > > > component page. If no website page contains an
answer
>-
>> > > > they can read wiki faqa.
>> > > > .. or something like that :)
>> > >
>> > > Nadya, I really appreciate our efforts :) But this morning I woke
up
>> > > and looked the site structure with the eye of a beginner. And
could
>> > > not find any obvius flaws in the main structure. Left-side
collection
>> > > of links is in a very good shape, good for beginner-level
navigation
>> > > and contains almost all links you listed here.
>> > >
>> > > This was a really refreshing morning :)
>> > >
>> > > I'll ask some guys who are new to the project, how they feel
about
>the
>> > > site. And will report back, if I find something.
>> > >
>> > > Refreshing morning is over, now back to work..
>> > >
>> > > > Thank you,
>> > > > Nadya Moroz

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

[Eugene Ostrovsky]

Opended issue  *HARMONY-2145
* .


On 11/10/06, Eugene Ostrovsky <[EMAIL PROTECTED]> 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."

Ideas & suggestions are welcome.

Thanks,
Eugene.

On 10/24/06, Eugene Ostrovsky < [EMAIL PROTECTED]> wrote:
>
> Hi all.
>
> It seems that we have most of JVMTI implemented in drlvm. Still some of
> profiling support features is left.
> I'm going to take a look on "VM Object Allocation" event.
> I'll try to come up with design tomorrow.
>
> Thanks,
> Eugene.
>
>

Re: [general] Sun will take GPL License?

[Ivan Volosyuk]

On 11/10/06, Dalibor Topic <[EMAIL PROTECTED]> wrote:

Geir Magnusson Jr.  pobox.com> writes:

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

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


IMHO, there can be still scary problems if some parts of the code are
covered by patents even if the code is licensed by GPL v2. Am I
correct?

--
Ivan

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

[Eugene Ostrovsky]

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."

Ideas & suggestions are welcome.

Thanks,
Eugene.

On 10/24/06, Eugene Ostrovsky <[EMAIL PROTECTED]> wrote:


Hi all.

It seems that we have most of JVMTI implemented in drlvm. Still some of
profiling support features is left.
I'm going to take a look on "VM Object Allocation" event.
I'll try to come up with design tomorrow.

Thanks,
Eugene.

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

[Dalibor Topic]

Stefano Mazzocchi  apache.org> writes:

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

What killed Harmony as the project it was planned to be wasn't people, in my
opinion. Everyone put a lot of effort into it.

It was stuck in time for months, betwen a non-existent GPLv3, and a non-existant
ASF third party license policy, without either the ASF having the ability to
accept code under anything other then the apache license, and the FSF having the
ability to relicense Classpath to apache license exclusively, without screwing
developers of GPLd VMs out of a class library. Everyone was running in circles.

Both the ASF and FSF have learned from that failure. ASF figured out that having
a third party license policy would work greatly in their favour, the FSF figured
out that they'd better listen to ASF's ideas and make sure GPLv3 and all that
stuff is actually fine.

Structurally, I'd say that the ASF was not the right place at the right time to
pull such a project off, since we got stuck so hard on apparently insurmountable
issues of policy. Same would have most likely happened with the FSF, though, so
with the hindsight, I think a third party, neutral ground without policies
already cast in stone would have worked out much better. I guess Sun figured
that out, too, and I hope they are successful.

After the Harmony experience, I don't think that ASF or FSF are the perfect
place for a project that goes wildly beyond their respective constituencies
(i.e. the people who really, really like the one true apache way or the one true
FSF way). On the other hand, the split has worked in each project's favor, to
some degree. It has also left a lot of people who put their heart in it rather
bitter about the failure to make it all work as planned.

Maybe one day we'll all meet together and exchange those war stories over
beverages in bar. It's been a great pleasure to help get all of this rolling
with you, Geir, Leo, Davanum, and the other guys, and watch Geir and the team
make Harmony rock.

till then,
dalibor topic

[classlib][swing] Serialization of Swing classes

[Ivanov, Alexey A]

Nathan, all,

You shouldn't add explicit serialVersionUID because Sun explicitly states that 
serialized form of Swing classes maybe incompatible with future Swing releases. 
And there's no description of serialized form for any Swing class.

I'm pretty sure Harmony is not compatible with Sun classes with regard to 
serialized from of Swing classes. And new fields can be added to a class or 
removed, which will break the serialized form.

See the Warning in JTree JavaDoc: 
http://java.sun.com/j2se/1.5.0/docs/api/javax/swing/JTree.html

The serialVersionUID declarations were intentionally missed.

Regards,
Alexey.


P.S. Thanks for cleaning up the code to use parameterized types where possible.
I've looked through j.s.BasicSwingTestCase and restricted the type parameter, 
as well as refactored the code accessing Swing components so that it always 
runs on the Event Dispatch Thread. See 
https://issues.apache.org/jira/browse/HARMONY-2078.

Also I've cleaned up some classes where I fixed bugs:
https://issues.apache.org/jira/browse/HARMONY-2089
https://issues.apache.org/jira/browse/HARMONY-2119
https://issues.apache.org/jira/browse/HARMONY-2121

--
Alexey A. Ivanov
Intel Enterprise Solutions Software Division

Re: [crypto] SHA-1 not implemented?

[Tim Ellison]

Robin Garner wrote:
> Stefano Mazzocchi wrote:
>> from Robin's latest runs
>>  
>> http://cs.anu.edu.au/people/Robin.Garner/dacapo/regression/results-20061110/DRLVM/eclipse.small.log
>>
>>
>> there are a bunch of log messages that indicate that harmony doesn't
>> implement SHA-1.
>>
>> Is that true?
>>
> 
> It can't be true, because _all_ the DaCapo benchmarks rely on SHA-1 for
> validation.  I raised JIRA Harmony-2135 on this issue.  Looks like after
> eclipse has run, drlvm forgets how to access the SHA-1 algorithm :(

Yep, the SHA-1 code is still there [1].

[1]
http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/modules/security/src/main/java/common/org/apache/harmony/security/provider/crypto/SHA1Impl.java?view=markup

Regards,
Tim

-- 

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

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

[Tim Ellison]

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

LOL.  AFAIK we took in a patch to get the IA32 code 64-bit clean, but
nobody is regularly building and testing with it.  If you can do that it
would be great.

Regards,
Tim

-- 

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

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

[Fedotov, Alexei A]

Guys,

I like good tutorials. I learned VIM using a tutorial. I don't need the
VIM tutorial any longer, but at the beginning it was useful.

+1 for maintain Getting Started as is with minor changes

Why Eclipse was chosen for the tutorial? Our goal was to use Harmony for
Harmony development. I liked that idea.

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

>-Original Message-
>From: news [mailto:[EMAIL PROTECTED] On Behalf Of Egor Pasko
>Sent: Friday, November 10, 2006 1:29 PM
>To: harmony-dev@incubator.apache.org
>Subject: Re: [doc][drlvm] The document "Getting started with DRL" is
>outdated
>
>On the 0x21D day of Apache Harmony Pavel Ozhdikhin wrote:
>> Nadya,
>>
>> One more proposal about "Getting Started": let's remove all current
>content
>> and write something like following:
>>
>> "To the moment we got rid of all major differences from other Java
>> implementations, so to use DRLVM you can just build it (here goes
link to
>> readme with build instructions) and run as any other Java VM. For
>commonly
>> used command-line options please look into the Wiki page (link to
>Salikh's
>> page or to the document)."
>>
>> What do you think?
>
>1 page to hold only 4 lines of text? :)
>
>> Thanks,
>> Pavel
>>
>>
>> On 10 Nov 2006 14:29:59 +0600, Egor Pasko <[EMAIL PROTECTED]>
wrote:
>> >
>> > On the 0x21D day of Apache Harmony Nadezhda Morozova wrote:
>> > > Good day to you, Egor!
>> >
>> > evening, dark and snowy evening :)
>> >
>> > > What do you say about the getting started doc?
>> >
>> > I expressed it recently. General idea is that Harmony operates near
>> > the same as other JSE implementations. Almost all specifics is in
>> > extra options which we started collecting on Wiki for an extra
>> > HOWTO-like page (BTW, thanks to Salikh for starting the page).
>> >
>> > I believe, it is time to remove the "Getting Started". So, +1 to
Pavel
>> > Ozhdikhin here.
>> >
>> > BTW, I asked my dad to look at the website. Ideas for improvement
from
>> > him:
>> > 1) site-local search is useful for a beginner. Hm, Tomcat has it
with
>> > links to google search. We can have something as soon as we get to
the
>> > desired TLP :)
>> > 2) it is not obvious that site misprints/problems should be
reported
>> > to the mailing list. Commercial websites have something like
>> > "support/suggestions mailto". We can point mailto to the mailing
list
>:)
>> >
>> > > Thank you,
>> > > Nadya Morozova
>> > >
>> > > -Original Message-
>> > > From: news [mailto:[EMAIL PROTECTED] On Behalf Of Egor Pasko
>> > > Sent: Friday, November 10, 2006 8:55 AM
>> > > To: harmony-dev@incubator.apache.org
>> > > Subject: Re: [doc][drlvm] The document "Getting started with DRL"
is
>> > > outdated
>> > >
>> > > On the 0x21D day of Apache Harmony Nadezhda Morozova wrote:
>> > > > Egor,
>> > > > I generally like the idea of improving navigation over the site
-
>> > > > there's never too much of that. However, I am not sure whether
we
>need
>> > > > yet another separate page for introductory/guidance info. I
hope
>the
>> > > > starting page + the generic pages we have are mostly fine.
However,
>> > > > adding a link here and there to lead site visitors.
>> > > >
>> > > > Getting started could be a more specific project-oriented page.
>There,
>> > > > you can tell people to go download,
build
>> > > the
>> > > > code. After which, they can start using it just as any other
>> > > > RI-compatible jdk. With the exceptions, see our
>> > > > wiki pages.
>> > > > To use the vm, readers might need to use the following
options...
>> > > > If they want to read more on our VM, they can visit the
>> > > > component page. If no website page contains an
answer
>-
>> > > > they can read wiki faqa.
>> > > > .. or something like that :)
>> > >
>> > > Nadya, I really appreciate our efforts :) But this morning I woke
up
>> > > and looked the site structure with the eye of a beginner. And
could
>> > > not find any obvius flaws in the main structure. Left-side
collection
>> > > of links is in a very good shape, good for beginner-level
navigation
>> > > and contains almost all links you listed here.
>> > >
>> > > This was a really refreshing morning :)
>> > >
>> > > I'll ask some guys who are new to the project, how they feel
about
>the
>> > > site. And will report back, if I find something.
>> > >
>> > > Refreshing morning is over, now back to work..
>> > >
>> > > > Thank you,
>> > > > Nadya Morozova
>> > > >
>> > > > -Original Message-
>> > > > From: news [mailto:[EMAIL PROTECTED] On Behalf Of Egor Pasko
>> > > > Sent: Thursday, November 09, 2006 5:33 PM
>> > > > To: harmony-dev@incubator.apache.org
>> > > > Subject: Re: [doc][drlvm] The document "Getting started with
DRL"
>is
>> > > > outdated
>> > > >
>> > > > On the 0x21C day of Apache Harmony Pavel Ozhdikhin wrote:
>> > > > > On 11/9/06, Morozova, Nadezhda <[EMAIL PROTECTED]>
>wrote:
>> > > > > >
>> > > > > > Egor,
>> > > > > > +1 for
>> > > > > > Just idea: "Getting Sta

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

[Egor Pasko]

On the 0x21D day of Apache Harmony Pavel Ozhdikhin wrote:
> Nadya,
> 
> One more proposal about "Getting Started": let's remove all current content
> and write something like following:
> 
> "To the moment we got rid of all major differences from other Java
> implementations, so to use DRLVM you can just build it (here goes link to
> readme with build instructions) and run as any other Java VM. For commonly
> used command-line options please look into the Wiki page (link to Salikh's
> page or to the document)."
> 
> What do you think?

1 page to hold only 4 lines of text? :)

> Thanks,
> Pavel
> 
> 
> On 10 Nov 2006 14:29:59 +0600, Egor Pasko <[EMAIL PROTECTED]> wrote:
> >
> > On the 0x21D day of Apache Harmony Nadezhda Morozova wrote:
> > > Good day to you, Egor!
> >
> > evening, dark and snowy evening :)
> >
> > > What do you say about the getting started doc?
> >
> > I expressed it recently. General idea is that Harmony operates near
> > the same as other JSE implementations. Almost all specifics is in
> > extra options which we started collecting on Wiki for an extra
> > HOWTO-like page (BTW, thanks to Salikh for starting the page).
> >
> > I believe, it is time to remove the "Getting Started". So, +1 to Pavel
> > Ozhdikhin here.
> >
> > BTW, I asked my dad to look at the website. Ideas for improvement from
> > him:
> > 1) site-local search is useful for a beginner. Hm, Tomcat has it with
> > links to google search. We can have something as soon as we get to the
> > desired TLP :)
> > 2) it is not obvious that site misprints/problems should be reported
> > to the mailing list. Commercial websites have something like
> > "support/suggestions mailto". We can point mailto to the mailing list :)
> >
> > > Thank you,
> > > Nadya Morozova
> > >
> > > -Original Message-
> > > From: news [mailto:[EMAIL PROTECTED] On Behalf Of Egor Pasko
> > > Sent: Friday, November 10, 2006 8:55 AM
> > > To: harmony-dev@incubator.apache.org
> > > Subject: Re: [doc][drlvm] The document "Getting started with DRL" is
> > > outdated
> > >
> > > On the 0x21D day of Apache Harmony Nadezhda Morozova wrote:
> > > > Egor,
> > > > I generally like the idea of improving navigation over the site -
> > > > there's never too much of that. However, I am not sure whether we need
> > > > yet another separate page for introductory/guidance info. I hope the
> > > > starting page + the generic pages we have are mostly fine. However,
> > > > adding a link here and there to lead site visitors.
> > > >
> > > > Getting started could be a more specific project-oriented page. There,
> > > > you can tell people to go download, build
> > > the
> > > > code. After which, they can start using it just as any other
> > > > RI-compatible jdk. With the exceptions, see our
> > > > wiki pages.
> > > > To use the vm, readers might need to use the following options...
> > > > If they want to read more on our VM, they can visit the
> > > > component page. If no website page contains an answer -
> > > > they can read wiki faqa.
> > > > .. or something like that :)
> > >
> > > Nadya, I really appreciate our efforts :) But this morning I woke up
> > > and looked the site structure with the eye of a beginner. And could
> > > not find any obvius flaws in the main structure. Left-side collection
> > > of links is in a very good shape, good for beginner-level navigation
> > > and contains almost all links you listed here.
> > >
> > > This was a really refreshing morning :)
> > >
> > > I'll ask some guys who are new to the project, how they feel about the
> > > site. And will report back, if I find something.
> > >
> > > Refreshing morning is over, now back to work..
> > >
> > > > Thank you,
> > > > Nadya Morozova
> > > >
> > > > -Original Message-
> > > > From: news [mailto:[EMAIL PROTECTED] On Behalf Of Egor Pasko
> > > > Sent: Thursday, November 09, 2006 5:33 PM
> > > > To: harmony-dev@incubator.apache.org
> > > > Subject: Re: [doc][drlvm] The document "Getting started with DRL" is
> > > > outdated
> > > >
> > > > On the 0x21C day of Apache Harmony Pavel Ozhdikhin wrote:
> > > > > On 11/9/06, Morozova, Nadezhda <[EMAIL PROTECTED]> wrote:
> > > > > >
> > > > > > Egor,
> > > > > > +1 for
> > > > > > Just idea: "Getting Started" may contain a collection of links to
> > > > the
> > > > > > main website and other resources with short descriptions ("Site
> > > Map"
> > > > > > or something) so that people are comfortable floating around in
> > > the
> > > > web.
> > > > >
> > > > >
> > > > >
> > > > > We already have one page having links to the resources about DRLVM:
> > > > > http://incubator.apache.org/harmony/subcomponents/drlvm/index.html
> > > > > Why do you think we need another one?
> > > >
> > > > because it is only DRLVM.
> > > > I think of something like "site map", a collection of links. Short
> > > > descriptions to some basic ones.
> > > >
> > > > >
> > > > > +1 for
> > > > > > * preparing the "Commonly Used Options for DRLVM" (omitting the
> > >

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

[Konovalova, Svetlana]

Alexey,
I've applied your patch and must admit that my local site looks much
better now. It really breaks nothing! :) The patch makes a white space
between the end of a section and a title of the next one wider. IMHO it
enhances information perception and makes pages more comprehensible.

+1 for the patch

Best regards,
Sveta

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

Nadya, all,

I've created JIRA issue and attached a patch to remove this extra table.
See https://issues.apache.org/jira/browse/HARMONY-2140

I've checked several pages, nothing seems to be broken. Please review
the changes.


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


>-Original Message-
>From: Morozova, Nadezhda [mailto:[EMAIL PROTECTED]
>Sent: Thursday, November 09, 2006 10:56 PM
>To: harmony-dev@incubator.apache.org
>Subject: RE: [jira] Good issue resolution guideline (was:
>[classlib]volunteer to supply patches for old JIRAs)
>
>Alexey,
>I agree  that the structure of the resulting HTML website page does not
>appear too linear. When editing the structure, I saw the additional
>table - and left as is; maybe, because I hoped somebody added it on
some
>purpose. For me, the only matter of convenience is that all content
that
>is varied on the page is in a separate table.
>If nobody has an idea why the structure is so complex, we can simplify
>it. The structure is defined in file site.vsl in
site/xdocs/stylesheets.
>A JIRA with patch is welcome as usual.
>
>Thank you,
>Nadya Morozova
>
>
>-Original Message-
>From: Ivanov, Alexey A [mailto:[EMAIL PROTECTED]
>Sent: Thursday, November 09, 2006 5:20 PM
>To: harmony-dev@incubator.apache.org
>Subject: RE: [jira] Good issue resolution guideline (was:
>[classlib]volunteer to supply patches for old JIRAs)
>
>Sveta, all,
>
>I've attached the updated patch to the JIRA.
>
>Please review.
>
>Regards,
>Alexey.
>
>
>P.S. By the way, do we really need to place all the main content into
>another table? I've just looked at the source of the generated HTML
>file, and found it quite confusing. I agree to have a table to format
>the heading of the page and the list of contents on the left, but why
>there's another table where the main content is. I am about this one:
>
> 
> 
>
>
>
>
>   
> 
>Good Issue
>Resolution Guideline
>
>   
>   ... 
>
>The comments here are added by me, and the source is slightly
>reformatted.
>I believe, the  part of the XML can be placed almost as is in the
>content cell of the top-level table without the need for another table
>because it's useless here. Or is it just Anakia limitation?
>
>--
>Alexey A. Ivanov
>Intel Enterprise Solutions Software Division
>
>
>>-Original Message-
>>From: Konovalova, Svetlana [mailto:[EMAIL PROTECTED]
>>Sent: Thursday, November 09, 2006 3:50 PM
>>To: harmony-dev@incubator.apache.org
>>Subject: RE: [jira] Good issue resolution guideline (was:
>>[classlib]volunteer to supply patches for old JIRAs)
>>
>>Alexey,
>>
I'd change the heading "Reporting the Issue" to "Reporting an
Issue",
or omit article at all.
 Well, both articles seem to be fine. Let it be "a/an"
>>>Maybe just omit articles then?
>>Well, how about the third variant: "Reporting Issues"?
>>
>>
>>>I'm still for 'reproduce' because a bug can be (non-)reproducible but
>>>not recreatable.
>>>Any other opinions?
>>Ok, "reproduce" is fine
>>
I'd say: "If you have any questions, discuss them...
>>>That's even better :)
>>Cool!:)
>>
All patches, such as tests and fixes, should be
>>>Good! It's clearer.
>>Fine!
>>
>>>OK. I'll prepare patch update then.
>>Good luck! I'd be glad to review it, if you do not mind. :)
>>
>>Cheers,
>>Sveta
>>
>>Thanks,
>>Alexey.
>>
>>>
>>>
>>>Best regards,
>>>Sveta
>>>
>>>-Original Message-
>>>From: Ivanov, Alexey A [mailto:[EMAIL PROTECTED]
>>>Sent: Thursday, November 09, 2006 1:33 PM
>>>To: harmony-dev@incubator.apache.org
>>>Subject: RE: [jira] Good issue resolution guideline (was:
>>>[classlib]volunteer to supply patches for old JIRAs)
>>>
-Original Message-
From: Konovalova, Svetlana [mailto:[EMAIL PROTECTED]
Sent: Wednesday, November 08, 2006 7:01 PM
To: harmony-dev@incubator.apache.org
Subject: RE: [jira] Good issue resolution guideline (was:
[classlib]volunteer to supply patches for old JIRAs)


I've just submitted a new JIRA
[http://issues.apache.org/jira/browse/HARMONY-2110].
I've added the necessary links from the website to the new page and
>>>have
tried to perfect it a little.
It would be great, if you could find a chance to look through the
>>>patch.
Thanks in advance.
>>>
>>>Sveta,
>>>
>>>I've taken a look and added my c

Re: [build] Building on Eclipse - FYI

[Sian January]

That sounds great.  It would be really good to be able to flesh out the
DRLVM+Eclipse section if anyone has any relevant experience or information.
I don't have any objections about applying the get-involved patch.

Thanks,

Sian


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


Sian,
I've looked through the patches, and they seem to be great! Thanks!
But I agree with Nadya, that we should hold off patching
eclipse-oriented docs. Let's wait and see what eclipse+drlvm gurus will
say.
IMHO we can ask the committers to apply get_involved.patch, which was
created to remove the "Am I Eligible?" section from [1] to [2]. Any
objections?

Best regards,
Sveta

[1]http://incubator.apache.org/harmony/subcomponents/classlibrary/dev_ec
lip
se.html
[2]http://incubator.apache.org/harmony/get-involved.html

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

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

Regards,

Sian


On 09/11/06, Konovalova, Svetlana <[EMAIL PROTECTED]> wrote:
>
> Folks,
> Looking through the site and figuring out how to improve the docs that
> include info on Eclipse, the following ideas came up to my mind:
> 1) Since the "Developing Apache Harmony Class-library
> Code with Eclipse" page [1] is mostly class-library oriented, I
suggest
> reviewing it to remove purely DRLVM-oriented info and leave the page
> where it is now [subcomponents/classlibrary/dev_eclipse.html].
> 2) Add the link from the Quick Help pages to the "Developing Apache
> Harmony Class-library Code with Eclipse" page [1].
> 3) Gather purely DRLVM-oriented info to store it in the "Getting
Started
> with DRL" doc (hope it won't be wiped off the face of the earth; for
> details, see the discussion thread: [doc][drlvm] The document "Getting
> started with DRL" is outdated)
> In this case, we'll get two docs providing info on developing with
> Eclipse:
> [1] - describing how to develop class-library code with Eclipse, and
"GS
> with DRL"(or whatever it'll be) describing how to develop DRLVM
> application in Eclipse.
> Any objections? What do you think? Please right me if I'm wrong.
>
> Best regards,
> Sveta Konovalova
>
> [1]
>
http://incubator.apache.org/harmony/subcomponents/classlibrary/dev_eclip
> se.html
>
>
> -Original Message-
> From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED]
> Sent: Thursday, November 09, 2006 3:58 PM
> To: harmony-dev@incubator.apache.org
> Subject: Re: FW: [build] Building on Eclipse - FYI
>
>
>
> Egor Pasko wrote:
> > On the 0x21C day of Apache Harmony Sian January wrote:
> >> Hello again,
> >>
> >> I have had a closer look at the  "Developing Apache Harmony
> Class-library
> >> Code with Eclipse" page, and I have noticed that the "Configuring
> Eclipse"
> >> and "Develop and Test Code" sections are quite class-library
> specific.
> >> Would it be better to leave those sections as they are and add a
> "Developing
> >> DRLVM with Eclipse" section on the same page?
> >
> > To the moment I am not aware of anybody who would use Eclipse for
> > DRLVM development. So, it's too early to add a page like this.
>
> This will ensure that no one does then - if it's simple to add, lets
add
>
> it...
>
> geir
>
> >
> >> Thanks,
> >>
> >> Sian
> >>
> >>
> >>
> >> On 07/11/06, Konovalova, Svetlana <[EMAIL PROTECTED]>
> wrote:
> >>>
> >>> Sian,
> >>> Sorry for delay in response.
>  I'd like to help with documentation but I don't want to duplicate
> any
> >>> work
>  that you are in the middle of, so let me know if there's anything
> >>> specific >I can do...
> >>> Thanks for your desire to help!
> >>> Well, let's work at the page "Developing Apache Harmony
> Class-library
> >>> Code with Eclipse"
> >>>
>
[http://incubator.apache.org/harmony/subcomponents/classlibrary/dev_ecli
> >>> pse.html] first, if you do not mind.
> >>> AFAIK the majority of items on the page can equally apply to DRLVM
> and
> >>> classlib. IMHO would be great to edit the page to remove
unnecessary
> >>> focus on classlib, to make the page equally relevant for vm
> developers.
> >>> To my mind, the introductory sections should be removed, as they
are
> >>> about generalities that do not always relate to the header of the
> page.
> >>> Could you please take a close look at the page and create the
patch
> to
> >>> improve the content and to remove all classlib-specific info? You
> can
> >>> use Harmony-2009 for it. It would be a great impact into
development
> of
> >>> the site documentation for sure! If you need my help, just let me
> know.
> >>> The second idea is to move the page up, not to store it in
> >>> subcompone

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

[Pavel Ozhdikhin]

Nadya,

One more proposal about "Getting Started": let's remove all current content
and write something like following:

"To the moment we got rid of all major differences from other Java
implementations, so to use DRLVM you can just build it (here goes link to
readme with build instructions) and run as any other Java VM. For commonly
used command-line options please look into the Wiki page (link to Salikh's
page or to the document)."

What do you think?

Thanks,
Pavel


On 10 Nov 2006 14:29:59 +0600, Egor Pasko <[EMAIL PROTECTED]> wrote:


On the 0x21D day of Apache Harmony Nadezhda Morozova wrote:
> Good day to you, Egor!

evening, dark and snowy evening :)

> What do you say about the getting started doc?

I expressed it recently. General idea is that Harmony operates near
the same as other JSE implementations. Almost all specifics is in
extra options which we started collecting on Wiki for an extra
HOWTO-like page (BTW, thanks to Salikh for starting the page).

I believe, it is time to remove the "Getting Started". So, +1 to Pavel
Ozhdikhin here.

BTW, I asked my dad to look at the website. Ideas for improvement from
him:
1) site-local search is useful for a beginner. Hm, Tomcat has it with
links to google search. We can have something as soon as we get to the
desired TLP :)
2) it is not obvious that site misprints/problems should be reported
to the mailing list. Commercial websites have something like
"support/suggestions mailto". We can point mailto to the mailing list :)

> Thank you,
> Nadya Morozova
>
> -Original Message-
> From: news [mailto:[EMAIL PROTECTED] On Behalf Of Egor Pasko
> Sent: Friday, November 10, 2006 8:55 AM
> To: harmony-dev@incubator.apache.org
> Subject: Re: [doc][drlvm] The document "Getting started with DRL" is
> outdated
>
> On the 0x21D day of Apache Harmony Nadezhda Morozova wrote:
> > Egor,
> > I generally like the idea of improving navigation over the site -
> > there's never too much of that. However, I am not sure whether we need
> > yet another separate page for introductory/guidance info. I hope the
> > starting page + the generic pages we have are mostly fine. However,
> > adding a link here and there to lead site visitors.
> >
> > Getting started could be a more specific project-oriented page. There,
> > you can tell people to go download, build
> the
> > code. After which, they can start using it just as any other
> > RI-compatible jdk. With the exceptions, see our
> > wiki pages.
> > To use the vm, readers might need to use the following options...
> > If they want to read more on our VM, they can visit the
> > component page. If no website page contains an answer -
> > they can read wiki faqa.
> > .. or something like that :)
>
> Nadya, I really appreciate our efforts :) But this morning I woke up
> and looked the site structure with the eye of a beginner. And could
> not find any obvius flaws in the main structure. Left-side collection
> of links is in a very good shape, good for beginner-level navigation
> and contains almost all links you listed here.
>
> This was a really refreshing morning :)
>
> I'll ask some guys who are new to the project, how they feel about the
> site. And will report back, if I find something.
>
> Refreshing morning is over, now back to work..
>
> > Thank you,
> > Nadya Morozova
> >
> > -Original Message-
> > From: news [mailto:[EMAIL PROTECTED] On Behalf Of Egor Pasko
> > Sent: Thursday, November 09, 2006 5:33 PM
> > To: harmony-dev@incubator.apache.org
> > Subject: Re: [doc][drlvm] The document "Getting started with DRL" is
> > outdated
> >
> > On the 0x21C day of Apache Harmony Pavel Ozhdikhin wrote:
> > > On 11/9/06, Morozova, Nadezhda <[EMAIL PROTECTED]> wrote:
> > > >
> > > > Egor,
> > > > +1 for
> > > > Just idea: "Getting Started" may contain a collection of links to
> > the
> > > > main website and other resources with short descriptions ("Site
> Map"
> > > > or something) so that people are comfortable floating around in
> the
> > web.
> > >
> > >
> > >
> > > We already have one page having links to the resources about DRLVM:
> > > http://incubator.apache.org/harmony/subcomponents/drlvm/index.html
> > > Why do you think we need another one?
> >
> > because it is only DRLVM.
> > I think of something like "site map", a collection of links. Short
> > descriptions to some basic ones.
> >
> > >
> > > +1 for
> > > > * preparing the "Commonly Used Options for DRLVM" (omitting the
> word
> > > > "supported" intentionally)
> > > > Question on this one: will the page contain vm-only options? What
> > about
> > > > JIT, GC, other? I'd have them all in one place, but we have
> separate
> > > > docs for EM/jit stuff. What do you say?
> > >
> > >
> > > I think we can describe basic options for every component there.
> Only
> > those
> > > that might be interesting for any user. The place for other options
> is
> > in
> > > the run-time help or Developer's Guide for a component.
> >
> > I thought of "most commonly used" op

Re: [drlvm][classlib] thread library - let there be one!

[Andrey Chernyshev]

On 10/26/06, Angela Lin <[EMAIL PROTECTED]> wrote:

On 10/24/06, Weldon Washburn <[EMAIL PROTECTED]> wrote:
>
> If an arbitrary commercial JVM decided to use classlib, will it need to be
> modified to reflect the existing Harmony Classlib threading model?

This is the case no matter how you split the thread library. Whatever
interface you specify for the classlib will need to be supported by
the VM.

> Also, does this mean VM design is constrained by classlib design?  And
> classlib  design is constrained by J9 design?

The classlib and the VM have certain dependencies on each other. This
is not a J9-specific issue.

I would aim for a thread API that is generic enough to support
multiple implementations.


I think it may be hard (if possible at all) to create high-level
threading library which would make just every VM happy. For instance,
DRLVM has a complex synchronization scheme with garbage collector
which is built into the threading library (for example, each time
thread goes into wait state, it must instruct the GC that the thread
can be garbage collected). There also could be VM-specific
optimizations for monitors which are tied to the object layout used in
a particular VM.

Finally, there might be pure-Java written VM's which may choose to
implement threading library almost entirely in Java (may be on top of
j.u.concurrent API ?), borrowing probably only park/unpark, atomic and
may be sort of fork operations from the native code. How could we have
a threading library which will work equally for all VM's?

I agree that bypassing layer (2) by the classlib can be undesirable
because of loosing track for thread/lock states. So it seems that:
- both VM and classlib need to use single thread library, and at the
same level (or, saying that differently, Java code and native code
from classlib should use same threading lib);
-  threading lib is likely be VM-specific (consider DRLVM as an example)

If we agree with the above, doesn't it just mean that the hythr must
be declared as a part of VM? Classlib may probably continue to keep a
"stub" library for the compilation purposes. But there must be the
possibility for other VM's to easily replace it with it's own version.
I guess we do something similar with the luni-kernel-stubs.jar.



Mature VMs that switch to the Harmony classlib would probably
implement a portability layer between the existing VM's thread model
and the Harmony thread API.


I guess mature VM's would likely to have their own very carefully
written and optimized threading libraries, integrated with GC, JIT
e.t.c. It will be easier for them to provide a suitable interface for
classlib rather than rewrite VM on top of hythread, no matter how
perfect is it.




Has anyone considered how ThreadMXBean would be supported by the
proposed classlib thread API subset?


May be ThreadMXBean is just a good candidate for the kernel class set?
At least the spec says "interface for the thread system of the Java
virtual machine". I guess other MXBeans are also interfaces to some of
VM services.


Thanks,
Andrey.




> On 10/24/06, Angela Lin <[EMAIL PROTECTED]> wrote:
> >
> > Consider the group of monitor-related functionality: enter/exit,
> > wait/notify, and interrupt. The implementations of these functions are
> > closely related in the J9-derived hythread, particularly for 3-tier
> > locking. We need to coordinate when we lock the thread mutex, when we
> > lock the monitor mutex, how we use spinlocks, etc. It would be
> > unnatural to split out enter/exit from this group.
>
>
> >
> > On 10/24/06, Weldon Washburn <[EMAIL PROTECTED]> wrote:
> > > On 10/23/06, Angela Lin <[EMAIL PROTECTED]> wrote:
> > > >
> > > > What is the goal here?
> > > >
> > > > 1. If the goal is to create a single thread library that can be used
> > > > by multiple VM and classlib implementations, then the unified thread
> > > > lib should contain everything needed to support a VM implementation.
> > > >
> > > > 2. If the goal is to simply define the interface between the classlib
> > > > and the VM, then the 3rd option may be acceptable. This option seems
> > > > to imply splitting up functionality that requires deep knowledge of
> > > > the threading implementation, which I don't like. Each VM
> > > > implementation would need to implement both the VM and classlib sides
> > > > of the API.
> > >
> > > Is this really the situation?  If Classlib only needs monenter/exit, TLS
> > and
> > > thread_create(), the "deep knowledge" required is probably only
> > > monitorenter/exit which seems like a managable situation.
> > >
> > >
> > > Regards,
> > > > Angela
> > > >
> > > > On 10/19/06, Artem Aliev <[EMAIL PROTECTED]> wrote:
> > > > > Angela, all,
> > > > >
> > > > > I see you point and agree.
> > > > > But if we move hythread lib to the VM we will require all VMs fully
> > > > support it.
> > > > > Is it necessary dependency?
> > > > >
> > > > > So Here is the third way I see.
> > > > > Leave the minimum implementation of hythread in

Re: Harmony passes all tests of Maven 2.0.4

[Alex Blewitt]

Cool! These kind of things really help to show what Harmony is capable of.

Alex.

On 10/11/06, Leo Li <[EMAIL PROTECTED]> wrote:

Hi, all:
 Harmony classlib at revision 473150 passes all tests of Maven 2.0.4 on
windows xp, redhat enterprise 4, unbuntu 6.0.6 and suse 10.
 As for drlvm, it passes on windows xp but fails on redhat linux
enterprise 4. If somebody can reproduce it, I will report it as a
application-oriented bug to jira.
 For detailed information, pls refer to
http://wiki.apache.org/harmony/Apache_Maven.

--
Leo Li
China Software Development Lab, IBM

Re: Harmony passes all tests of Maven 2.0.4

[Andrew Zhang]

Another great piece of news!  great work, Leo! :-)

On 11/10/06, Leo Li <[EMAIL PROTECTED]> wrote:


Hi, all:
Harmony classlib at revision 473150 passes all tests of Maven 2.0.4 on
windows xp, redhat enterprise 4, unbuntu 6.0.6 and suse 10.
As for drlvm, it passes on windows xp but fails on redhat linux
enterprise 4. If somebody can reproduce it, I will report it as a
application-oriented bug to jira.
For detailed information, pls refer to
http://wiki.apache.org/harmony/Apache_Maven.

--
Leo Li
China Software Development Lab, IBM





--
Best regards,
Andrew Zhang

Re: [drlvm] Class unloading support

[Aleksey Ignatenko]

Weldon, I have attached updated patch to H-2000:
cleanup_sources_1558_merged.patch.
Please, see comments.

Aleksey.


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


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


On 11/2/06, Weldon Washburn <[EMAIL PROTECTED]> wrote:
>
> Aleksey,
>
> Excellent step forward -- breaking the patch into two pieces.   This
made
> the patch(es) much more readable.
>
> I glanced at native_sources_cleanup.patch.  It looks like code for
> alloc/dealloc vtables and jitted code blocks.  The original patch made
> vtables into objects.  Will native_sources_cleanup need to change if
vtables
> are normal C structs instead?  Also, I see reference to path
.../gcv4/...  I
> guess this will need to change to support gc_gen and gc_cc.
>
> Once you get native_sources_cleanup.patch in good shape, I have no
problem
> committing it.
>
> If there is no other debate on class unloading design, I will call for a
> vote in a seperate email.
>
>
>
> On 11/2/06, Aleksey Ignatenko <[EMAIL PROTECTED]> wrote:
> >
> > Hi, everyone.
> >
> > I've splitted Harmony-2000 (see details:
> > http://issues.apache.org/jira/browse/HARMONY-2000) patch with
automatic
> > class unloading implementation into 2 independent parts:
> > 1. cleaning native resources (native_sources_cleanup.patch).
> > 2. automatic unloading design implementation (auto_unloading.patch).
> >
> > The first part is independent for all class unloading designs and
could
> > be
> > commited. The second part is class unloading design implementation
(the
> > best
> > class unloading approach is discussed now).
> >
> > I propose to commit native_sources_cleanup.patch and continue class
> > unloading development with minimal requirements on drlvm.
> >
> > Aleksey.
> >
> >
> > On 11/1/06, Aleksey Ignatenko <[EMAIL PROTECTED]> wrote:
> > >
> > > Oops, sorry, misprinted in my suggestion:
> > > if (cl->IsBootstrap() *||
> > *env->b_VTable_trace_is_not_supported_by_GC)
> > >
> > > {
> > > vm_enumerate_jlc(c);
> > > if (c->vtable)
> > >
vm_enumerate_root_reference((void**)&c->vtObj,
> > > FALSE);
> > > }
> > >
> > > Aleksey.
> > >
> > >  On 11/1/06, Aleksey Ignatenko < [EMAIL PROTECTED]> wrote:
> > > >
> > > > Weldon,
> > > >
> > > > >A question for all involved.  Is it possible to somehow make it
> > appear
> > > > that
> > > > >the new objects related to unloading  (VTable, ClassLoader,
> > etc)  are
> > > > always
> > > > >reachable and thus never collected?  I am trying to figure out a
> > way to
> > > > make
> > > > >integration of class unloading independent of correct support
> > inside
> > > > the GC
> > > > >and JIT.  This option could be a command line switch or compile
> > time
> > > > option.
> > > >
> > > > I agree with Robin:
> > > > >Simple.  Keep a list or table of these objects as part of the
root
> > set.
> > > > >Enumerate it optionally depending on a command line option.
> > > >
> > > > Details: you can see from Harmony-2000 patch, that this is done
for
> > > > Bootstrap classes already. If you look at root_set_enum_common.cpp
> > (with the
> > > > patch applied) vm_enumerate_static_fields() function, there is
line:
> > > > if (cl->IsBootstrap())
> > > > {
> > > > vm_enumerate_jlc(c);
> > > > if (c->vtable)
> > > >
> > vm_enumerate_root_reference((void**)&c->vtObj,
> > > > FALSE);
> > > > }
> > > > else
> > > > {
> > > > vm_enumerate_jlc(c, true/*weak*/);
> > > > }
> > > > You can see, that there are strong roots to Bootstrap
j.l.Classesand
> > > > their VTable objects. So I suppose, that it would be very simple
to
> > > > propogate strong roots to all other classes (not only Bootstrap),
> > something
> > > > like:
> > > > if (cl->IsBootstrap() *&&
> > > > env->b_VTable_trace_is_not_supported_by_GC*)
> > > > {
> > > > vm_enumerate_jlc(c);
> > > > if (c->vtable)
> > > >
> > vm_enumerate_root_reference((void**)&c->vtObj,
> > > > FALSE);
> > > > }
> > > > where *b_VTable_trace_is_not_supported_by_GC *is flag which is set
> > > > according to used GC. This will force switching off any class
> > unloading
> > > > support.
> > > >
> > > > Aleksey.
> > > >
> > > >  On 11/1/06, Robin Garner <[EMAIL PROTECTED] > wrote:
> > > > >
> > > > > Weldon Washburn wrote:
> > > > > > On 10/30/06, Robin Garner < [EMAIL PROTECTED] > wrote:
> > > > > >>
> > > > > >> Weldon Washburn wrote:
> > > > > >> > On 10/27/06, Geir Magnusson Jr. < [EMAIL PROTECTED]> wrote:
> > > > > >> >>
> > > > > >> >>
> > > > > >> >>
> > > > > >> >> Weld

Harmony passes all tests of Maven 2.0.4

[Leo Li]

Hi, all:
Harmony classlib at revision 473150 passes all tests of Maven 2.0.4 on
windows xp, redhat enterprise 4, unbuntu 6.0.6 and suse 10.
As for drlvm, it passes on windows xp but fails on redhat linux
enterprise 4. If somebody can reproduce it, I will report it as a
application-oriented bug to jira.
For detailed information, pls refer to
http://wiki.apache.org/harmony/Apache_Maven.

--
Leo Li
China Software Development Lab, IBM

RE: [build] Building on Eclipse - FYI

[Konovalova, Svetlana]

Sian, 
I've looked through the patches, and they seem to be great! Thanks!
But I agree with Nadya, that we should hold off patching
eclipse-oriented docs. Let's wait and see what eclipse+drlvm gurus will
say.
IMHO we can ask the committers to apply get_involved.patch, which was
created to remove the "Am I Eligible?" section from [1] to [2]. Any
objections?
 
Best regards,
Sveta

[1]http://incubator.apache.org/harmony/subcomponents/classlibrary/dev_ec
lip
se.html
[2]http://incubator.apache.org/harmony/get-involved.html

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

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

Regards,

Sian


On 09/11/06, Konovalova, Svetlana <[EMAIL PROTECTED]> wrote:
>
> Folks,
> Looking through the site and figuring out how to improve the docs that
> include info on Eclipse, the following ideas came up to my mind:
> 1) Since the "Developing Apache Harmony Class-library
> Code with Eclipse" page [1] is mostly class-library oriented, I
suggest
> reviewing it to remove purely DRLVM-oriented info and leave the page
> where it is now [subcomponents/classlibrary/dev_eclipse.html].
> 2) Add the link from the Quick Help pages to the "Developing Apache
> Harmony Class-library Code with Eclipse" page [1].
> 3) Gather purely DRLVM-oriented info to store it in the "Getting
Started
> with DRL" doc (hope it won't be wiped off the face of the earth; for
> details, see the discussion thread: [doc][drlvm] The document "Getting
> started with DRL" is outdated)
> In this case, we'll get two docs providing info on developing with
> Eclipse:
> [1] - describing how to develop class-library code with Eclipse, and
"GS
> with DRL"(or whatever it'll be) describing how to develop DRLVM
> application in Eclipse.
> Any objections? What do you think? Please right me if I'm wrong.
>
> Best regards,
> Sveta Konovalova
>
> [1]
>
http://incubator.apache.org/harmony/subcomponents/classlibrary/dev_eclip
> se.html
>
>
> -Original Message-
> From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED]
> Sent: Thursday, November 09, 2006 3:58 PM
> To: harmony-dev@incubator.apache.org
> Subject: Re: FW: [build] Building on Eclipse - FYI
>
>
>
> Egor Pasko wrote:
> > On the 0x21C day of Apache Harmony Sian January wrote:
> >> Hello again,
> >>
> >> I have had a closer look at the  "Developing Apache Harmony
> Class-library
> >> Code with Eclipse" page, and I have noticed that the "Configuring
> Eclipse"
> >> and "Develop and Test Code" sections are quite class-library
> specific.
> >> Would it be better to leave those sections as they are and add a
> "Developing
> >> DRLVM with Eclipse" section on the same page?
> >
> > To the moment I am not aware of anybody who would use Eclipse for
> > DRLVM development. So, it's too early to add a page like this.
>
> This will ensure that no one does then - if it's simple to add, lets
add
>
> it...
>
> geir
>
> >
> >> Thanks,
> >>
> >> Sian
> >>
> >>
> >>
> >> On 07/11/06, Konovalova, Svetlana <[EMAIL PROTECTED]>
> wrote:
> >>>
> >>> Sian,
> >>> Sorry for delay in response.
>  I'd like to help with documentation but I don't want to duplicate
> any
> >>> work
>  that you are in the middle of, so let me know if there's anything
> >>> specific >I can do...
> >>> Thanks for your desire to help!
> >>> Well, let's work at the page "Developing Apache Harmony
> Class-library
> >>> Code with Eclipse"
> >>>
>
[http://incubator.apache.org/harmony/subcomponents/classlibrary/dev_ecli
> >>> pse.html] first, if you do not mind.
> >>> AFAIK the majority of items on the page can equally apply to DRLVM
> and
> >>> classlib. IMHO would be great to edit the page to remove
unnecessary
> >>> focus on classlib, to make the page equally relevant for vm
> developers.
> >>> To my mind, the introductory sections should be removed, as they
are
> >>> about generalities that do not always relate to the header of the
> page.
> >>> Could you please take a close look at the page and create the
patch
> to
> >>> improve the content and to remove all classlib-specific info? You
> can
> >>> use Harmony-2009 for it. It would be a great impact into
development
> of
> >>> the site documentation for sure! If you need my help, just let me
> know.
> >>> The second idea is to move the page up, not to store it in
> >>> subcomponents/classlib. To make it easily accessible, we can store
> it in
> >>> top xdocs folder and link to the page from documentation.html,
quick
> >>> helps and other build-development web pages.
> >>> If you do not have any objections, I can create a patch with the
> >>> necessary links.
> >>> Wh

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

[Egor Pasko]

On the 0x21D day of Apache Harmony Nadezhda Morozova wrote:
> Good day to you, Egor! 

evening, dark and snowy evening :)

> What do you say about the getting started doc?

I expressed it recently. General idea is that Harmony operates near
the same as other JSE implementations. Almost all specifics is in
extra options which we started collecting on Wiki for an extra
HOWTO-like page (BTW, thanks to Salikh for starting the page).

I believe, it is time to remove the "Getting Started". So, +1 to Pavel
Ozhdikhin here.

BTW, I asked my dad to look at the website. Ideas for improvement from
him:
1) site-local search is useful for a beginner. Hm, Tomcat has it with
links to google search. We can have something as soon as we get to the
desired TLP :)
2) it is not obvious that site misprints/problems should be reported
to the mailing list. Commercial websites have something like
"support/suggestions mailto". We can point mailto to the mailing list :)

> Thank you, 
> Nadya Morozova
>  
> -Original Message-
> From: news [mailto:[EMAIL PROTECTED] On Behalf Of Egor Pasko
> Sent: Friday, November 10, 2006 8:55 AM
> To: harmony-dev@incubator.apache.org
> Subject: Re: [doc][drlvm] The document "Getting started with DRL" is
> outdated
> 
> On the 0x21D day of Apache Harmony Nadezhda Morozova wrote:
> > Egor,
> > I generally like the idea of improving navigation over the site -
> > there's never too much of that. However, I am not sure whether we need
> > yet another separate page for introductory/guidance info. I hope the
> > starting page + the generic pages we have are mostly fine. However,
> > adding a link here and there to lead site visitors. 
> > 
> > Getting started could be a more specific project-oriented page. There,
> > you can tell people to go download, build
> the
> > code. After which, they can start using it just as any other
> > RI-compatible jdk. With the exceptions, see our
> > wiki pages.
> > To use the vm, readers might need to use the following options...
> > If they want to read more on our VM, they can visit the
> > component page. If no website page contains an answer -
> > they can read wiki faqa. 
> > .. or something like that :) 
> 
> Nadya, I really appreciate our efforts :) But this morning I woke up
> and looked the site structure with the eye of a beginner. And could
> not find any obvius flaws in the main structure. Left-side collection
> of links is in a very good shape, good for beginner-level navigation
> and contains almost all links you listed here.
> 
> This was a really refreshing morning :)
> 
> I'll ask some guys who are new to the project, how they feel about the
> site. And will report back, if I find something.
> 
> Refreshing morning is over, now back to work..
> 
> > Thank you, 
> > Nadya Morozova
> >  
> > -Original Message-
> > From: news [mailto:[EMAIL PROTECTED] On Behalf Of Egor Pasko
> > Sent: Thursday, November 09, 2006 5:33 PM
> > To: harmony-dev@incubator.apache.org
> > Subject: Re: [doc][drlvm] The document "Getting started with DRL" is
> > outdated
> > 
> > On the 0x21C day of Apache Harmony Pavel Ozhdikhin wrote:
> > > On 11/9/06, Morozova, Nadezhda <[EMAIL PROTECTED]> wrote:
> > > >
> > > > Egor,
> > > > +1 for
> > > > Just idea: "Getting Started" may contain a collection of links to
> > the
> > > > main website and other resources with short descriptions ("Site
> Map"
> > > > or something) so that people are comfortable floating around in
> the
> > web.
> > > 
> > > 
> > > 
> > > We already have one page having links to the resources about DRLVM:
> > > http://incubator.apache.org/harmony/subcomponents/drlvm/index.html
> > > Why do you think we need another one?
> > 
> > because it is only DRLVM.
> > I think of something like "site map", a collection of links. Short
> > descriptions to some basic ones.
> > 
> > > 
> > > +1 for
> > > > * preparing the "Commonly Used Options for DRLVM" (omitting the
> word
> > > > "supported" intentionally)
> > > > Question on this one: will the page contain vm-only options? What
> > about
> > > > JIT, GC, other? I'd have them all in one place, but we have
> separate
> > > > docs for EM/jit stuff. What do you say?
> > > 
> > > 
> > > I think we can describe basic options for every component there.
> Only
> > those
> > > that might be interesting for any user. The place for other options
> is
> > in
> > > the run-time help or Developer's Guide for a component.
> > 
> > I thought of "most commonly used" options. They can possibly be
> > grouped by components, but not necessary. I would group them by
> > use-cases. BTW, "any user" is not an obvious substance for me. 
> > 
> > So, the list is not obvious, we need to work it out.
> > 
> > I see it like HOWTOs. For example:
> > "-Xem:jet <- use only baseline JIT compiler"
> > "-Xem:opt <- use only optimising JIT compiler"
> > "-Xtrace:em <- print method compilation events"
> > 
> > The 'big' question is: "does 'any user' need to know about JITs
> > switching?". I say YES

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

[Ivanov, Alexey A]

>-Original Message-
>From: Konovalova, Svetlana [mailto:[EMAIL PROTECTED]
>Sent: Friday, November 10, 2006 10:37 AM
>To: harmony-dev@incubator.apache.org
>Subject: RE: [jira] Good issue resolution guideline (was:
>[classlib]volunteer to supply patches for old JIRAs)
>
>Alexey,
>Thanks for the patch. I've looked it through and have fixed certain
>issues.
>The new patch is created (Harmony-2110). It'd be great, if you could
>find a chance to review it.

Everything's fine. It's time to update the site then :)

Regards,
Alexey.

>
>Best regards,
>Sveta
>
>-Original Message-
>From: Ivanov, Alexey A [mailto:[EMAIL PROTECTED]
>Sent: Thursday, November 09, 2006 5:20 PM
>To: harmony-dev@incubator.apache.org
>Subject: RE: [jira] Good issue resolution guideline (was:
>[classlib]volunteer to supply patches for old JIRAs)
>
>Sveta, all,
>
>I've attached the updated patch to the JIRA.
>
>Please review.
>
>Regards,
>Alexey.
>
>
>P.S. By the way, do we really need to place all the main content into
>another table? I've just looked at the source of the generated HTML
>file, and found it quite confusing. I agree to have a table to format
>the heading of the page and the list of contents on the left, but why
>there's another table where the main content is. I am about this one:
>
> 
> 
>
>
>
>
>   
> 
>Good Issue
>Resolution Guideline
>
>   
>   ... 
>
>The comments here are added by me, and the source is slightly
>reformatted.
>I believe, the  part of the XML can be placed almost as is in the
>content cell of the top-level table without the need for another table
>because it's useless here. Or is it just Anakia limitation?
>
>--
>Alexey A. Ivanov
>Intel Enterprise Solutions Software Division
>
>
>>-Original Message-
>>From: Konovalova, Svetlana [mailto:[EMAIL PROTECTED]
>>Sent: Thursday, November 09, 2006 3:50 PM
>>To: harmony-dev@incubator.apache.org
>>Subject: RE: [jira] Good issue resolution guideline (was:
>>[classlib]volunteer to supply patches for old JIRAs)
>>
>>Alexey,
>>
I'd change the heading "Reporting the Issue" to "Reporting an
Issue",
or omit article at all.
 Well, both articles seem to be fine. Let it be "a/an"
>>>Maybe just omit articles then?
>>Well, how about the third variant: "Reporting Issues"?
>>
>>
>>>I'm still for 'reproduce' because a bug can be (non-)reproducible but
>>>not recreatable.
>>>Any other opinions?
>>Ok, "reproduce" is fine
>>
I'd say: "If you have any questions, discuss them...
>>>That's even better :)
>>Cool!:)
>>
All patches, such as tests and fixes, should be
>>>Good! It's clearer.
>>Fine!
>>
>>>OK. I'll prepare patch update then.
>>Good luck! I'd be glad to review it, if you do not mind. :)
>>
>>Cheers,
>>Sveta
>>
>>Thanks,
>>Alexey.
>>
>>>
>>>
>>>Best regards,
>>>Sveta
>>>
>>>-Original Message-
>>>From: Ivanov, Alexey A [mailto:[EMAIL PROTECTED]
>>>Sent: Thursday, November 09, 2006 1:33 PM
>>>To: harmony-dev@incubator.apache.org
>>>Subject: RE: [jira] Good issue resolution guideline (was:
>>>[classlib]volunteer to supply patches for old JIRAs)
>>>
-Original Message-
From: Konovalova, Svetlana [mailto:[EMAIL PROTECTED]
Sent: Wednesday, November 08, 2006 7:01 PM
To: harmony-dev@incubator.apache.org
Subject: RE: [jira] Good issue resolution guideline (was:
[classlib]volunteer to supply patches for old JIRAs)


I've just submitted a new JIRA
[http://issues.apache.org/jira/browse/HARMONY-2110].
I've added the necessary links from the website to the new page and
>>>have
tried to perfect it a little.
It would be great, if you could find a chance to look through the
>>>patch.
Thanks in advance.
>>>
>>>Sveta,
>>>
>>>I've taken a look and added my comments to the JIRA itself.
>>>
>>>
>>>Regards,
>>>Alexey.
>>>

Best regards,
Sveta

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

Good! Go ahead. Do you need help? I can review the patch - just let
>me
know when you submit the JIRA.

Thank you,
Nadya Morozova

-Original Message-
From: Konovalova, Svetlana [mailto:[EMAIL PROTECTED]
Sent: Wednesday, November 08, 2006 9:13 AM
To: harmony-dev@incubator.apache.org
Subject: RE: [jira] Good issue resolution guideline (was:
[classlib]volunteer to supply patches for old JIRAs)

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

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

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

[Ivanov, Alexey A]

Nadya, all,

I've created JIRA issue and attached a patch to remove this extra table.
See https://issues.apache.org/jira/browse/HARMONY-2140

I've checked several pages, nothing seems to be broken. Please review
the changes.


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


>-Original Message-
>From: Morozova, Nadezhda [mailto:[EMAIL PROTECTED]
>Sent: Thursday, November 09, 2006 10:56 PM
>To: harmony-dev@incubator.apache.org
>Subject: RE: [jira] Good issue resolution guideline (was:
>[classlib]volunteer to supply patches for old JIRAs)
>
>Alexey,
>I agree  that the structure of the resulting HTML website page does not
>appear too linear. When editing the structure, I saw the additional
>table - and left as is; maybe, because I hoped somebody added it on
some
>purpose. For me, the only matter of convenience is that all content
that
>is varied on the page is in a separate table.
>If nobody has an idea why the structure is so complex, we can simplify
>it. The structure is defined in file site.vsl in
site/xdocs/stylesheets.
>A JIRA with patch is welcome as usual.
>
>Thank you,
>Nadya Morozova
>
>
>-Original Message-
>From: Ivanov, Alexey A [mailto:[EMAIL PROTECTED]
>Sent: Thursday, November 09, 2006 5:20 PM
>To: harmony-dev@incubator.apache.org
>Subject: RE: [jira] Good issue resolution guideline (was:
>[classlib]volunteer to supply patches for old JIRAs)
>
>Sveta, all,
>
>I've attached the updated patch to the JIRA.
>
>Please review.
>
>Regards,
>Alexey.
>
>
>P.S. By the way, do we really need to place all the main content into
>another table? I've just looked at the source of the generated HTML
>file, and found it quite confusing. I agree to have a table to format
>the heading of the page and the list of contents on the left, but why
>there's another table where the main content is. I am about this one:
>
> 
> 
>
>
>
>
>   
> 
>Good Issue
>Resolution Guideline
>
>   
>   ... 
>
>The comments here are added by me, and the source is slightly
>reformatted.
>I believe, the  part of the XML can be placed almost as is in the
>content cell of the top-level table without the need for another table
>because it's useless here. Or is it just Anakia limitation?
>
>--
>Alexey A. Ivanov
>Intel Enterprise Solutions Software Division
>
>
>>-Original Message-
>>From: Konovalova, Svetlana [mailto:[EMAIL PROTECTED]
>>Sent: Thursday, November 09, 2006 3:50 PM
>>To: harmony-dev@incubator.apache.org
>>Subject: RE: [jira] Good issue resolution guideline (was:
>>[classlib]volunteer to supply patches for old JIRAs)
>>
>>Alexey,
>>
I'd change the heading "Reporting the Issue" to "Reporting an
Issue",
or omit article at all.
 Well, both articles seem to be fine. Let it be "a/an"
>>>Maybe just omit articles then?
>>Well, how about the third variant: "Reporting Issues"?
>>
>>
>>>I'm still for 'reproduce' because a bug can be (non-)reproducible but
>>>not recreatable.
>>>Any other opinions?
>>Ok, "reproduce" is fine
>>
I'd say: "If you have any questions, discuss them...
>>>That's even better :)
>>Cool!:)
>>
All patches, such as tests and fixes, should be
>>>Good! It's clearer.
>>Fine!
>>
>>>OK. I'll prepare patch update then.
>>Good luck! I'd be glad to review it, if you do not mind. :)
>>
>>Cheers,
>>Sveta
>>
>>Thanks,
>>Alexey.
>>
>>>
>>>
>>>Best regards,
>>>Sveta
>>>
>>>-Original Message-
>>>From: Ivanov, Alexey A [mailto:[EMAIL PROTECTED]
>>>Sent: Thursday, November 09, 2006 1:33 PM
>>>To: harmony-dev@incubator.apache.org
>>>Subject: RE: [jira] Good issue resolution guideline (was:
>>>[classlib]volunteer to supply patches for old JIRAs)
>>>
-Original Message-
From: Konovalova, Svetlana [mailto:[EMAIL PROTECTED]
Sent: Wednesday, November 08, 2006 7:01 PM
To: harmony-dev@incubator.apache.org
Subject: RE: [jira] Good issue resolution guideline (was:
[classlib]volunteer to supply patches for old JIRAs)


I've just submitted a new JIRA
[http://issues.apache.org/jira/browse/HARMONY-2110].
I've added the necessary links from the website to the new page and
>>>have
tried to perfect it a little.
It would be great, if you could find a chance to look through the
>>>patch.
Thanks in advance.
>>>
>>>Sveta,
>>>
>>>I've taken a look and added my comments to the JIRA itself.
>>>
>>>
>>>Regards,
>>>Alexey.
>>>

Best regards,
Sveta

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

Good! Go ahead. Do you need help? I can review the patch - just let
>me
know when you submit the JIRA.

Thank you,
Nadya Morozova

-Original Message-
From: