Re: [vote] HARMONY-1363 - DRLVM fixes and additions

[Alexey Petrenko]

I've talked about a small patch for this exact issue of course.

SY, Alexey

2006/9/7, Alexey Varlamov <[EMAIL PROTECTED]>:

Alexey,

This conflict is trivial enough and was caused by recent Geir's
changes, see the parallel thread about launcher.
I don't think we need to redone the whole patch for this issue -
either commiter will resolve it by hand or minor patch for this
particular change can be made anew.

--
Regards,
Alexey


2006/9/7, Alexey Petrenko <[EMAIL PROTECTED]>:
> Guys,
>
> I've tried a patch.
> Patch failed in ./vm/em/src/DrlEMImpl.cpp. On Linux and Windows.
> Here is a rej file:
> === cut ===
> ***
> *** 151,165 
>  //_
>  // Reading and parsing configuration
>
>
> - std::string buildDefaultLibPath(const std::string& dll_name) {
> - std::string library_path = 
vm_get_property_value("vm.boot.library.path");
>  #ifdef PLATFORM_NT
> - std::string fullPath = library_path + "\\"+ dll_name+".dll";
> - #else
> - std::string fullPath = library_path + "/lib" + dll_name + ".so";
>  #endif
> - return fullPath;
>  }
>
>  static std::string getParam(const std::string& config, const
> std::string& name) {
> --- 167,198 
>  //_
>  // Reading and parsing configuration
>
> + static bool endsWith(const std::string& str, const std::string& suffix) {
> + if (str.length() < suffix.length()) {
> + return false;
> + }
> + return std::equal(suffix.rbegin(), suffix.rend(), str.rbegin());
> + }
>
> + std::string prepareLibPath(const std::string& origPath) {
>  #ifdef PLATFORM_NT
> + std::string separator("\\"), libPrefix(""), libSuffix(".dll");
> + #else
> + std::string separator("/"), libPrefix("lib"), libSuffix(".so");
>  #endif
> +
> + std::string path = origPath;
> + if (path.find('/') == path.npos && path.find('\\') == path.npos ) {
> + std::string dir = vm_get_property_value("vm.boot.library.path");
> + if (libPrefix.length() > 0 && !startsWith(path, libPrefix)) {
> + path = libPrefix + path;
> + }
> + path = dir + separator + path;
> + }
> + if (!endsWith(path, libSuffix)) {
> + path+=libSuffix;
> + }
> + return path;
>  }
>
>  static std::string getParam(const std::string& config, const
> std::string& name) {
> === cut ===
>
> As a result build fails.
>
> Salikh, it seems that you need to provide additional patch.
>
> SY, Alexey
>
> 2006/9/7, Alexey Varlamov <[EMAIL PROTECTED]>:
> > +1
> >
> > 2006/9/7, Geir Magnusson Jr. <[EMAIL PROTECTED]>:
> > > +1
> > >
> > > Geir Magnusson Jr. wrote:
> > > > All is in order and in SVN for Harmony-1225 wrt BCC and ACQ.  I think
> > > > that this an important patch so we can get better 1.5 support et al.
> > > >
> > > > Please vote to accept or reject this set of patches and fixes into the
> > > > Apache Harmony class library :
> > > >
> > > > [ ] + 1 Accept
> > > > [ ] -1 Reject  (provide reason below)
> > > >
> > > > Lets let this run a minimum of 3 days unless a) someone states they need
> > > > more time or b) we get all committer votes before then.
> > > >
> > > > geir
> > > >
> > > >
> > > >
> > > >
> > > > -
> > > > Terms of use : http://incubator.apache.org/harmony/mailing.html
> > > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > > For additional commands, e-mail: [EMAIL PROTECTED]
> > > >
> > >
> > > -
> > > Terms of use : http://incubator.apache.org/harmony/mailing.html
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> > >
> > >
> >
> > -
> > Terms of use : http://incubator.apache.org/harmony/mailing.html
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
>
> --
> Alexey A. Petrenko
> Intel Middleware Products Division
>
> -
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

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





--
Alexey A. Petrenko
Intel Middleware Products Division

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

Re: [vote] HARMONY-1363 - DRLVM fixes and additions

[Vladimir Gorr]

+1 from me.

Thanks,
Vladimir.

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


+1

2006/9/7, Geir Magnusson Jr. <[EMAIL PROTECTED]>:
> +1
>
> Geir Magnusson Jr. wrote:
> > All is in order and in SVN for Harmony-1225 wrt BCC and ACQ.  I think
> > that this an important patch so we can get better 1.5 support et al.
> >
> > Please vote to accept or reject this set of patches and fixes into the
> > Apache Harmony class library :
> >
> > [ ] + 1 Accept
> > [ ] -1 Reject  (provide reason below)
> >
> > Lets let this run a minimum of 3 days unless a) someone states they
need
> > more time or b) we get all committer votes before then.
> >
> > geir
> >
> >
> >
> >
> > -
> > Terms of use : http://incubator.apache.org/harmony/mailing.html
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
>
> -
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

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

Re: [vote] HARMONY-1363 - DRLVM fixes and additions

[Alexey Varlamov]

Alexey,

This conflict is trivial enough and was caused by recent Geir's
changes, see the parallel thread about launcher.
I don't think we need to redone the whole patch for this issue -
either commiter will resolve it by hand or minor patch for this
particular change can be made anew.

--
Regards,
Alexey


2006/9/7, Alexey Petrenko <[EMAIL PROTECTED]>:

Guys,

I've tried a patch.
Patch failed in ./vm/em/src/DrlEMImpl.cpp. On Linux and Windows.
Here is a rej file:
=== cut ===
***
*** 151,165 
 //_
 // Reading and parsing configuration


- std::string buildDefaultLibPath(const std::string& dll_name) {
- std::string library_path = vm_get_property_value("vm.boot.library.path");
 #ifdef PLATFORM_NT
- std::string fullPath = library_path + "\\"+ dll_name+".dll";
- #else
- std::string fullPath = library_path + "/lib" + dll_name + ".so";
 #endif
- return fullPath;
 }

 static std::string getParam(const std::string& config, const
std::string& name) {
--- 167,198 
 //_
 // Reading and parsing configuration

+ static bool endsWith(const std::string& str, const std::string& suffix) {
+ if (str.length() < suffix.length()) {
+ return false;
+ }
+ return std::equal(suffix.rbegin(), suffix.rend(), str.rbegin());
+ }

+ std::string prepareLibPath(const std::string& origPath) {
 #ifdef PLATFORM_NT
+ std::string separator("\\"), libPrefix(""), libSuffix(".dll");
+ #else
+ std::string separator("/"), libPrefix("lib"), libSuffix(".so");
 #endif
+
+ std::string path = origPath;
+ if (path.find('/') == path.npos && path.find('\\') == path.npos ) {
+ std::string dir = vm_get_property_value("vm.boot.library.path");
+ if (libPrefix.length() > 0 && !startsWith(path, libPrefix)) {
+ path = libPrefix + path;
+ }
+ path = dir + separator + path;
+ }
+ if (!endsWith(path, libSuffix)) {
+ path+=libSuffix;
+ }
+ return path;
 }

 static std::string getParam(const std::string& config, const
std::string& name) {
=== cut ===

As a result build fails.

Salikh, it seems that you need to provide additional patch.

SY, Alexey

2006/9/7, Alexey Varlamov <[EMAIL PROTECTED]>:
> +1
>
> 2006/9/7, Geir Magnusson Jr. <[EMAIL PROTECTED]>:
> > +1
> >
> > Geir Magnusson Jr. wrote:
> > > All is in order and in SVN for Harmony-1225 wrt BCC and ACQ.  I think
> > > that this an important patch so we can get better 1.5 support et al.
> > >
> > > Please vote to accept or reject this set of patches and fixes into the
> > > Apache Harmony class library :
> > >
> > > [ ] + 1 Accept
> > > [ ] -1 Reject  (provide reason below)
> > >
> > > Lets let this run a minimum of 3 days unless a) someone states they need
> > > more time or b) we get all committer votes before then.
> > >
> > > geir
> > >
> > >
> > >
> > >
> > > -
> > > Terms of use : http://incubator.apache.org/harmony/mailing.html
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> > >
> >
> > -
> > Terms of use : http://incubator.apache.org/harmony/mailing.html
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
> -
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


--
Alexey A. Petrenko
Intel Middleware Products Division

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




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

Re: [vote] HARMONY-1363 - DRLVM fixes and additions

[Alexey Petrenko]

Guys,

I've tried a patch.
Patch failed in ./vm/em/src/DrlEMImpl.cpp. On Linux and Windows.
Here is a rej file:
=== cut ===
***
*** 151,165 
 //_
 // Reading and parsing configuration


- std::string buildDefaultLibPath(const std::string& dll_name) {
- std::string library_path = vm_get_property_value("vm.boot.library.path");
 #ifdef PLATFORM_NT
- std::string fullPath = library_path + "\\"+ dll_name+".dll";
- #else
- std::string fullPath = library_path + "/lib" + dll_name + ".so";
 #endif
- return fullPath;
 }

 static std::string getParam(const std::string& config, const
std::string& name) {
--- 167,198 
 //_
 // Reading and parsing configuration

+ static bool endsWith(const std::string& str, const std::string& suffix) {
+ if (str.length() < suffix.length()) {
+ return false;
+ }
+ return std::equal(suffix.rbegin(), suffix.rend(), str.rbegin());
+ }

+ std::string prepareLibPath(const std::string& origPath) {
 #ifdef PLATFORM_NT
+ std::string separator("\\"), libPrefix(""), libSuffix(".dll");
+ #else
+ std::string separator("/"), libPrefix("lib"), libSuffix(".so");
 #endif
+
+ std::string path = origPath;
+ if (path.find('/') == path.npos && path.find('\\') == path.npos ) {
+ std::string dir = vm_get_property_value("vm.boot.library.path");
+ if (libPrefix.length() > 0 && !startsWith(path, libPrefix)) {
+ path = libPrefix + path;
+ }
+ path = dir + separator + path;
+ }
+ if (!endsWith(path, libSuffix)) {
+ path+=libSuffix;
+ }
+ return path;
 }

 static std::string getParam(const std::string& config, const
std::string& name) {
=== cut ===

As a result build fails.

Salikh, it seems that you need to provide additional patch.

SY, Alexey

2006/9/7, Alexey Varlamov <[EMAIL PROTECTED]>:

+1

2006/9/7, Geir Magnusson Jr. <[EMAIL PROTECTED]>:
> +1
>
> Geir Magnusson Jr. wrote:
> > All is in order and in SVN for Harmony-1225 wrt BCC and ACQ.  I think
> > that this an important patch so we can get better 1.5 support et al.
> >
> > Please vote to accept or reject this set of patches and fixes into the
> > Apache Harmony class library :
> >
> > [ ] + 1 Accept
> > [ ] -1 Reject  (provide reason below)
> >
> > Lets let this run a minimum of 3 days unless a) someone states they need
> > more time or b) we get all committer votes before then.
> >
> > geir
> >
> >
> >
> >
> > -
> > Terms of use : http://incubator.apache.org/harmony/mailing.html
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
>
> -
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

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





--
Alexey A. Petrenko
Intel Middleware Products Division

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

Re: [vote] HARMONY-1363 - DRLVM fixes and additions

[Alexey Varlamov]

+1

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

+1

Geir Magnusson Jr. wrote:
> All is in order and in SVN for Harmony-1225 wrt BCC and ACQ.  I think
> that this an important patch so we can get better 1.5 support et al.
>
> Please vote to accept or reject this set of patches and fixes into the
> Apache Harmony class library :
>
> [ ] + 1 Accept
> [ ] -1 Reject  (provide reason below)
>
> Lets let this run a minimum of 3 days unless a) someone states they need
> more time or b) we get all committer votes before then.
>
> geir
>
>
>
>
> -
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>

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




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

Re: [vote] HARMONY-1363 - DRLVM fixes and additions

[Geir Magnusson Jr.]

+1

Geir Magnusson Jr. wrote:
All is in order and in SVN for Harmony-1225 wrt BCC and ACQ.  I think 
that this an important patch so we can get better 1.5 support et al.


Please vote to accept or reject this set of patches and fixes into the
Apache Harmony class library :

[ ] + 1 Accept
[ ] -1 Reject  (provide reason below)

Lets let this run a minimum of 3 days unless a) someone states they need
more time or b) we get all committer votes before then.

geir




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



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

[vote] HARMONY-1363 - DRLVM fixes and additions

[Geir Magnusson Jr.]

All is in order and in SVN for Harmony-1225 wrt BCC and ACQ.  I think 
that this an important patch so we can get better 1.5 support et al.


Please vote to accept or reject this set of patches and fixes into the
Apache Harmony class library :

[ ] + 1 Accept
[ ] -1 Reject  (provide reason below)

Lets let this run a minimum of 3 days unless a) someone states they need
more time or b) we get all committer votes before then.

geir




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

Re: [drlvm] DRLVM, jre/bin/default and launcher

[Geir Magnusson Jr.]

Code is checked in for linux - and updating and testing now on WinXP.

The issue was that all of our library loading was done with full paths, 
which didn't let APR via dlopen() use LD_LIBRARY_PATH.


So I made some small mods - please review.  One problem I found was that 
 I had to make assumptions such as passing NULL instead of a path being 
safe, because there was no comments in the code about expected inputs 
(or resulting outputs).


I also neutered "vm.boot.library.path" to be "" unless set on command 
line, rather than be the directory of the launching executable, as I 
figured that a) I needed to have it be "" and b) that would lead to some 
interesting failures when people tried to embed DRLVM in other apps or such.


I'll see what I can take out of HARMONY-1390 for some of the issues 
related to teardown.  Or, Evgueni, you can tell me to close it and we 
can do another one.  There seemed to be a few extra things included in 
that patch, btw :)


Tomorrow, I'll finish the changes to the build so we get a 
launcher-based JRE and HDK.


I know this isn't perfect, but it's a step forward - thanks all for all 
the help.


geir

(and for the record, working in C, C++ and Java all at the same time is 
a hoot...)



Geir Magnusson Jr. wrote:

Ok, I think I have this working now.

DRLVM can be put anywhere and it works w/ the launcher w/o any unnatural 
acts with command line parameters and/or scripts.


There are a few things to chat about - I'll get my thoughts together 
later tonight and post, and check in the code.  I just wanted to let 
people know if they were thinking about working on it.


geir



Geir Magnusson Jr. wrote:



Evgueni Brevnov wrote:

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



Evgueni Brevnov wrote:
> HI All,
>
> Good news! I have a patch to run DRLVM with the classlib's launcher
> (I've checked Hello and Eclipse applications on Windows only).
> Actually, there are two patches. The first one is for classlib which
> changes vm default directory to drlvm.

I don't think we should do that - we'll keep it the same as it is now -
"default".

Why should we change it?


I don't care about it too much. Let it be "default". In that case
-vmdir option should be specified each time. Is it convenient for
users? 


?  right now, "default" is the default.  So the user doesn't have to 
specify anything...


With the DRLVM stuff in jre/bin/default the user just types

 java


 > BTW it seems there will be some problems with hythr.dll library

if we wish to use drlvm and j9 in simultaneously. But that's another
story...


Yes, we need to resolve this.





> The second one is for build
> system and VM itself. Unfortunatelly, it is impossible to eliminate
> all problems in a short period of time. There is still a bunch of 
work

> in initialization and jni modules. So this patch is just a one more
> step to our goal.

Great.  As I said in other mails, the build stuff isn't the part to
worry about but rather the VM itself.

So does this patch do it completely, or should we wait?


Yes, the patch contains changes for both parts vm and build.
It was easy for me to change the build than do manual manipulations 
each time to

check whether it runs OK or not.


So does this mean if I apply the patch, then DRLVM works w/ the 
launcher from the jre/bin/default directory w/o any problems?


geir





>
> The vm patch is quite heavy so I attach it and classlib patch.
> Hope it will work not only for me :-)
>
>
> On 9/5/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
>>
>>
>> Salikh Zakirov wrote:
>> > Andrey Chernyshev wrote:
>> >> 1.  Fix the DRLVM layout - rename vmcore to "harmonyvm" and move
>> >> ..dll/.so into the "default" subdirectory such that one doesn't
>> have to
>> >> type -vm and -vmdir options;
>> >
>> > While would you want to rename DRLVM to Harmony VM?
>> > It feels to me like claiming DRLVM to be "the only" Harmony VM.
>> > On the contrary, I thought Harmony project is about *encouraging*
>> diversity.
>> >
>> > I think having library named libdrlvm.so would be much better.
>>
>> No - the launcher picks up the vm from "harmonyvm.dll" (or .so) so
>> that's what we'll name it.
>>
>> Then it makes it easy.  put J9 in jre/bin/j9 and drlvm in 
jre/bin/drlvm

>> and then
>>
>>   java -vmdir:j9
>>
>> or
>>
>>   java -vmdir:drlvm
>>
>>
>> etc
>>
>> geir
>>
>> >
>> >> 2. Exclude building of the "original" launcher from the DRLVM 
build -
>> >> it currently conflicts with the classlib launcher (both are 
called

>> >> "java").
>> >>
>> >> 3. Aside from the hythread, it may also have a sense to make the
>> >> classlib and DRLVM using the same zlib dll/so (preferably the 
system

>> >> one).
>> >
>> >
>> > 
-

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

>> >
>>
>> 
-

Re: [drlvm] Cleaning insides of Class.h header

[Weldon Washburn]

Pavel,
In general I like the idea of cleaning up this code.  Maybe the best thing
to do is post some patches so that we have examples to discuss.
 Weldon

On 9/5/06, Pavel Pervov <[EMAIL PROTECTED]> wrote:


It's been long time this discussion stopped.
This may mean three things:
- first, everyone agrees this should be done and I'm ok to provide
consecutive patches;
- second, noone clearly understand the purpose of what is suggested to do;
if this is the case, do not hesitate to ask (again?);
- third, noone is really interested in making source code of DRLVM more
readable and more understandable, and I should drop this activity.

Meanwhile, I'd like to open jira and start posting patches there.

Regards,
   Pavel.

On 7/25/06, Pavel Pervov <[EMAIL PROTECTED]> wrote:
>
>  Geir,
>
> well, it is the argument at least for me to start thinking in this
> direction and initiate this discussion.
>
> And there are places in VM core code where only definition of members of
a
> class is required, but whole Class.h is included anyway. This is also
> about localizing potential development in separate functional groups to
> reduce recompilation when working intensively with these files.
>
> Hope, I answered, what you were asking about. :)
>
> Regards,
>  Pavel.
>
> On 7/24/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote:
> >
> >
> >
> > Pavel Pervov wrote:
> > > On 7/24/06, Alexey Petrenko < [EMAIL PROTECTED]> wrote:
> > >>
> > >> 2006/7/24, Pavel Pervov <[EMAIL PROTECTED]>:
> >
> > >> > First thing I would like to do is to split the file into a group
of
> >
> > >> files,
> > >> > each of which would contain only one entity (and some closely
> > related
> > >> > entities, if any). This would produce the following headers:
> > >> > 1)   Class.h – constant pool and class
> > >> > 2)   vtable.h – vtable
> > >> > 3)   class_member.h – field and method entities descriptors,
> > >> exception
> > >> > handler descriptor
> > >> > 4)   cci.h – code chunk entity (part of compiled method code)
> > >>
> > >> Will these header files be useful separately?
> > >
> > >
> > > Yes, sure, they will be. This is one of the arguments for doing so.
> > >
> >
> >
> > To whom?
> >
> > geir
> >
> >
> > -
> > Terms of use : http://incubator.apache.org/harmony/mailing.html
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>





--
Weldon Washburn
Intel Middleware Products Division

Re: [build] Use Sun 5.0_8 or Eclipse Compiler for automated builds

[Geir Magnusson Jr.]

Nathan Beyer wrote:



-Original Message-
From: Richard Liang [mailto:[EMAIL PROTECTED]

 Sun compiler (5.0_8) also has some unexpected behavior. See[1]

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



I've found that a second or third "ant build" takes care of it. 


LOL

That's not a solution.

> What I've

noticed though is that the failures are all linking to elements from classes
in luni-kernel. I'm looking at it, but I think there are some issues with
what's put on the bootclasspath. I've already found one discrepancy between
some of our 'luni-kernel' stubs and the spec. The Method.invoke() uses a
vararg and our stub didn't have this.


Cool.



-Nathan




There are a number of places that use ReferenceQueues and Reference, but
can't be generified because of a bug in the Sun compilers prior to

5.0_8. At

the end of this email is an example of code that causes a compiler error

in

previous releases. This issue does not affect the Eclipse compiler. I've

run

a full rebuild as of revision 440796 and everything compiles fine with

both

the Eclipse compiler and Sun 5.0_8 compiler.



-Nathan





private static final ReferenceQueue cacheQueue = new
ReferenceQueue();



private static final class CacheEntry extends WeakReference

{

String key;



CacheEntry(Object jar, String key, ReferenceQueue queue)

{

super(jar, queue);

this.key = key;

}

}



// ... code using the queue



CacheEntry entry;

// This cast fails on Sun 5.0_7 and prior compilers

while ((entry = (CacheEntry)cacheQueue.poll()) != null) {

jarCache.remove(entry.key);

}



// . more code









--
Richard Liang
China Software Development Lab, IBM

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



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



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

RE: [build] Use Sun 5.0_8 or Eclipse Compiler for automated builds

[Nathan Beyer]

> -Original Message-
> From: Richard Liang [mailto:[EMAIL PROTECTED]
> 
>  Sun compiler (5.0_8) also has some unexpected behavior. See[1]
> 
> [1]http://mail-archives.apache.org/mod_mbox/incubator-harmony-
> dev/200608.mbox/[EMAIL PROTECTED]
> 

I've found that a second or third "ant build" takes care of it. What I've
noticed though is that the failures are all linking to elements from classes
in luni-kernel. I'm looking at it, but I think there are some issues with
what's put on the bootclasspath. I've already found one discrepancy between
some of our 'luni-kernel' stubs and the spec. The Method.invoke() uses a
vararg and our stub didn't have this.

-Nathan


> 
> >
> >
> > There are a number of places that use ReferenceQueues and Reference, but
> > can't be generified because of a bug in the Sun compilers prior to
> 5.0_8. At
> > the end of this email is an example of code that causes a compiler error
> in
> > previous releases. This issue does not affect the Eclipse compiler. I've
> run
> > a full rebuild as of revision 440796 and everything compiles fine with
> both
> > the Eclipse compiler and Sun 5.0_8 compiler.
> >
> >
> >
> > -Nathan
> >
> >
> >
> >
> >
> > private static final ReferenceQueue cacheQueue = new
> > ReferenceQueue();
> >
> >
> >
> > private static final class CacheEntry extends WeakReference
> {
> >
> > String key;
> >
> >
> >
> > CacheEntry(Object jar, String key, ReferenceQueue queue)
> {
> >
> > super(jar, queue);
> >
> > this.key = key;
> >
> > }
> >
> > }
> >
> >
> >
> > // ... code using the queue
> >
> >
> >
> > CacheEntry entry;
> >
> > // This cast fails on Sun 5.0_7 and prior compilers
> >
> > while ((entry = (CacheEntry)cacheQueue.poll()) != null) {
> >
> > jarCache.remove(entry.key);
> >
> > }
> >
> >
> >
> > // . more code
> >
> >
> >
> >
> >
> >
> >
> 
> 
> --
> Richard Liang
> China Software Development Lab, IBM
> 
> -
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]


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

RE: [classlib][rmi] DISCUSSION : Use the RMI modiule and move the others to archive

[Nathan Beyer]

Ah...good call. I am indeed not sane.

-Nathan

> -Original Message-
> From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, September 06, 2006 8:21 PM
> To: harmony-dev@incubator.apache.org
> Subject: Re: [classlib][rmi] DISCUSSION : Use the RMI modiule and move the
> others to archive
> 
> sanity check : did you check it out as https?
> 
> (look in .svn/Entries)
> 
> geir
> 
> 
> Nathan Beyer wrote:
> > I don't seem to have SVN permissions to add stuff to 'archive'. I'm
> getting
> > a 403 forbidden when I perform the move.
> >
> > -Nathan
> >
> >> -Original Message-
> >> From: Nathan Beyer [mailto:[EMAIL PROTECTED]
> >> Sent: Wednesday, September 06, 2006 4:09 PM
> >> To: harmony-dev@incubator.apache.org
> >> Subject: RE: [classlib][rmi] DISCUSSION : Use the RMI modiule and move
> the
> >> others to archive
> >>
> >> We haven't heard anything else about this, so I'm going to assume that
> >> everyone's cool with moving the additional RMI modules to the archive
> >> folder. I will attempt to get this moved sometime in the next few
> hours.
> >>
> >> -Nathan
> >>
> >>> -Original Message-
> >>> From: Daniel Gandara [mailto:[EMAIL PROTECTED]
> >>> Sent: Tuesday, August 22, 2006 6:10 AM
> >>> To: harmony-dev@incubator.apache.org
> >>> Subject: Re: [classlib][rmi] DISCUSSION : Use the RMI modiule and move
> >> the
> >>> others to archive
> >>>
> >>> I agree, I think it is a good idea, since changes can still be made,
> >> code
> >>> will be on the archive, and we do not confuse people with multiple rmi
> >>> versions
> >>> within the classlib.
> >>>
> >>>
> >>> Daniel
> >>>
> >>> - Original Message -
> >>> From: "Nathan Beyer" <[EMAIL PROTECTED]>
> >>> To: 
> >>> Sent: Monday, August 21, 2006 9:51 PM
> >>> Subject: RE: [classlib][rmi] DISCUSSION : Use the RMI modiule and move
> >> the
> >>> others to archive
> >>>
> >>>
>  I like this approach. Anyone that wants to integrate changes can just
>  submit
>  patches.
> 
> > -Original Message-
> > From: Geir Magnusson Jr [mailto:[EMAIL PROTECTED]
> > Sent: Monday, August 21, 2006 8:34 AM
> > To: harmony-dev@incubator.apache.org
> > Subject: [classlib][rmi] DISCUSSION : Use the RMI modiule and move
> >> the
> > others to archive
> >
> > We've had multiple RMI modules hanging around for a while due to our
> > fortune of multiple submissions.
> >
> > Would anyone have a problem if we 'retired' all except modules/rmi
> to
> > the archive, and then took whatever was needed from there?
> >
> > geir
> >
> > 
> -
> > Terms of use : http://incubator.apache.org/harmony/mailing.html
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: harmony-dev-
> >> [EMAIL PROTECTED]
> 
>  -
>  Terms of use : http://incubator.apache.org/harmony/mailing.html
>  To unsubscribe, e-mail: [EMAIL PROTECTED]
>  For additional commands, e-mail: harmony-dev-
> [EMAIL PROTECTED]
> 
> >>>
> >>>
> >>> -
> >>> Terms of use : http://incubator.apache.org/harmony/mailing.html
> >>> To unsubscribe, e-mail: [EMAIL PROTECTED]
> >>> For additional commands, e-mail: [EMAIL PROTECTED]
> >>
> >> -
> >> Terms of use : http://incubator.apache.org/harmony/mailing.html
> >> To unsubscribe, e-mail: [EMAIL PROTECTED]
> >> For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> > -
> > Terms of use : http://incubator.apache.org/harmony/mailing.html
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> 
> -
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]


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

Re: [build] Use Sun 5.0_8 or Eclipse Compiler for automated builds

[Richard Liang]

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

Would there be any objections to asking the automated builds (that send
messages to the commit list) to use either the latest Sun compiler (5.0_8)
or the Eclipse compiler?



Sun compiler (5.0_8) also has some unexpected behavior. See[1]

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

Best regards,
Richard




There are a number of places that use ReferenceQueues and Reference, but
can't be generified because of a bug in the Sun compilers prior to 5.0_8. At
the end of this email is an example of code that causes a compiler error in
previous releases. This issue does not affect the Eclipse compiler. I've run
a full rebuild as of revision 440796 and everything compiles fine with both
the Eclipse compiler and Sun 5.0_8 compiler.



-Nathan





private static final ReferenceQueue cacheQueue = new
ReferenceQueue();



private static final class CacheEntry extends WeakReference {

String key;



CacheEntry(Object jar, String key, ReferenceQueue queue) {

super(jar, queue);

this.key = key;

}

}



// ... code using the queue



CacheEntry entry;

// This cast fails on Sun 5.0_7 and prior compilers

while ((entry = (CacheEntry)cacheQueue.poll()) != null) {

jarCache.remove(entry.key);

}



// . more code










--
Richard Liang
China Software Development Lab, IBM

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

Re: [drlvm] DRLVM, jre/bin/default and launcher

[Geir Magnusson Jr.]

Ok, I think I have this working now.

DRLVM can be put anywhere and it works w/ the launcher w/o any unnatural 
acts with command line parameters and/or scripts.


There are a few things to chat about - I'll get my thoughts together 
later tonight and post, and check in the code.  I just wanted to let 
people know if they were thinking about working on it.


geir



Geir Magnusson Jr. wrote:



Evgueni Brevnov wrote:

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



Evgueni Brevnov wrote:
> HI All,
>
> Good news! I have a patch to run DRLVM with the classlib's launcher
> (I've checked Hello and Eclipse applications on Windows only).
> Actually, there are two patches. The first one is for classlib which
> changes vm default directory to drlvm.

I don't think we should do that - we'll keep it the same as it is now -
"default".

Why should we change it?


I don't care about it too much. Let it be "default". In that case
-vmdir option should be specified each time. Is it convenient for
users? 


?  right now, "default" is the default.  So the user doesn't have to 
specify anything...


With the DRLVM stuff in jre/bin/default the user just types

 java


 > BTW it seems there will be some problems with hythr.dll library

if we wish to use drlvm and j9 in simultaneously. But that's another
story...


Yes, we need to resolve this.





> The second one is for build
> system and VM itself. Unfortunatelly, it is impossible to eliminate
> all problems in a short period of time. There is still a bunch of work
> in initialization and jni modules. So this patch is just a one more
> step to our goal.

Great.  As I said in other mails, the build stuff isn't the part to
worry about but rather the VM itself.

So does this patch do it completely, or should we wait?


Yes, the patch contains changes for both parts vm and build.
It was easy for me to change the build than do manual manipulations 
each time to

check whether it runs OK or not.


So does this mean if I apply the patch, then DRLVM works w/ the launcher 
from the jre/bin/default directory w/o any problems?


geir





>
> The vm patch is quite heavy so I attach it and classlib patch.
> Hope it will work not only for me :-)
>
>
> On 9/5/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
>>
>>
>> Salikh Zakirov wrote:
>> > Andrey Chernyshev wrote:
>> >> 1.  Fix the DRLVM layout - rename vmcore to "harmonyvm" and move
>> >> ..dll/.so into the "default" subdirectory such that one doesn't
>> have to
>> >> type -vm and -vmdir options;
>> >
>> > While would you want to rename DRLVM to Harmony VM?
>> > It feels to me like claiming DRLVM to be "the only" Harmony VM.
>> > On the contrary, I thought Harmony project is about *encouraging*
>> diversity.
>> >
>> > I think having library named libdrlvm.so would be much better.
>>
>> No - the launcher picks up the vm from "harmonyvm.dll" (or .so) so
>> that's what we'll name it.
>>
>> Then it makes it easy.  put J9 in jre/bin/j9 and drlvm in 
jre/bin/drlvm

>> and then
>>
>>   java -vmdir:j9
>>
>> or
>>
>>   java -vmdir:drlvm
>>
>>
>> etc
>>
>> geir
>>
>> >
>> >> 2. Exclude building of the "original" launcher from the DRLVM 
build -

>> >> it currently conflicts with the classlib launcher (both are called
>> >> "java").
>> >>
>> >> 3. Aside from the hythread, it may also have a sense to make the
>> >> classlib and DRLVM using the same zlib dll/so (preferably the 
system

>> >> one).
>> >
>> >
>> > 
-

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

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

>>
>>
>
>
> 


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

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




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



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



--

Re: [general] Marking JIRA issues before creation of patches.

[Geir Magnusson Jr.]

Good.

Also, don't just do things in JIRA.  Add the comment in JIRA, but also 
send something to the dev list.  That way, people who are interested 
will more easily notice and maybe offer to help, or such...


geir


Oleg Khaschansky wrote:

Hi all,

There were situations when several people started work on the same
issue simultaneously. This happens because it is impossible to assign
an issue to a non-committer. I suggest the following process to
prevent these collisions:

1. If non-committer starts investigation and is pretty sure that he
will proceed with the patch then he adds a comment like "starting
investigation" to the JIRA issue. Maybe we should have a special
keyword for this to make a search easier.
2. If for some reason he is unable to provide the patch, he adds a
comment about this also.

What do you think about this?

--
 Oleg

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



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

Re: [classlib][rmi] DISCUSSION : Use the RMI modiule and move the others to archive

[Geir Magnusson Jr.]

sanity check : did you check it out as https?

(look in .svn/Entries)

geir


Nathan Beyer wrote:

I don't seem to have SVN permissions to add stuff to 'archive'. I'm getting
a 403 forbidden when I perform the move.

-Nathan


-Original Message-
From: Nathan Beyer [mailto:[EMAIL PROTECTED]
Sent: Wednesday, September 06, 2006 4:09 PM
To: harmony-dev@incubator.apache.org
Subject: RE: [classlib][rmi] DISCUSSION : Use the RMI modiule and move the
others to archive

We haven't heard anything else about this, so I'm going to assume that
everyone's cool with moving the additional RMI modules to the archive
folder. I will attempt to get this moved sometime in the next few hours.

-Nathan


-Original Message-
From: Daniel Gandara [mailto:[EMAIL PROTECTED]
Sent: Tuesday, August 22, 2006 6:10 AM
To: harmony-dev@incubator.apache.org
Subject: Re: [classlib][rmi] DISCUSSION : Use the RMI modiule and move

the

others to archive

I agree, I think it is a good idea, since changes can still be made,

code

will be on the archive, and we do not confuse people with multiple rmi
versions
within the classlib.


Daniel

- Original Message -
From: "Nathan Beyer" <[EMAIL PROTECTED]>
To: 
Sent: Monday, August 21, 2006 9:51 PM
Subject: RE: [classlib][rmi] DISCUSSION : Use the RMI modiule and move

the

others to archive



I like this approach. Anyone that wants to integrate changes can just
submit
patches.


-Original Message-
From: Geir Magnusson Jr [mailto:[EMAIL PROTECTED]
Sent: Monday, August 21, 2006 8:34 AM
To: harmony-dev@incubator.apache.org
Subject: [classlib][rmi] DISCUSSION : Use the RMI modiule and move

the

others to archive

We've had multiple RMI modules hanging around for a while due to our
fortune of multiple submissions.

Would anyone have a problem if we 'retired' all except modules/rmi to
the archive, and then took whatever was needed from there?

geir

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

[EMAIL PROTECTED]


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




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


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



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



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

RE: [classlib][rmi] DISCUSSION : Use the RMI modiule and move the others to archive

[Nathan Beyer]

I don't seem to have SVN permissions to add stuff to 'archive'. I'm getting
a 403 forbidden when I perform the move.

-Nathan

> -Original Message-
> From: Nathan Beyer [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, September 06, 2006 4:09 PM
> To: harmony-dev@incubator.apache.org
> Subject: RE: [classlib][rmi] DISCUSSION : Use the RMI modiule and move the
> others to archive
> 
> We haven't heard anything else about this, so I'm going to assume that
> everyone's cool with moving the additional RMI modules to the archive
> folder. I will attempt to get this moved sometime in the next few hours.
> 
> -Nathan
> 
> > -Original Message-
> > From: Daniel Gandara [mailto:[EMAIL PROTECTED]
> > Sent: Tuesday, August 22, 2006 6:10 AM
> > To: harmony-dev@incubator.apache.org
> > Subject: Re: [classlib][rmi] DISCUSSION : Use the RMI modiule and move
> the
> > others to archive
> >
> > I agree, I think it is a good idea, since changes can still be made,
> code
> > will be on the archive, and we do not confuse people with multiple rmi
> > versions
> > within the classlib.
> >
> >
> > Daniel
> >
> > - Original Message -
> > From: "Nathan Beyer" <[EMAIL PROTECTED]>
> > To: 
> > Sent: Monday, August 21, 2006 9:51 PM
> > Subject: RE: [classlib][rmi] DISCUSSION : Use the RMI modiule and move
> the
> > others to archive
> >
> >
> > >I like this approach. Anyone that wants to integrate changes can just
> > >submit
> > > patches.
> > >
> > >> -Original Message-
> > >> From: Geir Magnusson Jr [mailto:[EMAIL PROTECTED]
> > >> Sent: Monday, August 21, 2006 8:34 AM
> > >> To: harmony-dev@incubator.apache.org
> > >> Subject: [classlib][rmi] DISCUSSION : Use the RMI modiule and move
> the
> > >> others to archive
> > >>
> > >> We've had multiple RMI modules hanging around for a while due to our
> > >> fortune of multiple submissions.
> > >>
> > >> Would anyone have a problem if we 'retired' all except modules/rmi to
> > >> the archive, and then took whatever was needed from there?
> > >>
> > >> geir
> > >>
> > >> -
> > >> Terms of use : http://incubator.apache.org/harmony/mailing.html
> > >> To unsubscribe, e-mail: [EMAIL PROTECTED]
> > >> For additional commands, e-mail: harmony-dev-
> [EMAIL PROTECTED]
> > >
> > >
> > > -
> > > Terms of use : http://incubator.apache.org/harmony/mailing.html
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> > >
> >
> >
> >
> > -
> > Terms of use : http://incubator.apache.org/harmony/mailing.html
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 
> -
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]


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

NEVER MIND Re: [drlvm] classpath.SysRes smoke test failing?

[Geir Magnusson Jr.]

I reverted a few files in luni, in which there should have been no 
material changes, and things are passing again.


So... sorry to bother everyone, thanks for the help Nathan and any 
others who tried it, and ... I'm still suspicious :)


geir

Geir Magnusson Jr. wrote:
Yes, that's what I meant. I thought I just did a clean rebuild, and it's 
still failing that test.  I'm doing it again, classlib and DRLVM.


Odd.

Nathan Beyer wrote:
I presume you mean "classloader.SysRes", correct? I just ran a clean, 
build

and test with a fresh classlib build on WinXP and everything passed.

-Nathan


-Original Message-
From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED]
Sent: Wednesday, September 06, 2006 4:09 PM
To: harmony-dev@incubator.apache.org
Subject: [drlvm] classpath.SysRes smoke test failing?

It's failing on my ubuntu box.  Anyone else seeing this?

geir




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



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



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

Re: [drlvm] classpath.SysRes smoke test failing?

[Geir Magnusson Jr.]

Yes, that's what I meant. I thought I just did a clean rebuild, and it's 
still failing that test.  I'm doing it again, classlib and DRLVM.


Odd.

Nathan Beyer wrote:

I presume you mean "classloader.SysRes", correct? I just ran a clean, build
and test with a fresh classlib build on WinXP and everything passed.

-Nathan


-Original Message-
From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED]
Sent: Wednesday, September 06, 2006 4:09 PM
To: harmony-dev@incubator.apache.org
Subject: [drlvm] classpath.SysRes smoke test failing?

It's failing on my ubuntu box.  Anyone else seeing this?

geir




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



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

RE: [drlvm] classpath.SysRes smoke test failing?

[Nathan Beyer]

I presume you mean "classloader.SysRes", correct? I just ran a clean, build
and test with a fresh classlib build on WinXP and everything passed.

-Nathan

> -Original Message-
> From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, September 06, 2006 4:09 PM
> To: harmony-dev@incubator.apache.org
> Subject: [drlvm] classpath.SysRes smoke test failing?
> 
> It's failing on my ubuntu box.  Anyone else seeing this?
> 
> geir



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

Re: [drlvm] [jvmti] Implementation of SingleStep event through TRAP breakpoints

[Gregory Shimansky]

On Thursday 07 September 2006 00:55 Weldon Washburn wrote:
> Gregory,
>
> The below seems like a reasonable place to start.  Some observations.
> Regular native code debuggers also like to use int 3.  Do you plan to
> somehow chain onto int 3 exception handler so that regular native code
> debugger also works while java debugger is in use?

Debugging the debugger is never an easy task and it won't be easy I think. On 
windows (XP) using VEH handler chains it is already implemented in 
HARMONY-1363 that breakpoits which are not handled by JVMTI should be handled 
by the other handler in chain. On Linux when SIGTRAP is caught and the 
address is not known by JVMTI I think it should crash just like for other 
unknown signal/locations values.

But when the program is ran under debugger, be it VS.NET Studio or gdb, of 
course int3 is caught by the debugger first. When executing the program under 
VS.NET and int3 is encountered stepping over it doesn't result in exception 
which has to th trigger a breakpoint. When executing the program on linux gdb 
allows SIGTRAP to be caught by the program after it catches it first.

I think mixing debugging VM and debugger is very subtle if possible at all. I 
don't think it is possible to make it easier.

> The threading model is 
> somewhat vague.  For example, when thread A hits a breakpoint, the
> remaining threads could be forced to suspend at a GC safepoint by the VM. 
> This would allow the java debugger to swich thread context and read/wriite
> local variables (a very handy feature).  Allowing other Java threads to
> continue executing once a breakpoint has been hit can cause all sorts of
> hard to reason about problems.

The interaction between thread stopped on breakpoint and other if done through 
standard thread manager capabilities. It is up to the user and the JVMTI 
agent to allow or not the other threads to run when some thread is stopped on 
breakpoint. I think that debugging scenarios usually stop all of the threads. 
Profiling will probably not, but they won't access the variables also.

>
> On 9/4/06, Gregory Shimansky <[EMAIL PROTECTED]> wrote:
> > Hello
> >
> > Now that DRLVM has some basic implementation of breakpoints in JIT mode
> > as HARMONY-1363 has been created I've decided the same mechanism may be
> > used for
> > implementation of SingleStep JVMTI event [1].
> >
> > I've thought of some draft design for SingleStep implementation using
> > just int3 breakpoints which are already written in HARMONY-1363. It seems
> > to be enough to satisfy JVMTI spec requirements.
> >
> > The way how I think SingleStep could be implemented is setting a new
> > breakpoint on every new bytecode in compiled code. The breakpoint handler
> > would remove SingleStep breakpoints instrumentation from compiled code
> > and set new ones for the next executable location.
> >
> > The tricky parts is to find the next executable location have the
> > following
> > points
> >
> > 1. Turning SingleStep event state on. When this state is turned on all
> > threads
> > should be switched into SingleStep mode. All of them have to have the
> > next after currently executed bytecode marked with SingleStep type
> > breakpoint. 2. New threads when started and SingleStep state is on have
> > to mark the first
> > bytecode marked with SingleStep breakpoint.
> > 3. Any native to Java transition have to mark first executable bytecode
> > of the
> > method with SingleStep type breakpoint.
> > 4. When exception occurs the SingleStep breakpoints have to be removed
> > from
> > the places of the next executable location and set to exception handler
> > starting address instead.
> > 5. Breakpoints handler which would handle SingleStep type breakpoints as
> > well
> > has to distinguish agent set Breakpoints and synthetic SingleStep ones.
> > 6. When SingleStep state is turned off all breakpoints for the next
> > bytecode
> > in all threads have to be deleted.
> >
> > The implementation would require "next bytecode predictor" which would
> > allow
> > the handler of breakpoints to set them on the next bytecode to be
> > executed.
> > For conditional situations it is easiest to have a set of possibly
> > executable
> > locations, or otherwise it would require parsing current Java stack
> > state. The breakpoints predicted for the next bytecode should certainly
> > be kept in
> > TLS for every thread.
> >
> > There is going to be some subtle logic for distinguishing plain
> > breakpoints
> > and synthetic SingleStep ones and turning SingleStep on/off while in
> > SingleStep and/or Breakpoint callback.
> >
> > So in places like #4, #5 and #6 "predicted" breakpoints would have to be
> > added
> > and removed in sets potentially with more than one target address.
> >
> > At the moment I don't see any flaws in this simple design and I'm going
> > to start working on its implementation. Let me know what you think about
> > it. Surely it is a subject for improvement.
> >
> > I am mostly keeping the who

RE: Re: [jira] Created: (HARMONY-1386) Update to Pack200 decoding libraries

[Nathan Beyer]

I can't say I recall the details, but I believe that's a known issue with
JIRA; it doesn't offer that selection when an attachment is added in the
create wizard.

-Nathan

> -Original Message-
> From: Alex Blewitt [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, September 06, 2006 4:12 PM
> To: harmony-dev@incubator.apache.org
> Subject: Re: Re: [jira] Created: (HARMONY-1386) Update to Pack200 decoding
> libraries
> 
> You know, when I added the files in the initial bug report, I didn't
> see anything that would have made me add the license. I also couldn't
> figure out how to change it, so I uploaded it again.
> 
> :-)
> 
> On 06/09/06, Mikhail Loenko <[EMAIL PROTECTED]> wrote:
> > Hi Alex
> >
> > Thanks for the patches!
> > Could you please grant ASF license to make their inclusion possible?
> >
> > Thanks,
> > Mikhail
> >
> > 2006/9/6, Alex Blewitt (JIRA) <[EMAIL PROTECTED]>:
> > > Update to Pack200 decoding libraries
> > > 
> > >
> > > Key: HARMONY-1386
> > > URL: http://issues.apache.org/jira/browse/HARMONY-1386
> > > Project: Harmony
> > >  Issue Type: Improvement
> > >  Components: Classlib
> > >Reporter: Alex Blewitt
> > >Priority: Minor
> > > Attachments: HelloWorld.pack, pack200.patch
> > >
> > > I've updated the Pack200 decoding to take into account of the dynamic
> codec switching (although it currently throws an error if it's detected
> that such a dynamic switch is used) as well as adding more descriptive
> logging of what bands are being parsed, including remaining unimplemented
> bands. No output should be seen unless -Ddebug.pack200=true, but this is
> only for use whilst ensuring the unpacking is right.
> > >
> > > I'm not sure whether the patch contains the updated binary for
> HelloWorld.pack, so I'll attach that in addition to the patch.
> > >
> > > I've also fixed a couple of minor bugs in parsing the class and field
> bands.
> > >
> > > This patch passes all the tests with against the HEAD, but it wouldn't
> surprise me if the patch was missing some required file :-(
> > >
> > > --
> > > This message is automatically generated by JIRA.
> > > -
> > > If you think it was sent incorrectly contact one of the
> administrators: http://issues.apache.org/jira/secure/Administrators.jspa
> > > -
> > > For more information on JIRA, see:
> http://www.atlassian.com/software/jira
> > >
> > >
> > >
> >
> > -
> > Terms of use : http://incubator.apache.org/harmony/mailing.html
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> 
> -
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]


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

Re: Re: [jira] Created: (HARMONY-1386) Update to Pack200 decoding libraries

[Alex Blewitt]

You know, when I added the files in the initial bug report, I didn't
see anything that would have made me add the license. I also couldn't
figure out how to change it, so I uploaded it again.

:-)

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

Hi Alex

Thanks for the patches!
Could you please grant ASF license to make their inclusion possible?

Thanks,
Mikhail

2006/9/6, Alex Blewitt (JIRA) <[EMAIL PROTECTED]>:
> Update to Pack200 decoding libraries
> 
>
> Key: HARMONY-1386
> URL: http://issues.apache.org/jira/browse/HARMONY-1386
> Project: Harmony
>  Issue Type: Improvement
>  Components: Classlib
>Reporter: Alex Blewitt
>Priority: Minor
> Attachments: HelloWorld.pack, pack200.patch
>
> I've updated the Pack200 decoding to take into account of the dynamic codec 
switching (although it currently throws an error if it's detected that such a 
dynamic switch is used) as well as adding more descriptive logging of what bands 
are being parsed, including remaining unimplemented bands. No output should be 
seen unless -Ddebug.pack200=true, but this is only for use whilst ensuring the 
unpacking is right.
>
> I'm not sure whether the patch contains the updated binary for 
HelloWorld.pack, so I'll attach that in addition to the patch.
>
> I've also fixed a couple of minor bugs in parsing the class and field bands.
>
> This patch passes all the tests with against the HEAD, but it wouldn't 
surprise me if the patch was missing some required file :-(
>
> --
> This message is automatically generated by JIRA.
> -
> If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
> -
> For more information on JIRA, see: http://www.atlassian.com/software/jira
>
>
>

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




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

[drlvm] classpath.SysRes smoke test failing?

[Geir Magnusson Jr.]

It's failing on my ubuntu box.  Anyone else seeing this?

geir

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

RE: [classlib][rmi] DISCUSSION : Use the RMI modiule and move the others to archive

[Nathan Beyer]

We haven't heard anything else about this, so I'm going to assume that
everyone's cool with moving the additional RMI modules to the archive
folder. I will attempt to get this moved sometime in the next few hours.

-Nathan

> -Original Message-
> From: Daniel Gandara [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, August 22, 2006 6:10 AM
> To: harmony-dev@incubator.apache.org
> Subject: Re: [classlib][rmi] DISCUSSION : Use the RMI modiule and move the
> others to archive
> 
> I agree, I think it is a good idea, since changes can still be made, code
> will be on the archive, and we do not confuse people with multiple rmi
> versions
> within the classlib.
> 
> 
> Daniel
> 
> - Original Message -
> From: "Nathan Beyer" <[EMAIL PROTECTED]>
> To: 
> Sent: Monday, August 21, 2006 9:51 PM
> Subject: RE: [classlib][rmi] DISCUSSION : Use the RMI modiule and move the
> others to archive
> 
> 
> >I like this approach. Anyone that wants to integrate changes can just
> >submit
> > patches.
> >
> >> -Original Message-
> >> From: Geir Magnusson Jr [mailto:[EMAIL PROTECTED]
> >> Sent: Monday, August 21, 2006 8:34 AM
> >> To: harmony-dev@incubator.apache.org
> >> Subject: [classlib][rmi] DISCUSSION : Use the RMI modiule and move the
> >> others to archive
> >>
> >> We've had multiple RMI modules hanging around for a while due to our
> >> fortune of multiple submissions.
> >>
> >> Would anyone have a problem if we 'retired' all except modules/rmi to
> >> the archive, and then took whatever was needed from there?
> >>
> >> geir
> >>
> >> -
> >> Terms of use : http://incubator.apache.org/harmony/mailing.html
> >> To unsubscribe, e-mail: [EMAIL PROTECTED]
> >> For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> > -
> > Terms of use : http://incubator.apache.org/harmony/mailing.html
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> 
> 
> 
> -
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]


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

Re: [drlvm] [jvmti] Implementation of SingleStep event through TRAP breakpoints

[Weldon Washburn]

Gregory,

The below seems like a reasonable place to start.  Some observations.
Regular native code debuggers also like to use int 3.  Do you plan to
somehow chain onto int 3 exception handler so that regular native code
debugger also works while java debugger is in use?  The threading model is
somewhat vague.  For example, when thread A hits a breakpoint, the remaining
threads could be forced to suspend at a GC safepoint by the VM.  This would
allow the java debugger to swich thread context and read/wriite local
variables (a very handy feature).  Allowing other Java threads to continue
executing once a breakpoint has been hit can cause all sorts of hard to
reason about problems.



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


Hello

Now that DRLVM has some basic implementation of breakpoints in JIT mode as
HARMONY-1363 has been created I've decided the same mechanism may be used
for
implementation of SingleStep JVMTI event [1].

I've thought of some draft design for SingleStep implementation using just
int3 breakpoints which are already written in HARMONY-1363. It seems to be
enough to satisfy JVMTI spec requirements.

The way how I think SingleStep could be implemented is setting a new
breakpoint on every new bytecode in compiled code. The breakpoint handler
would remove SingleStep breakpoints instrumentation from compiled code and
set new ones for the next executable location.

The tricky parts is to find the next executable location have the
following
points

1. Turning SingleStep event state on. When this state is turned on all
threads
should be switched into SingleStep mode. All of them have to have the next
after currently executed bytecode marked with SingleStep type breakpoint.
2. New threads when started and SingleStep state is on have to mark the
first
bytecode marked with SingleStep breakpoint.
3. Any native to Java transition have to mark first executable bytecode of
the
method with SingleStep type breakpoint.
4. When exception occurs the SingleStep breakpoints have to be removed
from
the places of the next executable location and set to exception handler
starting address instead.
5. Breakpoints handler which would handle SingleStep type breakpoints as
well
has to distinguish agent set Breakpoints and synthetic SingleStep ones.
6. When SingleStep state is turned off all breakpoints for the next
bytecode
in all threads have to be deleted.

The implementation would require "next bytecode predictor" which would
allow
the handler of breakpoints to set them on the next bytecode to be
executed.
For conditional situations it is easiest to have a set of possibly
executable
locations, or otherwise it would require parsing current Java stack state.
The breakpoints predicted for the next bytecode should certainly be kept
in
TLS for every thread.

There is going to be some subtle logic for distinguishing plain
breakpoints
and synthetic SingleStep ones and turning SingleStep on/off while in
SingleStep and/or Breakpoint callback.

So in places like #4, #5 and #6 "predicted" breakpoints would have to be
added
and removed in sets potentially with more than one target address.

At the moment I don't see any flaws in this simple design and I'm going to
start working on its implementation. Let me know what you think about it.
Surely it is a subject for improvement.

I am mostly keeping the whole idea in my head and never tried to write it
down
completely, I may miss describing some nuances since I may think of them
as
obvious so feel free to ask me.

[1]
http://java.sun.com/j2se/1.5.0/docs/guide/jvmti/jvmti.html#SingleStep

--
Gregory Shimansky, 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]





--
Weldon Washburn
Intel Middleware Products Division

[build] Use Sun 5.0_8 or Eclipse Compiler for automated builds

[Nathan Beyer]

Would there be any objections to asking the automated builds (that send
messages to the commit list) to use either the latest Sun compiler (5.0_8)
or the Eclipse compiler?

 

There are a number of places that use ReferenceQueues and Reference, but
can't be generified because of a bug in the Sun compilers prior to 5.0_8. At
the end of this email is an example of code that causes a compiler error in
previous releases. This issue does not affect the Eclipse compiler. I've run
a full rebuild as of revision 440796 and everything compiles fine with both
the Eclipse compiler and Sun 5.0_8 compiler.

 

-Nathan

 

 

private static final ReferenceQueue cacheQueue = new
ReferenceQueue();

 

private static final class CacheEntry extends WeakReference {

String key;

 

CacheEntry(Object jar, String key, ReferenceQueue queue) {

super(jar, queue);

this.key = key;

}

}

 

// ... code using the queue

 

CacheEntry entry;

// This cast fails on Sun 5.0_7 and prior compilers

while ((entry = (CacheEntry)cacheQueue.poll()) != null) {

jarCache.remove(entry.key);

}

 

// . more code

 

 

Re: [drlvm] Helper inlining in JIT

[Rana Dasgupta]

Hi Mikhail,
   Sorry I left this thread for a while. Are you implementing VMMagic
support in .OPT currently, and prototyping with bump allocation?  I am just
trying to understand in what order we are doing this.
  Would it be possible to list the fastpath helpers so that the java
interfaces to access them could be defined? All of them don't need magic
classes support and one of us could just write them. I don't know the list
of intrinsics implemented already in .JET. Can we just use them as is, and
what else ( other than TLS access, call support ) would need to be added?
 BTW, there may be a small omission in the example below..if I am reading
this right...

Thanks,
Rana

On 8/28/06, Mikhail Fursov <[EMAIL PROTECTED]> wrote:


Folks,
Here is the example of fast allocation helper written in Java with the
help
of VMMagic
If nobody objects I'm starting to implement VMMagic support in
Jitrino.OPTthis week.



private static final int GC_TLS_OFFSET = 10;
private static final int GC_CURRENT_OFFSET= GC_TLS_OFFSET + 0;
private static final int GC_CEILING_OFFSET= GC_TLS_OFFSET + 4;
private static final int OBJ_VTABLE_OFFSET = 0;

//annotate with calling convention and real VM helper id/name information
private static Address slowAlloc(int vtable, int size) {throw new
Error("must never be called!");}

private static Address fastAlloc(int vtable, int size) {
   Address tlsBase = TLS.getAddress();  //load thread local client area
address

   Address currentFieldAddress = tlsBase.plus(GC_CURRENT_OFFSET);
   Address ceilingFieldAddress = tlsBase.plus(GC_CEILING_OFFSET);

   Address newObjectAddress; //the result of the method

   // check if there is enough size to do allocation in thread local
buffer
   Address current = currentFieldAddress.loadAddress();
   Address ceiling = ceilingFieldAddress.loadAddress();
   Address newCurrent = current.plus(size);
   if (newCurrent.LT(ceiling)) {




   newCurrent = newCurrent.plus(-size);


  currentFieldAddress.store(newCurrent.toWord());

   newObjectAddress = newCurrent;
   newObjectAddress.store(vtable, Offset.fromInt(OBJ_VTABLE_OFFSET));

   } else {
   newObjectAddress = slowAlloc(vtable, size);
   }
   return newObjectAddress;
}

--
Mikhail Fursov

RE: [doc] no images on website pages

[Morozova, Nadezhda]

Geir, 

Could you please migrate the images? It seems easier than giving a patch
and resending all images that are in SVN already. 

DRLVM doc images are in drlvm/trunk/vm/doc/images/ and need to be placed
in site/docs/subcomponents/drlvm/images/.

We also have several API docs, located in classlib/trunk/doc/*/images
subdirectories, where * includes the following directories:
awt/
regex/
security/
These images logically below to site/docs/subcomponents/classlib/images/

Side question: current HTML doc have some common elements, can we
remove? Specifically:
- disclaimers (ASF, Intel notice)
- conventions (a table of fonts and symbols used); same for all
docs;   can be one website page instead of multiple instances in SVN
- drl.css (old style sheet) - obsolete, will be replaced by
harmony CSS instead of multiple instances in SVN

Best regards, 
Nadya Morozova
 
-Original Message-
From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, September 06, 2006 1:48 AM
To: harmony-dev@incubator.apache.org
Subject: Re: [doc] no images on website pages



Morozova, Nadezhda wrote:
> 
> Best regards, 
> Nadya Morozova
>  
>  Folks, 
> 
> I have just submitted a patch that fixing the conflict in styles on
the
> website [1]. When doing this, I noticed another issue with the docs
> deployed: 
> 
> There are no images! The image files used in individual documents are
> stored in the SVN repository at their initial location and not copied
> into the website. This way, the links are broken. What do we do with
> this? 
> 
> I see at least 2 solutions: 
> 1. Move the images to corresponding folders in the website (for
example,
> site/docs/subcomponents/drlvm/images) and configure SVN to make a
> read-only copy from there to the initial location of files

Yes.  We should just move them.

> 2. Leave as is and change the links to the images: add checkout links
> instead specifying the current location of the file
> 
> Any other suggestions? Your feedback is most welcome. 
> 
> Cheers, Nadya
> 
> [1] JIRA issue 1384,
https://issues.apache.org/jira/browse/HARMONY-1384
> 
> -
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 

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

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

Re: [drlvm] DRLVM, jre/bin/default and launcher

[Geir Magnusson Jr.]

Evgueni Brevnov wrote:

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



Evgueni Brevnov wrote:
> HI All,
>
> Good news! I have a patch to run DRLVM with the classlib's launcher
> (I've checked Hello and Eclipse applications on Windows only).
> Actually, there are two patches. The first one is for classlib which
> changes vm default directory to drlvm.

I don't think we should do that - we'll keep it the same as it is now -
"default".

Why should we change it?


I don't care about it too much. Let it be "default". In that case
-vmdir option should be specified each time. Is it convenient for
users? 


?  right now, "default" is the default.  So the user doesn't have to 
specify anything...


With the DRLVM stuff in jre/bin/default the user just types

 java


> BTW it seems there will be some problems with hythr.dll library

if we wish to use drlvm and j9 in simultaneously. But that's another
story...


Yes, we need to resolve this.





> The second one is for build
> system and VM itself. Unfortunatelly, it is impossible to eliminate
> all problems in a short period of time. There is still a bunch of work
> in initialization and jni modules. So this patch is just a one more
> step to our goal.

Great.  As I said in other mails, the build stuff isn't the part to
worry about but rather the VM itself.

So does this patch do it completely, or should we wait?


Yes, the patch contains changes for both parts vm and build.
It was easy for me to change the build than do manual manipulations each 
time to

check whether it runs OK or not.


So does this mean if I apply the patch, then DRLVM works w/ the launcher 
from the jre/bin/default directory w/o any problems?


geir





>
> The vm patch is quite heavy so I attach it and classlib patch.
> Hope it will work not only for me :-)
>
>
> On 9/5/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
>>
>>
>> Salikh Zakirov wrote:
>> > Andrey Chernyshev wrote:
>> >> 1.  Fix the DRLVM layout - rename vmcore to "harmonyvm" and move
>> >> ..dll/.so into the "default" subdirectory such that one doesn't
>> have to
>> >> type -vm and -vmdir options;
>> >
>> > While would you want to rename DRLVM to Harmony VM?
>> > It feels to me like claiming DRLVM to be "the only" Harmony VM.
>> > On the contrary, I thought Harmony project is about *encouraging*
>> diversity.
>> >
>> > I think having library named libdrlvm.so would be much better.
>>
>> No - the launcher picks up the vm from "harmonyvm.dll" (or .so) so
>> that's what we'll name it.
>>
>> Then it makes it easy.  put J9 in jre/bin/j9 and drlvm in 
jre/bin/drlvm

>> and then
>>
>>   java -vmdir:j9
>>
>> or
>>
>>   java -vmdir:drlvm
>>
>>
>> etc
>>
>> geir
>>
>> >
>> >> 2. Exclude building of the "original" launcher from the DRLVM 
build -

>> >> it currently conflicts with the classlib launcher (both are called
>> >> "java").
>> >>
>> >> 3. Aside from the hythread, it may also have a sense to make the
>> >> classlib and DRLVM using the same zlib dll/so (preferably the 
system

>> >> one).
>> >
>> >
>> > 
-

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

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


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

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




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



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

[general] Marking JIRA issues before creation of patches.

[Oleg Khaschansky]

Hi all,

There were situations when several people started work on the same
issue simultaneously. This happens because it is impossible to assign
an issue to a non-committer. I suggest the following process to
prevent these collisions:

1. If non-committer starts investigation and is pretty sure that he
will proceed with the patch then he adds a comment like "starting
investigation" to the JIRA issue. Maybe we should have a special
keyword for this to make a search easier.
2. If for some reason he is unable to provide the patch, he adds a
comment about this also.

What do you think about this?

--
 Oleg

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

Re: [DRLVM][JIT] can Jitrino.JET call MMTk alloc() instead of C helper?

[Weldon Washburn]

On 9/6/06, Mikhail Fursov <[EMAIL PROTECTED]> wrote:


Weldon,
The replacement of the 'new' opcode call with another call is relatively
easy task.

To send a working patch I need the following information:
1) Which Java method to call? Is it an instance method or a static?



Its an instance method.  Ideally you can use the same approach as the one
used when adding write barriers to Jitrino.JET.  Specifically
PlanLocal.javain Jira Harmony-816.  The API is:

public Address alloc(int bytes, int align, int offset, int allocator, int
site);

The only parameter I care about at this time is bytes.  This must  be
accurate.  I will ignore the rest of the parameters.  In other words, to
allocate a 52 byte object, the call site should look like:

alloc( 52, 0, 0, 0, 0);

Make sure the JIT loads the vtable ptr (and array length if required).

2) How to test the implementation? I can get and deploy all of your changes

or just to call some stub methods in a specialized testcase before sending
the result to you.




It would be best to test with a stub that is similar to what's in
Harmony-816.  It would also be great if the object allocator can chosen by
pattern matching on the method name.  A similar facility already exists for
the write barrier -- it might be a simple cut/paste.

The above will work fine during the single thread stage of this project.
Once we decide to turn on multiple Java threads, we will need to stuff a
thread specific MMTk object in DRLVM's thread block.  Then during execution
of JITed code, use vmmagic to load fs:14+offset_of_the_alloc_object into,
for example, EBX.  Do a "mov eax, [ebx]" to get the vtable pointer into
eax.  And finally, "call [eax + offset_of_the_alloc_method].

Let me know if you have further questions.



?



On 9/6/06, Weldon Washburn <[EMAIL PROTECTED]> wrote:
>
> A question for Jitrino.JET developers.  How hard would it be to modify
the
> existing Jitrino.JET code  so that the "new" opcode calls MMTk alloc()?
>
> Thanks
> --
> Weldon Washburn
> Intel Middleware Products Division
>
>


--
Mikhail Fursov





--
Weldon Washburn
Intel Middleware Products Division

Re: [drlvm] DRLVM, jre/bin/default and launcher

[Alexey Varlamov]

2006/9/6, Evgueni Brevnov <[EMAIL PROTECTED]>:

On 9/6/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
>
>
> Evgueni Brevnov wrote:
> > HI All,
> >
> > Good news! I have a patch to run DRLVM with the classlib's launcher
> > (I've checked Hello and Eclipse applications on Windows only).
> > Actually, there are two patches. The first one is for classlib which
> > changes vm default directory to drlvm.
>
> I don't think we should do that - we'll keep it the same as it is now -
> "default".
>
> Why should we change it?

I don't care about it too much. Let it be "default". In that case
-vmdir option should be specified each time. Is it convenient for
users? BTW it seems there will be some problems with hythr.dll library
if we wish to use drlvm and j9 in simultaneously. But that's another
story...


Evgueni,
The patch you provided hardcodes name of vmdir, so the command-line
option would not help... OTOH, indeed it is possible to put J9 in
jre/bin/j9 and drlvm in jre/bin/drlvm (exactly as Geir said) and just
symlink one of them to jre/bin/default as needed :)

Regarding hythr lib, DRLVM can load the lib from it's own directory,
isn't it? BTW, is there any reason to name it equally with the
classlib's counterpart? I suppose it is loaded only dynamically
anyway.

Still I think this patch is enough for basic launcher support; we can
make it more reliable and customizable later.

--
Alexey


>
> > The second one is for build
> > system and VM itself. Unfortunatelly, it is impossible to eliminate
> > all problems in a short period of time. There is still a bunch of work
> > in initialization and jni modules. So this patch is just a one more
> > step to our goal.
>
> Great.  As I said in other mails, the build stuff isn't the part to
> worry about but rather the VM itself.
>
> So does this patch do it completely, or should we wait?

Yes, the patch contains changes for both parts vm and build.
It was easy for me to change the build than do manual manipulations each time to
check whether it runs OK or not.

>
> >
> > The vm patch is quite heavy so I attach it and classlib patch.
> > Hope it will work not only for me :-)
> >
> >
> > On 9/5/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
> >>
> >>
> >> Salikh Zakirov wrote:
> >> > Andrey Chernyshev wrote:
> >> >> 1.  Fix the DRLVM layout - rename vmcore to "harmonyvm" and move
> >> >> ..dll/.so into the "default" subdirectory such that one doesn't
> >> have to
> >> >> type -vm and -vmdir options;
> >> >
> >> > While would you want to rename DRLVM to Harmony VM?
> >> > It feels to me like claiming DRLVM to be "the only" Harmony VM.
> >> > On the contrary, I thought Harmony project is about *encouraging*
> >> diversity.
> >> >
> >> > I think having library named libdrlvm.so would be much better.
> >>
> >> No - the launcher picks up the vm from "harmonyvm.dll" (or .so) so
> >> that's what we'll name it.
> >>
> >> Then it makes it easy.  put J9 in jre/bin/j9 and drlvm in jre/bin/drlvm
> >> and then
> >>
> >>   java -vmdir:j9
> >>
> >> or
> >>
> >>   java -vmdir:drlvm
> >>
> >>
> >> etc
> >>
> >> geir
> >>
> >> >
> >> >> 2. Exclude building of the "original" launcher from the DRLVM build -
> >> >> it currently conflicts with the classlib launcher (both are called
> >> >> "java").
> >> >>
> >> >> 3. Aside from the hythread, it may also have a sense to make the
> >> >> classlib and DRLVM using the same zlib dll/so (preferably the system
> >> >> one).
> >> >
> >> >
> >> > -
> >> > Terms of use : http://incubator.apache.org/harmony/mailing.html
> >> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> >> > For additional commands, e-mail: [EMAIL PROTECTED]
> >> >
> >>
> >> -
> >> Terms of use : http://incubator.apache.org/harmony/mailing.html
> >> To unsubscribe, e-mail: [EMAIL PROTECTED]
> >> For additional commands, e-mail: [EMAIL PROTECTED]
> >>
> >>
> >
> >
> > 
> >
> > -
> > Terms of use : http://incubator.apache.org/harmony/mailing.html
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
>
> -
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

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




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

Re: [jira] Updated: (HARMONY-1392) Different properties are used to run awt and swing tests

[Alexey Petrenko]

Both solutions are possible.

2006/9/6, Mikhail Loenko <[EMAIL PROTECTED]>:

Is there a reason to have two different options for classes and for tests?

Why not have -Dwith.awt.swing for both?

Thanks,
Mikhail

2006/9/6, Alexey Petrenko (JIRA) <[EMAIL PROTECTED]>:
> [ http://issues.apache.org/jira/browse/HARMONY-1392?page=all ]
>
> Alexey Petrenko updated HARMONY-1392:
> -
>
>Attachment: HARMONY-1392.diff
>
> > Different properties are used to run awt and swing tests
> > 
> >
> > Key: HARMONY-1392
> > URL: http://issues.apache.org/jira/browse/HARMONY-1392
> > Project: Harmony
> >  Issue Type: Bug
> >  Components: Classlib
> >Reporter: Alexey Petrenko
> > Attachments: HARMONY-1392.diff
> >
> >
> > We need to set different properties to run awt and swing tests. And this is 
wrong.
> > I suggest set with.awt.swing.tests property as for awt.
> > I'll prepare the patch shortly
>
> --
> This message is automatically generated by JIRA.
> -
> If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
> -
> For more information on JIRA, see: http://www.atlassian.com/software/jira
>
>
>

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





--
Alexey A. Petrenko
Intel Middleware Products Division

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

Re: [classlib][TestNG] groups of Harmony test

[Richard Liang]

On 9/6/06, Vladimir Ivanov <[EMAIL PROTECTED]> wrote:

On 9/6/06, Paulex Yang <[EMAIL PROTECTED]> wrote:
>
> Vladimir Ivanov wrote:
> > Do we really need in it? At present time tests were designed for
> win/unix
> > only.
> >
> I thought at least we have interest to port Harmony to these platforms[1].
>
> [1] http://incubator.apache.org/harmony/roadmap.html#Porting%20Matrix


Yes, but I don't sure that we will have unique java API tests for all of
them. In any case, if we define groups set it should include names for all
defined platforms.



We proposed to use os+arch to define platform.

Best regards,
Richard


 thanks, Vladimir


--
> Paulex Yang
> China Software Development Lab
> IBM
>
>
>
> -
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>





--
Richard Liang
China Software Development Lab, IBM

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

Re: [drlvm] DRLVM, jre/bin/default and launcher

[Evgueni Brevnov]

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



Evgueni Brevnov wrote:
> HI All,
>
> Good news! I have a patch to run DRLVM with the classlib's launcher
> (I've checked Hello and Eclipse applications on Windows only).
> Actually, there are two patches. The first one is for classlib which
> changes vm default directory to drlvm.

I don't think we should do that - we'll keep it the same as it is now -
"default".

Why should we change it?


I don't care about it too much. Let it be "default". In that case
-vmdir option should be specified each time. Is it convenient for
users? BTW it seems there will be some problems with hythr.dll library
if we wish to use drlvm and j9 in simultaneously. But that's another
story...



> The second one is for build
> system and VM itself. Unfortunatelly, it is impossible to eliminate
> all problems in a short period of time. There is still a bunch of work
> in initialization and jni modules. So this patch is just a one more
> step to our goal.

Great.  As I said in other mails, the build stuff isn't the part to
worry about but rather the VM itself.

So does this patch do it completely, or should we wait?


Yes, the patch contains changes for both parts vm and build.
It was easy for me to change the build than do manual manipulations each time to
check whether it runs OK or not.



>
> The vm patch is quite heavy so I attach it and classlib patch.
> Hope it will work not only for me :-)
>
>
> On 9/5/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
>>
>>
>> Salikh Zakirov wrote:
>> > Andrey Chernyshev wrote:
>> >> 1.  Fix the DRLVM layout - rename vmcore to "harmonyvm" and move
>> >> ..dll/.so into the "default" subdirectory such that one doesn't
>> have to
>> >> type -vm and -vmdir options;
>> >
>> > While would you want to rename DRLVM to Harmony VM?
>> > It feels to me like claiming DRLVM to be "the only" Harmony VM.
>> > On the contrary, I thought Harmony project is about *encouraging*
>> diversity.
>> >
>> > I think having library named libdrlvm.so would be much better.
>>
>> No - the launcher picks up the vm from "harmonyvm.dll" (or .so) so
>> that's what we'll name it.
>>
>> Then it makes it easy.  put J9 in jre/bin/j9 and drlvm in jre/bin/drlvm
>> and then
>>
>>   java -vmdir:j9
>>
>> or
>>
>>   java -vmdir:drlvm
>>
>>
>> etc
>>
>> geir
>>
>> >
>> >> 2. Exclude building of the "original" launcher from the DRLVM build -
>> >> it currently conflicts with the classlib launcher (both are called
>> >> "java").
>> >>
>> >> 3. Aside from the hythread, it may also have a sense to make the
>> >> classlib and DRLVM using the same zlib dll/so (preferably the system
>> >> one).
>> >
>> >
>> > -
>> > Terms of use : http://incubator.apache.org/harmony/mailing.html
>> > To unsubscribe, e-mail: [EMAIL PROTECTED]
>> > For additional commands, e-mail: [EMAIL PROTECTED]
>> >
>>
>> -
>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>
>
> 
>
> -
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]

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




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

Re: [jira] Updated: (HARMONY-1392) Different properties are used to run awt and swing tests

[Mikhail Loenko]

Is there a reason to have two different options for classes and for tests?

Why not have -Dwith.awt.swing for both?

Thanks,
Mikhail

2006/9/6, Alexey Petrenko (JIRA) <[EMAIL PROTECTED]>:

[ http://issues.apache.org/jira/browse/HARMONY-1392?page=all ]

Alexey Petrenko updated HARMONY-1392:
-

   Attachment: HARMONY-1392.diff

> Different properties are used to run awt and swing tests
> 
>
> Key: HARMONY-1392
> URL: http://issues.apache.org/jira/browse/HARMONY-1392
> Project: Harmony
>  Issue Type: Bug
>  Components: Classlib
>Reporter: Alexey Petrenko
> Attachments: HARMONY-1392.diff
>
>
> We need to set different properties to run awt and swing tests. And this is 
wrong.
> I suggest set with.awt.swing.tests property as for awt.
> I'll prepare the patch shortly

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira





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

Re: [classlib][TestNG] groups of Harmony test

[Vladimir Ivanov]

On 9/6/06, Paulex Yang <[EMAIL PROTECTED]> wrote:


Vladimir Ivanov wrote:
> Do we really need in it? At present time tests were designed for
win/unix
> only.
>
I thought at least we have interest to port Harmony to these platforms[1].

[1] http://incubator.apache.org/harmony/roadmap.html#Porting%20Matrix



Yes, but I don't sure that we will have unique java API tests for all of
them. In any case, if we define groups set it should include names for all
defined platforms.

thanks, Vladimir


--

Paulex Yang
China Software Development Lab
IBM



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

Re: [result] Re: [vote] HARMONY-1225 : Assorted fixes and enhancements for AWT and Swing

[Mikhail Loenko]

A list of tests for exclude is OK, or a patch to the old patch :)

Thanks,
Mikhail

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



Mikhail Loenko wrote:
> Seems like a new patch is a better way.
>
> If apply it as is then some tests fail some hang up...

What would the new patch be?  :)

If new code to replace the code we just voted on, then we have a problem.

If it's simply a set of tests to exclude, cool...

geir

>
> Thanks,
> Mikhail
>
>
> 2006/8/31, Geir Magnusson Jr. <[EMAIL PROTECTED]>:
>> Well, that's 3 days :)
>>
>> +1 from geir, alexey, vladimir, Ilya, the other alexey, sergey, mark,
>> oleg, paulex, mikhail, kenny,
>>
>> no other votes (other than interest in getting the dependency thing
>> fixed once and for all, and some chat about patching the patch)
>>
>> so this passes.
>>
>> Once we finish arguing about *how* it should be committed, I'll be happy
>> to commit it so people can focus new work on it.
>>
>> geir
>>
>> Geir Magnusson Jr wrote:
>> > All is in order and in SVN for Harmony-1225 wrt BCC and ACQ.
>> >
>> > Please vote to accept or reject this set of patches and fixes into the
>> > Apache Harmony class library :
>> >
>> > [ ] + 1 Accept
>> > [ ] -1 Reject  (provide reason below)
>> >
>> > Lets let this run a minimum of 3 days unless a) someone states they
>> need
>> > more time or b) we get all committer votes before then.
>> >
>> > geir
>> >
>> >
>> >
>> > -
>> > Terms of use : http://incubator.apache.org/harmony/mailing.html
>> > To unsubscribe, e-mail: [EMAIL PROTECTED]
>> > For additional commands, e-mail: [EMAIL PROTECTED]
>> >
>>
>> -
>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>
> -
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>

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




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

Re: [drlvm] DRLVM, jre/bin/default and launcher

[Geir Magnusson Jr.]

Thanks - putting patches in JIRA is the best way.

geir

Evgueni Brevnov wrote:

Hi Geir,

It seems not all of us are able to see my attachments :-(
I've created new jira HARMONY-1390 with attachments.

Thanks
Evgueni.

On 9/6/06, Evgueni Brevnov <[EMAIL PROTECTED]> wrote:

HI All,

Good news! I have a patch to run DRLVM with the classlib's launcher
(I've checked Hello and Eclipse applications on Windows only).
Actually, there are two patches. The first one is for classlib which
changes vm default directory to drlvm. The second one is for build
system and VM itself. Unfortunatelly, it is impossible to eliminate
all problems in a short period of time. There is still a bunch of work
in initialization and jni modules. So this patch is just a one more
step to our goal.

The vm patch is quite heavy so I attach it and classlib patch.
Hope it will work not only for me :-)


On 9/5/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
>
>
> Salikh Zakirov wrote:
> > Andrey Chernyshev wrote:
> >> 1.  Fix the DRLVM layout - rename vmcore to "harmonyvm" and move
> >> ..dll/.so into the "default" subdirectory such that one doesn't 
have to

> >> type -vm and -vmdir options;
> >
> > While would you want to rename DRLVM to Harmony VM?
> > It feels to me like claiming DRLVM to be "the only" Harmony VM.
> > On the contrary, I thought Harmony project is about *encouraging* 
diversity.

> >
> > I think having library named libdrlvm.so would be much better.
>
> No - the launcher picks up the vm from "harmonyvm.dll" (or .so) so
> that's what we'll name it.
>
> Then it makes it easy.  put J9 in jre/bin/j9 and drlvm in jre/bin/drlvm
> and then
>
>   java -vmdir:j9
>
> or
>
>   java -vmdir:drlvm
>
>
> etc
>
> geir
>
> >
> >> 2. Exclude building of the "original" launcher from the DRLVM 
build -

> >> it currently conflicts with the classlib launcher (both are called
> >> "java").
> >>
> >> 3. Aside from the hythread, it may also have a sense to make the
> >> classlib and DRLVM using the same zlib dll/so (preferably the system
> >> one).
> >
> >
> > -
> > Terms of use : http://incubator.apache.org/harmony/mailing.html
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: 
[EMAIL PROTECTED]

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





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



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

Re: [drlvm] DRLVM, jre/bin/default and launcher

[Geir Magnusson Jr.]

Evgueni Brevnov wrote:

HI All,

Good news! I have a patch to run DRLVM with the classlib's launcher
(I've checked Hello and Eclipse applications on Windows only).
Actually, there are two patches. The first one is for classlib which
changes vm default directory to drlvm.


I don't think we should do that - we'll keep it the same as it is now - 
"default".


Why should we change it?


The second one is for build
system and VM itself. Unfortunatelly, it is impossible to eliminate
all problems in a short period of time. There is still a bunch of work
in initialization and jni modules. So this patch is just a one more
step to our goal.


Great.  As I said in other mails, the build stuff isn't the part to 
worry about but rather the VM itself.


So does this patch do it completely, or should we wait?



The vm patch is quite heavy so I attach it and classlib patch.
Hope it will work not only for me :-)


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



Salikh Zakirov wrote:
> Andrey Chernyshev wrote:
>> 1.  Fix the DRLVM layout - rename vmcore to "harmonyvm" and move
>> ..dll/.so into the "default" subdirectory such that one doesn't 
have to

>> type -vm and -vmdir options;
>
> While would you want to rename DRLVM to Harmony VM?
> It feels to me like claiming DRLVM to be "the only" Harmony VM.
> On the contrary, I thought Harmony project is about *encouraging* 
diversity.

>
> I think having library named libdrlvm.so would be much better.

No - the launcher picks up the vm from "harmonyvm.dll" (or .so) so
that's what we'll name it.

Then it makes it easy.  put J9 in jre/bin/j9 and drlvm in jre/bin/drlvm
and then

  java -vmdir:j9

or

  java -vmdir:drlvm


etc

geir

>
>> 2. Exclude building of the "original" launcher from the DRLVM build -
>> it currently conflicts with the classlib launcher (both are called
>> "java").
>>
>> 3. Aside from the hythread, it may also have a sense to make the
>> classlib and DRLVM using the same zlib dll/so (preferably the system
>> one).
>
>
> -
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>

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







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


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

Re: [jira] Created: (HARMONY-1386) Update to Pack200 decoding libraries

[Mikhail Loenko]

Hi Alex

Thanks for the patches!
Could you please grant ASF license to make their inclusion possible?

Thanks,
Mikhail

2006/9/6, Alex Blewitt (JIRA) <[EMAIL PROTECTED]>:

Update to Pack200 decoding libraries


Key: HARMONY-1386
URL: http://issues.apache.org/jira/browse/HARMONY-1386
Project: Harmony
 Issue Type: Improvement
 Components: Classlib
   Reporter: Alex Blewitt
   Priority: Minor
Attachments: HelloWorld.pack, pack200.patch

I've updated the Pack200 decoding to take into account of the dynamic codec 
switching (although it currently throws an error if it's detected that such a 
dynamic switch is used) as well as adding more descriptive logging of what 
bands are being parsed, including remaining unimplemented bands. No output 
should be seen unless -Ddebug.pack200=true, but this is only for use whilst 
ensuring the unpacking is right.

I'm not sure whether the patch contains the updated binary for HelloWorld.pack, 
so I'll attach that in addition to the patch.

I've also fixed a couple of minor bugs in parsing the class and field bands.

This patch passes all the tests with against the HEAD, but it wouldn't surprise 
me if the patch was missing some required file :-(

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira





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

Re: [result] Re: [vote] HARMONY-1225 : Assorted fixes and enhancements for AWT and Swing

[Geir Magnusson Jr.]

Mikhail Loenko wrote:

Seems like a new patch is a better way.

If apply it as is then some tests fail some hang up...


What would the new patch be?  :)

If new code to replace the code we just voted on, then we have a problem.

If it's simply a set of tests to exclude, cool...

geir



Thanks,
Mikhail


2006/8/31, Geir Magnusson Jr. <[EMAIL PROTECTED]>:

Well, that's 3 days :)

+1 from geir, alexey, vladimir, Ilya, the other alexey, sergey, mark,
oleg, paulex, mikhail, kenny,

no other votes (other than interest in getting the dependency thing
fixed once and for all, and some chat about patching the patch)

so this passes.

Once we finish arguing about *how* it should be committed, I'll be happy
to commit it so people can focus new work on it.

geir

Geir Magnusson Jr wrote:
> All is in order and in SVN for Harmony-1225 wrt BCC and ACQ.
>
> Please vote to accept or reject this set of patches and fixes into the
> Apache Harmony class library :
>
> [ ] + 1 Accept
> [ ] -1 Reject  (provide reason below)
>
> Lets let this run a minimum of 3 days unless a) someone states they 
need

> more time or b) we get all committer votes before then.
>
> geir
>
>
>
> -
> Terms of use : http://incubator.apache.org/harmony/mailing.html
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>

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




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



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

Re: [DRLVM][JIT] can Jitrino.JET call MMTk alloc() instead of C helper?

[Mikhail Fursov]

Weldon,
The replacement of the 'new' opcode call with another call is relatively
easy task.

To send a working patch I need the following information:
1) Which Java method to call? Is it an instance method or a static?
2) How to test the implementation? I can get and deploy all of your changes
or just to call some stub methods in a specialized testcase before sending
the result to you.

?


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


A question for Jitrino.JET developers.  How hard would it be to modify the
existing Jitrino.JET code  so that the "new" opcode calls MMTk alloc()?

Thanks
--
Weldon Washburn
Intel Middleware Products Division





--
Mikhail Fursov

Re: [classlib] internationalization and new patches

[Ilya Okomin]

On 9/6/06, Paulex Yang <[EMAIL PROTECTED]> wrote:


Ilya Okomin wrote:
> When I dealt with nio_char module I found that some messages were
already
> marked with non-nls tag.
> (e.g. java.nio.charset.CharsetDecoder)
> These messages aren't described in the spec.
> Is there any reason to left them as is without internationalization?
Specific to CharsetDecoder.replaceWith(), I don't believe there is any
reason not to i18n the exception messages, I guess it was marked
"non-nls" by mistake, or just because the developer didn't like to see
the warning message;-). Please go ahead and provide patch for it.



I have the same meaning and going to make an update patch for these
messages.

Thanks,
Ilya.



> Thanks,
> Ilya.
>
> [SNIP]
>
>


--
Paulex Yang
China Software Development Lab
IBM



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





--
--
Ilya Okomin
Intel Middleware Products Division

Re: [classlib][TestNG] groups of Harmony test

[Paulex Yang]

Vladimir Ivanov wrote:

Do we really need in it? At present time tests were designed for win/unix
only.


I thought at least we have interest to port Harmony to these platforms[1].

[1] http://incubator.apache.org/harmony/roadmap.html#Porting%20Matrix

--
Paulex Yang
China Software Development Lab
IBM



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

Re: [classlib] internationalization and new patches

[Paulex Yang]

Ilya Okomin wrote:

When I dealt with nio_char module I found that some messages were already
marked with non-nls tag.
(e.g. java.nio.charset.CharsetDecoder)
These messages aren't described in the spec.
Is there any reason to left them as is without internationalization?
Specific to CharsetDecoder.replaceWith(), I don't believe there is any 
reason not to i18n the exception messages, I guess it was marked 
"non-nls" by mistake, or just because the developer didn't like to see 
the warning message;-). Please go ahead and provide patch for it.


Thanks,
Ilya.

[SNIP]





--
Paulex Yang
China Software Development Lab
IBM



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

Re: [classlib] internationalization and new patches

[Ilya Okomin]

When I dealt with nio_char module I found that some messages were already
marked with non-nls tag.
(e.g. java.nio.charset.CharsetDecoder)
These messages aren't described in the spec.
Is there any reason to left them as is without internationalization?

Thanks,
Ilya.

On 9/4/06, Ilya Okomin <[EMAIL PROTECTED]> wrote:




 On 9/4/06, Mikhail Loenko <[EMAIL PROTECTED]> wrote:
>
> We have recently starting internationalization of existing modules
> (thanks to all people involved!)
>
> Now when we submit new patches and apply old ones let's make sure that
> we don't break internationalization for the modules that were already
> internationalized!


 I've analyzed modules in Harmony that were already internationalized,
they are: luni, archive, sql.
IMHO we must don't break internationalization for the modules that were
already
internationalized but we should update them to follow the
new internationalization scheme that was discussed on harmony-dev. This
scheme supposed to be common for all modules in harmony.

Turning back to already internationalized modules..
There is nothing to do for sql module.
Archive module was partly internationalized. I've prepared patch where all
necessary messages were ported from the
o.a.h.luni.util.ExternalMessages.properties file into the
o.a.h.archive.internal.nls.messages.properties file with updated keys.
Committer who is going to apply this patch or any other patch with
internationalization for this module - should check if everything is
correct.
I suggest to do the same with luni module.

Regards,
Ilya.


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


--

--
Ilya Okomin
Intel Middleware Products Division





--
--
Ilya Okomin
Intel Middleware Products Division