Re: [doc][drlvm] The document Getting started with DRL is outdated
On the 0x21D day of Apache Harmony Nadezhda Morozova wrote: Egor, I think we're mixing things up a bit, or at least our perceptions of various docs. I'd not call what you're suggesting a tutorial - it's more of a howto doc, right? We are lucky to have Salikh write this How to write a GC? Doc - do you mean something similar for DRLVM Command-line Args Tutorial? on Wikipedia: * A _how-to_ is an informal, often short, description of how to accomplish some specific task * A _tutorial_ is a document, software, or other media created for the purpose of instruction for any of a wide variety of tasks yes, I mix those terms :) As suggested earlier, we can store drlvm+eclipse specifics on another page = see JIRA 2009. cmd options reference is on wiki, but a short howto will be marvelous - illustrating usage of common options, solving typical problems by using our vm correctly, etc. Does anybody volunteer to help? let's collect the options first. To choose between them for the howto Thank you, Nadya Morozova -Original Message- From: news [mailto:[EMAIL PROTECTED] On Behalf Of Egor Pasko Sent: Friday, November 10, 2006 4:06 PM To: harmony-dev@incubator.apache.org Subject: Re: [doc][drlvm] The document Getting started with DRL is outdated On the 0x21D day of Apache Harmony Nadezhda Morozova wrote: Alexei, Tutorials might be fine for mature projects, but I do not think ours is ready for a big flow of users yet, that would require a tutorial. we _are_ mature for a small tutorial :) So +1 for having a nice good tutorial ... one day. If there are volunteers to write the tutorial now, I'd be happy to help though. well, actually, I love tutorials too, especially the one for VIM :) some contraversal inside me..fighting..done let's then say A Short Eclipse Tutorial with Harmony, and then DRLVM Command-line Args Tutorial. Howabout that? Thank you, Nadya Morozova -Original Message- From: Fedotov, Alexei A [mailto:[EMAIL PROTECTED] Sent: Friday, November 10, 2006 1:40 PM To: harmony-dev@incubator.apache.org Subject: RE: Re: [doc][drlvm] The document Getting started with DRL is outdated Guys, I like good tutorials. I learned VIM using a tutorial. I don't need the VIM tutorial any longer, but at the beginning it was useful. +1 for maintain Getting Started as is with minor changes Why Eclipse was chosen for the tutorial? Our goal was to use Harmony for Harmony development. I liked that idea. With best regards, Alexei Fedotov, Intel Java XML Engineering -Original Message- From: news [mailto:[EMAIL PROTECTED] On Behalf Of Egor Pasko Sent: Friday, November 10, 2006 1:29 PM To: harmony-dev@incubator.apache.org Subject: Re: [doc][drlvm] The document Getting started with DRL is outdated On the 0x21D day of Apache Harmony Pavel Ozhdikhin wrote: Nadya, One more proposal about Getting Started: let's remove all current content and write something like following: To the moment we got rid of all major differences from other Java implementations, so to use DRLVM you can just build it (here goes link to readme with build instructions) and run as any other Java VM. For commonly used command-line options please look into the Wiki page (link to Salikh's page or to the document). What do you think? 1 page to hold only 4 lines of text? :) Thanks, Pavel On 10 Nov 2006 14:29:59 +0600, Egor Pasko [EMAIL PROTECTED] wrote: On the 0x21D day of Apache Harmony Nadezhda Morozova wrote: Good day to you, Egor! evening, dark and snowy evening :) What do you say about the getting started doc? I expressed it recently. General idea is that Harmony operates near the same as other JSE implementations. Almost all specifics is in extra options which we started collecting on Wiki for an extra HOWTO-like page (BTW, thanks to Salikh for starting the page). I believe, it is time to remove the Getting Started. So, +1 to Pavel Ozhdikhin here. BTW, I asked my dad to look at the website. Ideas for improvement from him: 1) site-local search is useful for a beginner. Hm, Tomcat has it with links to google search. We can have something as soon as we get to the desired TLP :) 2) it is not obvious that site misprints/problems should be reported to the mailing list. Commercial websites have something like support/suggestions mailto. We can point mailto to the mailing list :) Thank you, Nadya Morozova -Original Message- From: news [mailto:[EMAIL PROTECTED] On Behalf Of Egor Pasko Sent: Friday, November 10, 2006 8:55 AM To: harmony-dev@incubator.apache.org Subject: Re: [doc][drlvm] The document Getting started with DRL is outdated On the 0x21D day of Apache
RE: Re: [doc][drlvm] The document Getting started with DRL is outdated
Ok, I'll use http://issues.apache.org/jira/browse/HARMONY-2150 to get an initial patch for the getting started document, and we can then work to improve it. Let's make it a short page with links to wiki and maybe some how-tos. Thank you, Nadya Morozova -Original Message- From: news [mailto:[EMAIL PROTECTED] On Behalf Of Egor Pasko Sent: Monday, November 13, 2006 11:10 AM To: harmony-dev@incubator.apache.org Subject: Re: [doc][drlvm] The document Getting started with DRL is outdated On the 0x21D day of Apache Harmony Nadezhda Morozova wrote: Egor, I think we're mixing things up a bit, or at least our perceptions of various docs. I'd not call what you're suggesting a tutorial - it's more of a howto doc, right? We are lucky to have Salikh write this How to write a GC? Doc - do you mean something similar for DRLVM Command-line Args Tutorial? on Wikipedia: * A _how-to_ is an informal, often short, description of how to accomplish some specific task * A _tutorial_ is a document, software, or other media created for the purpose of instruction for any of a wide variety of tasks yes, I mix those terms :) As suggested earlier, we can store drlvm+eclipse specifics on another page = see JIRA 2009. cmd options reference is on wiki, but a short howto will be marvelous - illustrating usage of common options, solving typical problems by using our vm correctly, etc. Does anybody volunteer to help? let's collect the options first. To choose between them for the howto Thank you, Nadya Morozova -Original Message- From: news [mailto:[EMAIL PROTECTED] On Behalf Of Egor Pasko Sent: Friday, November 10, 2006 4:06 PM To: harmony-dev@incubator.apache.org Subject: Re: [doc][drlvm] The document Getting started with DRL is outdated On the 0x21D day of Apache Harmony Nadezhda Morozova wrote: Alexei, Tutorials might be fine for mature projects, but I do not think ours is ready for a big flow of users yet, that would require a tutorial. we _are_ mature for a small tutorial :) So +1 for having a nice good tutorial ... one day. If there are volunteers to write the tutorial now, I'd be happy to help though. well, actually, I love tutorials too, especially the one for VIM :) some contraversal inside me..fighting..done let's then say A Short Eclipse Tutorial with Harmony, and then DRLVM Command-line Args Tutorial. Howabout that? Thank you, Nadya Morozova -Original Message- From: Fedotov, Alexei A [mailto:[EMAIL PROTECTED] Sent: Friday, November 10, 2006 1:40 PM To: harmony-dev@incubator.apache.org Subject: RE: Re: [doc][drlvm] The document Getting started with DRL is outdated Guys, I like good tutorials. I learned VIM using a tutorial. I don't need the VIM tutorial any longer, but at the beginning it was useful. +1 for maintain Getting Started as is with minor changes Why Eclipse was chosen for the tutorial? Our goal was to use Harmony for Harmony development. I liked that idea. With best regards, Alexei Fedotov, Intel Java XML Engineering -Original Message- From: news [mailto:[EMAIL PROTECTED] On Behalf Of Egor Pasko Sent: Friday, November 10, 2006 1:29 PM To: harmony-dev@incubator.apache.org Subject: Re: [doc][drlvm] The document Getting started with DRL is outdated On the 0x21D day of Apache Harmony Pavel Ozhdikhin wrote: Nadya, One more proposal about Getting Started: let's remove all current content and write something like following: To the moment we got rid of all major differences from other Java implementations, so to use DRLVM you can just build it (here goes link to readme with build instructions) and run as any other Java VM. For commonly used command-line options please look into the Wiki page (link to Salikh's page or to the document). What do you think? 1 page to hold only 4 lines of text? :) Thanks, Pavel On 10 Nov 2006 14:29:59 +0600, Egor Pasko [EMAIL PROTECTED] wrote: On the 0x21D day of Apache Harmony Nadezhda Morozova wrote: Good day to you, Egor! evening, dark and snowy evening :) What do you say about the getting started doc? I expressed it recently. General idea is that Harmony operates near the same as other JSE implementations. Almost all specifics is in extra options which we started collecting on Wiki for an extra HOWTO-like page (BTW, thanks to Salikh for starting the page). I believe, it is time to remove the Getting Started. So, +1 to Pavel Ozhdikhin here. BTW, I asked my dad to look at the website. Ideas for improvement from him: 1) site-local search is useful for a beginner. Hm, Tomcat has it with links to google search. We can have something as soon as we get to the desired TLP :) 2) it is not obvious that site misprints/problems should be reported
Re: [general] Sun will take GPL License?
But does Apache License make JDK out of control? I don't think so:) 在 06-11-13，Geir Magnusson Jr.[EMAIL PROTECTED] 写道： Jin Mingjian wrote: GPL is not very compatible with Apache License. So, I guess Sun want to prevent Harmony from using any codes they owned?! Very Very Very... No - it was simply about control. geir 在 06-11-13，LvJimmy，Jing[EMAIL PROTECTED] 写道： Oops！GPL v2? I can hardly believe it! Does it mean, all codes using Sun's JDK have to take GPL? Crazy and unbelieveable... However I like GPL ;) 在06-11-13，Jin Mingjian [EMAIL PROTECTED] 写道： Mark Reinhold's blog has confirmed this news. He said: ... Sun is open-sourcing its entire Java stack―ME, SE, and EE―under the GNU General Public License, version 2. The license choice―which has taken many by surprise (gotcha!)―is a giant leap. For more on the big picture, including a link to tomorrow's webcast announcement, please see http://sun.com/opensource/java. ... link: http://blogs.sun.com/mr/entry/one_giant_leap -- Best Regards! Jimmy, Jing Lv China Software Development Lab, IBM
Re: [general] Sun will take GPL License?
Jin Mingjian wrote: But does Apache License make JDK out of control? I don't think so:) I think that it just means that it helps them limit the number of proprietary forks of the code. But I'm not worried about that being harmful no matter what the license - the market doesn't want broken Java. geir 在 06-11-13，Geir Magnusson Jr.[EMAIL PROTECTED] 写道： Jin Mingjian wrote: GPL is not very compatible with Apache License. So, I guess Sun want to prevent Harmony from using any codes they owned?! Very Very Very... No - it was simply about control. geir 在 06-11-13，LvJimmy，Jing[EMAIL PROTECTED] 写道： Oops！GPL v2? I can hardly believe it! Does it mean, all codes using Sun's JDK have to take GPL? Crazy and unbelieveable... However I like GPL ;) 在06-11-13，Jin Mingjian [EMAIL PROTECTED] 写道： Mark Reinhold's blog has confirmed this news. He said: ... Sun is open-sourcing its entire Java stack―ME, SE, and EE―under the GNU General Public License, version 2. The license choice―which has taken many by surprise (gotcha!)―is a giant leap. For more on the big picture, including a link to tomorrow's webcast announcement, please see http://sun.com/opensource/java. ... link: http://blogs.sun.com/mr/entry/one_giant_leap -- Best Regards! Jimmy, Jing Lv China Software Development Lab, IBM
Re: [drlvm] [ipf] I suggest a series of patches for ipf code generator
Hi Egor,
good point about multimap :) I have fixed it and going to submit new patch
in Jira.
IpfEmitter is code of Igor and he already has patch for it. I suggest to
wait for him.
Thank you,
Konstantin
Egor Pasko [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
On the 0x21D day of Apache Harmony Konstantin Anisimov wrote:
Hi all,
I have created new Jira request - HARMONY-2139. It is about:
1. Added operand coalescer. It is integrated with register allocator.
2. I finished migration on STL with memory manager support.
Could someone review it?
here is my review:
(1)
patch applies well, does not affect IA-32, x86_64 builds
(2)
Migration to MemoryManager based STL is of special goodness. Thank you!
But some of not MemManaged usages are not wiped out yet:
IpfType.h: multimap
IpfEmitter.{h|cpp}: vector bitset
could you eliminate them for unification, please?
(3)
some logging code is commented-out, but this should be OK for now
Thank you,
Konstantin
Konstantin Anisimov [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Hi all,
I suggest new patch from the series Igor introdusced.
1. To move direct predicated calls in separete node. It allows to have
under
predicate short branch instruction instead of call and thus
reduce possible misprediction penalty.
2. I have implemented new node merging algorithm. It is more effective
than
previouc one and besides purging empty nodes.
All changes made in Code layouting and I suggest integrate them in one
patch.
Thank you,
Konstantin
Igor Chebykin [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Hello all,
I suggest a short series of patches for drlvm ipf code generator.
We have some improvements for jitrino/ipf
and would like to commit its to harmony.
All patches will change only vm/jitrino/src/codegenerator/ipf/* files,
therefore ia32 remains OK.
The first patch is about 67k size and contains following files:
IpfCfg.h, IpfCfg.cpp
methods added in Edge and Node classes
IpfCodeLayouter.h, IpfCodeLayouter.cpp
new BotomUp algorithm implementation
IpfEmitter.h, IpfEmitter.cpp
minor changes in logging, Emitter::registerDirectCall() and
debugging support
IpfIrPrinter.h, IpfIrPrinter.cpp
added method to print Node chains
IpfType.h
types to support Node chains added
IpfCfgVerifier.cpp
method cfg.getArgs() deprecated
IpfInst.cpp
methods to identify inst kind added (isBr, isCall ?)
IpfRegisterAllocator.cpp
minor changes in logging
Thanks,
Igor.
--
Igor Chebykin, Intel Middleware Products Division
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Egor Pasko
Re: [drlvm][classlib] thread library - let there be one!
On 11/10/06, Weldon Washburn [EMAIL PROTECTED] wrote: hmm it seems that we need to create kernel natives, the C version of java kernel classes. The expectation is that the JVM supplier would write their own kernel natives. And the classlib native code would only call kernel natives. Thoughts? This would be an interesting design choice, but not how it works right now. The problem with this approach could be that, each VM, while preserving the standard Java interface for kernel class libraries (which is governed by J2SE spec), may choose to have a different interface for kernel natives. Relationship between the kernel Java classes and native VM code may be very different. (As a corner case, consider VM that has a little or no native code for kernel classes). Therefore, it might be difficult to standardize such native interface to kernel's classes native code. Classlib, in addition to the kernel classes set, is currently using VMI interface to access some of native VM services (such as getting the portlib). The problem could be that, classlib (for ex, see zipsup.c in achieve module) is using hythread services bypassing that interface. Hythread is currently used directly by the classlib, portlib and VM code. If we think this has to be the high level threading library (which would export exactly the same sync objects as the ones used for Java monitors) provided by VM, then may be it makes sense to export hythread to the classlib's code using VMI interface just like we do this for the HyPortLibrary (see luni/src/main/native/include/shared/vmi.h)? Thanks, Andrey. On 11/10/06, Andrey Chernyshev [EMAIL PROTECTED] wrote: On 10/26/06, Angela Lin [EMAIL PROTECTED] wrote: On 10/24/06, Weldon Washburn [EMAIL PROTECTED] wrote: If an arbitrary commercial JVM decided to use classlib, will it need to be modified to reflect the existing Harmony Classlib threading model? This is the case no matter how you split the thread library. Whatever interface you specify for the classlib will need to be supported by the VM. Also, does this mean VM design is constrained by classlib design? And classlib design is constrained by J9 design? The classlib and the VM have certain dependencies on each other. This is not a J9-specific issue. I would aim for a thread API that is generic enough to support multiple implementations. I think it may be hard (if possible at all) to create high-level threading library which would make just every VM happy. For instance, DRLVM has a complex synchronization scheme with garbage collector which is built into the threading library (for example, each time thread goes into wait state, it must instruct the GC that the thread can be garbage collected). There also could be VM-specific optimizations for monitors which are tied to the object layout used in a particular VM. Finally, there might be pure-Java written VM's which may choose to implement threading library almost entirely in Java (may be on top of j.u.concurrent API ?), borrowing probably only park/unpark, atomic and may be sort of fork operations from the native code. How could we have a threading library which will work equally for all VM's? I agree that bypassing layer (2) by the classlib can be undesirable because of loosing track for thread/lock states. So it seems that: - both VM and classlib need to use single thread library, and at the same level (or, saying that differently, Java code and native code from classlib should use same threading lib); - threading lib is likely be VM-specific (consider DRLVM as an example) If we agree with the above, doesn't it just mean that the hythr must be declared as a part of VM? Classlib may probably continue to keep a stub library for the compilation purposes. But there must be the possibility for other VM's to easily replace it with it's own version. I guess we do something similar with the luni-kernel-stubs.jar. Mature VMs that switch to the Harmony classlib would probably implement a portability layer between the existing VM's thread model and the Harmony thread API. I guess mature VM's would likely to have their own very carefully written and optimized threading libraries, integrated with GC, JIT e.t.c. It will be easier for them to provide a suitable interface for classlib rather than rewrite VM on top of hythread, no matter how perfect is it. Has anyone considered how ThreadMXBean would be supported by the proposed classlib thread API subset? May be ThreadMXBean is just a good candidate for the kernel class set? At least the spec says interface for the thread system of the Java virtual machine. I guess other MXBeans are also interfaces to some of VM services. Thanks, Andrey. On 10/24/06, Angela Lin [EMAIL PROTECTED] wrote: Consider the group of monitor-related functionality: enter/exit, wait/notify, and interrupt. The implementations of these functions are
Re: [general] Sun will take GPL License?
Java is still the trademark of Sun:) So I think we can do control though JCP. BTW, I like GPL as well:) Whatever, this is big step for Java community. 在 06-11-13，Geir Magnusson Jr.[EMAIL PROTECTED] 写道： Jin Mingjian wrote: But does Apache License make JDK out of control? I don't think so:) I think that it just means that it helps them limit the number of proprietary forks of the code. But I'm not worried about that being harmful no matter what the license - the market doesn't want broken Java. geir 在 06-11-13，Geir Magnusson Jr.[EMAIL PROTECTED] 写道： Jin Mingjian wrote: GPL is not very compatible with Apache License. So, I guess Sun want to prevent Harmony from using any codes they owned?! Very Very Very... No - it was simply about control. geir 在 06-11-13，LvJimmy，Jing[EMAIL PROTECTED] 写道： Oops！GPL v2? I can hardly believe it! Does it mean, all codes using Sun's JDK have to take GPL? Crazy and unbelieveable... However I like GPL ;) 在06-11-13，Jin Mingjian [EMAIL PROTECTED] 写道： Mark Reinhold's blog has confirmed this news. He said: ... Sun is open-sourcing its entire Java stack―ME, SE, and EE―under the GNU General Public License, version 2. The license choice―which has taken many by surprise (gotcha!)―is a giant leap. For more on the big picture, including a link to tomorrow's webcast announcement, please see http://sun.com/opensource/java. ... link: http://blogs.sun.com/mr/entry/one_giant_leap -- Best Regards! Jimmy, Jing Lv China Software Development Lab, IBM
Re: [general] Sun will take GPL License?
It's actually Sun's trademark, not the JCPs. And I don't like the GPL - but that's ok, because there are choices for people. Apache Harmony or Sun's OpenJDK project. geir Jin Mingjian wrote: Java is still the trademark of Sun:) So I think we can do control though JCP. BTW, I like GPL as well:) Whatever, this is big step for Java community. 在 06-11-13，Geir Magnusson Jr.[EMAIL PROTECTED] 写道： Jin Mingjian wrote: But does Apache License make JDK out of control? I don't think so:) I think that it just means that it helps them limit the number of proprietary forks of the code. But I'm not worried about that being harmful no matter what the license - the market doesn't want broken Java. geir 在 06-11-13，Geir Magnusson Jr.[EMAIL PROTECTED] 写道： Jin Mingjian wrote: GPL is not very compatible with Apache License. So, I guess Sun want to prevent Harmony from using any codes they owned?! Very Very Very... No - it was simply about control. geir 在 06-11-13，LvJimmy，Jing[EMAIL PROTECTED] 写道： Oops！GPL v2? I can hardly believe it! Does it mean, all codes using Sun's JDK have to take GPL? Crazy and unbelieveable... However I like GPL ;) 在06-11-13，Jin Mingjian [EMAIL PROTECTED] 写道： Mark Reinhold's blog has confirmed this news. He said: ... Sun is open-sourcing its entire Java stack―ME, SE, and EE―under the GNU General Public License, version 2. The license choice―which has taken many by surprise (gotcha!)―is a giant leap. For more on the big picture, including a link to tomorrow's webcast announcement, please see http://sun.com/opensource/java. ... link: http://blogs.sun.com/mr/entry/one_giant_leap -- Best Regards! Jimmy, Jing Lv China Software Development Lab, IBM
Re: [classlib][sql] SerialJavaObject constructor throws SerialException when the object is unserializable?
I guess that Sun has implemented some behavior and some exception
could be thrown by that implementation. Then they wrapped that exception
by SerialException and documented in the spec ;)
You might want to implement it without exception throwing and if we find an
inconsistency later -- fix it
Thanks,
Mikhail
2006/11/12, Andrew Zhang [EMAIL PROTECTED]:
Hi folks,
I'm confused by javax.sql.rowset.serial.SerialJavaObject spec. The spec of
SerialJavaObject constructor says throws SerialException if the object is
found to be unserializable. It also mentions Static or transient fields
cannot be serialized; an attempt to serialize them will result in a
SerialException object being thrown. . Does it mean to throw
SerialException if the object doesn't implement Serializable or it contains
static/transient fields? I tried some tests[1], but SerialException is never
thrown. Am I missing something? Thank you in advance for your help!
[1] SerialJavaObject constructor test case:
public void test_Constructor() throws Exception {
Object obj = new NonSerializableClass();
SerialJavaObject sjo = new SerialJavaObject(obj);
}
static class NonSerializableClass {
public static int i;
public static Thread t;
public transient String s;
NonSerializableClass() {
}
}
--
Best regards,
Andrew Zhang
Re: [drlvm] [ipf] I suggest a series of patches for ipf code generator
On the 0x220 day of Apache Harmony Konstantin Anisimov wrote:
Hi Egor,
good point about multimap :) I have fixed it and going to submit new patch
in Jira.
thanks for the new patch! I'll say that it is fine in JIRA for
comitters to be easier at following The Idea of the issue
IpfEmitter is code of Igor and he already has patch for it. I suggest to
wait for him.
OK, let Igor do it as he is more familiar with the code..
Thank you,
Konstantin
Egor Pasko [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
On the 0x21D day of Apache Harmony Konstantin Anisimov wrote:
Hi all,
I have created new Jira request - HARMONY-2139. It is about:
1. Added operand coalescer. It is integrated with register allocator.
2. I finished migration on STL with memory manager support.
Could someone review it?
here is my review:
(1)
patch applies well, does not affect IA-32, x86_64 builds
(2)
Migration to MemoryManager based STL is of special goodness. Thank you!
But some of not MemManaged usages are not wiped out yet:
IpfType.h: multimap
IpfEmitter.{h|cpp}: vector bitset
could you eliminate them for unification, please?
(3)
some logging code is commented-out, but this should be OK for now
Thank you,
Konstantin
Konstantin Anisimov [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Hi all,
I suggest new patch from the series Igor introdusced.
1. To move direct predicated calls in separete node. It allows to have
under
predicate short branch instruction instead of call and thus
reduce possible misprediction penalty.
2. I have implemented new node merging algorithm. It is more effective
than
previouc one and besides purging empty nodes.
All changes made in Code layouting and I suggest integrate them in one
patch.
Thank you,
Konstantin
Igor Chebykin [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Hello all,
I suggest a short series of patches for drlvm ipf code generator.
We have some improvements for jitrino/ipf
and would like to commit its to harmony.
All patches will change only vm/jitrino/src/codegenerator/ipf/* files,
therefore ia32 remains OK.
The first patch is about 67k size and contains following files:
IpfCfg.h, IpfCfg.cpp
methods added in Edge and Node classes
IpfCodeLayouter.h, IpfCodeLayouter.cpp
new BotomUp algorithm implementation
IpfEmitter.h, IpfEmitter.cpp
minor changes in logging, Emitter::registerDirectCall() and
debugging support
IpfIrPrinter.h, IpfIrPrinter.cpp
added method to print Node chains
IpfType.h
types to support Node chains added
IpfCfgVerifier.cpp
method cfg.getArgs() deprecated
IpfInst.cpp
methods to identify inst kind added (isBr, isCall ?)
IpfRegisterAllocator.cpp
minor changes in logging
Thanks,
Igor.
--
Igor Chebykin, Intel Middleware Products Division
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Egor Pasko
--
Egor Pasko
RE: [classlib][swing] Serialization of Swing classes
-Original Message- From: Tim Ellison [mailto:[EMAIL PROTECTED] Sent: Sunday, November 12, 2006 1:12 AM To: harmony-dev@incubator.apache.org Subject: Re: [classlib][swing] Serialization of Swing classes Nathan Beyer wrote: Runtime optimization - I'm not positive of this, nor do I completely understand the actual affect, but wouldn't explicit 'serialVersionUID' fields mean that when those classes are actually serialized, a UID wouldn't need to be generated at runtime, correct? Now, I'll be the first to admit, this is a micro optimization, so it doesn't carry to much weight. However, I am curious about the details of the reality behind this thought, so if anyone knows, please post. Take a look at the effect of java.io.ObjectStreamClass#lookup(Class) for types that have a SUID field and those that don't. The actual work is done in ObjectStreamClass#computeSerialVersionUID(Class, Field[]), which scans the fields looking for a serialVersionUID field first, and computing it if not found using some non-trivial algorithm. The lookup result is cached, so any saving will be only on the first time the class is seen. Whether the computation is noticeable will depend upon the set of classes of objects being serialized as well as the presence (or absence) of the SUID field. Actually I don't mind having SUIDs declared in classes. Though IMHO without declaring this field, we communicate to developers serialized form of this class is not guaranteed to deserialize correctly. OTOH having looked through the methods Tim pointed, I can say that if classes declare SUID and one tries to serialize an object, there'll be no time spent to compute SUID during execution thus improving performance a little. Therefore I'm inclined to declare SUID rather than using @SuppressWarning(serial). However it may be worth to add a comment similar to that in the JavaDoc. What do you think? Regards, Alexey. Regards, Tim -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. -- Alexey A. Ivanov Intel Enterprise Solutions Software Division
Re: [drlvm][threading] Should hythread_monitor_init() aquire the monitor?
It turned out that DRL implementation of hythread_monitor_init / hythread_monitor_init_with_name initializes and acquires a monitor. Eugeni, Both drlvm and classlib hythread work this way. This original hythread design that for compatibility reason was implemented in drlvm. Thanks Artem On 11/10/06, Evgueni Brevnov [EMAIL PROTECTED] wrote: Hi, While investigating deadlock scenario which is described in HARMONY-2006 I found out one interesting thing. It turned out that DRL implementation of hythread_monitor_init / hythread_monitor_init_with_name initializes and acquires a monitor. Original spec reads: Acquire and initialize a new monitor from the threading library AFAIU that doesn't mean to lock the monitor but get it from the threading library. So the hythread_monitor_init should not lock the monitor. Could somebody comment on that? Thanks Evgueni
Re: [doc][drlvm] The document Getting started with DRL is outdated
On the 0x220 day of Apache Harmony Nadezhda Morozova wrote: Ok, I'll use http://issues.apache.org/jira/browse/HARMONY-2150 to get an initial patch for the getting started document, and we can then work to improve it. OK, I am watching it Let's make it a short page with links to wiki and maybe some how-tos. To summarize: * we agreed that there will be no eclipse screenshots (they are for eclipse+drlvm page) * we agreed that there should be something like see what kind of links we have Am I right? Thank you, Nadya Morozova -Original Message- From: news [mailto:[EMAIL PROTECTED] On Behalf Of Egor Pasko Sent: Monday, November 13, 2006 11:10 AM To: harmony-dev@incubator.apache.org Subject: Re: [doc][drlvm] The document Getting started with DRL is outdated On the 0x21D day of Apache Harmony Nadezhda Morozova wrote: Egor, I think we're mixing things up a bit, or at least our perceptions of various docs. I'd not call what you're suggesting a tutorial - it's more of a howto doc, right? We are lucky to have Salikh write this How to write a GC? Doc - do you mean something similar for DRLVM Command-line Args Tutorial? on Wikipedia: * A _how-to_ is an informal, often short, description of how to accomplish some specific task * A _tutorial_ is a document, software, or other media created for the purpose of instruction for any of a wide variety of tasks yes, I mix those terms :) As suggested earlier, we can store drlvm+eclipse specifics on another page = see JIRA 2009. cmd options reference is on wiki, but a short howto will be marvelous - illustrating usage of common options, solving typical problems by using our vm correctly, etc. Does anybody volunteer to help? let's collect the options first. To choose between them for the howto Thank you, Nadya Morozova -Original Message- From: news [mailto:[EMAIL PROTECTED] On Behalf Of Egor Pasko Sent: Friday, November 10, 2006 4:06 PM To: harmony-dev@incubator.apache.org Subject: Re: [doc][drlvm] The document Getting started with DRL is outdated On the 0x21D day of Apache Harmony Nadezhda Morozova wrote: Alexei, Tutorials might be fine for mature projects, but I do not think ours is ready for a big flow of users yet, that would require a tutorial. we _are_ mature for a small tutorial :) So +1 for having a nice good tutorial ... one day. If there are volunteers to write the tutorial now, I'd be happy to help though. well, actually, I love tutorials too, especially the one for VIM :) some contraversal inside me..fighting..done let's then say A Short Eclipse Tutorial with Harmony, and then DRLVM Command-line Args Tutorial. Howabout that? Thank you, Nadya Morozova -Original Message- From: Fedotov, Alexei A [mailto:[EMAIL PROTECTED] Sent: Friday, November 10, 2006 1:40 PM To: harmony-dev@incubator.apache.org Subject: RE: Re: [doc][drlvm] The document Getting started with DRL is outdated Guys, I like good tutorials. I learned VIM using a tutorial. I don't need the VIM tutorial any longer, but at the beginning it was useful. +1 for maintain Getting Started as is with minor changes Why Eclipse was chosen for the tutorial? Our goal was to use Harmony for Harmony development. I liked that idea. With best regards, Alexei Fedotov, Intel Java XML Engineering -Original Message- From: news [mailto:[EMAIL PROTECTED] On Behalf Of Egor Pasko Sent: Friday, November 10, 2006 1:29 PM To: harmony-dev@incubator.apache.org Subject: Re: [doc][drlvm] The document Getting started with DRL is outdated On the 0x21D day of Apache Harmony Pavel Ozhdikhin wrote: Nadya, One more proposal about Getting Started: let's remove all current content and write something like following: To the moment we got rid of all major differences from other Java implementations, so to use DRLVM you can just build it (here goes link to readme with build instructions) and run as any other Java VM. For commonly used command-line options please look into the Wiki page (link to Salikh's page or to the document). What do you think? 1 page to hold only 4 lines of text? :) Thanks, Pavel On 10 Nov 2006 14:29:59 +0600, Egor Pasko [EMAIL PROTECTED] wrote: On the 0x21D day of Apache Harmony Nadezhda Morozova wrote: Good day to you, Egor! evening, dark and snowy evening :) What do you say about the getting started doc? I expressed it recently. General idea is that Harmony operates near the same as other JSE implementations. Almost all specifics is in extra options which we started collecting on Wiki for an extra HOWTO-like page (BTW, thanks to Salikh for starting the page).
RE: Re: [doc][drlvm] The document Getting started with DRL is outdated
-Original Message- From: news [mailto:[EMAIL PROTECTED] On Behalf Of Egor Pasko Sent: Monday, November 13, 2006 12:40 PM To: harmony-dev@incubator.apache.org Subject: Re: [doc][drlvm] The document Getting started with DRL is outdated On the 0x220 day of Apache Harmony Nadezhda Morozova wrote: Ok, I'll use http://issues.apache.org/jira/browse/HARMONY-2150 to get an initial patch for the getting started document, and we can then work to improve it. OK, I am watching it Let's make it a short page with links to wiki and maybe some how-tos. To summarize: * we agreed that there will be no eclipse screenshots (they are for eclipse+drlvm page) * we agreed that there should be something like see what kind of links we have Am I right? [Nadya] Yop, quite right. An additional enhancement would be to comment out copyrights and update info that is incorrect. Not sure I'll fix everything, but can give a start. Thanks for all your help. Thank you, Nadya Morozova -Original Message- From: news [mailto:[EMAIL PROTECTED] On Behalf Of Egor Pasko Sent: Monday, November 13, 2006 11:10 AM To: harmony-dev@incubator.apache.org Subject: Re: [doc][drlvm] The document Getting started with DRL is outdated On the 0x21D day of Apache Harmony Nadezhda Morozova wrote: Egor, I think we're mixing things up a bit, or at least our perceptions of various docs. I'd not call what you're suggesting a tutorial - it's more of a howto doc, right? We are lucky to have Salikh write this How to write a GC? Doc - do you mean something similar for DRLVM Command-line Args Tutorial? on Wikipedia: * A _how-to_ is an informal, often short, description of how to accomplish some specific task * A _tutorial_ is a document, software, or other media created for the purpose of instruction for any of a wide variety of tasks yes, I mix those terms :) As suggested earlier, we can store drlvm+eclipse specifics on another page = see JIRA 2009. cmd options reference is on wiki, but a short howto will be marvelous - illustrating usage of common options, solving typical problems by using our vm correctly, etc. Does anybody volunteer to help? let's collect the options first. To choose between them for the howto Thank you, Nadya Morozova -Original Message- From: news [mailto:[EMAIL PROTECTED] On Behalf Of Egor Pasko Sent: Friday, November 10, 2006 4:06 PM To: harmony-dev@incubator.apache.org Subject: Re: [doc][drlvm] The document Getting started with DRL is outdated On the 0x21D day of Apache Harmony Nadezhda Morozova wrote: Alexei, Tutorials might be fine for mature projects, but I do not think ours is ready for a big flow of users yet, that would require a tutorial. we _are_ mature for a small tutorial :) So +1 for having a nice good tutorial ... one day. If there are volunteers to write the tutorial now, I'd be happy to help though. well, actually, I love tutorials too, especially the one for VIM :) some contraversal inside me..fighting..done let's then say A Short Eclipse Tutorial with Harmony, and then DRLVM Command-line Args Tutorial. Howabout that? Thank you, Nadya Morozova -Original Message- From: Fedotov, Alexei A [mailto:[EMAIL PROTECTED] Sent: Friday, November 10, 2006 1:40 PM To: harmony-dev@incubator.apache.org Subject: RE: Re: [doc][drlvm] The document Getting started with DRL is outdated Guys, I like good tutorials. I learned VIM using a tutorial. I don't need the VIM tutorial any longer, but at the beginning it was useful. +1 for maintain Getting Started as is with minor changes Why Eclipse was chosen for the tutorial? Our goal was to use Harmony for Harmony development. I liked that idea. With best regards, Alexei Fedotov, Intel Java XML Engineering -Original Message- From: news [mailto:[EMAIL PROTECTED] On Behalf Of Egor Pasko Sent: Friday, November 10, 2006 1:29 PM To: harmony-dev@incubator.apache.org Subject: Re: [doc][drlvm] The document Getting started with DRL is outdated On the 0x21D day of Apache Harmony Pavel Ozhdikhin wrote: Nadya, One more proposal about Getting Started: let's remove all current content and write something like following: To the moment we got rid of all major differences from other Java implementations, so to use DRLVM you can just build it (here goes link to readme with build instructions) and run as any other Java VM. For commonly used command-line options please look into the Wiki page (link to Salikh's page or to the document). What do you think? 1 page to hold only 4 lines of text? :) Thanks, Pavel On 10 Nov 2006 14:29:59 +0600, Egor Pasko [EMAIL PROTECTED] wrote: On the 0x21D day of Apache Harmony Nadezhda Morozova wrote: Good day
Re: [drlvm] drlvm and gdb and shared libraries
On the 0x220 day of Apache Harmony Geir Magnusson, Jr. wrote: I have a dumb question - I was playing today with a toy launcher for DRLVM working out some embedding issues, and for the life of me, I couldn't get dgb to ever let me break on anything in a shared library. I loaded the vm via dlopen() an dlsym(), and the code runs fine. But even build in debug, I couldn't ever specify a breakpoint in a shared lib even after it was loaded. has anyone run across this? you cannot enable a breakpoint until the library is loaded. Just wait until it is loaded. I wrote [1] to help with that. Hope it helps :) [1] http://wiki.apache.org/harmony/Debugging%20DRLVM%20with%20GDB%20on%20Linux -- Egor Pasko
Re: [doc][drlvm] The document Getting started with DRL is outdated
On the 0x220 day of Apache Harmony Nadezhda Morozova wrote: -Original Message- From: news [mailto:[EMAIL PROTECTED] On Behalf Of Egor Pasko Sent: Monday, November 13, 2006 12:40 PM To: harmony-dev@incubator.apache.org Subject: Re: [doc][drlvm] The document Getting started with DRL is outdated On the 0x220 day of Apache Harmony Nadezhda Morozova wrote: Ok, I'll use http://issues.apache.org/jira/browse/HARMONY-2150 to get an initial patch for the getting started document, and we can then work to improve it. OK, I am watching it Let's make it a short page with links to wiki and maybe some how-tos. To summarize: * we agreed that there will be no eclipse screenshots (they are for eclipse+drlvm page) * we agreed that there should be something like see what kind of links we have Am I right? [Nadya] Yop, quite right. An additional enhancement would be to comment out copyrights and update info that is incorrect. remove these annoyed substances? I am not an expert in copyright law, not sure we can remove them. But copyright notices are not what I desire to look at on the getting started page. Not sure I'll fix everything, but can give a start. Thanks for all your help. u r welcome Thank you, Nadya Morozova -Original Message- From: news [mailto:[EMAIL PROTECTED] On Behalf Of Egor Pasko Sent: Monday, November 13, 2006 11:10 AM To: harmony-dev@incubator.apache.org Subject: Re: [doc][drlvm] The document Getting started with DRL is outdated On the 0x21D day of Apache Harmony Nadezhda Morozova wrote: Egor, I think we're mixing things up a bit, or at least our perceptions of various docs. I'd not call what you're suggesting a tutorial - it's more of a howto doc, right? We are lucky to have Salikh write this How to write a GC? Doc - do you mean something similar for DRLVM Command-line Args Tutorial? on Wikipedia: * A _how-to_ is an informal, often short, description of how to accomplish some specific task * A _tutorial_ is a document, software, or other media created for the purpose of instruction for any of a wide variety of tasks yes, I mix those terms :) As suggested earlier, we can store drlvm+eclipse specifics on another page = see JIRA 2009. cmd options reference is on wiki, but a short howto will be marvelous - illustrating usage of common options, solving typical problems by using our vm correctly, etc. Does anybody volunteer to help? let's collect the options first. To choose between them for the howto Thank you, Nadya Morozova -Original Message- From: news [mailto:[EMAIL PROTECTED] On Behalf Of Egor Pasko Sent: Friday, November 10, 2006 4:06 PM To: harmony-dev@incubator.apache.org Subject: Re: [doc][drlvm] The document Getting started with DRL is outdated On the 0x21D day of Apache Harmony Nadezhda Morozova wrote: Alexei, Tutorials might be fine for mature projects, but I do not think ours is ready for a big flow of users yet, that would require a tutorial. we _are_ mature for a small tutorial :) So +1 for having a nice good tutorial ... one day. If there are volunteers to write the tutorial now, I'd be happy to help though. well, actually, I love tutorials too, especially the one for VIM :) some contraversal inside me..fighting..done let's then say A Short Eclipse Tutorial with Harmony, and then DRLVM Command-line Args Tutorial. Howabout that? Thank you, Nadya Morozova -Original Message- From: Fedotov, Alexei A [mailto:[EMAIL PROTECTED] Sent: Friday, November 10, 2006 1:40 PM To: harmony-dev@incubator.apache.org Subject: RE: Re: [doc][drlvm] The document Getting started with DRL is outdated Guys, I like good tutorials. I learned VIM using a tutorial. I don't need the VIM tutorial any longer, but at the beginning it was useful. +1 for maintain Getting Started as is with minor changes Why Eclipse was chosen for the tutorial? Our goal was to use Harmony for Harmony development. I liked that idea. With best regards, Alexei Fedotov, Intel Java XML Engineering -Original Message- From: news [mailto:[EMAIL PROTECTED] On Behalf Of Egor Pasko Sent: Friday, November 10, 2006 1:29 PM To: harmony-dev@incubator.apache.org Subject: Re: [doc][drlvm] The document Getting started with DRL is outdated On the 0x21D day of Apache Harmony Pavel Ozhdikhin wrote: Nadya, One more proposal about Getting Started: let's remove all current content and write something like following: To the moment we got rid of all major differences from other Java implementations, so to use DRLVM you can just build it (here goes link to readme with build instructions)
[drlvm][threading] Which group to choose for new thread?
Hi community, I'd like to discuss one particular feature of DRL threading library with you. TM provides four interface functions that can be used to create a new native thread or attach existing one to TM. Here they are: 1. hythread_create(hythread_t *handle, UDATA stacksize, UDATA priority, UDATA suspend, hythread_entrypoint_t entrypoint, void *entryarg); 2. hythread_attach (hythread_t *handle); 3. hythread_create_with_group (hythread_t *ret_thread, hythread_group_t group, UDATA stacksize, UDATA priority, UDATA suspend, hythread_entrypoint_t func, void *data); 4.hythread_attach_to_group (hythread_t *handle, hythread_group_t group); As I understand the 1. 2. are mandatory for any TM implementation. The 3. 4. are DRL extenstion. The difference between 1 and 3, 2 and 4 is that the later one takes one additional group parameter. This parameter allows to put a thread in any particular group. Besides that TM manages one default group. This is special group to track all java threads for suspension and enumeration purposes. Any thread created/attached using 1. or 2. appears in the default group as well as if null is specified as group parameter to 3. and 4. This is how current DRL TM works. Such scheme works fine until used properly. But I see the following problems/limitations which users can experience. a) Any NATIVE thread created/attached using 1. or 2. (3. and 4. with null group) resides in the java group among all other java threads running in the VM. These native threads are iterated each time GC (or something else) suspends and enumerates java threads. b) If someone creates a new thread using 3. with non null group and later associates that thread with java thread then it will never be enumerated. In other words we have java thread which is not stopped/enumerated during GC. c) Any particular thread can't exist in more than one group simultaneously. It is possible when threads should be grouped by different properties. I'd like to know if you think it SHOULD BE FIXED or it is OK to go with it. One alternative solution could be to have two internal groups. One for keeping native threads and another one for java threads. Each thread exists in one of these groups in any particular time. Instead of 3. and 4. TM will provide hythread_group_add hythread_group_remove. It allows to put one thread into different groups with special property. Such solution has a little bit more complicated implementation but seems to be more convenient and consistent. I appreciate any ideas/comments. Thanks Evgueni
Re: [drlvm][threading] Should hythread_monitor_init() aquire the monitor?
Hello Artem, Are you 100% sure? I've looked at the classlib's implementation and can't find where the monitor is acquired. Moreover if you look at the initializeSignalTools() located in modules\portlib\src\main\native\port\linux\hysignal.c you will find that it initializes new monitors with hyhtread_monitor_init_with_name and never frees these monitors. That turned out to be the reason of a deadlock in HARMONY-2006. Thanks Evgueni On 11/13/06, Artem Aliev [EMAIL PROTECTED] wrote: It turned out that DRL implementation of hythread_monitor_init / hythread_monitor_init_with_name initializes and acquires a monitor. Eugeni, Both drlvm and classlib hythread work this way. This original hythread design that for compatibility reason was implemented in drlvm. Thanks Artem On 11/10/06, Evgueni Brevnov [EMAIL PROTECTED] wrote: Hi, While investigating deadlock scenario which is described in HARMONY-2006 I found out one interesting thing. It turned out that DRL implementation of hythread_monitor_init / hythread_monitor_init_with_name initializes and acquires a monitor. Original spec reads: Acquire and initialize a new monitor from the threading library AFAIU that doesn't mean to lock the monitor but get it from the threading library. So the hythread_monitor_init should not lock the monitor. Could somebody comment on that? Thanks Evgueni
Re: [drlvm][threading] Should hythread_monitor_init() aquire the monitor?
Could someone familiar with classlib's implementation comment on that ? Thanks in advance. Evgueni On 11/13/06, Evgueni Brevnov [EMAIL PROTECTED] wrote: Hello Artem, Are you 100% sure? I've looked at the classlib's implementation and can't find where the monitor is acquired. Moreover if you look at the initializeSignalTools() located in modules\portlib\src\main\native\port\linux\hysignal.c you will find that it initializes new monitors with hyhtread_monitor_init_with_name and never frees these monitors. That turned out to be the reason of a deadlock in HARMONY-2006. Thanks Evgueni On 11/13/06, Artem Aliev [EMAIL PROTECTED] wrote: It turned out that DRL implementation of hythread_monitor_init / hythread_monitor_init_with_name initializes and acquires a monitor. Eugeni, Both drlvm and classlib hythread work this way. This original hythread design that for compatibility reason was implemented in drlvm. Thanks Artem On 11/10/06, Evgueni Brevnov [EMAIL PROTECTED] wrote: Hi, While investigating deadlock scenario which is described in HARMONY-2006 I found out one interesting thing. It turned out that DRL implementation of hythread_monitor_init / hythread_monitor_init_with_name initializes and acquires a monitor. Original spec reads: Acquire and initialize a new monitor from the threading library AFAIU that doesn't mean to lock the monitor but get it from the threading library. So the hythread_monitor_init should not lock the monitor. Could somebody comment on that? Thanks Evgueni
Re: [crypto] SHA-1 not implemented?
Sure, see https://issues.apache.org/jira/browse/HARMONY-2163
Thanks,
Yuri.
On 11/10/06, Tim Ellison [EMAIL PROTECTED] wrote:
Good catch Yuri -- please log it into JIRA.
Regards,
Tim
Yuri Dolgov wrote:
Hello,
I've made an investigation and found out the root of the problem.
It seems that eclipse test in DaCapo benchmarks canges value of *
java.home* system property to .\scratch\dummyjre. It affects
initialization of Security class in java.security module which loads
java.security file from *java.home*/lib/security directory.
This is potential security gap since a person could change *java.home*
value
before Security class initialization and load malicious java.securityfile.
The following test demonstrates the described behavior:
import java.security.MessageDigest;
public class Test {
public static void main (String[] args) {
try {
System.setProperty(java.home, foo/path);
MessageDigest md = MessageDigest.getInstance (SHA-1);
} catch (Exception e) {
e.printStackTrace();
}
}
}
Yuri Dolgov
On 11/10/06, Tim Ellison [EMAIL PROTECTED] wrote:
Robin Garner wrote:
Stefano Mazzocchi wrote:
from Robin's latest runs
http://cs.anu.edu.au/people/Robin.Garner/dacapo/regression/results-20061110/DRLVM/eclipse.small.log
there are a bunch of log messages that indicate that harmony doesn't
implement SHA-1.
Is that true?
It can't be true, because _all_ the DaCapo benchmarks rely on SHA-1
for
validation. I raised JIRA Harmony-2135 on this issue. Looks like
after
eclipse has run, drlvm forgets how to access the SHA-1 algorithm :(
Yep, the SHA-1 code is still there [1].
[1]
http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/modules/security/src/main/java/common/org/apache/harmony/security/provider/crypto/SHA1Impl.java?view=markup
Regards,
Tim
--
Tim Ellison ([EMAIL PROTECTED])
IBM Java technology centre, UK.
--
Tim Ellison ([EMAIL PROTECTED])
IBM Java technology centre, UK.
[classlib][swing][awt] fork mode for the tests
I've run swing and awt tests with fork mode once a dozen times
on Windows and Linux. All tests passed.
So to speed up precommit testing I'd like to change fork mode in
swign and awt to ${hy.test.forkmode} like it's done in other modules.
Objections?
Thanks,
Mikhail
RE: Re: [doc][drlvm] The document Getting started with DRL is outdated
Successfully added a patch to fix getting Started outdated content to http://issues.apache.org/jira/browse/HARMONY-2150. The patch is not final - need help to add more content. The current structure is: - overview - running an app - eclipse-related (now much shorter) -- running an app -- debugging an app - configuring vm operation (empty) Questions: how do you like the current patch? Do you think we can add a link to debugging vmjit doc (or to wiki)? Any ideas on what to write in Configuring vm operation? Thank you, Nadya Morozova -Original Message- From: news [mailto:[EMAIL PROTECTED] On Behalf Of Egor Pasko Sent: Monday, November 13, 2006 1:00 PM To: harmony-dev@incubator.apache.org Subject: Re: [doc][drlvm] The document Getting started with DRL is outdated On the 0x220 day of Apache Harmony Nadezhda Morozova wrote: -Original Message- From: news [mailto:[EMAIL PROTECTED] On Behalf Of Egor Pasko Sent: Monday, November 13, 2006 12:40 PM To: harmony-dev@incubator.apache.org Subject: Re: [doc][drlvm] The document Getting started with DRL is outdated On the 0x220 day of Apache Harmony Nadezhda Morozova wrote: Ok, I'll use http://issues.apache.org/jira/browse/HARMONY-2150 to get an initial patch for the getting started document, and we can then work to improve it. OK, I am watching it Let's make it a short page with links to wiki and maybe some how-tos. To summarize: * we agreed that there will be no eclipse screenshots (they are for eclipse+drlvm page) * we agreed that there should be something like see what kind of links we have Am I right? [Nadya] Yop, quite right. An additional enhancement would be to comment out copyrights and update info that is incorrect. remove these annoyed substances? I am not an expert in copyright law, not sure we can remove them. But copyright notices are not what I desire to look at on the getting started page. Not sure I'll fix everything, but can give a start. Thanks for all your help. u r welcome Thank you, Nadya Morozova -Original Message- From: news [mailto:[EMAIL PROTECTED] On Behalf Of Egor Pasko Sent: Monday, November 13, 2006 11:10 AM To: harmony-dev@incubator.apache.org Subject: Re: [doc][drlvm] The document Getting started with DRL is outdated On the 0x21D day of Apache Harmony Nadezhda Morozova wrote: Egor, I think we're mixing things up a bit, or at least our perceptions of various docs. I'd not call what you're suggesting a tutorial - it's more of a howto doc, right? We are lucky to have Salikh write this How to write a GC? Doc - do you mean something similar for DRLVM Command-line Args Tutorial? on Wikipedia: * A _how-to_ is an informal, often short, description of how to accomplish some specific task * A _tutorial_ is a document, software, or other media created for the purpose of instruction for any of a wide variety of tasks yes, I mix those terms :) As suggested earlier, we can store drlvm+eclipse specifics on another page = see JIRA 2009. cmd options reference is on wiki, but a short howto will be marvelous - illustrating usage of common options, solving typical problems by using our vm correctly, etc. Does anybody volunteer to help? let's collect the options first. To choose between them for the howto Thank you, Nadya Morozova -Original Message- From: news [mailto:[EMAIL PROTECTED] On Behalf Of Egor Pasko Sent: Friday, November 10, 2006 4:06 PM To: harmony-dev@incubator.apache.org Subject: Re: [doc][drlvm] The document Getting started with DRL is outdated On the 0x21D day of Apache Harmony Nadezhda Morozova wrote: Alexei, Tutorials might be fine for mature projects, but I do not think ours is ready for a big flow of users yet, that would require a tutorial. we _are_ mature for a small tutorial :) So +1 for having a nice good tutorial ... one day. If there are volunteers to write the tutorial now, I'd be happy to help though. well, actually, I love tutorials too, especially the one for VIM :) some contraversal inside me..fighting..done let's then say A Short Eclipse Tutorial with Harmony, and then DRLVM Command-line Args Tutorial. Howabout that? Thank you, Nadya Morozova -Original Message- From: Fedotov, Alexei A [mailto:[EMAIL PROTECTED] Sent: Friday, November 10, 2006 1:40 PM To: harmony-dev@incubator.apache.org Subject: RE: Re: [doc][drlvm] The document Getting started with DRL is outdated Guys, I like good tutorials. I learned VIM using a tutorial. I don't need the VIM tutorial any longer, but at the beginning it was useful. +1 for maintain Getting Started as is with minor changes Why Eclipse was chosen for the tutorial? Our goal was to use Harmony for
Re: [drlvm][test]Exclude some tests from build test target, make 'build test' pass
On 10/26/06, Elena Semukhina [EMAIL PROTECTED] wrote: After H-1823 has been committed, I still see intermittent failures of drlvm kernel ThreadTest. Normally this test passes but today I got ThreadTest.testInterrupt_Sleeping() and testGetStateBlocked() failures. There is H-1789 for the first issue but it is not reprodiced with the attached test anymore. For the second test I filed H-1876 to make the test more stable. The patch has been committed recently but the test still may fail. I'd like someone to review the above mentioned tests to be sure they are correct otherwise we need to investigate failures and file JIRA's before the tests are exclued. I looked at ThreadTest again and found one more incorrectness in testGetStateBlocked(): it does not wait for the thread's run() method actually starts. I filed https://issues.apache.org/jira/browse/HARMONY-2166 and attached the patch. I ran the test more than 100 times and did not see a failure. Vera, could you please review the tests? On 10/26/06, Pavel Ozhdikhin [EMAIL PROTECTED] wrote: +1 to exclude failing tests for now and require that all remaining tests must pass. Assuming some tests fail anyway cause people don't treat the failures seriously. As soon as the bug causing the failure is fixed the tests need to be unexcluded. Thanks, Pavel On 10/26/06, Rana Dasgupta [EMAIL PROTECTED] wrote: The ideal way would be for acceptance tests like build test to always pass and to catch and roll back the patch that breaks this invariant, rather than to disable the tests. But I agree with Vera, it is important to keep a running set up as acceptance tests, so disabling the well known failures may be the only way until we fix the problems. I don't know that any of the tests are unstable. These are implementation bugs. gc.LOS is a bug in thread yielding by the apr Windows functionality. The java.lang.ObjectTest also looks like an interpreter implementation error. On 10/25/06, Volynets, Vera [EMAIL PROTECTED] wrote: Geir Some tests launched by command build test fail. The idea of build test is to run it before each commit. In this way you can catch regressions. In order to effectively catch regressions, i.e. tests that started to fail after some change, it's necessary to have 'build test' pass in a stable way. One of the ways to achieve stable state is to exclude failing tests or tests which show unstable behavior. So I analysed statistics of test runs on win ia32 platform and made up a list of tests to be excluded: 1) smoke *** gc.LOS fails always on jitrino and interpreter, debug and release 2) kernel *** java.lang.ClasssGenericsTest and *** java.lang.ClassGenericsTest4 fail because of timeout, so I increase timeout in kernel.test.xml *** java.lang.ObjectTest fail on interpreter with following message: Testsuite: java.lang.ObjectTest Tests run: 18, Failures: 1, Errors: 0, Time elapsed: 6.109 sec Testcase: testWait1(java.lang.ObjectTest): FAILED An InterruptedException must be thrown in test thread! junit.framework.AssertionFailedError: An InterruptedException must be thrown in test thread! See HARNONY-1966 issue with attached patch. Vera Volynets Intel Middleware ProductsDivision -- Thanks, Elena -- Thanks, Elena
Re: Japi diffs for harmony
On 11/9/06, Ivanov, Alexey A wrote: -Original Message- From: Nathan Beyer [mailto:[EMAIL PROTECTED] Sent: Thursday, November 09, 2006 5:49 AM To: harmony-dev@incubator.apache.org Subject: Re: Japi diffs for harmony No problem on the name change, but doesn't what Stuart is talking about require that methods add this exception to the signature to actually show up in the reports? I guess the answer is yes. They can be added lazily when unimplemented methods are spotted. And new stubs should have this throws from the beginning. Maybe it's worth putting this info somewhere on the site. Added to [1] at r474287. -Stepan. [1] http://incubator.apache.org/harmony/subcomponents/classlibrary/agreements.html Also having this kind of declaration will simplify searching for not implemented methods. Regards, Alexey. On 11/8/06, Tim Ellison [EMAIL PROTECTED] wrote: Stuart Ballard wrote: Tim Ellison wrote: I'm no fan of stubs for just such reason. But for those dev's that are following along, there is an org.apache.harmony.luni.util.NotYetImplementedException that is defined for just such purposes. Would you consider renaming this to NotImplementedException since Japi recognizes that name in throws clauses and treats it specially? If you feel strongly about not changing the existing name, I can add NotYetImplementedException as an alternative hardcoded name in Japitools but that seems kinda redundant... What do you think? I have no objection to renaming it. If nobody objects in the next day or so then I'll go ahead and do it. Regards, Tim -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. -- Alexey A. Ivanov Intel Enterprise Solutions Software Division -- Stepan Mishura Intel Middleware Products Division -- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[testing][nio] 2 tests fail on the SUSE linux
Hello everyone, today my cruise control failed on the linux SUSE box with 2 errors in the org.apache.harmony.nio.tests.java.nio.channels.SocketChannelTest test. Could somebody reproduce/ fix this issue? Thanks, Vlaidimir Tests testSocket_configureblocking and testCFII_ConnectAfterFinish_Server_NonBlock reports ERROR with similar output: The address is not available java.net.BindException: The address is not available at org.apache.harmony.luni.platform.OSNetworkSystem.socketBindImpl(Native Method) at org.apache.harmony.luni.platform.OSNetworkSystem.bind( OSNetworkSystem.java:126) at org.apache.harmony.luni.net.PlainSocketImpl.bind(PlainSocketImpl.java:161) at java.net.ServerSocket.init(ServerSocket.java:116) at java.net.ServerSocket.init(ServerSocket.java:72) at org.apache.harmony.nio.tests.java.nio.channels.SocketChannelTest.setUp( SocketChannelTest.java:77)
Deleted version_svn_tag.h
Nathan Beyer wrote: I deleted the file and added it to the ignore property. For those of us poor souls not using SVN directly this deletion broke the build, as the file version_svn_tag.h is not available directly now. The issue HARMONY-2168 provides a fix: copy the file.
[app-testing] Geronimo
Has anyone tried running Geronimo recently? The wiki page [1] looks quite out of date. Just wondering how we are doing? [1] http://wiki.apache.org/harmony/Apache_Geronimo Regards, Tim -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK.
RE: [doc][drlvm] The document Getting started with DRL is outdated
What about the portions of the Unicode copyright? Thank you, Nadya Morozova -Original Message- From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED] Sent: Monday, November 13, 2006 5:06 PM To: harmony-dev@incubator.apache.org Subject: Re: [doc][drlvm] The document Getting started with DRL is outdated as an intel person, you can remove an intel copyright. if it's an ASF copyright, you can remove that too from the document (it should be auto-generated at the bottom anyway) geir Egor Pasko wrote: On the 0x220 day of Apache Harmony Nadezhda Morozova wrote: -Original Message- From: news [mailto:[EMAIL PROTECTED] On Behalf Of Egor Pasko Sent: Monday, November 13, 2006 12:40 PM To: harmony-dev@incubator.apache.org Subject: Re: [doc][drlvm] The document Getting started with DRL is outdated On the 0x220 day of Apache Harmony Nadezhda Morozova wrote: Ok, I'll use http://issues.apache.org/jira/browse/HARMONY-2150 to get an initial patch for the getting started document, and we can then work to improve it. OK, I am watching it Let's make it a short page with links to wiki and maybe some how-tos. To summarize: * we agreed that there will be no eclipse screenshots (they are for eclipse+drlvm page) * we agreed that there should be something like see what kind of links we have Am I right? [Nadya] Yop, quite right. An additional enhancement would be to comment out copyrights and update info that is incorrect. remove these annoyed substances? I am not an expert in copyright law, not sure we can remove them. But copyright notices are not what I desire to look at on the getting started page. Not sure I'll fix everything, but can give a start. Thanks for all your help. u r welcome Thank you, Nadya Morozova -Original Message- From: news [mailto:[EMAIL PROTECTED] On Behalf Of Egor Pasko Sent: Monday, November 13, 2006 11:10 AM To: harmony-dev@incubator.apache.org Subject: Re: [doc][drlvm] The document Getting started with DRL is outdated On the 0x21D day of Apache Harmony Nadezhda Morozova wrote: Egor, I think we're mixing things up a bit, or at least our perceptions of various docs. I'd not call what you're suggesting a tutorial - it's more of a howto doc, right? We are lucky to have Salikh write this How to write a GC? Doc - do you mean something similar for DRLVM Command-line Args Tutorial? on Wikipedia: * A _how-to_ is an informal, often short, description of how to accomplish some specific task * A _tutorial_ is a document, software, or other media created for the purpose of instruction for any of a wide variety of tasks yes, I mix those terms :) As suggested earlier, we can store drlvm+eclipse specifics on another page = see JIRA 2009. cmd options reference is on wiki, but a short howto will be marvelous - illustrating usage of common options, solving typical problems by using our vm correctly, etc. Does anybody volunteer to help? let's collect the options first. To choose between them for the howto Thank you, Nadya Morozova -Original Message- From: news [mailto:[EMAIL PROTECTED] On Behalf Of Egor Pasko Sent: Friday, November 10, 2006 4:06 PM To: harmony-dev@incubator.apache.org Subject: Re: [doc][drlvm] The document Getting started with DRL is outdated On the 0x21D day of Apache Harmony Nadezhda Morozova wrote: Alexei, Tutorials might be fine for mature projects, but I do not think ours is ready for a big flow of users yet, that would require a tutorial. we _are_ mature for a small tutorial :) So +1 for having a nice good tutorial ... one day. If there are volunteers to write the tutorial now, I'd be happy to help though. well, actually, I love tutorials too, especially the one for VIM :) some contraversal inside me..fighting..done let's then say A Short Eclipse Tutorial with Harmony, and then DRLVM Command-line Args Tutorial. Howabout that? Thank you, Nadya Morozova -Original Message- From: Fedotov, Alexei A [mailto:[EMAIL PROTECTED] Sent: Friday, November 10, 2006 1:40 PM To: harmony-dev@incubator.apache.org Subject: RE: Re: [doc][drlvm] The document Getting started with DRL is outdated Guys, I like good tutorials. I learned VIM using a tutorial. I don't need the VIM tutorial any longer, but at the beginning it was useful. +1 for maintain Getting Started as is with minor changes Why Eclipse was chosen for the tutorial? Our goal was to use Harmony for Harmony development. I liked that idea. With best regards, Alexei Fedotov, Intel Java XML Engineering -Original Message- From: news [mailto:[EMAIL PROTECTED] On Behalf Of Egor Pasko Sent: Friday, November 10, 2006 1:29 PM To: harmony-dev@incubator.apache.org Subject: Re: [doc][drlvm] The document Getting started with DRL is outdated On the 0x21D day of Apache Harmony Pavel Ozhdikhin wrote: Nadya, One more proposal about Getting Started: let's remove all
Re: Deleted version_svn_tag.h
Patch applied - please test Salikh Zakirov wrote: Nathan Beyer wrote: I deleted the file and added it to the ignore property. For those of us poor souls not using SVN directly this deletion broke the build, as the file version_svn_tag.h is not available directly now. The issue HARMONY-2168 provides a fix: copy the file.
Re: [doc][drlvm] The document Getting started with DRL is outdated
what's the link we're talking about? Morozova, Nadezhda wrote: What about the portions of the Unicode copyright? Thank you, Nadya Morozova -Original Message- From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED] Sent: Monday, November 13, 2006 5:06 PM To: harmony-dev@incubator.apache.org Subject: Re: [doc][drlvm] The document Getting started with DRL is outdated as an intel person, you can remove an intel copyright. if it's an ASF copyright, you can remove that too from the document (it should be auto-generated at the bottom anyway) geir Egor Pasko wrote: On the 0x220 day of Apache Harmony Nadezhda Morozova wrote: -Original Message- From: news [mailto:[EMAIL PROTECTED] On Behalf Of Egor Pasko Sent: Monday, November 13, 2006 12:40 PM To: harmony-dev@incubator.apache.org Subject: Re: [doc][drlvm] The document Getting started with DRL is outdated On the 0x220 day of Apache Harmony Nadezhda Morozova wrote: Ok, I'll use http://issues.apache.org/jira/browse/HARMONY-2150 to get an initial patch for the getting started document, and we can then work to improve it. OK, I am watching it Let's make it a short page with links to wiki and maybe some how-tos. To summarize: * we agreed that there will be no eclipse screenshots (they are for eclipse+drlvm page) * we agreed that there should be something like see what kind of links we have Am I right? [Nadya] Yop, quite right. An additional enhancement would be to comment out copyrights and update info that is incorrect. remove these annoyed substances? I am not an expert in copyright law, not sure we can remove them. But copyright notices are not what I desire to look at on the getting started page. Not sure I'll fix everything, but can give a start. Thanks for all your help. u r welcome Thank you, Nadya Morozova -Original Message- From: news [mailto:[EMAIL PROTECTED] On Behalf Of Egor Pasko Sent: Monday, November 13, 2006 11:10 AM To: harmony-dev@incubator.apache.org Subject: Re: [doc][drlvm] The document Getting started with DRL is outdated On the 0x21D day of Apache Harmony Nadezhda Morozova wrote: Egor, I think we're mixing things up a bit, or at least our perceptions of various docs. I'd not call what you're suggesting a tutorial - it's more of a howto doc, right? We are lucky to have Salikh write this How to write a GC? Doc - do you mean something similar for DRLVM Command-line Args Tutorial? on Wikipedia: * A _how-to_ is an informal, often short, description of how to accomplish some specific task * A _tutorial_ is a document, software, or other media created for the purpose of instruction for any of a wide variety of tasks yes, I mix those terms :) As suggested earlier, we can store drlvm+eclipse specifics on another page = see JIRA 2009. cmd options reference is on wiki, but a short howto will be marvelous - illustrating usage of common options, solving typical problems by using our vm correctly, etc. Does anybody volunteer to help? let's collect the options first. To choose between them for the howto Thank you, Nadya Morozova -Original Message- From: news [mailto:[EMAIL PROTECTED] On Behalf Of Egor Pasko Sent: Friday, November 10, 2006 4:06 PM To: harmony-dev@incubator.apache.org Subject: Re: [doc][drlvm] The document Getting started with DRL is outdated On the 0x21D day of Apache Harmony Nadezhda Morozova wrote: Alexei, Tutorials might be fine for mature projects, but I do not think ours is ready for a big flow of users yet, that would require a tutorial. we _are_ mature for a small tutorial :) So +1 for having a nice good tutorial ... one day. If there are volunteers to write the tutorial now, I'd be happy to help though. well, actually, I love tutorials too, especially the one for VIM :) some contraversal inside me..fighting..done let's then say A Short Eclipse Tutorial with Harmony, and then DRLVM Command-line Args Tutorial. Howabout that? Thank you, Nadya Morozova -Original Message- From: Fedotov, Alexei A [mailto:[EMAIL PROTECTED] Sent: Friday, November 10, 2006 1:40 PM To: harmony-dev@incubator.apache.org Subject: RE: Re: [doc][drlvm] The document Getting started with DRL is outdated Guys, I like good tutorials. I learned VIM using a tutorial. I don't need the VIM tutorial any longer, but at the beginning it was useful. +1 for maintain Getting Started as is with minor changes Why Eclipse was chosen for the tutorial? Our goal was to use Harmony for Harmony development. I liked that idea. With best regards, Alexei Fedotov, Intel Java XML Engineering -Original Message- From: news [mailto:[EMAIL PROTECTED] On Behalf Of Egor Pasko Sent: Friday, November 10, 2006 1:29 PM To: harmony-dev@incubator.apache.org Subject: Re: [doc][drlvm] The document Getting started with DRL is outdated On the 0x21D day of Apache Harmony Pavel Ozhdikhin wrote: Nadya, One more proposal about Getting Started:
Re: [app-testing] Geronimo
I haven't tried since June I'm afraid. Sian On 13/11/06, Tim Ellison [EMAIL PROTECTED] wrote: Has anyone tried running Geronimo recently? The wiki page [1] looks quite out of date. Just wondering how we are doing? [1] http://wiki.apache.org/harmony/Apache_Geronimo Regards, Tim -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. -- Sian January IBM Java Technology Centre, UK
RE: [doc][drlvm] The document Getting started with DRL is outdated
http://incubator.apache.org/harmony/subcomponents/drlvm/getting_started. html#Disclaimer http://incubator.apache.org/harmony/subcomponents/drlvm/developers_guide .html - these seem to have apache and intel copyright (can be resolved) + the Unicode disclaimer. Thank you, Nadya Morozova -Original Message- From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED] Sent: Monday, November 13, 2006 5:14 PM To: harmony-dev@incubator.apache.org Subject: Re: [doc][drlvm] The document Getting started with DRL is outdated what's the link we're talking about? Morozova, Nadezhda wrote: What about the portions of the Unicode copyright? Thank you, Nadya Morozova -Original Message- From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED] Sent: Monday, November 13, 2006 5:06 PM To: harmony-dev@incubator.apache.org Subject: Re: [doc][drlvm] The document Getting started with DRL is outdated as an intel person, you can remove an intel copyright. if it's an ASF copyright, you can remove that too from the document (it should be auto-generated at the bottom anyway) geir Egor Pasko wrote: On the 0x220 day of Apache Harmony Nadezhda Morozova wrote: -Original Message- From: news [mailto:[EMAIL PROTECTED] On Behalf Of Egor Pasko Sent: Monday, November 13, 2006 12:40 PM To: harmony-dev@incubator.apache.org Subject: Re: [doc][drlvm] The document Getting started with DRL is outdated On the 0x220 day of Apache Harmony Nadezhda Morozova wrote: Ok, I'll use http://issues.apache.org/jira/browse/HARMONY-2150 to get an initial patch for the getting started document, and we can then work to improve it. OK, I am watching it Let's make it a short page with links to wiki and maybe some how-tos. To summarize: * we agreed that there will be no eclipse screenshots (they are for eclipse+drlvm page) * we agreed that there should be something like see what kind of links we have Am I right? [Nadya] Yop, quite right. An additional enhancement would be to comment out copyrights and update info that is incorrect. remove these annoyed substances? I am not an expert in copyright law, not sure we can remove them. But copyright notices are not what I desire to look at on the getting started page. Not sure I'll fix everything, but can give a start. Thanks for all your help. u r welcome Thank you, Nadya Morozova -Original Message- From: news [mailto:[EMAIL PROTECTED] On Behalf Of Egor Pasko Sent: Monday, November 13, 2006 11:10 AM To: harmony-dev@incubator.apache.org Subject: Re: [doc][drlvm] The document Getting started with DRL is outdated On the 0x21D day of Apache Harmony Nadezhda Morozova wrote: Egor, I think we're mixing things up a bit, or at least our perceptions of various docs. I'd not call what you're suggesting a tutorial - it's more of a howto doc, right? We are lucky to have Salikh write this How to write a GC? Doc - do you mean something similar for DRLVM Command-line Args Tutorial? on Wikipedia: * A _how-to_ is an informal, often short, description of how to accomplish some specific task * A _tutorial_ is a document, software, or other media created for the purpose of instruction for any of a wide variety of tasks yes, I mix those terms :) As suggested earlier, we can store drlvm+eclipse specifics on another page = see JIRA 2009. cmd options reference is on wiki, but a short howto will be marvelous - illustrating usage of common options, solving typical problems by using our vm correctly, etc. Does anybody volunteer to help? let's collect the options first. To choose between them for the howto Thank you, Nadya Morozova -Original Message- From: news [mailto:[EMAIL PROTECTED] On Behalf Of Egor Pasko Sent: Friday, November 10, 2006 4:06 PM To: harmony-dev@incubator.apache.org Subject: Re: [doc][drlvm] The document Getting started with DRL is outdated On the 0x21D day of Apache Harmony Nadezhda Morozova wrote: Alexei, Tutorials might be fine for mature projects, but I do not think ours is ready for a big flow of users yet, that would require a tutorial. we _are_ mature for a small tutorial :) So +1 for having a nice good tutorial ... one day. If there are volunteers to write the tutorial now, I'd be happy to help though. well, actually, I love tutorials too, especially the one for VIM :) some contraversal inside me..fighting..done let's then say A Short Eclipse Tutorial with Harmony, and then DRLVM Command-line Args Tutorial. Howabout that? Thank you, Nadya Morozova -Original Message- From: Fedotov, Alexei A [mailto:[EMAIL PROTECTED] Sent: Friday, November 10, 2006 1:40 PM To: harmony-dev@incubator.apache.org Subject: RE: Re: [doc][drlvm] The document Getting started with DRL is outdated Guys, I like good tutorials. I learned VIM using a tutorial. I don't need the VIM tutorial any longer, but at the beginning it was useful. +1 for
Re: [doc][drlvm] The document Getting started with DRL is outdated
Additional terms from the Database ? LOL Just get rid of it all. Those terms are in our notice file, and that's enough. Unicode didn't put them there, anyway. geir Morozova, Nadezhda wrote: http://incubator.apache.org/harmony/subcomponents/drlvm/getting_started. html#Disclaimer http://incubator.apache.org/harmony/subcomponents/drlvm/developers_guide .html - these seem to have apache and intel copyright (can be resolved) + the Unicode disclaimer. Thank you, Nadya Morozova -Original Message- From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED] Sent: Monday, November 13, 2006 5:14 PM To: harmony-dev@incubator.apache.org Subject: Re: [doc][drlvm] The document Getting started with DRL is outdated what's the link we're talking about? Morozova, Nadezhda wrote: What about the portions of the Unicode copyright? Thank you, Nadya Morozova -Original Message- From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED] Sent: Monday, November 13, 2006 5:06 PM To: harmony-dev@incubator.apache.org Subject: Re: [doc][drlvm] The document Getting started with DRL is outdated as an intel person, you can remove an intel copyright. if it's an ASF copyright, you can remove that too from the document (it should be auto-generated at the bottom anyway) geir Egor Pasko wrote: On the 0x220 day of Apache Harmony Nadezhda Morozova wrote: -Original Message- From: news [mailto:[EMAIL PROTECTED] On Behalf Of Egor Pasko Sent: Monday, November 13, 2006 12:40 PM To: harmony-dev@incubator.apache.org Subject: Re: [doc][drlvm] The document Getting started with DRL is outdated On the 0x220 day of Apache Harmony Nadezhda Morozova wrote: Ok, I'll use http://issues.apache.org/jira/browse/HARMONY-2150 to get an initial patch for the getting started document, and we can then work to improve it. OK, I am watching it Let's make it a short page with links to wiki and maybe some how-tos. To summarize: * we agreed that there will be no eclipse screenshots (they are for eclipse+drlvm page) * we agreed that there should be something like see what kind of links we have Am I right? [Nadya] Yop, quite right. An additional enhancement would be to comment out copyrights and update info that is incorrect. remove these annoyed substances? I am not an expert in copyright law, not sure we can remove them. But copyright notices are not what I desire to look at on the getting started page. Not sure I'll fix everything, but can give a start. Thanks for all your help. u r welcome Thank you, Nadya Morozova -Original Message- From: news [mailto:[EMAIL PROTECTED] On Behalf Of Egor Pasko Sent: Monday, November 13, 2006 11:10 AM To: harmony-dev@incubator.apache.org Subject: Re: [doc][drlvm] The document Getting started with DRL is outdated On the 0x21D day of Apache Harmony Nadezhda Morozova wrote: Egor, I think we're mixing things up a bit, or at least our perceptions of various docs. I'd not call what you're suggesting a tutorial - it's more of a howto doc, right? We are lucky to have Salikh write this How to write a GC? Doc - do you mean something similar for DRLVM Command-line Args Tutorial? on Wikipedia: * A _how-to_ is an informal, often short, description of how to accomplish some specific task * A _tutorial_ is a document, software, or other media created for the purpose of instruction for any of a wide variety of tasks yes, I mix those terms :) As suggested earlier, we can store drlvm+eclipse specifics on another page = see JIRA 2009. cmd options reference is on wiki, but a short howto will be marvelous - illustrating usage of common options, solving typical problems by using our vm correctly, etc. Does anybody volunteer to help? let's collect the options first. To choose between them for the howto Thank you, Nadya Morozova -Original Message- From: news [mailto:[EMAIL PROTECTED] On Behalf Of Egor Pasko Sent: Friday, November 10, 2006 4:06 PM To: harmony-dev@incubator.apache.org Subject: Re: [doc][drlvm] The document Getting started with DRL is outdated On the 0x21D day of Apache Harmony Nadezhda Morozova wrote: Alexei, Tutorials might be fine for mature projects, but I do not think ours is ready for a big flow of users yet, that would require a tutorial. we _are_ mature for a small tutorial :) So +1 for having a nice good tutorial ... one day. If there are volunteers to write the tutorial now, I'd be happy to help though. well, actually, I love tutorials too, especially the one for VIM :) some contraversal inside me..fighting..done let's then say A Short Eclipse Tutorial with Harmony, and then DRLVM Command-line Args Tutorial. Howabout that? Thank you, Nadya Morozova -Original Message- From: Fedotov, Alexei A [mailto:[EMAIL PROTECTED] Sent: Friday, November 10, 2006 1:40 PM To: harmony-dev@incubator.apache.org Subject: RE: Re: [doc][drlvm] The document Getting started with DRL is outdated
RE: [doc][drlvm] The document Getting started with DRL is outdated
Ok, thanks. I somehow feel dumb with anything that deals with legal - copyrights, contracts, licenses...oh! I'd erase all excess disclaimers from our website with pleasure :) Thank you, Nadya Morozova -Original Message- From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED] Sent: Monday, November 13, 2006 5:45 PM To: harmony-dev@incubator.apache.org Subject: Re: [doc][drlvm] The document Getting started with DRL is outdated Additional terms from the Database ? LOL Just get rid of it all. Those terms are in our notice file, and that's enough. Unicode didn't put them there, anyway. geir Morozova, Nadezhda wrote: http://incubator.apache.org/harmony/subcomponents/drlvm/getting_started. html#Disclaimer http://incubator.apache.org/harmony/subcomponents/drlvm/developers_guide .html - these seem to have apache and intel copyright (can be resolved) + the Unicode disclaimer. Thank you, Nadya Morozova -Original Message- From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED] Sent: Monday, November 13, 2006 5:14 PM To: harmony-dev@incubator.apache.org Subject: Re: [doc][drlvm] The document Getting started with DRL is outdated what's the link we're talking about? Morozova, Nadezhda wrote: What about the portions of the Unicode copyright? Thank you, Nadya Morozova -Original Message- From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED] Sent: Monday, November 13, 2006 5:06 PM To: harmony-dev@incubator.apache.org Subject: Re: [doc][drlvm] The document Getting started with DRL is outdated as an intel person, you can remove an intel copyright. if it's an ASF copyright, you can remove that too from the document (it should be auto-generated at the bottom anyway) geir Egor Pasko wrote: On the 0x220 day of Apache Harmony Nadezhda Morozova wrote: -Original Message- From: news [mailto:[EMAIL PROTECTED] On Behalf Of Egor Pasko Sent: Monday, November 13, 2006 12:40 PM To: harmony-dev@incubator.apache.org Subject: Re: [doc][drlvm] The document Getting started with DRL is outdated On the 0x220 day of Apache Harmony Nadezhda Morozova wrote: Ok, I'll use http://issues.apache.org/jira/browse/HARMONY-2150 to get an initial patch for the getting started document, and we can then work to improve it. OK, I am watching it Let's make it a short page with links to wiki and maybe some how-tos. To summarize: * we agreed that there will be no eclipse screenshots (they are for eclipse+drlvm page) * we agreed that there should be something like see what kind of links we have Am I right? [Nadya] Yop, quite right. An additional enhancement would be to comment out copyrights and update info that is incorrect. remove these annoyed substances? I am not an expert in copyright law, not sure we can remove them. But copyright notices are not what I desire to look at on the getting started page. Not sure I'll fix everything, but can give a start. Thanks for all your help. u r welcome Thank you, Nadya Morozova -Original Message- From: news [mailto:[EMAIL PROTECTED] On Behalf Of Egor Pasko Sent: Monday, November 13, 2006 11:10 AM To: harmony-dev@incubator.apache.org Subject: Re: [doc][drlvm] The document Getting started with DRL is outdated On the 0x21D day of Apache Harmony Nadezhda Morozova wrote: Egor, I think we're mixing things up a bit, or at least our perceptions of various docs. I'd not call what you're suggesting a tutorial - it's more of a howto doc, right? We are lucky to have Salikh write this How to write a GC? Doc - do you mean something similar for DRLVM Command-line Args Tutorial? on Wikipedia: * A _how-to_ is an informal, often short, description of how to accomplish some specific task * A _tutorial_ is a document, software, or other media created for the purpose of instruction for any of a wide variety of tasks yes, I mix those terms :) As suggested earlier, we can store drlvm+eclipse specifics on another page = see JIRA 2009. cmd options reference is on wiki, but a short howto will be marvelous - illustrating usage of common options, solving typical problems by using our vm correctly, etc. Does anybody volunteer to help? let's collect the options first. To choose between them for the howto Thank you, Nadya Morozova -Original Message- From: news [mailto:[EMAIL PROTECTED] On Behalf Of Egor Pasko Sent: Friday, November 10, 2006 4:06 PM To: harmony-dev@incubator.apache.org Subject: Re: [doc][drlvm] The document Getting started with DRL is outdated On the 0x21D day of Apache Harmony Nadezhda Morozova wrote: Alexei, Tutorials might be fine for mature projects, but I do not think ours is ready for a big flow of users yet, that would require a tutorial. we _are_ mature for a small tutorial :) So +1 for having a nice good tutorial ... one day. If there are volunteers to write the tutorial now, I'd be happy to help though. well,
Re: [drlvm][threading] Should hythread_monitor_init() aquire the monitor?
Oops, You were right. I take a llook into classlib hythread code. It looks like I incorrectly understand the documentation. This is a bug. Thanks Artem On 11/13/06, Evgueni Brevnov [EMAIL PROTECTED] wrote: Could someone familiar with classlib's implementation comment on that ? Thanks in advance. Evgueni On 11/13/06, Evgueni Brevnov [EMAIL PROTECTED] wrote: Hello Artem, Are you 100% sure? I've looked at the classlib's implementation and can't find where the monitor is acquired. Moreover if you look at the initializeSignalTools() located in modules\portlib\src\main\native\port\linux\hysignal.c you will find that it initializes new monitors with hyhtread_monitor_init_with_name and never frees these monitors. That turned out to be the reason of a deadlock in HARMONY-2006. Thanks Evgueni On 11/13/06, Artem Aliev [EMAIL PROTECTED] wrote: It turned out that DRL implementation of hythread_monitor_init / hythread_monitor_init_with_name initializes and acquires a monitor. Eugeni, Both drlvm and classlib hythread work this way. This original hythread design that for compatibility reason was implemented in drlvm. Thanks Artem On 11/10/06, Evgueni Brevnov [EMAIL PROTECTED] wrote: Hi, While investigating deadlock scenario which is described in HARMONY-2006 I found out one interesting thing. It turned out that DRL implementation of hythread_monitor_init / hythread_monitor_init_with_name initializes and acquires a monitor. Original spec reads: Acquire and initialize a new monitor from the threading library AFAIU that doesn't mean to lock the monitor but get it from the threading library. So the hythread_monitor_init should not lock the monitor. Could somebody comment on that? Thanks Evgueni
[doc] site.css
Hi all, I've updated formatting of definition lists DL on site: https://issues.apache.org/jira/browse/HARMONY-2173 The new formatting looks more natural to me; the screenshots can be found in the JIRA issue. When editing site.css I faced that there are many different styles of indentation used: * Some statements are indented using tabs, * Some -- using spaces, * And a mixture of tabs and space, in the worse case. There are also inconsistencies in formatting of rules, and trailing white-space. Let's agree on using either tabs or spaces for indentation of CSS statements. If they are different, it causes inconveniences when creating patches because some lines look changed while nothing was modified there. I have no strong opinion on which one to use here. But let it be one: either tabs or spaces. What do you think about it? Thank you in advance, -- Alexey A. Ivanov Intel Enterprise Solutions Software Division
Re: [drlvm][jvmti][testing] I want to add JVMTI tests to drlvm commit checks
Geir Magnusson Jr. wrote: Gregory Shimansky wrote: One reason would be is that I don't know ant well enough to redesign the whole stuff all together. I used the existing setup and init targets which take care of including ancontrip and cctask jars. If you ask me, I'd prefer make in the first place, ant is just too foreign to me. There is no reason to use caps, we didn't even start to discuss how we want to see drlvm build and when WE ARE GOING TO GET RID OF IT at some point. The caps were to get your attention. I thought you had a nice way to create a standalone testbed and then hook that in. Well as I've written already, there is very much that is done in setup and init targets of drlvm build. It is checking for necessary jar files like junit, ant-contrib, cctask. Also these targets setup a lot of necessary properties. I just didn't want to duplicate all of that stuff. The fact that these targets (setup and init) also do XML transform is almost not used in jvmti tests. Yes there are 2 select which are processed in XML transform, but I can remove them when necessary. I consider this dependency on current drlvm build minor. If we decide to get rid of XML processing, the changes in jvmti tests build shall be minimal. Does it sound ok to you? The time invested, well... I learned a lot since the last time I used ant. Maybe one day I'll be able to write something as impressive and unmaintainable as the current drlvm built :) Seriously, if we're going to change it, let's discuss it how we want it to look like and which tool we'll use. I vote for make (gnu version, that is gmake), even on win32 it exists in cygwin and mingw. I think that we should simply use the same tooling that we're using now in classlib. Ok let's decide that exactly we don't like in the current drlvm build. Probably I should start another thread. -- Gregory
Re: [drlvm][em64t] build fails
Gregory Shimansky wrote: On Saturday 11 November 2006 02:36 Pavel Pervov wrote: Gregory, Could you look at https://issues.apache.org/jira/browse/HARMONY-2152. I believe it'll fix the build. Thank you for a quick fix. The build works now. Don't try to run acceptance tests though. The StackTest is a machine killer. It eats all of the virtual memory in a moment because it cannot find any stack limit (ulimit -s 8192 may be used as a workaround) and maps all of 2^48 (or whatever number of bits are configured in kernel for virtual address space) bytes of virtual memory. After that only reset helps. Ok back to this bug. I decided that on x86_64 linuxes (and ia32 which don't have a stack limit for some reason) we need to at least fix the test so that it doesn't make OS unusable. I've modified StackTest to check firt 10,000,000 recursions and fail is SOE is not thrown. The patch is available in HARMONY-2175. -- Gregory
Re: Re: [classlib][pack200] Status update
Oh, and I've discovered that the default Sun implementation doesn't actually allow you to replace it with another implementation unless it's on the boot classpath. Have you tried endorsed dirs -Djava.endorsed.dirs=... [1]? Seems it was specially designed for this purpose. [1] http://java.sun.com/j2se/1.5.0/docs/guide/standards/index.html Regards, 2006/11/11, Alex Blewitt [EMAIL PROTECTED]: A call of frustration at times perhaps :-) It's going along. I'm hoping to get to a stage where I can get a better patch together and get it into the harmony subversion codebase in the near future. But sometimes it's just slow progress. One thing I'd like to get sorted is moving the pack200 code into its own module in the near future, perhaps after the next patch bomb. Oh, and I've discovered that the default Sun implementation doesn't actually allow you to replace it with another implementation unless it's on the boot classpath. D'oh! Fortunately, I've raised it as a bug with Sun: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6489723 We should ensure that it doesn't happen with Harmony too :-) Alex. On 10/11/06, Tim Ellison [EMAIL PROTECTED] wrote: Thanks for the update Alex. I assume from this description (and please don't take this the wrong way) that you are happy to be left alone to work on this for the moment, rather than it be read as a call for help? Keep up the good work. Tim Alex Blewitt wrote: I'm still lurking around in the background, but I'm busier than ever what with having to keep posting at EclipseZone where I'm editor now ... but I'm still managing to plod along with the Pack200 code. The last patch (1994, IIRC) went down pretty badly; the subclipse plugin didn't seem to capture all the newly created classes that I had put together for a bit of refactoring that I did. It's also a nightmare submitting newly created files; once they've been uploaded to JIRA into the patch queue, I effectively have to stop work until they're applied, because there's no way of getting SVN to figure out that the file called ClassFile.java is the same as the ClassFile.java that's been added by someone else on my behalf, and I have to overwrite my local copy to update. Kinda prevents doing any sensible work on newly created files between submission and application to be honest. Instead, I plan to sprint (well, jog, at least) to the next stable point, and then upload a whole wodge of code and leave it for a week or two to be applied before picking up again. I'm fairly close to being at that stage, but not quite. Where I am at is being able to generate (abstract) methods with exceptions and fields with constant (integer) values, so a bit further forward than last time. On the one hand, it means that I understand what needs to be done (no mean feat!) but on the other hand, there's still a fair bit to go. For a start, I'm going to need to process the actual bytecode for non-abstract methods (or indeed, any classes) before there's any point in it trying to be used for real, and there's still a few missing bits (Longs, Doubles, Floats) from the constant pools. I'm pretty sure Strings would work, but I've not tried them yet. Unfortunately, the code is really awful. The Segment.java is getting on for 1500 lines of code in a single class; and the attribute parsing contains both duplicated code and isn't as generic as it needs to be to handle other attributes; and the (in)visible annotations like @Overrides and similar are going to be a bit of a nightmare ... My plan is to get the code to a stage where it can start to be useful for extracting simple classes from a pack file, and then start generating test data which can be used for regressions. (There's a bit there at the moment, but it's not exactly a large coverage.) Once I've done that, I'll start tackling some of the refactoring which will result in less duplicated code and hopefully something that will be easier to look after in the future. Anyway, excuse the long rambling but I've been a bit quiet for a while and wanted to let people know I was still alive and kicking the code :-) -- Alexei Zakharov, Intel Enterprise Solutions Software Division
Re: [drlvm] drlvm and gdb and shared libraries
Well, I was able to use breakpoints for the libraries still not loaded. Just type: 'br func' and it will inform you that the library is not loaded yet and will suggest to make it pending on future shared library load. When the library will be loaded the breakpoint will be automatically enabled. -- Ivan On 13 Nov 2006 15:46:44 +0600, Egor Pasko [EMAIL PROTECTED] wrote: On the 0x220 day of Apache Harmony Geir Magnusson, Jr. wrote: I have a dumb question - I was playing today with a toy launcher for DRLVM working out some embedding issues, and for the life of me, I couldn't get dgb to ever let me break on anything in a shared library. I loaded the vm via dlopen() an dlsym(), and the code runs fine. But even build in debug, I couldn't ever specify a breakpoint in a shared lib even after it was loaded. has anyone run across this? you cannot enable a breakpoint until the library is loaded. Just wait until it is loaded. I wrote [1] to help with that. Hope it helps :) [1] http://wiki.apache.org/harmony/Debugging%20DRLVM%20with%20GDB%20on%20Linux -- Egor Pasko -- Ivan Intel Enterprise Solutions Software Division
Re: [vm][classlib] hythr library
On 11/13/06, Alexey Petrenko [EMAIL PROTECTED] wrote: Guys, is there any progress in making possible for IBM and DRL VM to use the same hythr library? I imagine they would have to share some more VM internals first, like GC or object layout interface, before they can migrate to a common threading library :) It is really a pain now to run class library tests on DRLVM now. And nearly impossible to easy switch VMs by launcher command line parameters. Since class library builds IBM version of hythr library and rewrites it in jre/bin directory. So you need to copy this library What if just disable copying of the hythr.dll into the deploy/jre/jdk/bin directory, may be harmony-vme could be providing the one? from DRL VM after each build. (Yes, I know how to write scripts :) If it is not possible for both VMs to use the same library probably we need to move these libraries to VM directories... +1. Seems like we don't have any VM at the moment which would be really using the hythr from classlib. Even IBM VME doesn't use the hythr. As Tim wrote earlier, VME is using it's own threading library called j9thr23 [1]. Does it differ a much from the hythr? Guess it might be favourable for the classlib + IBM VME stack as well if it was using a single thread library. Would it be possible for VME to include a straightforward hythr implementation which can delegate hythread_* calls to the j9thr23? Thanks, Andrey. [1] http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200606.mbox/[EMAIL PROTECTED] SY, Alexey -- Andrey Chernyshev Intel Enterprise Solutions Software Division
Re: [drlvm][em64t] build fails
Hello I think that Stack test should print pass if no stack overflow error is happened. Test should check processing of this error but not existing of it. Optimizing compiler can do very deep recursion unrolling, and SOE can happen never in this case. Thanks Pavel Afremov. On 11/13/06, Gregory Shimansky [EMAIL PROTECTED] wrote: Gregory Shimansky wrote: On Saturday 11 November 2006 02:36 Pavel Pervov wrote: Gregory, Could you look at https://issues.apache.org/jira/browse/HARMONY-2152. I believe it'll fix the build. Thank you for a quick fix. The build works now. Don't try to run acceptance tests though. The StackTest is a machine killer. It eats all of the virtual memory in a moment because it cannot find any stack limit (ulimit -s 8192 may be used as a workaround) and maps all of 2^48 (or whatever number of bits are configured in kernel for virtual address space) bytes of virtual memory. After that only reset helps. Ok back to this bug. I decided that on x86_64 linuxes (and ia32 which don't have a stack limit for some reason) we need to at least fix the test so that it doesn't make OS unusable. I've modified StackTest to check firt 10,000,000 recursions and fail is SOE is not thrown. The patch is available in HARMONY-2175. -- Gregory
RE: [doc] site.css
My two cents below. Thank you, Nadya Morozova -Original Message- From: Ivanov, Alexey A [mailto:[EMAIL PROTECTED] Sent: Monday, November 13, 2006 5:56 PM To: harmony-dev@incubator.apache.org Subject: [doc] site.css Hi all, I've updated formatting of definition lists DL on site: https://issues.apache.org/jira/browse/HARMONY-2173 The new formatting looks more natural to me; the screenshots can be found in the JIRA issue. [Nadya] good patch! I checked it on IE and Opera and Netscape. Works fine. When editing site.css I faced that there are many different styles of indentation used: * Some statements are indented using tabs, * Some -- using spaces, * And a mixture of tabs and space, in the worse case. There are also inconsistencies in formatting of rules, and trailing white- space. Let's agree on using either tabs or spaces for indentation of CSS statements. If they are different, it causes inconveniences when creating patches because some lines look changed while nothing was modified there. I have no strong opinion on which one to use here. But let it be one: either tabs or spaces. What do you think about it? [Nadya] I agree it looks dirty with a mixture of spaces and tabs. I like spaces, they are more reliable. Thank you in advance, -- Alexey A. Ivanov Intel Enterprise Solutions Software Division
Re: [drlvm][em64t] build fails
Pavel Afremov wrote: Hello I think that Stack test should print pass if no stack overflow error is happened. Test should check processing of this error but not existing of it. Optimizing compiler can do very deep recursion unrolling, and SOE can happen never in this case. So what is the point to have a test which would pass either way? Check that it doesn't crash the VM, is it the only purpose for it? -- Gregory
Re: [drlvm][test]Exclude some tests from build test target, make 'build test' pass
On Monday 13 November 2006 15:51 Elena Semukhina wrote: On 10/26/06, Elena Semukhina [EMAIL PROTECTED] wrote: After H-1823 has been committed, I still see intermittent failures of drlvm kernel ThreadTest. Normally this test passes but today I got ThreadTest.testInterrupt_Sleeping() and testGetStateBlocked() failures. There is H-1789 for the first issue but it is not reprodiced with the attached test anymore. For the second test I filed H-1876 to make the test more stable. The patch has been committed recently but the test still may fail. I'd like someone to review the above mentioned tests to be sure they are correct otherwise we need to investigate failures and file JIRA's before the tests are exclued. I looked at ThreadTest again and found one more incorrectness in testGetStateBlocked(): it does not wait for the thread's run() method actually starts. I filed https://issues.apache.org/jira/browse/HARMONY-2166 and attached the patch. I ran the test more than 100 times and did not see a failure. Cool! I'd like to see this patch applied (in case it really helps) ASAP. Alexey V, please don't hold it for long. I would really like to see all acceptance to pass again on all platforms and then we'll maintain no regression state. -- Gregory Shimansky, Intel Middleware Products Division
Re: [vm][classlib] hythr library
Hmm... Pre-Harmony, the IBM VM + classlib used the same thread library. When the classlib was contributed, I guess they forked the thread lib and changed the names of the functions. (I'm only speculating since I wasn't involved in that process.) hythr should be virtually identical to a subset of j9thr23.dll. I agree, the IBM VM + classlib should be using the same thread library. It shouldn't be hard to implement a redirector lib from hythr to j9thr. Would this obsolete the current classlib hythr implementation? Angela On 11/13/06, Andrey Chernyshev [EMAIL PROTECTED] wrote: On 11/13/06, Alexey Petrenko [EMAIL PROTECTED] wrote: Guys, is there any progress in making possible for IBM and DRL VM to use the same hythr library? I imagine they would have to share some more VM internals first, like GC or object layout interface, before they can migrate to a common threading library :) It is really a pain now to run class library tests on DRLVM now. And nearly impossible to easy switch VMs by launcher command line parameters. Since class library builds IBM version of hythr library and rewrites it in jre/bin directory. So you need to copy this library What if just disable copying of the hythr.dll into the deploy/jre/jdk/bin directory, may be harmony-vme could be providing the one? from DRL VM after each build. (Yes, I know how to write scripts :) If it is not possible for both VMs to use the same library probably we need to move these libraries to VM directories... +1. Seems like we don't have any VM at the moment which would be really using the hythr from classlib. Even IBM VME doesn't use the hythr. As Tim wrote earlier, VME is using it's own threading library called j9thr23 [1]. Does it differ a much from the hythr? Guess it might be favourable for the classlib + IBM VME stack as well if it was using a single thread library. Would it be possible for VME to include a straightforward hythr implementation which can delegate hythread_* calls to the j9thr23? Thanks, Andrey. [1] http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200606.mbox/[EMAIL PROTECTED] SY, Alexey -- Andrey Chernyshev Intel Enterprise Solutions Software Division
Re: [drlvm] drlvm and gdb and shared libraries
Let me point out the second section of Egor's manual - LD_LIBRARY_PATH is the only thing which should be additionally configured. On 13 Nov 2006 15:46:44 +0600, Egor Pasko [EMAIL PROTECTED] wrote: On the 0x220 day of Apache Harmony Geir Magnusson, Jr. wrote: I have a dumb question - I was playing today with a toy launcher for DRLVM working out some embedding issues, and for the life of me, I couldn't get dgb to ever let me break on anything in a shared library. I loaded the vm via dlopen() an dlsym(), and the code runs fine. But even build in debug, I couldn't ever specify a breakpoint in a shared lib even after it was loaded. has anyone run across this? you cannot enable a breakpoint until the library is loaded. Just wait until it is loaded. I wrote [1] to help with that. Hope it helps :) [1] http://wiki.apache.org/harmony/Debugging%20DRLVM%20with%20GDB%20on%20Linux -- Egor Pasko -- Thank you, Alexei
Re: Re: Re: [classlib][pack200] Status update
No, it's a bug (see http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6489723). Also note that the list of packages that are listed at the URL you gave specify the full set of packages that can be overridden, and the pack200 classes aren't on there :-) The Pack200 stuff is supposed to be like the JDBC stuff, in that you should be able to substitute different implementations at a later stage. The problem with the current implementation is that the factory is loaded via the system classloader rather than the context classloader (mainly because it's a static method, I think) and thus the bootclasspath is the only one that has been changed. In any case, ideally you'd want to be able to substitute a different implementation without having to do special things on the classpath, either via the bootclasspath or endorsed directories, in order to deploy it with your own VM or applications. Alex. On 13/11/06, Alexei Zakharov [EMAIL PROTECTED] wrote: Oh, and I've discovered that the default Sun implementation doesn't actually allow you to replace it with another implementation unless it's on the boot classpath. Have you tried endorsed dirs -Djava.endorsed.dirs=... [1]? Seems it was specially designed for this purpose. [1] http://java.sun.com/j2se/1.5.0/docs/guide/standards/index.html Regards, 2006/11/11, Alex Blewitt [EMAIL PROTECTED]: A call of frustration at times perhaps :-) It's going along. I'm hoping to get to a stage where I can get a better patch together and get it into the harmony subversion codebase in the near future. But sometimes it's just slow progress. One thing I'd like to get sorted is moving the pack200 code into its own module in the near future, perhaps after the next patch bomb. Oh, and I've discovered that the default Sun implementation doesn't actually allow you to replace it with another implementation unless it's on the boot classpath. D'oh! Fortunately, I've raised it as a bug with Sun: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6489723 We should ensure that it doesn't happen with Harmony too :-) Alex. On 10/11/06, Tim Ellison [EMAIL PROTECTED] wrote: Thanks for the update Alex. I assume from this description (and please don't take this the wrong way) that you are happy to be left alone to work on this for the moment, rather than it be read as a call for help? Keep up the good work. Tim Alex Blewitt wrote: I'm still lurking around in the background, but I'm busier than ever what with having to keep posting at EclipseZone where I'm editor now ... but I'm still managing to plod along with the Pack200 code. The last patch (1994, IIRC) went down pretty badly; the subclipse plugin didn't seem to capture all the newly created classes that I had put together for a bit of refactoring that I did. It's also a nightmare submitting newly created files; once they've been uploaded to JIRA into the patch queue, I effectively have to stop work until they're applied, because there's no way of getting SVN to figure out that the file called ClassFile.java is the same as the ClassFile.java that's been added by someone else on my behalf, and I have to overwrite my local copy to update. Kinda prevents doing any sensible work on newly created files between submission and application to be honest. Instead, I plan to sprint (well, jog, at least) to the next stable point, and then upload a whole wodge of code and leave it for a week or two to be applied before picking up again. I'm fairly close to being at that stage, but not quite. Where I am at is being able to generate (abstract) methods with exceptions and fields with constant (integer) values, so a bit further forward than last time. On the one hand, it means that I understand what needs to be done (no mean feat!) but on the other hand, there's still a fair bit to go. For a start, I'm going to need to process the actual bytecode for non-abstract methods (or indeed, any classes) before there's any point in it trying to be used for real, and there's still a few missing bits (Longs, Doubles, Floats) from the constant pools. I'm pretty sure Strings would work, but I've not tried them yet. Unfortunately, the code is really awful. The Segment.java is getting on for 1500 lines of code in a single class; and the attribute parsing contains both duplicated code and isn't as generic as it needs to be to handle other attributes; and the (in)visible annotations like @Overrides and similar are going to be a bit of a nightmare ... My plan is to get the code to a stage where it can start to be useful for extracting simple classes from a pack file, and then start generating test data which can be used for regressions. (There's a bit there at the moment, but it's not exactly a large coverage.) Once I've done that, I'll start tackling some of the refactoring which will result in less duplicated code and
Re: [general] creation of jdktools
Nathan, thank you for creation of the trunk/working_jdktools. Geir, Please look at comment and scripts attached to the HARMONY-2180. I tried to make them trivial so that reviewing doesn't take much time. Proposed build system has two levels of enrties: - working_jdktools/build.xml which can be used for processing all or selected modules. To be used in federated build; - working_jdktools/modules/$M/build.xml used for processing the $M module. These module-level build.xml files can be used while working with single module. The working_jdktools/make/ dir contains definitions imported by modules' build.xml files so few simple buildfiles are required in each module directory. I'm going to complete the HARMONY-2180 sub-task in few days to provide final script set. Thank you -Ilya On 11/13/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Can you please give us an idea of what you have right now? There's no way we can participate with you if we don't have an idea of current status... geir Ilya Neverov wrote: On 10/31/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: [skip] Assumptions which look reasonable for jdktool's build subsystem: 1) it works in presence of built classlib (as HDK binaries or as a result of classlib phase of overall build); yes - think of the same trick we do w/ DRLVM to reach over to find it. I'd imagine the federated build to then have : trunk/ working_classlib/ working_vm/ working_jdktools/ Commiters, Could you please create empty directory trunk/working_jdktools. I need it to check building jdktools as part of the federated build. Without having the working_jdktools/ in the repository the moving sources and patching buiild files would require additional manual steps. Thank you. -Ilya
Re: [drlvm][em64t] build fails
Gregory Shimansky wrote: Gregory Shimansky wrote: On Saturday 11 November 2006 02:36 Pavel Pervov wrote: Gregory, Could you look at https://issues.apache.org/jira/browse/HARMONY-2152. I believe it'll fix the build. Thank you for a quick fix. The build works now. Don't try to run acceptance tests though. The StackTest is a machine killer. It eats all of the virtual memory in a moment because it cannot find any stack limit (ulimit -s 8192 may be used as a workaround) and maps all of 2^48 (or whatever number of bits are configured in kernel for virtual address space) bytes of virtual memory. After that only reset helps. Ok back to this bug. I decided that on x86_64 linuxes (and ia32 which don't have a stack limit for some reason) we need to at least fix the test so that it doesn't make OS unusable. I've modified StackTest to check firt 10,000,000 recursions and fail is SOE is not thrown. The patch is available in HARMONY-2175. Gregory, does this mean that you are able to compile harmony on your em64t machine? if so, can you tell me what version of gcc/ld you're using? thanks -- Stefano.
Re: [drlvm][em64t] build fails
Stefano Mazzocchi wrote: Gregory Shimansky wrote: Gregory Shimansky wrote: On Saturday 11 November 2006 02:36 Pavel Pervov wrote: Gregory, Could you look at https://issues.apache.org/jira/browse/HARMONY-2152. I believe it'll fix the build. Thank you for a quick fix. The build works now. Don't try to run acceptance tests though. The StackTest is a machine killer. It eats all of the virtual memory in a moment because it cannot find any stack limit (ulimit -s 8192 may be used as a workaround) and maps all of 2^48 (or whatever number of bits are configured in kernel for virtual address space) bytes of virtual memory. After that only reset helps. Ok back to this bug. I decided that on x86_64 linuxes (and ia32 which don't have a stack limit for some reason) we need to at least fix the test so that it doesn't make OS unusable. I've modified StackTest to check firt 10,000,000 recursions and fail is SOE is not thrown. The patch is available in HARMONY-2175. Gregory, does this mean that you are able to compile harmony on your em64t machine? if so, can you tell me what version of gcc/ld you're using? thanks I did compile harmony on em64t. The most tricky part was to set up depends for classlib, I think I've written about it already. The distribution is quite old SuSE9 with gcc 3.3.3 and GNU binutils (which include ld) 2.15.90.0.1.1 20040303 (SuSE Linux). I'm going to try to do this on my Gentoo at home now. It is mostly bleeding edge up to date installation. -- Gregory
Re: [vm][classlib] hythr library
Andrey, Angela, If I understood a problem correctly Alexey asked to make a developer's life easier. It looks like now a developer should rebuild class library, then to rebuild DRLVM each time he wants to check his class library changes with DRLVM. Can we simplify the procedure? For example, if I don't change DRLVM, I shouldn't rebuild it each time to have correct files in jre/bin. * This is more conventional. * This allows people to use prebuilt DRLVM binaries. * Prebuilt binaries minimize astonishment for a class library developer. Alexey mentioned scripts as a quick solution. Is it possible to solve this problem on a build script level? Or should we change a launcher to reorder paths in LD_LIBRARY_PATH? Your design discussion about long term solution is quite interesting reading as well. Andrey said IBM should expose object layout. Let me speculate on it a bit. I really don't have any knowledge on J9, so any coincidence is not intentional. * Imagine that J9 is able to work with Sun's class library that was licensed by IBM from Sun for 10 years. * Imagine that class library has functions which access objects directly for performance reasons. Taking these two statements together I don't think we should count on exposing this object layout to the third party when this third party is a competing Open Source community. Thank you, Alexei On 11/13/06, Angela Lin [EMAIL PROTECTED] wrote: Hmm... Pre-Harmony, the IBM VM + classlib used the same thread library. When the classlib was contributed, I guess they forked the thread lib and changed the names of the functions. (I'm only speculating since I wasn't involved in that process.) hythr should be virtually identical to a subset of j9thr23.dll. I agree, the IBM VM + classlib should be using the same thread library. It shouldn't be hard to implement a redirector lib from hythr to j9thr. Would this obsolete the current classlib hythr implementation? Angela On 11/13/06, Andrey Chernyshev [EMAIL PROTECTED] wrote: On 11/13/06, Alexey Petrenko [EMAIL PROTECTED] wrote: Guys, is there any progress in making possible for IBM and DRL VM to use the same hythr library? I imagine they would have to share some more VM internals first, like GC or object layout interface, before they can migrate to a common threading library :) It is really a pain now to run class library tests on DRLVM now. And nearly impossible to easy switch VMs by launcher command line parameters. Since class library builds IBM version of hythr library and rewrites it in jre/bin directory. So you need to copy this library What if just disable copying of the hythr.dll into the deploy/jre/jdk/bin directory, may be harmony-vme could be providing the one? from DRL VM after each build. (Yes, I know how to write scripts :) If it is not possible for both VMs to use the same library probably we need to move these libraries to VM directories... +1. Seems like we don't have any VM at the moment which would be really using the hythr from classlib. Even IBM VME doesn't use the hythr. As Tim wrote earlier, VME is using it's own threading library called j9thr23 [1]. Does it differ a much from the hythr? Guess it might be favourable for the classlib + IBM VME stack as well if it was using a single thread library. Would it be possible for VME to include a straightforward hythr implementation which can delegate hythread_* calls to the j9thr23? Thanks, Andrey. [1] http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200606.mbox/[EMAIL PROTECTED] SY, Alexey -- Andrey Chernyshev Intel Enterprise Solutions Software Division -- Thank you, Alexei
Re: [drlvm][threading] Should hythread_monitor_init() aquire the monitor?
Evgueni Brevnov wrote: hmmm strange. The patch was tested on multi-processor system running SUSE9. I will check if the patch misses something. Anyway, we need to wait with the patch submission until we 100% sure how hythread_monitor_init should behave. Thanks Evgueni On 11/11/06, Gregory Shimansky [EMAIL PROTECTED] wrote: On Friday 10 November 2006 17:45 Evgueni Brevnov wrote: Hi, While investigating deadlock scenario which is described in HARMONY-2006 I found out one interesting thing. It turned out that DRL implementation of hythread_monitor_init / hythread_monitor_init_with_name initializes and acquires a monitor. Original spec reads: Acquire and initialize a new monitor from the threading library AFAIU that doesn't mean to lock the monitor but get it from the threading library. So the hythread_monitor_init should not lock the monitor. Could somebody comment on that? It might be that semantic is different on different platforms which is probably even worse. Your patch in HARMONY-2149 breaks nearly all of acceptance tests on Linux while everything on Windows works (ok I tested on laptop with 1 processor while Linux was a HT server, sometimes it is important for threading). I've tried to investigate the problem but didn't find the end of it yet. The bug seems to be ubuntu specific (jokeshall we maybe call this distribution buggy and move on?/joke). I didn't reproduce it on gentoo, all tests work just fine. The bug look likes this, on tests gc.Force, gc.LOS, gc.List, gc.NPE, gc.PhantomReferenceTest, gc.WeakReferenceTest, stress.WeakHashMapTest VM segfaults. The stack looks like an infinite recursion of 4 stack frames: #0 0xb6dcb814 in null_java_reference_handler (signum=11, info=0xb71a503c, context=0xb71a50bc) at /nfs/ims/proj/drl/mrt1/users/gregory/Harmony/enhanced/drlvm/trunk/vm/vmco re/src/util/linux/signals_ia32.cpp:443 #1 signal handler called #2 0xb6dcc20a in get_stack_addr () at /nfs/ims/proj/drl/mrt1/users/gregory/Harmony/enhanced/drlvm/trunk/vm/vmco re/src/util/linux/signals_ia32.cpp:293 #3 0xb6dcb6cd in check_stack_overflow (info=0xb71a546c, uc=0xb71a54ec) at /nfs/ims/proj/drl/mrt1/users/gregory/Harmony/enhanced/drlvm/trunk/vm/vmco re/src/util/linux/signals_ia32.cpp:399 #4 0xb6dcb900 in null_java_reference_handler (signum=11, info=0xb71a546c, context=0xb71a54ec) at /nfs/ims/proj/drl/mrt1/users/gregory/Harmony/enhanced/drlvm/trunk/vm/vmco re/src/util/linux/signals_ia32.cpp:451 and so on. The stack is very long. When I run VM with -Xtrace:signals I get a very long log of messages that NPE or SOE detected at The first time address always varies, but it appears to be memcpy. The next addresses are always the same, they point to get_stack_addr function. So I tried to find out why memcpy crashes in the first place. It appears to be a struct copy called from jsig_handler hysig. The stack looks like this (if I can trust gdb on ubuntu): #0 0xb7a9b9dc in memcpy () from /lib/tls/i686/cmov/libc.so.6 #1 0xb7ba0fa0 in jsig_handler (sig=-1215196204, siginfo=0x0, uc=0x0) at hysigunix.c:169 #2 0xb7f9ec8b in asynchSignalReporter (userData=0x0) at hysignal.c:971 #3 0xb7baa8ef in thread_start_proc (thd=0x807a8e8, p_args=0x807a8d8) at /nfs/ims/proj/drl/mrt1/users/gregory/Harmony/enhanced/drlvm/trunk/vm/thread/src/thread_native_basic.c:712 #4 0xb7bb0ed4 in dummy_worker (opaque=0x0) at threadproc/unix/thread.c:138 #5 0xb7b65341 in start_thread () from lib/tls/i686/cmov/libpthread.so.0 #6 0xb7af94ee in clone () from /lib/tls/i686/cmov/libc.so.6 In jsig_handler a struct of type sigaction is copied act = saved_sigaction[sig]; and gcc replaces this statement with a call to memcpy it seems. But the parameter sig is quite weird if you look at it. It is sig=-1215196204... Now if I could only find where and this sig happened there... I cannot find it in the depth of classlib native code this late at night. -- Gregory
Re: [drlvm][threading] Should hythread_monitor_init() aquire the monitor?
Evgueni, That was great. Artem, It's nice to see you online. Could you please check the last comments to http://issues.apache.org/jira/browse/HARMONY-1904 and decide what should we do about this issue?
Please set a Patch available flag for H-1669 Was: [drlvm] [testing] Excluding commit tests until the problem is fixed
Elena, Could you please set Patch available flag for the following issue to attract committer's attention to this issue? http://issues.apache.org/jira/browse/HARMONY-1669 Classlib test tests/api/java/io/PipedInputStreamTest hangs on Windows 2003 (After the last JIRA configuration changes a submitter can edit her issues). With best regards, Alexei Fedotov, Intel Java XML Engineering -Original Message- From: Elena Semukhina [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 18, 2006 3:56 PM To: harmony-dev@incubator.apache.org Subject: Re: [drlvm] [testing] Excluding commit tests until the problem is fixed On 10/17/06, Gregory Shimansky [EMAIL PROTECTED] wrote: My 2003 server is installed on a single core P4 with HT. The test attached to HARMONY-1669 works fine for me both with and without patch :) I may get an access to dual core server as described in JIRA but I am afraid it will take a few days. Probably we can just apply the patch since it doesn't seem to do any harm. Indeed the attached test passes and PipedInputStream test passes being run separately now but when I ran the whole luni module, it hung. I applied the patch and it helped. 2006/10/17, Geir Magnusson Jr. [EMAIL PROTECTED]: Rana Dasgupta wrote: On 10/16/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: So since I don't have Win 2003, I gotta just commit and let someone else test? Any committer have win 2003? I think that it may be hard to find a test at this point that fails on Windows Server 2003, but passes on XP. But perf etc. characteristics will be different. At some point, gc_v5 etc. is likely to have server specific variations, eg., parallel gc may be on server only. Are we talking of tests in general? I am sorry, but I may not have understood the comment. There is a test that demonstrates a Win 2003 bug... I can just commit it and let someone confirm since I don't have a win 2003 machine geir -- Gregory Shimansky, Intel Middleware Products Division -- Thanks, Elena
Re: [testing][nio] 2 tests fail on the SUSE linux
Hello, Vladimir, I have checked JIRA and http://harmonytest.org. This looks like a new issue. I wonder if it could be a result of some recent fix? With best regards, Alexei On 11/13/06, Vladimir Ivanov [EMAIL PROTECTED] wrote: Hello everyone, today my cruise control failed on the linux SUSE box with 2 errors in the org.apache.harmony.nio.tests.java.nio.channels.SocketChannelTest test. Could somebody reproduce/ fix this issue? Thanks, Vlaidimir Tests testSocket_configureblocking and testCFII_ConnectAfterFinish_Server_NonBlock reports ERROR with similar output: The address is not available java.net.BindException: The address is not available at org.apache.harmony.luni.platform.OSNetworkSystem.socketBindImpl(Native Method) at org.apache.harmony.luni.platform.OSNetworkSystem.bind( OSNetworkSystem.java:126) at org.apache.harmony.luni.net.PlainSocketImpl.bind(PlainSocketImpl.java:161) at java.net.ServerSocket.init(ServerSocket.java:116) at java.net.ServerSocket.init(ServerSocket.java:72) at org.apache.harmony.nio.tests.java.nio.channels.SocketChannelTest.setUp( SocketChannelTest.java:77) -- Thank you, Alexei
Re: [drlvm][em64t] build fails
On Tuesday 14 November 2006 00:51 Gregory Shimansky wrote: I'm going to try to do this on my Gentoo at home now. It is mostly bleeding edge up to date installation. Now I see what you're talking about. The threading library of classlib doesn't compile on x86_64. It fails with the same error [exec] /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.1/../../../../x86_64-pc-linux-gnu/bin/ld: warning: creating a DT_TEXTREL in object. [exec] /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.1/../../../../x86_64-pc-linux-gnu/bin/ld: x86_64/thrspinlock.o: relocation R_X86_64_PC32 against `hythread_yield' can not be used when making a shared object; recompile with -fPIC [exec] /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.1/../../../../x86_64-pc-linux-gnu/bin/ld: final link failed: Bad value I've found out that thrspinlock.o is compiled from an assembly code of thrspinlock.s which was created in HARMONY-1005. It looks like something wasn't done correctly enough. On SuSE9 it did work ok, but not any more. Compiling assembly sources with gcc -fpic didn't change anything. It looks like the code itself has to be changed. -- Gregory Shimansky, Intel Middleware Products Division
Re: [drlvm][em64t] build fails
Gregory Shimansky wrote: On Tuesday 14 November 2006 00:51 Gregory Shimansky wrote: I'm going to try to do this on my Gentoo at home now. It is mostly bleeding edge up to date installation. Now I see what you're talking about. The threading library of classlib doesn't compile on x86_64. It fails with the same error [exec] /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.1/../../../../x86_64-pc-linux-gnu/bin/ld: warning: creating a DT_TEXTREL in object. [exec] /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.1/../../../../x86_64-pc-linux-gnu/bin/ld: x86_64/thrspinlock.o: relocation R_X86_64_PC32 against `hythread_yield' can not be used when making a shared object; recompile with -fPIC [exec] /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.1/../../../../x86_64-pc-linux-gnu/bin/ld: final link failed: Bad value I've found out that thrspinlock.o is compiled from an assembly code of thrspinlock.s which was created in HARMONY-1005. It looks like something wasn't done correctly enough. On SuSE9 it did work ok, but not any more. Compiling assembly sources with gcc -fpic didn't change anything. It looks like the code itself has to be changed. Thanks for having identified the issue. Do we have any idea on how to proceed? (sorry for being pushy, but gump is waiting ;-) -- Stefano.
Re: [jira] Patch available setting
Sian, This is a good catch. I have the following justification for 3. I think it is better process when a bug submitter validates a patch *before* commit to ensure that it is good. Also it validates the patch *after*. This worth to be requested via public alias. Why a bug submitter should do a pre-commit check? He has most interest in the bug resolution. Thanks! On 11/13/06, Sian January [EMAIL PROTECTED] wrote: Hi, I have just discovered that it's not possible for a contributor to set Patch available on a JIRA unless they reported it. (I'm not sure about committers as I'm not one...) I imagine this is to stop people coming in and editing other details on the JIRA, so I can see that it makes sense. My question is, what is the best thing to do if I attach a patch to a JIRA and I can't set Patch available? I can think of three alternatives at the moment: 1. Assume that the reporter will notice and set it themselves (or commit the fix if they're also a comitter) 2. E-mail the reporter privately 3. Post to the mailing list Or a fourth alternative would be a combination of the above where the person who contributed the patch waits a few days before doing either 2 or 3. Any thoughts on what would be best? Thanks, Sian -- Sian January IBM Java Technology Centre, UK -- Thank you, Alexei
Re: [testing][nio] 2 tests fail on the SUSE linux
Vladimir Ivanov wrote: Hello everyone, today my cruise control failed on the linux SUSE box with 2 errors in the org.apache.harmony.nio.tests.java.nio.channels.SocketChannelTest test. Could somebody reproduce/ fix this issue? Thanks, Vlaidimir Tests testSocket_configureblocking and testCFII_ConnectAfterFinish_Server_NonBlock reports ERROR with similar output: The address is not available java.net.BindException: The address is not available at org.apache.harmony.luni.platform.OSNetworkSystem.socketBindImpl(Native Method) at org.apache.harmony.luni.platform.OSNetworkSystem.bind( OSNetworkSystem.java:126) at org.apache.harmony.luni.net.PlainSocketImpl.bind(PlainSocketImpl.java:161) at java.net.ServerSocket.init(ServerSocket.java:116) at java.net.ServerSocket.init(ServerSocket.java:72) at org.apache.harmony.nio.tests.java.nio.channels.SocketChannelTest.setUp( SocketChannelTest.java:77) Hi, I have run the test with latest Harmony with IBMVME on SUSE 10 Enterprise but find nothing wrong. However IMO it was Support_PortManager.getNextPort() cause the problem. This method, as we already know, is unsafe. Thus the test is not stable sometimes, though it appears in-frequently. We may find a way to fix it, e.g, try to bind to an available port, check if successful. -- Best Regards! Jimmy, Jing Lv China Software Development Lab, IBM
Re: [testing][nio] 2 tests fail on the SUSE linux
Jimmy, Jing Lv wrote: However IMO it was Support_PortManager.getNextPort() cause the problem. This method, as we already know, is unsafe. Thus the test is not stable sometimes, though it appears in-frequently. Agreed, I've mentioned this before. We may find a way to fix it, e.g, try to bind to an available port, check if successful. The tests should be modified to bind to port zero and let the OS allocate the next available port. Regards, Tim -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK.
Re: [doc] site.css
Spaces only please! -Nathan On 11/13/06, Ivanov, Alexey A [EMAIL PROTECTED] wrote: Hi all, I've updated formatting of definition lists DL on site: https://issues.apache.org/jira/browse/HARMONY-2173 The new formatting looks more natural to me; the screenshots can be found in the JIRA issue. When editing site.css I faced that there are many different styles of indentation used: * Some statements are indented using tabs, * Some -- using spaces, * And a mixture of tabs and space, in the worse case. There are also inconsistencies in formatting of rules, and trailing white-space. Let's agree on using either tabs or spaces for indentation of CSS statements. If they are different, it causes inconveniences when creating patches because some lines look changed while nothing was modified there. I have no strong opinion on which one to use here. But let it be one: either tabs or spaces. What do you think about it? Thank you in advance, -- Alexey A. Ivanov Intel EnterpriseSolutions SoftwareDivision
Re: Deleted version_svn_tag.h
Not using SVN directly? Do I even want to ask? In any case, I tested it after I deleted the file and the file was regenerated during the build. Did I miss something? I thought this bit was already in the scripts. -Nathan On 11/13/06, Salikh Zakirov [EMAIL PROTECTED] wrote: Nathan Beyer wrote: I deleted the file and added it to the ignore property. For those of us poor souls not using SVN directly this deletion broke the build, as the file version_svn_tag.h is not available directly now. The issue HARMONY-2168 provides a fix: copy the file.
Re: [classlib][swing] Serialization of Swing classes
On 11/13/06, Ivanov, Alexey A [EMAIL PROTECTED] wrote: -Original Message- From: Tim Ellison [mailto:[EMAIL PROTECTED] Sent: Sunday, November 12, 2006 1:12 AM To: harmony-dev@incubator.apache.org Subject: Re: [classlib][swing] Serialization of Swing classes Nathan Beyer wrote: Runtime optimization - I'm not positive of this, nor do I completely understand the actual affect, but wouldn't explicit 'serialVersionUID' fields mean that when those classes are actually serialized, a UID wouldn't need to be generated at runtime, correct? Now, I'll be the first to admit, this is a micro optimization, so it doesn't carry to much weight. However, I am curious about the details of the reality behind this thought, so if anyone knows, please post. Take a look at the effect of java.io.ObjectStreamClass#lookup(Class) for types that have a SUID field and those that don't. The actual work is done in ObjectStreamClass#computeSerialVersionUID(Class, Field[]), which scans the fields looking for a serialVersionUID field first, and computing it if not found using some non-trivial algorithm. The lookup result is cached, so any saving will be only on the first time the class is seen. Whether the computation is noticeable will depend upon the set of classes of objects being serialized as well as the presence (or absence) of the SUID field. Actually I don't mind having SUIDs declared in classes. Though IMHO without declaring this field, we communicate to developers serialized form of this class is not guaranteed to deserialize correctly. OTOH having looked through the methods Tim pointed, I can say that if classes declare SUID and one tries to serialize an object, there'll be no time spent to compute SUID during execution thus improving performance a little. Therefore I'm inclined to declare SUID rather than using @SuppressWarning(serial). However it may be worth to add a comment similar to that in the JavaDoc. What do you think? I'm fine with that approach. Regards, Alexey. Regards, Tim -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. -- Alexey A. Ivanov Intel Enterprise Solutions Software Division
Re: [classlib][swing][awt] fork mode for the tests
done in 474664
2006/11/14, Alexei Fedotov [EMAIL PROTECTED]:
+1 to use a uniform property for all modules
On 11/13/06, Mikhail Loenko [EMAIL PROTECTED] wrote:
I've run swing and awt tests with fork mode once a dozen times
on Windows and Linux. All tests passed.
So to speed up precommit testing I'd like to change fork mode in
swign and awt to ${hy.test.forkmode} like it's done in other modules.
Objections?
Thanks,
Mikhail
--
Thank you,
Alexei
Re: [classlib][swing] Serialization of Swing classes
On 11/13/06, Ivanov, Alexey A wrote: -Original Message- From: Tim Ellison Sent: Sunday, November 12, 2006 1:12 AM To: harmony-dev@incubator.apache.org Subject: Re: [classlib][swing] Serialization of Swing classes Nathan Beyer wrote: Runtime optimization - I'm not positive of this, nor do I completely understand the actual affect, but wouldn't explicit 'serialVersionUID' fields mean that when those classes are actually serialized, a UID wouldn't need to be generated at runtime, correct? Now, I'll be the first to admit, this is a micro optimization, so it doesn't carry to much weight. However, I am curious about the details of the reality behind this thought, so if anyone knows, please post. Take a look at the effect of java.io.ObjectStreamClass#lookup(Class) for types that have a SUID field and those that don't. The actual work is done in ObjectStreamClass#computeSerialVersionUID(Class, Field[]), which scans the fields looking for a serialVersionUID field first, and computing it if not found using some non-trivial algorithm. The lookup result is cached, so any saving will be only on the first time the class is seen. Whether the computation is noticeable will depend upon the set of classes of objects being serialized as well as the presence (or absence) of the SUID field. Actually I don't mind having SUIDs declared in classes. Though IMHO without declaring this field, we communicate to developers serialized form of this class is not guaranteed to deserialize correctly. OTOH having looked through the methods Tim pointed, I can say that if classes declare SUID and one tries to serialize an object, there'll be no time spent to compute SUID during execution thus improving performance a little. Therefore I'm inclined to declare SUID rather than using @SuppressWarning(serial). However it may be worth to add a comment similar to that in the JavaDoc. What do you think? +1 -Stepan. Regards, Alexey. Regards, Tim -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. -- Alexey A. Ivanov Intel Enterprise Solutions Software Division -- Stepan Mishura Intel Middleware Products Division -- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Japitools 0.9.7 released
I'm thrilled to be able to announce four things: 1) After far too long a wait, Japitools 0.9.7 Life, liberty[1] and the pursuit of Japiness has been released. This release includes the following improvements over 0.9.5: - Almost complete 1.5 language support, including generics, enums and varargs methods. The only missing feature for full language support (and the only blocker for a 1.0 release) is annotations. Big thanks to Jeroen Frijters for doing the heavy lifting of teaching Japitools to parse these features in .class files. - The ability to mark methods as not implemented by adding NotImplementedException to the throws clause. This allows Japitools to give results that more accurately match reality when parts of an API are known to have been stubbed out rather than actually being implemented. - The ability to traverse packages non-recursively (thanks to a contribution from Jaroslav Tuloch), making it easier to correctly specify the packages that are part of a public API, especially when that API is large. The new japiextractpkgs tool allows the list of packages to be extracted from Javadoc documentation. - An Ant task for running Japitools, thanks again to Jaroslav. - Too many bug fixes and minor enhancements to name, including a lot of changes that eliminate false positives and false negatives from the results. Thanks to many people for bug reports, feature suggestions and help in testing. 2) That there is now a Japitools mailing list, [EMAIL PROTECTED] See the mailing lists page (http://sab39.netreach.com/Software/Japitools/Mailing_Lists/52/) for more information. 3) That Japitools has a new homepage, http://sab39.netreach.com/japi/. It's ugly, and it's still a work in progress - some sections are still missing content, and others still have content that hasn't entirely been updated to match the current state of reality. I didn't want to delay any further getting the new release into people's hands. I'll continue working on filling out the content. 4) That Sun are AWESOME today! Stuart. [1] https://openjdk.dev.java.net/ -- http://sab39.netreach.com/
Re: [drlvm] drlvm and gdb and shared libraries
On the 0x220 day of Apache Harmony Ivan Volosyuk wrote: Well, I was able to use breakpoints for the libraries still not loaded. Just type: 'br func' and it will inform you that the library is not loaded yet and will suggest to make it pending on future shared library load. When the library will be loaded the breakpoint will be automatically enabled. hm, that misteriously did not work for me one day, so I invented a lot of garbage, now it works... You can even type 'br file:line'. Ivan, maybe, you know how to make it with cpp. For example: (gdb) br 'Jitrino::JavaByteCodeTranslator::ldc' Can't find member of namespace, class, struct, or union named Jitrino::JavaByteCodeTranslator::ldc Hint: try 'Jitrino::JavaByteCodeTranslator::ldc'TAB or 'Jitrino::JavaByteCodeTranslator::ldc'ESC-? (Note leading single quote.) -- Ivan On 13 Nov 2006 15:46:44 +0600, Egor Pasko [EMAIL PROTECTED] wrote: On the 0x220 day of Apache Harmony Geir Magnusson, Jr. wrote: I have a dumb question - I was playing today with a toy launcher for DRLVM working out some embedding issues, and for the life of me, I couldn't get dgb to ever let me break on anything in a shared library. I loaded the vm via dlopen() an dlsym(), and the code runs fine. But even build in debug, I couldn't ever specify a breakpoint in a shared lib even after it was loaded. has anyone run across this? you cannot enable a breakpoint until the library is loaded. Just wait until it is loaded. I wrote [1] to help with that. Hope it helps :) [1] http://wiki.apache.org/harmony/Debugging%20DRLVM%20with%20GDB%20on%20Linux -- Egor Pasko -- Ivan Intel Enterprise Solutions Software Division -- Egor Pasko
Re: [drlvm][threading] Should hythread_monitor_init() aquire the monitor?
Gregory, I can't reproduce the problem described by you on my local Ubuntu machine. So I can only guess. And my guess is that mapPortLibSignalToUnix can't find corresponding signal in the map. That's why you have undefined sig (-1215196204) in jsig_handler. I can think of two reasons why everything works fine on my machine: 1) Another signal is generated on my build. 2) It is just a matter of luck that eax contains some proper value upon returning from mapPortLibSignalToUnix. That's it for now Thanks Evgueni On 11/14/06, Alexei Fedotov [EMAIL PROTECTED] wrote: Evgueni, That was great. Artem, It's nice to see you online. Could you please check the last comments to http://issues.apache.org/jira/browse/HARMONY-1904 and decide what should we do about this issue?
Re: Re: [doc][drlvm] The document Getting started with DRL is outdated
Nadya, I've looked through your patch. Please see my comments in JIRA: http://issues.apache.org/jira/browse/HARMONY-2150 Do you think we can add a link to debugging vmjit doc (or to wiki)? I don't think we need it - it is rather info for developers than for users. Any ideas on what to write in Configuring vm operation? This section will duplicate the info from the Wiki page. Since we gave a link to that page in the overview we may skip creation of a separate section here. Thanks, Pavel On 11/13/06, Morozova, Nadezhda [EMAIL PROTECTED] wrote: Successfully added a patch to fix getting Started outdated content to http://issues.apache.org/jira/browse/HARMONY-2150. The patch is not final - need help to add more content. The current structure is: - overview - running an app - eclipse-related (now much shorter) -- running an app -- debugging an app - configuring vm operation (empty) Questions: how do you like the current patch? Do you think we can add a link to debugging vmjit doc (or to wiki)? Any ideas on what to write in Configuring vm operation? Thank you, Nadya Morozova -Original Message- From: news [mailto:[EMAIL PROTECTED] On Behalf Of Egor Pasko Sent: Monday, November 13, 2006 1:00 PM To: harmony-dev@incubator.apache.org Subject: Re: [doc][drlvm] The document Getting started with DRL is outdated On the 0x220 day of Apache Harmony Nadezhda Morozova wrote: -Original Message- From: news [mailto:[EMAIL PROTECTED] On Behalf Of Egor Pasko Sent: Monday, November 13, 2006 12:40 PM To: harmony-dev@incubator.apache.org Subject: Re: [doc][drlvm] The document Getting started with DRL is outdated On the 0x220 day of Apache Harmony Nadezhda Morozova wrote: Ok, I'll use http://issues.apache.org/jira/browse/HARMONY-2150 to get an initial patch for the getting started document, and we can then work to improve it. OK, I am watching it Let's make it a short page with links to wiki and maybe some how-tos. To summarize: * we agreed that there will be no eclipse screenshots (they are for eclipse+drlvm page) * we agreed that there should be something like see what kind of links we have Am I right? [Nadya] Yop, quite right. An additional enhancement would be to comment out copyrights and update info that is incorrect. remove these annoyed substances? I am not an expert in copyright law, not sure we can remove them. But copyright notices are not what I desire to look at on the getting started page. Not sure I'll fix everything, but can give a start. Thanks for all your help. u r welcome Thank you, Nadya Morozova -Original Message- From: news [mailto:[EMAIL PROTECTED] On Behalf Of Egor Pasko Sent: Monday, November 13, 2006 11:10 AM To: harmony-dev@incubator.apache.org Subject: Re: [doc][drlvm] The document Getting started with DRL is outdated On the 0x21D day of Apache Harmony Nadezhda Morozova wrote: Egor, I think we're mixing things up a bit, or at least our perceptions of various docs. I'd not call what you're suggesting a tutorial - it's more of a howto doc, right? We are lucky to have Salikh write this How to write a GC? Doc - do you mean something similar for DRLVM Command-line Args Tutorial? on Wikipedia: * A _how-to_ is an informal, often short, description of how to accomplish some specific task * A _tutorial_ is a document, software, or other media created for the purpose of instruction for any of a wide variety of tasks yes, I mix those terms :) As suggested earlier, we can store drlvm+eclipse specifics on another page = see JIRA 2009. cmd options reference is on wiki, but a short howto will be marvelous - illustrating usage of common options, solving typical problems by using our vm correctly, etc. Does anybody volunteer to help? let's collect the options first. To choose between them for the howto Thank you, Nadya Morozova -Original Message- From: news [mailto:[EMAIL PROTECTED] On Behalf Of Egor Pasko Sent: Friday, November 10, 2006 4:06 PM To: harmony-dev@incubator.apache.org Subject: Re: [doc][drlvm] The document Getting started with DRL is outdated On the 0x21D day of Apache Harmony Nadezhda Morozova wrote: Alexei, Tutorials might be fine for mature projects, but I do not think ours is ready for a big flow of users yet, that would require a tutorial. we _are_ mature for a small tutorial :) So +1 for having a nice good tutorial ... one day. If there are volunteers to write the tutorial now, I'd be happy to help though. well, actually, I love tutorials too, especially the one for VIM :) some contraversal inside me..fighting..done let's then say A Short Eclipse Tutorial with Harmony, and then DRLVM Command-line Args Tutorial. Howabout that? Thank you, Nadya Morozova -Original Message-
RE: Re: [doc][drlvm] The document Getting started with DRL is outdated
Pavel, Thanks for your comments. I'll work through the examples and post an updated patch soon. As for the Configuring VM operation - can we at least have a couple of examples in the form of scenarios or something? The wiki page only gives a reference, an enumeration of available options. Using these might not always be transparent. I know it's tutorial-level info, but why not have it? Giving a show-case of customizing vm to a specific need would be great. Thank you, Nadya Morozova -Original Message- From: Pavel Ozhdikhin [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 14, 2006 9:23 AM To: harmony-dev@incubator.apache.org Subject: Re: Re: [doc][drlvm] The document Getting started with DRL is outdated Nadya, I've looked through your patch. Please see my comments in JIRA: http://issues.apache.org/jira/browse/HARMONY-2150 Do you think we can add a link to debugging vmjit doc (or to wiki)? I don't think we need it - it is rather info for developers than for users. Any ideas on what to write in Configuring vm operation? This section will duplicate the info from the Wiki page. Since we gave a link to that page in the overview we may skip creation of a separate section here. Thanks, Pavel On 11/13/06, Morozova, Nadezhda [EMAIL PROTECTED] wrote: Successfully added a patch to fix getting Started outdated content to http://issues.apache.org/jira/browse/HARMONY-2150. The patch is not final - need help to add more content. The current structure is: - overview - running an app - eclipse-related (now much shorter) -- running an app -- debugging an app - configuring vm operation (empty) Questions: how do you like the current patch? Do you think we can add a link to debugging vmjit doc (or to wiki)? Any ideas on what to write in Configuring vm operation? Thank you, Nadya Morozova -Original Message- From: news [mailto:[EMAIL PROTECTED] On Behalf Of Egor Pasko Sent: Monday, November 13, 2006 1:00 PM To: harmony-dev@incubator.apache.org Subject: Re: [doc][drlvm] The document Getting started with DRL is outdated On the 0x220 day of Apache Harmony Nadezhda Morozova wrote: -Original Message- From: news [mailto:[EMAIL PROTECTED] On Behalf Of Egor Pasko Sent: Monday, November 13, 2006 12:40 PM To: harmony-dev@incubator.apache.org Subject: Re: [doc][drlvm] The document Getting started with DRL is outdated On the 0x220 day of Apache Harmony Nadezhda Morozova wrote: Ok, I'll use http://issues.apache.org/jira/browse/HARMONY-2150 to get an initial patch for the getting started document, and we can then work to improve it. OK, I am watching it Let's make it a short page with links to wiki and maybe some how-tos. To summarize: * we agreed that there will be no eclipse screenshots (they are for eclipse+drlvm page) * we agreed that there should be something like see what kind of links we have Am I right? [Nadya] Yop, quite right. An additional enhancement would be to comment out copyrights and update info that is incorrect. remove these annoyed substances? I am not an expert in copyright law, not sure we can remove them. But copyright notices are not what I desire to look at on the getting started page. Not sure I'll fix everything, but can give a start. Thanks for all your help. u r welcome Thank you, Nadya Morozova -Original Message- From: news [mailto:[EMAIL PROTECTED] On Behalf Of Egor Pasko Sent: Monday, November 13, 2006 11:10 AM To: harmony-dev@incubator.apache.org Subject: Re: [doc][drlvm] The document Getting started with DRL is outdated On the 0x21D day of Apache Harmony Nadezhda Morozova wrote: Egor, I think we're mixing things up a bit, or at least our perceptions of various docs. I'd not call what you're suggesting a tutorial - it's more of a howto doc, right? We are lucky to have Salikh write this How to write a GC? Doc - do you mean something similar for DRLVM Command-line Args Tutorial? on Wikipedia: * A _how-to_ is an informal, often short, description of how to accomplish some specific task * A _tutorial_ is a document, software, or other media created for the purpose of instruction for any of a wide variety of tasks yes, I mix those terms :) As suggested earlier, we can store drlvm+eclipse specifics on another page = see JIRA 2009. cmd options reference is on wiki, but a short howto will be marvelous - illustrating usage of common options, solving typical problems by using our vm correctly, etc. Does anybody volunteer to help? let's collect the options first. To choose between them for the howto Thank you, Nadya Morozova -Original Message- From: news [mailto:[EMAIL PROTECTED] On Behalf Of Egor Pasko Sent: Friday, November 10, 2006 4:06 PM To:
Re: [drlvm] drlvm and gdb and shared libraries
On the 0x221 day of Apache Harmony Egor Pasko wrote: On the 0x220 day of Apache Harmony Ivan Volosyuk wrote: Well, I was able to use breakpoints for the libraries still not loaded. Just type: 'br func' and it will inform you that the library is not loaded yet and will suggest to make it pending on future shared library load. When the library will be loaded the breakpoint will be automatically enabled. hm, that misteriously did not work for me one day, so I invented a lot of garbage, now it works... You can even type 'br file:line'. Ivan, maybe, you know how to make it with cpp. For example: (gdb) br 'Jitrino::JavaByteCodeTranslator::ldc' Can't find member of namespace, class, struct, or union named Jitrino::JavaByteCodeTranslator::ldc Hint: try 'Jitrino::JavaByteCodeTranslator::ldc'TAB or 'Jitrino::JavaByteCodeTranslator::ldc'ESC-? (Note leading single quote.) OK, I found the recipe (Thanks 2 Evgeny Brevnov helping in private). Need to type method name with signature. If the library is loaded, pressing TAB helps (but need to remove the last quote before pressing), but in case the library is not loaded, you will have to type the full signature. (nm, c++filt and grep are friends:) -- Ivan On 13 Nov 2006 15:46:44 +0600, Egor Pasko [EMAIL PROTECTED] wrote: On the 0x220 day of Apache Harmony Geir Magnusson, Jr. wrote: I have a dumb question - I was playing today with a toy launcher for DRLVM working out some embedding issues, and for the life of me, I couldn't get dgb to ever let me break on anything in a shared library. I loaded the vm via dlopen() an dlsym(), and the code runs fine. But even build in debug, I couldn't ever specify a breakpoint in a shared lib even after it was loaded. has anyone run across this? you cannot enable a breakpoint until the library is loaded. Just wait until it is loaded. I wrote [1] to help with that. Hope it helps :) [1] http://wiki.apache.org/harmony/Debugging%20DRLVM%20with%20GDB%20on%20Linux -- Egor Pasko -- Ivan Intel Enterprise Solutions Software Division -- Egor Pasko -- Egor Pasko
Re: Re: [doc][drlvm] The document Getting started with DRL is outdated
OK then for Configuring VM section JIT options proposed by Egor will be suitable: -Xem:jet - use only baseline JIT compiler -Xem:opt - use only optimising JIT compiler -Xtrace:em - print method compilation events I'd also add: -Xem:server - enable dynamic optimization mode tuned for long-running server-side applications (default optimization mode is tuned for fast start-up and client-side applications) -Xem server_static - enable static optimization mode tuned for long-running server-side applications Thanks, Pavel On 11/14/06, Morozova, Nadezhda [EMAIL PROTECTED] wrote: Pavel, Thanks for your comments. I'll work through the examples and post an updated patch soon. As for the Configuring VM operation - can we at least have a couple of examples in the form of scenarios or something? The wiki page only gives a reference, an enumeration of available options. Using these might not always be transparent. I know it's tutorial-level info, but why not have it? Giving a show-case of customizing vm to a specific need would be great. Thank you, Nadya Morozova -Original Message- From: Pavel Ozhdikhin [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 14, 2006 9:23 AM To: harmony-dev@incubator.apache.org Subject: Re: Re: [doc][drlvm] The document Getting started with DRL is outdated Nadya, I've looked through your patch. Please see my comments in JIRA: http://issues.apache.org/jira/browse/HARMONY-2150 Do you think we can add a link to debugging vmjit doc (or to wiki)? I don't think we need it - it is rather info for developers than for users. Any ideas on what to write in Configuring vm operation? This section will duplicate the info from the Wiki page. Since we gave a link to that page in the overview we may skip creation of a separate section here. Thanks, Pavel On 11/13/06, Morozova, Nadezhda [EMAIL PROTECTED] wrote: Successfully added a patch to fix getting Started outdated content to http://issues.apache.org/jira/browse/HARMONY-2150. The patch is not final - need help to add more content. The current structure is: - overview - running an app - eclipse-related (now much shorter) -- running an app -- debugging an app - configuring vm operation (empty) Questions: how do you like the current patch? Do you think we can add a link to debugging vmjit doc (or to wiki)? Any ideas on what to write in Configuring vm operation? Thank you, Nadya Morozova -Original Message- From: news [mailto:[EMAIL PROTECTED] On Behalf Of Egor Pasko Sent: Monday, November 13, 2006 1:00 PM To: harmony-dev@incubator.apache.org Subject: Re: [doc][drlvm] The document Getting started with DRL is outdated On the 0x220 day of Apache Harmony Nadezhda Morozova wrote: -Original Message- From: news [mailto:[EMAIL PROTECTED] On Behalf Of Egor Pasko Sent: Monday, November 13, 2006 12:40 PM To: harmony-dev@incubator.apache.org Subject: Re: [doc][drlvm] The document Getting started with DRL is outdated On the 0x220 day of Apache Harmony Nadezhda Morozova wrote: Ok, I'll use http://issues.apache.org/jira/browse/HARMONY-2150 to get an initial patch for the getting started document, and we can then work to improve it. OK, I am watching it Let's make it a short page with links to wiki and maybe some how-tos. To summarize: * we agreed that there will be no eclipse screenshots (they are for eclipse+drlvm page) * we agreed that there should be something like see what kind of links we have Am I right? [Nadya] Yop, quite right. An additional enhancement would be to comment out copyrights and update info that is incorrect. remove these annoyed substances? I am not an expert in copyright law, not sure we can remove them. But copyright notices are not what I desire to look at on the getting started page. Not sure I'll fix everything, but can give a start. Thanks for all your help. u r welcome Thank you, Nadya Morozova -Original Message- From: news [mailto:[EMAIL PROTECTED] On Behalf Of Egor Pasko Sent: Monday, November 13, 2006 11:10 AM To: harmony-dev@incubator.apache.org Subject: Re: [doc][drlvm] The document Getting started with DRL is outdated On the 0x21D day of Apache Harmony Nadezhda Morozova wrote: Egor, I think we're mixing things up a bit, or at least our perceptions of various docs. I'd not call what you're suggesting a tutorial - it's more of a howto doc, right? We are lucky to have Salikh write this How to write a GC? Doc - do you mean something similar for DRLVM Command-line Args Tutorial? on Wikipedia: * A _how-to_ is an informal, often short, description of how to accomplish some specific task * A _tutorial_ is a document, software, or other media created for the purpose of instruction for any of a wide variety of tasks yes, I mix those terms :) As
Re: [drlvm][test]Exclude some tests from build test target, make 'build test' pass
2006/11/14, Gregory Shimansky [EMAIL PROTECTED]: On Monday 13 November 2006 15:51 Elena Semukhina wrote: On 10/26/06, Elena Semukhina [EMAIL PROTECTED] wrote: After H-1823 has been committed, I still see intermittent failures of drlvm kernel ThreadTest. Normally this test passes but today I got ThreadTest.testInterrupt_Sleeping() and testGetStateBlocked() failures. There is H-1789 for the first issue but it is not reprodiced with the attached test anymore. For the second test I filed H-1876 to make the test more stable. The patch has been committed recently but the test still may fail. I'd like someone to review the above mentioned tests to be sure they are correct otherwise we need to investigate failures and file JIRA's before the tests are exclued. I looked at ThreadTest again and found one more incorrectness in testGetStateBlocked(): it does not wait for the thread's run() method actually starts. I filed https://issues.apache.org/jira/browse/HARMONY-2166 and attached the patch. I ran the test more than 100 times and did not see a failure. Cool! I'd like to see this patch applied (in case it really helps) ASAP. Alexey V, please don't hold it for long. I would really like to see all acceptance to pass again on all platforms and then we'll maintain no regression state. Verified and applied (at r474672). BTW, seems we are very close to 100% pass rate for classlib tests on DRLVM. The wiki status page [1] lists just few pending issues, hopefully we'll fix them all in a couple of days. [1] http://wiki.apache.org/harmony/Unit_Tests_Pass_on_DRLVM
Re: [vm][classlib] hythr library
2006/11/14, Alexei Fedotov [EMAIL PROTECTED]: Andrey, Angela, If I understood a problem correctly Alexey asked to make a developer's life easier. Yes :) It looks like now a developer should rebuild class library, then to rebuild DRLVM each time he wants to check his class library changes with DRLVM. No :) He should not but he could. That's an another solution: 1. Go to classlib 2. Build it 3. Go to DRL VM 4. Build it (DRL VM copies classlib to internal deploy directory while build) 5. Go to classlib 6. Run the tests, pointing to DRL VM internal deploy directory Can we simplify the procedure? For example, if I don't change DRLVM, I shouldn't rebuild it each time to have correct files in jre/bin. * This is more conventional. * This allows people to use prebuilt DRLVM binaries. * Prebuilt binaries minimize astonishment for a class library developer. The easiest way to achieve this is to copy DRL VM to deploy directory of class library and make it possible for IBM VME and DRL VM to work in one deploy directory. That's what I'm talking about. Another big reason for this solution is to give Harmony users an easy possibility to switch between different Harmony VMs. Alexey mentioned scripts as a quick solution. Is it possible to solve this problem on a build script level? Yes, it's possible. We could specify needed VM by property and copy hythr library for needed VM in class library test target. But this solution looks like a hack but not fix :) Or should we change a launcher to reorder paths in LD_LIBRARY_PATH? That's possible solution two. But I think it will be easier to move hythr library to VMs directory (deploy/jdk/jre/bin/default or so) and let VM load it from there. Your design discussion about long term solution is quite interesting reading as well. Andrey said IBM should expose object layout. Let me speculate on it a bit. I really don't have any knowledge on J9, so any coincidence is not intentional. * Imagine that J9 is able to work with Sun's class library that was licensed by IBM from Sun for 10 years. * Imagine that class library has functions which access objects directly for performance reasons. Taking these two statements together I don't think we should count on exposing this object layout to the third party when this third party is a competing Open Source community. Thank you, Alexei On 11/13/06, Angela Lin [EMAIL PROTECTED] wrote: Hmm... Pre-Harmony, the IBM VM + classlib used the same thread library. When the classlib was contributed, I guess they forked the thread lib and changed the names of the functions. (I'm only speculating since I wasn't involved in that process.) hythr should be virtually identical to a subset of j9thr23.dll. I agree, the IBM VM + classlib should be using the same thread library. It shouldn't be hard to implement a redirector lib from hythr to j9thr. Would this obsolete the current classlib hythr implementation? Angela On 11/13/06, Andrey Chernyshev [EMAIL PROTECTED] wrote: On 11/13/06, Alexey Petrenko [EMAIL PROTECTED] wrote: Guys, is there any progress in making possible for IBM and DRL VM to use the same hythr library? I imagine they would have to share some more VM internals first, like GC or object layout interface, before they can migrate to a common threading library :) It is really a pain now to run class library tests on DRLVM now. And nearly impossible to easy switch VMs by launcher command line parameters. Since class library builds IBM version of hythr library and rewrites it in jre/bin directory. So you need to copy this library What if just disable copying of the hythr.dll into the deploy/jre/jdk/bin directory, may be harmony-vme could be providing the one? from DRL VM after each build. (Yes, I know how to write scripts :) If it is not possible for both VMs to use the same library probably we need to move these libraries to VM directories... +1. Seems like we don't have any VM at the moment which would be really using the hythr from classlib. Even IBM VME doesn't use the hythr. As Tim wrote earlier, VME is using it's own threading library called j9thr23 [1]. Does it differ a much from the hythr? Guess it might be favourable for the classlib + IBM VME stack as well if it was using a single thread library. Would it be possible for VME to include a straightforward hythr implementation which can delegate hythread_* calls to the j9thr23? Thanks, Andrey. [1] http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200606.mbox/[EMAIL PROTECTED] SY, Alexey -- Andrey Chernyshev Intel Enterprise Solutions Software Division -- Thank you, Alexei
Re: [jira] Patch available setting
From the one hand, fix checking by issue creator is good... But from the other hand, bug submitter could be a person who is using Harmony snapshot and does not know how to apply the patch and build Harmony... It is also possible that issue creator is not subscribed to Harmony dev list... So I think that *require* from issue creator to check the fix *before* not the best solution. Let's allow to set this field to everybody and clear it for committers (if it's possible :) In this case resolution provider could set the property and committer could clear it if he does not like the fix... SY, Alexey 2006/11/14, Alexei Fedotov [EMAIL PROTECTED]: Sian, This is a good catch. I have the following justification for 3. I think it is better process when a bug submitter validates a patch *before* commit to ensure that it is good. Also it validates the patch *after*. This worth to be requested via public alias. Why a bug submitter should do a pre-commit check? He has most interest in the bug resolution. Thanks! On 11/13/06, Sian January [EMAIL PROTECTED] wrote: Hi, I have just discovered that it's not possible for a contributor to set Patch available on a JIRA unless they reported it. (I'm not sure about committers as I'm not one...) I imagine this is to stop people coming in and editing other details on the JIRA, so I can see that it makes sense. My question is, what is the best thing to do if I attach a patch to a JIRA and I can't set Patch available? I can think of three alternatives at the moment: 1. Assume that the reporter will notice and set it themselves (or commit the fix if they're also a comitter) 2. E-mail the reporter privately 3. Post to the mailing list Or a fourth alternative would be a combination of the above where the person who contributed the patch waits a few days before doing either 2 or 3. Any thoughts on what would be best? Thanks, Sian -- Sian January IBM Java Technology Centre, UK -- Thank you, Alexei
Re: [testing][nio] 2 tests fail on the SUSE linux
2006/11/14, Tim Ellison [EMAIL PROTECTED]: Jimmy, Jing Lv wrote: However IMO it was Support_PortManager.getNextPort() cause the problem. This method, as we already know, is unsafe. Thus the test is not stable sometimes, though it appears in-frequently. Agreed, I've mentioned this before. We may find a way to fix it, e.g, try to bind to an available port, check if successful. The tests should be modified to bind to port zero and let the OS allocate the next available port. +1
Re: Japitools 0.9.7 released
Great news! Thanks, Stuart, for creation and support of such useful software! SY, Alexey 2006/11/14, Stuart Ballard [EMAIL PROTECTED]: I'm thrilled to be able to announce four things: 1) After far too long a wait, Japitools 0.9.7 Life, liberty[1] and the pursuit of Japiness has been released. This release includes the following improvements over 0.9.5: - Almost complete 1.5 language support, including generics, enums and varargs methods. The only missing feature for full language support (and the only blocker for a 1.0 release) is annotations. Big thanks to Jeroen Frijters for doing the heavy lifting of teaching Japitools to parse these features in .class files. - The ability to mark methods as not implemented by adding NotImplementedException to the throws clause. This allows Japitools to give results that more accurately match reality when parts of an API are known to have been stubbed out rather than actually being implemented. - The ability to traverse packages non-recursively (thanks to a contribution from Jaroslav Tuloch), making it easier to correctly specify the packages that are part of a public API, especially when that API is large. The new japiextractpkgs tool allows the list of packages to be extracted from Javadoc documentation. - An Ant task for running Japitools, thanks again to Jaroslav. - Too many bug fixes and minor enhancements to name, including a lot of changes that eliminate false positives and false negatives from the results. Thanks to many people for bug reports, feature suggestions and help in testing. 2) That there is now a Japitools mailing list, [EMAIL PROTECTED] See the mailing lists page (http://sab39.netreach.com/Software/Japitools/Mailing_Lists/52/) for more information. 3) That Japitools has a new homepage, http://sab39.netreach.com/japi/. It's ugly, and it's still a work in progress - some sections are still missing content, and others still have content that hasn't entirely been updated to match the current state of reality. I didn't want to delay any further getting the new release into people's hands. I'll continue working on filling out the content. 4) That Sun are AWESOME today! Stuart. [1] https://openjdk.dev.java.net/ -- http://sab39.netreach.com/
Re: [doc] site.css
2006/11/14, Nathan Beyer [EMAIL PROTECTED]: Spaces only please! +1 On 11/13/06, Ivanov, Alexey A [EMAIL PROTECTED] wrote: Hi all, I've updated formatting of definition lists DL on site: https://issues.apache.org/jira/browse/HARMONY-2173 The new formatting looks more natural to me; the screenshots can be found in the JIRA issue. When editing site.css I faced that there are many different styles of indentation used: * Some statements are indented using tabs, * Some -- using spaces, * And a mixture of tabs and space, in the worse case. There are also inconsistencies in formatting of rules, and trailing white-space. Let's agree on using either tabs or spaces for indentation of CSS statements. If they are different, it causes inconveniences when creating patches because some lines look changed while nothing was modified there. I have no strong opinion on which one to use here. But let it be one: either tabs or spaces. What do you think about it? Thank you in advance, -- Alexey A. Ivanov Intel EnterpriseSolutions SoftwareDivision
