Re: [vote] HARMONY-1363 - DRLVM fixes and additions
I've talked about a small patch for this exact issue of course.
SY, Alexey
2006/9/7, Alexey Varlamov [EMAIL PROTECTED]:
Alexey,
This conflict is trivial enough and was caused by recent Geir's
changes, see the parallel thread about launcher.
I don't think we need to redone the whole patch for this issue -
either commiter will resolve it by hand or minor patch for this
particular change can be made anew.
--
Regards,
Alexey
2006/9/7, Alexey Petrenko [EMAIL PROTECTED]:
Guys,
I've tried a patch.
Patch failed in ./vm/em/src/DrlEMImpl.cpp. On Linux and Windows.
Here is a rej file:
=== cut ===
***
*** 151,165
//_
// Reading and parsing configuration
- std::string buildDefaultLibPath(const std::string dll_name) {
- std::string library_path =
vm_get_property_value(vm.boot.library.path);
#ifdef PLATFORM_NT
- std::string fullPath = library_path + \\+ dll_name+.dll;
- #else
- std::string fullPath = library_path + /lib + dll_name + .so;
#endif
- return fullPath;
}
static std::string getParam(const std::string config, const
std::string name) {
--- 167,198
//_
// Reading and parsing configuration
+ static bool endsWith(const std::string str, const std::string suffix) {
+ if (str.length() suffix.length()) {
+ return false;
+ }
+ return std::equal(suffix.rbegin(), suffix.rend(), str.rbegin());
+ }
+ std::string prepareLibPath(const std::string origPath) {
#ifdef PLATFORM_NT
+ std::string separator(\\), libPrefix(), libSuffix(.dll);
+ #else
+ std::string separator(/), libPrefix(lib), libSuffix(.so);
#endif
+
+ std::string path = origPath;
+ if (path.find('/') == path.npos path.find('\\') == path.npos ) {
+ std::string dir = vm_get_property_value(vm.boot.library.path);
+ if (libPrefix.length() 0 !startsWith(path, libPrefix)) {
+ path = libPrefix + path;
+ }
+ path = dir + separator + path;
+ }
+ if (!endsWith(path, libSuffix)) {
+ path+=libSuffix;
+ }
+ return path;
}
static std::string getParam(const std::string config, const
std::string name) {
=== cut ===
As a result build fails.
Salikh, it seems that you need to provide additional patch.
SY, Alexey
2006/9/7, Alexey Varlamov [EMAIL PROTECTED]:
+1
2006/9/7, Geir Magnusson Jr. [EMAIL PROTECTED]:
+1
Geir Magnusson Jr. wrote:
All is in order and in SVN for Harmony-1225 wrt BCC and ACQ. I think
that this an important patch so we can get better 1.5 support et al.
Please vote to accept or reject this set of patches and fixes into the
Apache Harmony class library :
[ ] + 1 Accept
[ ] -1 Reject (provide reason below)
Lets let this run a minimum of 3 days unless a) someone states they need
more time or b) we get all committer votes before then.
geir
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Alexey A. Petrenko
Intel Middleware Products Division
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Alexey A. Petrenko
Intel Middleware Products Division
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] DRLVM, jre/bin/default and launcher
On 9/7/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Code is checked in for linux - and updating and testing now on WinXP. The issue was that all of our library loading was done with full paths, which didn't let APR via dlopen() use LD_LIBRARY_PATH. So I made some small mods - please review. One problem I found was that I had to make assumptions such as passing NULL instead of a path being safe, because there was no comments in the code about expected inputs (or resulting outputs). I also neutered vm.boot.library.path to be unless set on command line, rather than be the directory of the launching executable, as I figured that a) I needed to have it be and b) that would lead to some interesting failures when people tried to embed DRLVM in other apps or such. It seems we don't need vm.boot.library.path anymore. I propose to remove it from the sources completely. What do you think? I'll see what I can take out of HARMONY-1390 for some of the issues related to teardown. Or, Evgueni, you can tell me to close it and we can do another one. There seemed to be a few extra things included in that patch, btw :) Ok, let me give you some details regarding HARMONY-1390 patches. You definitely don't need classlib.launcher.patch anymore. drlvm.launcghr.patch contains the following logic parts: 1) Get rid of old DRLVM launcher and related stuff like parsing command line (new launcher do it for us) and executing main method. BTW I just noticed that I forgot to delete useless code in j.l.VMStarter class. 2) Fix stack trace creation for new scheme. Now when main thread starts application main method from native code through JNI we have different few first frames on the stack. See changes for vm\vmcore\src\kernel_classes\native\org_apache_harmony_vm_VMStack.cpp 3) Fix -help and -X options processing when VM is created by calling JNI_CreateJavaVM. 4) Changes related to new location of VM's dll's. We don't need part number 4) anymore since you did it in more elegant way. I believe it still makes sense to apply parts 1) 2) 3). Tomorrow, I'll finish the changes to the build so we get a launcher-based JRE and HDK. I know this isn't perfect, but it's a step forward - thanks all for all the help. geir (and for the record, working in C, C++ and Java all at the same time is a hoot...) Geir Magnusson Jr. wrote: Ok, I think I have this working now. DRLVM can be put anywhere and it works w/ the launcher w/o any unnatural acts with command line parameters and/or scripts. There are a few things to chat about - I'll get my thoughts together later tonight and post, and check in the code. I just wanted to let people know if they were thinking about working on it. geir Geir Magnusson Jr. wrote: Evgueni Brevnov wrote: On 9/6/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Evgueni Brevnov wrote: HI All, Good news! I have a patch to run DRLVM with the classlib's launcher (I've checked Hello and Eclipse applications on Windows only). Actually, there are two patches. The first one is for classlib which changes vm default directory to drlvm. I don't think we should do that - we'll keep it the same as it is now - default. Why should we change it? I don't care about it too much. Let it be default. In that case -vmdir option should be specified each time. Is it convenient for users? ? right now, default is the default. So the user doesn't have to specify anything... With the DRLVM stuff in jre/bin/default the user just types java BTW it seems there will be some problems with hythr.dll library if we wish to use drlvm and j9 in simultaneously. But that's another story... Yes, we need to resolve this. The second one is for build system and VM itself. Unfortunatelly, it is impossible to eliminate all problems in a short period of time. There is still a bunch of work in initialization and jni modules. So this patch is just a one more step to our goal. Great. As I said in other mails, the build stuff isn't the part to worry about but rather the VM itself. So does this patch do it completely, or should we wait? Yes, the patch contains changes for both parts vm and build. It was easy for me to change the build than do manual manipulations each time to check whether it runs OK or not. So does this mean if I apply the patch, then DRLVM works w/ the launcher from the jre/bin/default directory w/o any problems? geir The vm patch is quite heavy so I attach it and classlib patch. Hope it will work not only for me :-) On 9/5/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Salikh Zakirov wrote: Andrey Chernyshev wrote: 1. Fix the DRLVM layout - rename vmcore to harmonyvm and move ..dll/.so into the default subdirectory such that one doesn't have to type -vm and -vmdir options; While would you want to rename DRLVM to Harmony VM? It feels to me like claiming DRLVM to be the only Harmony VM. On the
Re: [classlib][sql] Another confusing behavior: java.sql.Timestamp
Hello,
I have raised Harmony-1400[1] for this issue. Thanks a lot.
[1]http://issues.apache.org/jira/browse/HARMONY-1400
Best regards,
Richard.
On 8/30/06, Richard Liang [EMAIL PROTECTED] wrote:
Geir Magnusson Jr. wrote:
1) What should it do?
When calculating nanos value, underflow may occur if the given time is
near Long.MIN_VALUE. In fact, I'm also not sure what it should do. Just
notice that RI handles the underflow situation in a special/confusing
way, while Harmony does not have any handling.
2) if it's just a single value, why not fix it and never have to deal
w/ it again? Is it an easy fix?
Yes, the fix is quite easy. Do you mean we shall follow RI?
Thanks a lot.
Richard.
geir
Anton Luht wrote:
Hello,
I don't think we should bother about single value which is very
unlikely to happpen in real data.
On 8/29/06, Richard Liang [EMAIL PROTECTED] wrote:
Hello All,
RI's java.sql.Timestamp(long time) behaves confusing when the
parameter time is in Long.MIN_VALUE. Shall we follow RI?
Output of the following sample is:
time: -9223372036854775808
time: 9223372036854775192
timestamp: 292278994-08-17 15:12:55.192
timestamp: 292278994-08-17 15:12:55.192
=
import java.sql.Timestamp;
public class TimeStampTest {
public static void main(String[] args) {
long time = Long.MIN_VALUE;
long time2 = 9223372036854775192l;
Timestamp timestamp = new Timestamp(time);
Timestamp timestamp2 = new Timestamp(time2);
System.out.println(time: + time);
System.out.println(time: + time2);
System.out.println(timestamp: + timestamp);
System.out.println(timestamp: + timestamp2);
}
}
--
Richard Liang
China Software Development Lab, IBM
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Richard Liang
China Software Development Lab, IBM
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Richard Liang
China Software Development Lab, IBM
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [build] Use Sun 5.0_8 or Eclipse Compiler for automated builds
Nathan Beyer wrote:
-Original Message-
From: Richard Liang [mailto:[EMAIL PROTECTED]
Sun compiler (5.0_8) also has some unexpected behavior. See[1]
[1]http://mail-archives.apache.org/mod_mbox/incubator-harmony-
dev/200608.mbox/[EMAIL PROTECTED]
I've found that a second or third ant build takes care of it. What I've
noticed though is that the failures are all linking to elements from classes
in luni-kernel. I'm looking at it, but I think there are some issues with
what's put on the bootclasspath. I've already found one discrepancy between
some of our 'luni-kernel' stubs and the spec. The Method.invoke() uses a
vararg and our stub didn't have this.
I spotted this as well, was preparing a patch for it - unless you want
to just go ahead and
fix it?
Regards,
Oliver
-Nathan
There are a number of places that use ReferenceQueues and Reference, but
can't be generified because of a bug in the Sun compilers prior to
5.0_8. At
the end of this email is an example of code that causes a compiler error
in
previous releases. This issue does not affect the Eclipse compiler. I've
run
a full rebuild as of revision 440796 and everything compiles fine with
both
the Eclipse compiler and Sun 5.0_8 compiler.
-Nathan
private static final ReferenceQueueObject cacheQueue = new
ReferenceQueueObject();
private static final class CacheEntry extends WeakReferenceObject
{
String key;
CacheEntry(Object jar, String key, ReferenceQueueObject queue)
{
super(jar, queue);
this.key = key;
}
}
// ... code using the queue
CacheEntry entry;
// This cast fails on Sun 5.0_7 and prior compilers
while ((entry = (CacheEntry)cacheQueue.poll()) != null) {
jarCache.remove(entry.key);
}
// . more code
--
Richard Liang
China Software Development Lab, IBM
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Oliver Deakin
IBM United Kingdom Limited
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [build] Use Sun 5.0_8 or Eclipse Compiler for automated builds
2006/9/7, Oliver Deakin [EMAIL PROTECTED]:
Nathan Beyer wrote:
-Original Message-
From: Richard Liang [mailto:[EMAIL PROTECTED]
Sun compiler (5.0_8) also has some unexpected behavior. See[1]
[1]http://mail-archives.apache.org/mod_mbox/incubator-harmony-
dev/200608.mbox/[EMAIL PROTECTED]
I've found that a second or third ant build takes care of it. What I've
noticed though is that the failures are all linking to elements from classes
in luni-kernel. I'm looking at it, but I think there are some issues with
what's put on the bootclasspath. I've already found one discrepancy between
some of our 'luni-kernel' stubs and the spec. The Method.invoke() uses a
vararg and our stub didn't have this.
I spotted this as well, was preparing a patch for it - unless you want
to just go ahead and
fix it?
Could you please restore j.l.Thread.setInterruptAction() co, as well?
--
Alexey
Regards,
Oliver
-Nathan
There are a number of places that use ReferenceQueues and Reference, but
can't be generified because of a bug in the Sun compilers prior to
5.0_8. At
the end of this email is an example of code that causes a compiler error
in
previous releases. This issue does not affect the Eclipse compiler. I've
run
a full rebuild as of revision 440796 and everything compiles fine with
both
the Eclipse compiler and Sun 5.0_8 compiler.
-Nathan
private static final ReferenceQueueObject cacheQueue = new
ReferenceQueueObject();
private static final class CacheEntry extends WeakReferenceObject
{
String key;
CacheEntry(Object jar, String key, ReferenceQueueObject queue)
{
super(jar, queue);
this.key = key;
}
}
// ... code using the queue
CacheEntry entry;
// This cast fails on Sun 5.0_7 and prior compilers
while ((entry = (CacheEntry)cacheQueue.poll()) != null) {
jarCache.remove(entry.key);
}
// . more code
--
Richard Liang
China Software Development Lab, IBM
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Oliver Deakin
IBM United Kingdom Limited
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][concurrent] Next IBM VME request
Tim Ellison wrote: Nathan Beyer wrote: For those kind souls working that help release the IBM VME, I'd like to ask for an implementation of the sun.misc.Unsafe interface for the next release to facilitate the 'concurrent' modules continued development. As such, the only portion of the Unsafe class that would need to be implemented is what's defined in the 'luni-kernel' module. Additionally, the 'concurrent' module has one other requirement and that's the implementation of a native method in AtomicLong [1]. My initial goal it to be able to enable all of the tests in the 'concurrent' module's build (all tests are currently disabled). Hey Nathan -- I'm just about to set off for a few days, but briefly, I'd expect that we'd agree on an addition to the luni kernel for some o.a.h.FooBar type that has the required functionality, and create sun.misc in the suncompat component. Agreed, this sounds like the right way to do it. Add a class to the suncompat module that redirects method calls to some o.a.h class in luni kernel. Regards, Oliver Regards, Tim Let me and the list know how we can help if there's anything needed. Thanks. -Nathan [1] private static native boolean VMSupportsCS8(); -- Oliver Deakin IBM United Kingdom Limited - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [general] Marking JIRA issues before creation of patches.
Geir Magnusson Jr. wrote: Good. Also, don't just do things in JIRA. Add the comment in JIRA, but also send something to the dev list. That way, people who are interested will more easily notice and maybe offer to help, or such... +1, and for classlib, we have had some wiki pages[1]-[3] to list the ToDos and to record who is doing or has interest on what. [1] http://wiki.apache.org/harmony/component_development_status [2] http://wiki.apache.org/harmony/Excluded_tests [3] http://wiki.apache.org/harmony/ClassLibrary geir Oleg Khaschansky wrote: Hi all, There were situations when several people started work on the same issue simultaneously. This happens because it is impossible to assign an issue to a non-committer. I suggest the following process to prevent these collisions: 1. If non-committer starts investigation and is pretty sure that he will proceed with the patch then he adds a comment like starting investigation to the JIRA issue. Maybe we should have a special keyword for this to make a search easier. 2. If for some reason he is unable to provide the patch, he adds a comment about this also. What do you think about this? -- Oleg - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Paulex Yang China Software Development Lab IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [general] Marking JIRA issues before creation of patches.
-Original Message- From: Paulex Yang [mailto:[EMAIL PROTECTED] Sent: Thursday, September 07, 2006 12:38 PM To: harmony-dev@incubator.apache.org Subject: Re: [general] Marking JIRA issues before creation of patches. Geir Magnusson Jr. wrote: Good. Also, don't just do things in JIRA. Add the comment in JIRA, but also send something to the dev list. That way, people who are interested will more easily notice and maybe offer to help, or such... +1, and for classlib, we have had some wiki pages[1]-[3] to list the ToDos and to record who is doing or has interest on what. +1 Regards, Alexey. [1] http://wiki.apache.org/harmony/component_development_status [2] http://wiki.apache.org/harmony/Excluded_tests [3] http://wiki.apache.org/harmony/ClassLibrary geir Oleg Khaschansky wrote: Hi all, There were situations when several people started work on the same issue simultaneously. This happens because it is impossible to assign an issue to a non-committer. I suggest the following process to prevent these collisions: 1. If non-committer starts investigation and is pretty sure that he will proceed with the patch then he adds a comment like starting investigation to the JIRA issue. Maybe we should have a special keyword for this to make a search easier. 2. If for some reason he is unable to provide the patch, he adds a comment about this also. What do you think about this? -- Oleg - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Paulex Yang China Software Development Lab IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Alexey A. Ivanov Intel Middleware Product Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [build] Use Sun 5.0_8 or Eclipse Compiler for automated builds
Alexey Varlamov wrote:
2006/9/7, Oliver Deakin [EMAIL PROTECTED]:
Nathan Beyer wrote:
-Original Message-
From: Richard Liang [mailto:[EMAIL PROTECTED]
Sun compiler (5.0_8) also has some unexpected behavior. See[1]
[1]http://mail-archives.apache.org/mod_mbox/incubator-harmony-
dev/200608.mbox/[EMAIL PROTECTED]
I've found that a second or third ant build takes care of it.
What I've
noticed though is that the failures are all linking to elements
from classes
in luni-kernel. I'm looking at it, but I think there are some
issues with
what's put on the bootclasspath. I've already found one discrepancy
between
some of our 'luni-kernel' stubs and the spec. The Method.invoke()
uses a
vararg and our stub didn't have this.
I spotted this as well, was preparing a patch for it - unless you want
to just go ahead and
fix it?
Could you please restore j.l.Thread.setInterruptAction() co, as well?
Isn't setInterruptAction() a private method? Why do we need this in the
luni-kernel
stubs?
As far as I can see, that is the only method that has been removed
recently from the
Thread class stub - were there any others that I have missed that are
required?
Regards,
Oliver
--
Alexey
Regards,
Oliver
-Nathan
There are a number of places that use ReferenceQueues and
Reference, but
can't be generified because of a bug in the Sun compilers prior to
5.0_8. At
the end of this email is an example of code that causes a
compiler error
in
previous releases. This issue does not affect the Eclipse
compiler. I've
run
a full rebuild as of revision 440796 and everything compiles fine
with
both
the Eclipse compiler and Sun 5.0_8 compiler.
-Nathan
private static final ReferenceQueueObject cacheQueue = new
ReferenceQueueObject();
private static final class CacheEntry extends
WeakReferenceObject
{
String key;
CacheEntry(Object jar, String key, ReferenceQueueObject
queue)
{
super(jar, queue);
this.key = key;
}
}
// ... code using the queue
CacheEntry entry;
// This cast fails on Sun 5.0_7 and prior compilers
while ((entry = (CacheEntry)cacheQueue.poll()) !=
null) {
jarCache.remove(entry.key);
}
// . more code
--
Richard Liang
China Software Development Lab, IBM
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Oliver Deakin
IBM United Kingdom Limited
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Oliver Deakin
IBM United Kingdom Limited
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [build] Use Sun 5.0_8 or Eclipse Compiler for automated builds
2006/9/7, Oliver Deakin [EMAIL PROTECTED]: Alexey Varlamov wrote: 2006/9/7, Oliver Deakin [EMAIL PROTECTED]: Nathan Beyer wrote: -Original Message- From: Richard Liang [mailto:[EMAIL PROTECTED] Sun compiler (5.0_8) also has some unexpected behavior. See[1] [1]http://mail-archives.apache.org/mod_mbox/incubator-harmony- dev/200608.mbox/[EMAIL PROTECTED] I've found that a second or third ant build takes care of it. What I've noticed though is that the failures are all linking to elements from classes in luni-kernel. I'm looking at it, but I think there are some issues with what's put on the bootclasspath. I've already found one discrepancy between some of our 'luni-kernel' stubs and the spec. The Method.invoke() uses a vararg and our stub didn't have this. I spotted this as well, was preparing a patch for it - unless you want to just go ahead and fix it? Could you please restore j.l.Thread.setInterruptAction() co, as well? Isn't setInterruptAction() a private method? Why do we need this in the luni-kernel stubs? As long as luni-kernel stubs actually document VMI, we should keep all related methods there (until someone can suggest better place, which I doubt - you know, the code is best doc itslef and any separate docs become outdated sooner or later). Real-life example: I noted NoSuchMethodException in DRLVM trace logs, and was quite puzzled what it is about - so had to browse dev-list history... As far as I can see, that is the only method that has been removed recently from the Thread class stub - were there any others that I have missed that are required? Simply reapply luni-kernel part of HARMONY-635. Thank you! -- Regards, Alexey - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm]A subject to profiling instrumenting
On 9/6/06, zouqiong [EMAIL PROTECTED] wrote: Ok, I will put my diffs to the JIRA later. And I have solved the issue I asked two days ago. Ok, I will wait the JIRA number from you. It needs liblwdis.so supporting. Check JIRA 1402 for it. http://issues.apache.org/jira/browse/HARMONY-1402 -- Mikhail Fursov
Re: [DRLVM][JIT] can Jitrino.JET call MMTk alloc() instead of C helper?
Weldon, the problem is clear. I going to add the support to JET in a day. + Note that even for a simple single method HelloWorld application DRLVM starts multiple threads to support finalization. Also some threads may be created by API itself (but I'm not sure it does). So, at least, you need to disable finalizer threads with -Dvm.finalize=false property. On 9/6/06, Weldon Washburn [EMAIL PROTECTED] wrote: On 9/6/06, Mikhail Fursov [EMAIL PROTECTED] wrote: Weldon, The replacement of the 'new' opcode call with another call is relatively easy task. To send a working patch I need the following information: 1) Which Java method to call? Is it an instance method or a static? Its an instance method. Ideally you can use the same approach as the one used when adding write barriers to Jitrino.JET. Specifically PlanLocal.javain Jira Harmony-816. The API is: public Address alloc(int bytes, int align, int offset, int allocator, int site); The only parameter I care about at this time is bytes. This must be accurate. I will ignore the rest of the parameters. In other words, to allocate a 52 byte object, the call site should look like: alloc( 52, 0, 0, 0, 0); Make sure the JIT loads the vtable ptr (and array length if required). 2) How to test the implementation? I can get and deploy all of your changes or just to call some stub methods in a specialized testcase before sending the result to you. It would be best to test with a stub that is similar to what's in Harmony-816. It would also be great if the object allocator can chosen by pattern matching on the method name. A similar facility already exists for the write barrier -- it might be a simple cut/paste. The above will work fine during the single thread stage of this project. Once we decide to turn on multiple Java threads, we will need to stuff a thread specific MMTk object in DRLVM's thread block. Then during execution of JITed code, use vmmagic to load fs:14+offset_of_the_alloc_object into, for example, EBX. Do a mov eax, [ebx] to get the vtable pointer into eax. And finally, call [eax + offset_of_the_alloc_method]. Let me know if you have further questions. ? On 9/6/06, Weldon Washburn [EMAIL PROTECTED] wrote: A question for Jitrino.JET developers. How hard would it be to modify the existing Jitrino.JET code so that the new opcode calls MMTk alloc()? Thanks -- Weldon Washburn Intel Middleware Products Division -- Mikhail Fursov -- Weldon Washburn Intel Middleware Products Division -- Mikhail Fursov
Re: [jira] Created: (HARMONY-1395) Code for reading and writing binary DTDs using ASN.1 encoding
Hi Miguel
Thanks for your patches! Could you please grant ASF license to them?
Thanks,
Mikhail
2006/9/7, Miguel Montes (JIRA) [EMAIL PROTECTED]:
Code for reading and writing binary DTDs using ASN.1 encoding
-
Key: HARMONY-1395
URL: http://issues.apache.org/jira/browse/HARMONY-1395
Project: Harmony
Issue Type: Improvement
Components: Contributions
Reporter: Miguel Montes
Attachments: ASN1_01.patch, ASN1_ITC-Contribution_20060905.zip
The class javax.swing.text.html.parser.DTD has a method read() for loading a
binary DTD. The format of this binary file is not specified, so the current
implementation uses serialization. This approach has several problems, so it
was suggested in harmony-dev the use of ASN.1 to encode the DTD information.
Attached is a zip file with a set of classes for encoding and decoding a DTD,
using the ASN.1 framework already in use in javax.crypto; and two bdtds, one
for HTML 3.2 and one for HTML 4.01. Also attached is a patch for DTD.java and
DTDUtilities.java.
The proposed format is:
BDTD ::= SEQUENCE {
name UTF8String,
entity SET OF HTMLEntity,
element SET OF HTMLElement
}
HTMLEntity ::= SEQUENCE {
name UTF8String,
value INTEGER,
general [0] IMPLICIT BOOLEAN DEFAULT FALSE,
parameter [1] IMPLICIT BOOLEAN DEFAULT FALSE,
data UTF8String
}
HTMLElement ::= SEQUENCE {
index INTEGER,
name UTF8String,
type INTEGER,
oStart BOOLEAN,
oEnd BOOLEAN,
exclusions [0] IMPLICIT SET OF INTEGER OPTIONAL,
inclusions [1] IMPLICIT SET OF INTEGER OPTIONAL,
attributes SET OF HTMLElementAttributes OPTIONAL,
contentModel HTMLContentModel
}
HTMLContentModel ::= SEQUENCE OF SEQUENCE {
type INTEGER,
index INTEGER
}
HTMLElementAttributes ::= SEQUENCE {
name UTF8String,
type INTEGER,
modifier INTEGER,
defaultValue UTF8String OPTIONAL,
possibleValues SET OF UTF8String OPTIONAL
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] HARMONY-1363 - DRLVM fixes and additions
+1 2006/9/7, Geir Magnusson Jr. [EMAIL PROTECTED]: All is in order and in SVN for Harmony-1225 wrt BCC and ACQ. I think that this an important patch so we can get better 1.5 support et al. Please vote to accept or reject this set of patches and fixes into the Apache Harmony class library : [ ] + 1 Accept [ ] -1 Reject (provide reason below) Lets let this run a minimum of 3 days unless a) someone states they need more time or b) we get all committer votes before then. geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Created: (HARMONY-1395) Code for reading and writing binary DTDs using ASN.1 encoding
Hi Mikhail:
The attach button in the JIRA form doesn't have the checkbox to grant the
license. Now I notice the button is there when you try to attach files to an
already created issue, so i understand I have to create the issue first, and
attach the files later.
What should i do now to grant the license? Re-attach the files granting the
license? Sorry if this was explained before, but i didn't read it
Miguel
On 9/7/06, Mikhail Loenko [EMAIL PROTECTED] wrote:
Hi Miguel
Thanks for your patches! Could you please grant ASF license to them?
Thanks,
Mikhail
2006/9/7, Miguel Montes (JIRA) [EMAIL PROTECTED]:
Code for reading and writing binary DTDs using ASN.1 encoding
-
Key: HARMONY-1395
URL: http://issues.apache.org/jira/browse/HARMONY-1395
Project: Harmony
Issue Type: Improvement
Components: Contributions
Reporter: Miguel Montes
Attachments: ASN1_01.patch, ASN1_ITC-Contribution_20060905.zip
The class javax.swing.text.html.parser.DTD has a method read() for
loading a binary DTD. The format of this binary file is not specified, so
the current implementation uses serialization. This approach has several
problems, so it was suggested in harmony-dev the use of ASN.1 to encode
the DTD information.
Attached is a zip file with a set of classes for encoding and decoding a
DTD, using the ASN.1 framework already in use in javax.crypto; and two
bdtds, one for HTML 3.2 and one for HTML 4.01. Also attached is a patch
for DTD.java and DTDUtilities.java.
The proposed format is:
BDTD ::= SEQUENCE {
name UTF8String,
entity SET OF HTMLEntity,
element SET OF HTMLElement
}
HTMLEntity ::= SEQUENCE {
name UTF8String,
value INTEGER,
general [0] IMPLICIT BOOLEAN DEFAULT FALSE,
parameter [1] IMPLICIT BOOLEAN DEFAULT FALSE,
data UTF8String
}
HTMLElement ::= SEQUENCE {
index INTEGER,
name UTF8String,
type INTEGER,
oStart BOOLEAN,
oEnd BOOLEAN,
exclusions [0] IMPLICIT SET OF INTEGER OPTIONAL,
inclusions [1] IMPLICIT SET OF INTEGER OPTIONAL,
attributes SET OF HTMLElementAttributes OPTIONAL,
contentModel HTMLContentModel
}
HTMLContentModel ::= SEQUENCE OF SEQUENCE {
type INTEGER,
index INTEGER
}
HTMLElementAttributes ::= SEQUENCE {
name UTF8String,
type INTEGER,
modifier INTEGER,
defaultValue UTF8String OPTIONAL,
possibleValues SET OF UTF8String OPTIONAL
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Miguel Montes
active discussion in Suns OpenSource-Java forum
Hi Harmonys! I want only to mention, that at http://forums.java.net/jive/thread.jspa?threadID=18036start=0tstart=0 is an active discussion about what GNU Classpath developer think, how Suns Java license must look like and what people think, if it is better to have only one implementation (if Suns Java is OpenSource) or more. Greatings theuserbl - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [jira] Created: (HARMONY-1395) Code for reading and writing binary DTDs using ASN.1 encoding
-Original Message-
From: Miguel Montes [mailto:[EMAIL PROTECTED]
Sent: Thursday, September 07, 2006 4:26 PM
To: harmony-dev@incubator.apache.org
Subject: Re: [jira] Created: (HARMONY-1395) Code for reading and
writing
binary DTDs using ASN.1 encoding
Hi Mikhail:
The attach button in the JIRA form doesn't have the checkbox to grant
the
license. Now I notice the button is there when you try to attach files
to
an
already created issue, so i understand I have to create the issue
first,
and
attach the files later.
What should i do now to grant the license? Re-attach the files granting
the
license? Sorry if this was explained before, but i didn't read IT
Miguel,
Yes, just re-attach the files granting the license.
It was discussed several weeks ago [1]. There were also several other
threads about this issue.
Regards,
Alexey.
[1]
http://thread.gmane.org/gmane.comp.java.harmony.devel/11975/focus=11991
Miguel
On 9/7/06, Mikhail Loenko [EMAIL PROTECTED] wrote:
Hi Miguel
Thanks for your patches! Could you please grant ASF license to them?
Thanks,
Mikhail
2006/9/7, Miguel Montes (JIRA) [EMAIL PROTECTED]:
Code for reading and writing binary DTDs using ASN.1 encoding
-
Key: HARMONY-1395
URL:
http://issues.apache.org/jira/browse/HARMONY-1395
Project: Harmony
Issue Type: Improvement
Components: Contributions
Reporter: Miguel Montes
Attachments: ASN1_01.patch,
ASN1_ITC-Contribution_20060905.zip
The class javax.swing.text.html.parser.DTD has a method read() for
loading a binary DTD. The format of this binary file is not
specified, so
the current implementation uses serialization. This approach has
several
problems, so it was suggested in harmony-dev the use of ASN.1 to
encode
the DTD information.
Attached is a zip file with a set of classes for encoding and
decoding
a
DTD, using the ASN.1 framework already in use in javax.crypto; and
two
bdtds, one for HTML 3.2 and one for HTML 4.01. Also attached is a
patch
for DTD.java and DTDUtilities.java.
The proposed format is:
BDTD ::= SEQUENCE {
name UTF8String,
entity SET OF HTMLEntity,
element SET OF HTMLElement
}
HTMLEntity ::= SEQUENCE {
name UTF8String,
value INTEGER,
general [0] IMPLICIT BOOLEAN DEFAULT FALSE,
parameter [1] IMPLICIT BOOLEAN DEFAULT FALSE,
data UTF8String
}
HTMLElement ::= SEQUENCE {
index INTEGER,
name UTF8String,
type INTEGER,
oStart BOOLEAN,
oEnd BOOLEAN,
exclusions [0] IMPLICIT SET OF INTEGER OPTIONAL,
inclusions [1] IMPLICIT SET OF INTEGER OPTIONAL,
attributes SET OF HTMLElementAttributes OPTIONAL,
contentModel HTMLContentModel
}
HTMLContentModel ::= SEQUENCE OF SEQUENCE {
type INTEGER,
index INTEGER
}
HTMLElementAttributes ::= SEQUENCE {
name UTF8String,
type INTEGER,
modifier INTEGER,
defaultValue UTF8String OPTIONAL,
possibleValues SET OF UTF8String OPTIONAL
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the
administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
--
Miguel Montes
--
Alexey A. Ivanov
Intel Middleware Product Division
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] Helper inlining in JIT
Hi Xiao-Feng, I think that MMTk unboxed package + native call support + tls access magics are enought for the all helpers I know. Do you know any examples to extend this list? On 8/29/06, Xiao-Feng Li [EMAIL PROTECTED] wrote: Fursov, what are the intrinsics supports you want to implement? The code below you gave has only a few examples. I think it would be a good idea to well define the instrinsics before code them. Thanks, xiaofeng -- Mikhail Fursov
Re: [drlvm] Helper inlining in JIT
On 9/7/06, Rana Dasgupta [EMAIL PROTECTED] wrote:
Hi Mikhail,
Sorry I left this thread for a while. Are you implementing VMMagic
support in .OPT currently, and prototyping with bump allocation? I am
just
trying to understand in what order we are doing this.
I'm implementing VMMagics and going to use it to prototype bump pointer
allocation. I hope I will finish VMMagic OPT package in a several weeks.
Would it be possible to list the fastpath helpers so that the java
interfaces to access them could be defined? All of them don't need magic
classes support and one of us could just write them. I don't know the list
of intrinsics implemented already in .JET. Can we just use them as is, and
what else ( other than TLS access, call support ) would need to be added?
The list of the helpers with fast path to be written in Java:
1) object allocation
2) array allocation
3) monitor enters
4) monitor exits
5) I hope we can move some profiling helpers to Java and to remove the
knowledge about their implementation from JIT.
6) write and read barriers
7) back branch polling helper
8) ? Some TI helpers ?
VM gurus, have you anything to add to this list?
+ I think that TLS and call support are enough.
BTW, there may be a small omission in the example below..if I am reading
this right...
IMO newCurrent = oldCurrent + size is OK. May be the source of the problem
is the variable name, i.e. 'ceiling' is always = 'current' in my example.
Thanks,
Rana
On 8/28/06, Mikhail Fursov [EMAIL PROTECTED] wrote:
Folks,
Here is the example of fast allocation helper written in Java with the
help
of VMMagic
If nobody objects I'm starting to implement VMMagic support in
Jitrino.OPTthis week.
private static final int GC_TLS_OFFSET = 10;
private static final int GC_CURRENT_OFFSET= GC_TLS_OFFSET + 0;
private static final int GC_CEILING_OFFSET= GC_TLS_OFFSET + 4;
private static final int OBJ_VTABLE_OFFSET = 0;
//annotate with calling convention and real VM helper id/name
information
private static Address slowAlloc(int vtable, int size) {throw new
Error(must never be called!);}
private static Address fastAlloc(int vtable, int size) {
Address tlsBase = TLS.getAddress(); //load thread local client area
address
Address currentFieldAddress = tlsBase.plus(GC_CURRENT_OFFSET);
Address ceilingFieldAddress = tlsBase.plus(GC_CEILING_OFFSET);
Address newObjectAddress; //the result of the method
// check if there is enough size to do allocation in thread local
buffer
Address current = currentFieldAddress.loadAddress();
Address ceiling = ceilingFieldAddress.loadAddress();
Address newCurrent = current.plus(size);
if (newCurrent.LT(ceiling)) {
newCurrent = newCurrent.plus(-size);
currentFieldAddress.store(newCurrent.toWord());
newObjectAddress = newCurrent;
newObjectAddress.store(vtable, Offset.fromInt
(OBJ_VTABLE_OFFSET));
} else {
newObjectAddress = slowAlloc(vtable, size);
}
return newObjectAddress;
}
--
Mikhail Fursov
--
Mikhail Fursov
Re: [jira] Created: (HARMONY-1395) Code for reading and writing binary DTDs using ASN.1 encoding
Done
On 9/7/06, Ivanov, Alexey A [EMAIL PROTECTED] wrote:
-Original Message-
From: Miguel Montes [mailto:[EMAIL PROTECTED]
Sent: Thursday, September 07, 2006 4:26 PM
To: harmony-dev@incubator.apache.org
Subject: Re: [jira] Created: (HARMONY-1395) Code for reading and
writing
binary DTDs using ASN.1 encoding
Hi Mikhail:
The attach button in the JIRA form doesn't have the checkbox to grant
the
license. Now I notice the button is there when you try to attach files
to
an
already created issue, so i understand I have to create the issue
first,
and
attach the files later.
What should i do now to grant the license? Re-attach the files granting
the
license? Sorry if this was explained before, but i didn't read IT
Miguel,
Yes, just re-attach the files granting the license.
It was discussed several weeks ago [1]. There were also several other
threads about this issue.
Regards,
Alexey.
[1]
http://thread.gmane.org/gmane.comp.java.harmony.devel/11975/focus=11991
Miguel
On 9/7/06, Mikhail Loenko [EMAIL PROTECTED] wrote:
Hi Miguel
Thanks for your patches! Could you please grant ASF license to them?
Thanks,
Mikhail
2006/9/7, Miguel Montes (JIRA) [EMAIL PROTECTED]:
Code for reading and writing binary DTDs using ASN.1 encoding
-
Key: HARMONY-1395
URL:
http://issues.apache.org/jira/browse/HARMONY-1395
Project: Harmony
Issue Type: Improvement
Components: Contributions
Reporter: Miguel Montes
Attachments: ASN1_01.patch,
ASN1_ITC-Contribution_20060905.zip
The class javax.swing.text.html.parser.DTD has a method read() for
loading a binary DTD. The format of this binary file is not
specified, so
the current implementation uses serialization. This approach has
several
problems, so it was suggested in harmony-dev the use of ASN.1 to
encode
the DTD information.
Attached is a zip file with a set of classes for encoding and
decoding
a
DTD, using the ASN.1 framework already in use in javax.crypto; and
two
bdtds, one for HTML 3.2 and one for HTML 4.01. Also attached is a
patch
for DTD.java and DTDUtilities.java.
The proposed format is:
BDTD ::= SEQUENCE {
name UTF8String,
entity SET OF HTMLEntity,
element SET OF HTMLElement
}
HTMLEntity ::= SEQUENCE {
name UTF8String,
value INTEGER,
general [0] IMPLICIT BOOLEAN DEFAULT FALSE,
parameter [1] IMPLICIT BOOLEAN DEFAULT FALSE,
data UTF8String
}
HTMLElement ::= SEQUENCE {
index INTEGER,
name UTF8String,
type INTEGER,
oStart BOOLEAN,
oEnd BOOLEAN,
exclusions [0] IMPLICIT SET OF INTEGER OPTIONAL,
inclusions [1] IMPLICIT SET OF INTEGER OPTIONAL,
attributes SET OF HTMLElementAttributes OPTIONAL,
contentModel HTMLContentModel
}
HTMLContentModel ::= SEQUENCE OF SEQUENCE {
type INTEGER,
index INTEGER
}
HTMLElementAttributes ::= SEQUENCE {
name UTF8String,
type INTEGER,
modifier INTEGER,
defaultValue UTF8String OPTIONAL,
possibleValues SET OF UTF8String OPTIONAL
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the
administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
--
Miguel Montes
--
Alexey A. Ivanov
Intel Middleware Product Division
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Miguel Montes
Re: [vote] HARMONY-1363 - DRLVM fixes and additions
thats something I just changed yesterday...
Alexey Petrenko wrote:
Guys,
I've tried a patch.
Patch failed in ./vm/em/src/DrlEMImpl.cpp. On Linux and Windows.
Here is a rej file:
=== cut ===
***
*** 151,165
//_
// Reading and parsing configuration
- std::string buildDefaultLibPath(const std::string dll_name) {
- std::string library_path =
vm_get_property_value(vm.boot.library.path);
#ifdef PLATFORM_NT
- std::string fullPath = library_path + \\+ dll_name+.dll;
- #else
- std::string fullPath = library_path + /lib + dll_name + .so;
#endif
- return fullPath;
}
static std::string getParam(const std::string config, const
std::string name) {
--- 167,198
//_
// Reading and parsing configuration
+ static bool endsWith(const std::string str, const std::string suffix) {
+ if (str.length() suffix.length()) {
+ return false;
+ }
+ return std::equal(suffix.rbegin(), suffix.rend(), str.rbegin());
+ }
+ std::string prepareLibPath(const std::string origPath) {
#ifdef PLATFORM_NT
+ std::string separator(\\), libPrefix(), libSuffix(.dll);
+ #else
+ std::string separator(/), libPrefix(lib), libSuffix(.so);
#endif
+
+ std::string path = origPath;
+ if (path.find('/') == path.npos path.find('\\') == path.npos ) {
+ std::string dir = vm_get_property_value(vm.boot.library.path);
+ if (libPrefix.length() 0 !startsWith(path, libPrefix)) {
+ path = libPrefix + path;
+ }
+ path = dir + separator + path;
+ }
+ if (!endsWith(path, libSuffix)) {
+ path+=libSuffix;
+ }
+ return path;
}
static std::string getParam(const std::string config, const
std::string name) {
=== cut ===
As a result build fails.
Salikh, it seems that you need to provide additional patch.
SY, Alexey
2006/9/7, Alexey Varlamov [EMAIL PROTECTED]:
+1
2006/9/7, Geir Magnusson Jr. [EMAIL PROTECTED]:
+1
Geir Magnusson Jr. wrote:
All is in order and in SVN for Harmony-1225 wrt BCC and ACQ. I think
that this an important patch so we can get better 1.5 support et al.
Please vote to accept or reject this set of patches and fixes into
the
Apache Harmony class library :
[ ] + 1 Accept
[ ] -1 Reject (provide reason below)
Lets let this run a minimum of 3 days unless a) someone states
they need
more time or b) we get all committer votes before then.
geir
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] DRLVM, jre/bin/default and launcher
Evgueni Brevnov wrote: On 9/7/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Code is checked in for linux - and updating and testing now on WinXP. The issue was that all of our library loading was done with full paths, which didn't let APR via dlopen() use LD_LIBRARY_PATH. So I made some small mods - please review. One problem I found was that I had to make assumptions such as passing NULL instead of a path being safe, because there was no comments in the code about expected inputs (or resulting outputs). I also neutered vm.boot.library.path to be unless set on command line, rather than be the directory of the launching executable, as I figured that a) I needed to have it be and b) that would lead to some interesting failures when people tried to embed DRLVM in other apps or such. It seems we don't need vm.boot.library.path anymore. I propose to remove it from the sources completely. What do you think? I wasn't sure. It is used in Classloader and Runtime, I suppose as a parallel to Sun's equivalent? I'll see what I can take out of HARMONY-1390 for some of the issues related to teardown. Or, Evgueni, you can tell me to close it and we can do another one. There seemed to be a few extra things included in that patch, btw :) Ok, let me give you some details regarding HARMONY-1390 patches. You definitely don't need classlib.launcher.patch anymore. drlvm.launcghr.patch contains the following logic parts: 1) Get rid of old DRLVM launcher and related stuff like parsing command line (new launcher do it for us) and executing main method. BTW I just noticed that I forgot to delete useless code in j.l.VMStarter class. 2) Fix stack trace creation for new scheme. Now when main thread starts application main method from native code through JNI we have different few first frames on the stack. See changes for vm\vmcore\src\kernel_classes\native\org_apache_harmony_vm_VMStack.cpp 3) Fix -help and -X options processing when VM is created by calling JNI_CreateJavaVM. 4) Changes related to new location of VM's dll's. We don't need part number 4) anymore since you did it in more elegant way. I believe it still makes sense to apply parts 1) 2) 3). I was definitely going to do 1) and 3). I didn't really yet understand 2), but I'll study that and ask any questions if I have any. Thanks geir Tomorrow, I'll finish the changes to the build so we get a launcher-based JRE and HDK. I know this isn't perfect, but it's a step forward - thanks all for all the help. geir (and for the record, working in C, C++ and Java all at the same time is a hoot...) Geir Magnusson Jr. wrote: Ok, I think I have this working now. DRLVM can be put anywhere and it works w/ the launcher w/o any unnatural acts with command line parameters and/or scripts. There are a few things to chat about - I'll get my thoughts together later tonight and post, and check in the code. I just wanted to let people know if they were thinking about working on it. geir Geir Magnusson Jr. wrote: Evgueni Brevnov wrote: On 9/6/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Evgueni Brevnov wrote: HI All, Good news! I have a patch to run DRLVM with the classlib's launcher (I've checked Hello and Eclipse applications on Windows only). Actually, there are two patches. The first one is for classlib which changes vm default directory to drlvm. I don't think we should do that - we'll keep it the same as it is now - default. Why should we change it? I don't care about it too much. Let it be default. In that case -vmdir option should be specified each time. Is it convenient for users? ? right now, default is the default. So the user doesn't have to specify anything... With the DRLVM stuff in jre/bin/default the user just types java BTW it seems there will be some problems with hythr.dll library if we wish to use drlvm and j9 in simultaneously. But that's another story... Yes, we need to resolve this. The second one is for build system and VM itself. Unfortunatelly, it is impossible to eliminate all problems in a short period of time. There is still a bunch of work in initialization and jni modules. So this patch is just a one more step to our goal. Great. As I said in other mails, the build stuff isn't the part to worry about but rather the VM itself. So does this patch do it completely, or should we wait? Yes, the patch contains changes for both parts vm and build. It was easy for me to change the build than do manual manipulations each time to check whether it runs OK or not. So does this mean if I apply the patch, then DRLVM works w/ the launcher from the jre/bin/default directory w/o any problems? geir The vm patch is quite heavy so I attach it and classlib patch. Hope it will work not only for me :-) On 9/5/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Salikh Zakirov wrote: Andrey Chernyshev wrote: 1. Fix
Re: [DRLVM][JIT] can Jitrino.JET call MMTk alloc() instead of C helper?
Mikhail, Thanks. Please put the mods in JIRA Harmony-816. Thanks for pointing out the other drlvm threads. It turns out that even though these java threads are running, the MMTk user mode setup that has been created for initial integration only sees one single java thread. At some point soon we need to go multithread. When can you fix the vmmagic atomic operations? Thanks Weldon On 9/7/06, Mikhail Fursov [EMAIL PROTECTED] wrote: Weldon, the problem is clear. I going to add the support to JET in a day. + Note that even for a simple single method HelloWorld application DRLVM starts multiple threads to support finalization. Also some threads may be created by API itself (but I'm not sure it does). So, at least, you need to disable finalizer threads with -Dvm.finalize=false property. On 9/6/06, Weldon Washburn [EMAIL PROTECTED] wrote: On 9/6/06, Mikhail Fursov [EMAIL PROTECTED] wrote: Weldon, The replacement of the 'new' opcode call with another call is relatively easy task. To send a working patch I need the following information: 1) Which Java method to call? Is it an instance method or a static? Its an instance method. Ideally you can use the same approach as the one used when adding write barriers to Jitrino.JET. Specifically PlanLocal.javain Jira Harmony-816. The API is: public Address alloc(int bytes, int align, int offset, int allocator, int site); The only parameter I care about at this time is bytes. This must be accurate. I will ignore the rest of the parameters. In other words, to allocate a 52 byte object, the call site should look like: alloc( 52, 0, 0, 0, 0); Make sure the JIT loads the vtable ptr (and array length if required). 2) How to test the implementation? I can get and deploy all of your changes or just to call some stub methods in a specialized testcase before sending the result to you. It would be best to test with a stub that is similar to what's in Harmony-816. It would also be great if the object allocator can chosen by pattern matching on the method name. A similar facility already exists for the write barrier -- it might be a simple cut/paste. The above will work fine during the single thread stage of this project. Once we decide to turn on multiple Java threads, we will need to stuff a thread specific MMTk object in DRLVM's thread block. Then during execution of JITed code, use vmmagic to load fs:14+offset_of_the_alloc_object into, for example, EBX. Do a mov eax, [ebx] to get the vtable pointer into eax. And finally, call [eax + offset_of_the_alloc_method]. Let me know if you have further questions. ? On 9/6/06, Weldon Washburn [EMAIL PROTECTED] wrote: A question for Jitrino.JET developers. How hard would it be to modify the existing Jitrino.JET code so that the new opcode calls MMTk alloc()? Thanks -- Weldon Washburn Intel Middleware Products Division -- Mikhail Fursov -- Weldon Washburn Intel Middleware Products Division -- Mikhail Fursov -- Weldon Washburn Intel Middleware Products Division
Re: [general] Marking JIRA issues before creation of patches.
but again, I'll emphasize that you want to bring this to the dev list. Adding to a wiki or a JIRA is very silent compared to an introduction and discussion :) geir Paulex Yang wrote: Geir Magnusson Jr. wrote: Good. Also, don't just do things in JIRA. Add the comment in JIRA, but also send something to the dev list. That way, people who are interested will more easily notice and maybe offer to help, or such... +1, and for classlib, we have had some wiki pages[1]-[3] to list the ToDos and to record who is doing or has interest on what. [1] http://wiki.apache.org/harmony/component_development_status [2] http://wiki.apache.org/harmony/Excluded_tests [3] http://wiki.apache.org/harmony/ClassLibrary geir Oleg Khaschansky wrote: Hi all, There were situations when several people started work on the same issue simultaneously. This happens because it is impossible to assign an issue to a non-committer. I suggest the following process to prevent these collisions: 1. If non-committer starts investigation and is pretty sure that he will proceed with the patch then he adds a comment like starting investigation to the JIRA issue. Maybe we should have a special keyword for this to make a search easier. 2. If for some reason he is unable to provide the patch, he adds a comment about this also. What do you think about this? -- Oleg - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [build] Use Sun 5.0_8 or Eclipse Compiler for automated builds
Alexey Varlamov wrote: 2006/9/7, Oliver Deakin [EMAIL PROTECTED]: Alexey Varlamov wrote: 2006/9/7, Oliver Deakin [EMAIL PROTECTED]: Nathan Beyer wrote: -Original Message- From: Richard Liang [mailto:[EMAIL PROTECTED] Sun compiler (5.0_8) also has some unexpected behavior. See[1] [1]http://mail-archives.apache.org/mod_mbox/incubator-harmony- dev/200608.mbox/[EMAIL PROTECTED] I've found that a second or third ant build takes care of it. What I've noticed though is that the failures are all linking to elements from classes in luni-kernel. I'm looking at it, but I think there are some issues with what's put on the bootclasspath. I've already found one discrepancy between some of our 'luni-kernel' stubs and the spec. The Method.invoke() uses a vararg and our stub didn't have this. I spotted this as well, was preparing a patch for it - unless you want to just go ahead and fix it? Could you please restore j.l.Thread.setInterruptAction() co, as well? Isn't setInterruptAction() a private method? Why do we need this in the luni-kernel stubs? As long as luni-kernel stubs actually document VMI, we should keep all related methods there (until someone can suggest better place, which I doubt - you know, the code is best doc itslef and any separate docs become outdated sooner or later). Real-life example: I noted NoSuchMethodException in DRLVM trace logs, and was quite puzzled what it is about - so had to browse dev-list history... When I first saw this suggestion, I too thought that it shouldn't go in Thread. But where is it used or documented as part of VMI? I couldn't find it... geir As far as I can see, that is the only method that has been removed recently from the Thread class stub - were there any others that I have missed that are required? Simply reapply luni-kernel part of HARMONY-635. Thank you! -- Regards, Alexey - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Created: (HARMONY-1395) Code for reading and writing binary DTDs using ASN.1 encoding
Just add a comment saying I grant the attached materials under the
terms of the Apache License v2.0
Miguel Montes wrote:
Hi Mikhail:
The attach button in the JIRA form doesn't have the checkbox to grant the
license. Now I notice the button is there when you try to attach files
to an
already created issue, so i understand I have to create the issue first,
and
attach the files later.
What should i do now to grant the license? Re-attach the files granting the
license? Sorry if this was explained before, but i didn't read it
Miguel
On 9/7/06, Mikhail Loenko [EMAIL PROTECTED] wrote:
Hi Miguel
Thanks for your patches! Could you please grant ASF license to them?
Thanks,
Mikhail
2006/9/7, Miguel Montes (JIRA) [EMAIL PROTECTED]:
Code for reading and writing binary DTDs using ASN.1 encoding
-
Key: HARMONY-1395
URL: http://issues.apache.org/jira/browse/HARMONY-1395
Project: Harmony
Issue Type: Improvement
Components: Contributions
Reporter: Miguel Montes
Attachments: ASN1_01.patch, ASN1_ITC-Contribution_20060905.zip
The class javax.swing.text.html.parser.DTD has a method read() for
loading a binary DTD. The format of this binary file is not specified, so
the current implementation uses serialization. This approach has several
problems, so it was suggested in harmony-dev the use of ASN.1 to encode
the DTD information.
Attached is a zip file with a set of classes for encoding and
decoding a
DTD, using the ASN.1 framework already in use in javax.crypto; and two
bdtds, one for HTML 3.2 and one for HTML 4.01. Also attached is a patch
for DTD.java and DTDUtilities.java.
The proposed format is:
BDTD ::= SEQUENCE {
name UTF8String,
entity SET OF HTMLEntity,
element SET OF HTMLElement
}
HTMLEntity ::= SEQUENCE {
name UTF8String,
value INTEGER,
general [0] IMPLICIT BOOLEAN DEFAULT FALSE,
parameter [1] IMPLICIT BOOLEAN DEFAULT FALSE,
data UTF8String
}
HTMLElement ::= SEQUENCE {
index INTEGER,
name UTF8String,
type INTEGER,
oStart BOOLEAN,
oEnd BOOLEAN,
exclusions [0] IMPLICIT SET OF INTEGER OPTIONAL,
inclusions [1] IMPLICIT SET OF INTEGER OPTIONAL,
attributes SET OF HTMLElementAttributes OPTIONAL,
contentModel HTMLContentModel
}
HTMLContentModel ::= SEQUENCE OF SEQUENCE {
type INTEGER,
index INTEGER
}
HTMLElementAttributes ::= SEQUENCE {
name UTF8String,
type INTEGER,
modifier INTEGER,
defaultValue UTF8String OPTIONAL,
possibleValues SET OF UTF8String OPTIONAL
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm]A subject to profiling instrumenting
This is the JIRA number. https://issues.apache.org/jira/browse/HARMONY-1406 I upload the vm code, it`s not so large, 3.8 Megabytes. And the code still have bugs when profile the AALOAD. But I am not sure the GETFIELD and GETSTATIC are totally right. :( If you want to profile the AALOAD, please look at the _TEST_ macro in gen_aload() method. And the GETFIELD and GETSTATIC is opened automatically. Now I have the following schedule: 1.First implement the instrument which helps to profile the access patterns 2.Second using sampling to implement the instrument. 2006/9/7, Mikhail Fursov [EMAIL PROTECTED]: On 9/6/06, zouqiong [EMAIL PROTECTED] wrote: Ok, I will put my diffs to the JIRA later. And I have solved the issue I asked two days ago. Ok, I will wait the JIRA number from you. It needs liblwdis.so supporting. Check JIRA 1402 for it. http://issues.apache.org/jira/browse/HARMONY-1402 -- Mikhail Fursov -- Best Regards, Qiong,Zou
Re: [drlvm] Helper inlining in JIT
On 9/7/06, Mikhail Fursov [EMAIL PROTECTED] wrote:
On 9/7/06, Rana Dasgupta [EMAIL PROTECTED] wrote:
Hi Mikhail,
Sorry I left this thread for a while. Are you implementing VMMagic
support in .OPT currently, and prototyping with bump allocation? I am
just
trying to understand in what order we are doing this.
I'm implementing VMMagics and going to use it to prototype bump pointer
allocation. I hope I will finish VMMagic OPT package in a several weeks.
Would it be possible to list the fastpath helpers so that the java
interfaces to access them could be defined? All of them don't need magic
classes support and one of us could just write them. I don't know the
list
of intrinsics implemented already in .JET. Can we just use them as is,
and
what else ( other than TLS access, call support ) would need to be
added?
The list of the helpers with fast path to be written in Java:
1) object allocation
2) array allocation
3) monitor enters
4) monitor exits
5) I hope we can move some profiling helpers to Java and to remove the
knowledge about their implementation from JIT.
6) write and read barriers
7) back branch polling helper
8) ? Some TI helpers ?
VM gurus, have you anything to add to this list?
This is a good list to start with. I would focus on the first four for
now. This is because for the most part the interface from the common, fast
code to the slow not-so-common code is real simple and well understood. The
idea is to start with the simplest thing possible that exercises all the
vmmagic functions you want to add (call, thread-local access).
Write barriers fall into a different category. It depends on the write
barrier algorithm that happens to be implemented by the GC. And what the GC
happens to be written in. In other words, the integration we recently did
for MMTk probably does not apply to what Xiao Feng will be doing in GCV5.
Also on closer look, there are allocation algorithms that are not as simple
and clean as bump the pointer. For example a non-moving collector might
search size segregated lists to allocate an object. The point is that it
would be good if the JIT keeps the existing helper interface in addition to
the work you are proposing.
+ I think that TLS and call support are enough.
BTW, there may be a small omission in the example below..if I am reading
this right...
IMO newCurrent = oldCurrent + size is OK. May be the source of the
problem
is the variable name, i.e. 'ceiling' is always = 'current' in my example.
Thanks,
Rana
On 8/28/06, Mikhail Fursov [EMAIL PROTECTED] wrote:
Folks,
Here is the example of fast allocation helper written in Java with the
help
of VMMagic
If nobody objects I'm starting to implement VMMagic support in
Jitrino.OPTthis week.
private static final int GC_TLS_OFFSET = 10;
private static final int GC_CURRENT_OFFSET= GC_TLS_OFFSET + 0;
private static final int GC_CEILING_OFFSET= GC_TLS_OFFSET + 4;
private static final int OBJ_VTABLE_OFFSET = 0;
//annotate with calling convention and real VM helper id/name
information
private static Address slowAlloc(int vtable, int size) {throw new
Error(must never be called!);}
private static Address fastAlloc(int vtable, int size) {
Address tlsBase = TLS.getAddress(); //load thread local client
area
address
Address currentFieldAddress = tlsBase.plus(GC_CURRENT_OFFSET);
Address ceilingFieldAddress = tlsBase.plus(GC_CEILING_OFFSET);
Address newObjectAddress; //the result of the method
// check if there is enough size to do allocation in thread local
buffer
Address current = currentFieldAddress.loadAddress();
Address ceiling = ceilingFieldAddress.loadAddress();
Address newCurrent = current.plus(size);
if (newCurrent.LT(ceiling)) {
newCurrent = newCurrent.plus(-size);
currentFieldAddress.store(newCurrent.toWord());
newObjectAddress = newCurrent;
newObjectAddress.store(vtable, Offset.fromInt
(OBJ_VTABLE_OFFSET));
} else {
newObjectAddress = slowAlloc(vtable, size);
}
return newObjectAddress;
}
--
Mikhail Fursov
--
Mikhail Fursov
--
Weldon Washburn
Intel Middleware Products Division
Re: [build] Use Sun 5.0_8 or Eclipse Compiler for automated builds
2006/9/7, Geir Magnusson Jr. [EMAIL PROTECTED]: Alexey Varlamov wrote: 2006/9/7, Oliver Deakin [EMAIL PROTECTED]: Alexey Varlamov wrote: 2006/9/7, Oliver Deakin [EMAIL PROTECTED]: Nathan Beyer wrote: -Original Message- From: Richard Liang [mailto:[EMAIL PROTECTED] Sun compiler (5.0_8) also has some unexpected behavior. See[1] [1]http://mail-archives.apache.org/mod_mbox/incubator-harmony- dev/200608.mbox/[EMAIL PROTECTED] I've found that a second or third ant build takes care of it. What I've noticed though is that the failures are all linking to elements from classes in luni-kernel. I'm looking at it, but I think there are some issues with what's put on the bootclasspath. I've already found one discrepancy between some of our 'luni-kernel' stubs and the spec. The Method.invoke() uses a vararg and our stub didn't have this. I spotted this as well, was preparing a patch for it - unless you want to just go ahead and fix it? Could you please restore j.l.Thread.setInterruptAction() co, as well? Isn't setInterruptAction() a private method? Why do we need this in the luni-kernel stubs? As long as luni-kernel stubs actually document VMI, we should keep all related methods there (until someone can suggest better place, which I doubt - you know, the code is best doc itslef and any separate docs become outdated sooner or later). Real-life example: I noted NoSuchMethodException in DRLVM trace logs, and was quite puzzled what it is about - so had to browse dev-list history... When I first saw this suggestion, I too thought that it shouldn't go in Thread. Yep, I let the original discussion slip and still not comfortable about current state. I especially dislike using brute force as reflection to overcome design flaws... I will try to look into this closer, when time permits. But where is it used or documented as part of VMI? I couldn't find it... Used in java.nio.channels.spi.AbstractInterruptibleChannel, the only documentation was in javadocs to j.l.Thread.setInterruptAction(). geir As far as I can see, that is the only method that has been removed recently from the Thread class stub - were there any others that I have missed that are required? Simply reapply luni-kernel part of HARMONY-635. Thank you! -- Regards, Alexey - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][luni] signalis interruptus in hysock
On 9/1/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Artem Aliev wrote: The hyport and hy* are a porting layer that provides os independent interface. hysock_select() does not return EINTR on windows why it should do it under linux? either user presses Ctrl-c or ctrl-\ or VM uses other signals for its owns needs. I think you just gave me the answer. The *caller* to hysock_select() needs to decide what to do on EINTR, not hysock_select() itself. I still don't think this is a perfect solution, but I think it's better :) Does the above solve the problem completely or is it a temporary patch? Will the caller to hysock_select() need to have #ifdef Windows #ifdef Linux...? I still want to know about J9 though. Maybe I need to go work for IBM again :) geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Weldon Washburn Intel Middleware Products Division
Re: [classlib][luni] signalis interruptus in hysock
Weldon Washburn wrote: On 9/1/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Artem Aliev wrote: The hyport and hy* are a porting layer that provides os independent interface. hysock_select() does not return EINTR on windows why it should do it under linux? either user presses Ctrl-c or ctrl-\ or VM uses other signals for its owns needs. I think you just gave me the answer. The *caller* to hysock_select() needs to decide what to do on EINTR, not hysock_select() itself. I still don't think this is a perfect solution, but I think it's better :) Does the above solve the problem completely or is it a temporary patch? I don't know, but happy to call it a temporary patch - right now we're stuck, because we can't even run tomcat and I want to do a new snapshot. Will the caller to hysock_select() need to have #ifdef Windows #ifdef Linux...? We already have platform specific code that calls hysock_select() geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [build] Use Sun 5.0_8 or Eclipse Compiler for automated builds
Alexey Varlamov wrote: 2006/9/7, Geir Magnusson Jr. [EMAIL PROTECTED]: Alexey Varlamov wrote: As long as luni-kernel stubs actually document VMI, we should keep all related methods there (until someone can suggest better place, which I doubt - you know, the code is best doc itslef and any separate docs become outdated sooner or later). Real-life example: I noted NoSuchMethodException in DRLVM trace logs, and was quite puzzled what it is about - so had to browse dev-list history... When I first saw this suggestion, I too thought that it shouldn't go in Thread. Yep, I let the original discussion slip and still not comfortable about current state. I especially dislike using brute force as reflection to overcome design flaws... I will try to look into this closer, when time permits. Ah - I wasn't arguing for or against the technical solution, but just wondering about how to document. But where is it used or documented as part of VMI? I couldn't find it... Used in java.nio.channels.spi.AbstractInterruptibleChannel, the only documentation was in javadocs to j.l.Thread.setInterruptAction(). Got it - I understand now. I agree that we should put something in our Thread stub with good javadoc pointing back at j.n.c.spi.AIC... geir geir As far as I can see, that is the only method that has been removed recently from the Thread class stub - were there any others that I have missed that are required? Simply reapply luni-kernel part of HARMONY-635. Thank you! -- Regards, Alexey - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][luni] signalis interruptus in hysock
And one other comment on the proposed patch... it doesn't respect the timeout as it restarts the select() with the original timeout... Geir Magnusson Jr. wrote: Weldon Washburn wrote: On 9/1/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: Artem Aliev wrote: The hyport and hy* are a porting layer that provides os independent interface. hysock_select() does not return EINTR on windows why it should do it under linux? either user presses Ctrl-c or ctrl-\ or VM uses other signals for its owns needs. I think you just gave me the answer. The *caller* to hysock_select() needs to decide what to do on EINTR, not hysock_select() itself. I still don't think this is a perfect solution, but I think it's better :) Does the above solve the problem completely or is it a temporary patch? I don't know, but happy to call it a temporary patch - right now we're stuck, because we can't even run tomcat and I want to do a new snapshot. Will the caller to hysock_select() need to have #ifdef Windows #ifdef Linux...? We already have platform specific code that calls hysock_select() geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] HARMONY-1363 - DRLVM fixes and additions
+1 It contains JVMTI breakpoint support which I hope to use in future JVMTI development. On Thursday 07 September 2006 08:33 Geir Magnusson Jr. wrote: All is in order and in SVN for Harmony-1225 wrt BCC and ACQ. I think that this an important patch so we can get better 1.5 support et al. Please vote to accept or reject this set of patches and fixes into the Apache Harmony class library : [ ] + 1 Accept [ ] -1 Reject (provide reason below) Lets let this run a minimum of 3 days unless a) someone states they need more time or b) we get all committer votes before then. geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Gregory Shimansky, Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [build] Use Sun 5.0_8 or Eclipse Compiler for automated builds
Not that I agree or disagree about the Thread method, but perhaps we should start a new thread for that. -Nathan -Original Message- From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED] Sent: Thursday, September 07, 2006 11:31 AM To: harmony-dev@incubator.apache.org Subject: Re: [build] Use Sun 5.0_8 or Eclipse Compiler for automated builds Alexey Varlamov wrote: 2006/9/7, Geir Magnusson Jr. [EMAIL PROTECTED]: Alexey Varlamov wrote: As long as luni-kernel stubs actually document VMI, we should keep all related methods there (until someone can suggest better place, which I doubt - you know, the code is best doc itslef and any separate docs become outdated sooner or later). Real-life example: I noted NoSuchMethodException in DRLVM trace logs, and was quite puzzled what it is about - so had to browse dev-list history... When I first saw this suggestion, I too thought that it shouldn't go in Thread. Yep, I let the original discussion slip and still not comfortable about current state. I especially dislike using brute force as reflection to overcome design flaws... I will try to look into this closer, when time permits. Ah - I wasn't arguing for or against the technical solution, but just wondering about how to document. But where is it used or documented as part of VMI? I couldn't find it... Used in java.nio.channels.spi.AbstractInterruptibleChannel, the only documentation was in javadocs to j.l.Thread.setInterruptAction(). Got it - I understand now. I agree that we should put something in our Thread stub with good javadoc pointing back at j.n.c.spi.AIC... geir geir As far as I can see, that is the only method that has been removed recently from the Thread class stub - were there any others that I have missed that are required? Simply reapply luni-kernel part of HARMONY-635. Thank you! -- Regards, Alexey - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: harmony-dev- [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[classlib][luni] Put setInterruptAction() in our j.l.Thread stub?
This came up in another thread. Currently, java.nio.channels.spi.AbstractInterruptibleChannel depends on there being a setInterruptAction() method on java.lang.Thread. I certainly think that this kind of thing should be documented, so the question - should we add this to our Thread stub class? geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[classlib][luni] socketus interruptus - fix committed
I committed the initial fix to the socket interrupt problem. I stared at it a while and did what I thought the simplest thing possible. (Most of the staring was trying to grok some of the intent in the socket.c and hysock.c code... Simply put, I ensured that hysock_select() just dealt w/ that return code correctly, translating to the HSOCK error code. (I also did a bit of reformatting... apologies if it really upsets someone - I'll put it back). The result is that hysock_select() still behaves the same. I also modified one function in socket.c - the pollSelectRead() call - to deal with the interrupt return code from hysock_select(). I *think* I got it right, and am hoping that some others can review and comment. I'm embarrassed to have used a 'goto' (mimicing the style there), but didn't want to do the rewrite I wanted to while also fixing the interrupt problem. :) (I also want some better tests before we take it apart...) This of course fixes the problems w/ Tomcat that we created w/ the DRLVM thread manager fix, so I'm going to try to spin a new snapshot tonight. Also, I'll go and treat the other usages of hysock_select() to deal w/ this return code, but after there's been a period of review and comment for these changes. geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][luni] Put setInterruptAction() in our j.l.Thread stub?
On 9/8/06, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: This came up in another thread. Currently, java.nio.channels.spi.AbstractInterruptibleChannel depends on there being a setInterruptAction() method on java.lang.Thread. I certainly think that this kind of thing should be documented, so the question - should we add this to our Thread stub class? +1. It is a part of vmi, and we should add setInterruptAction Thread stub class as a private method. Thanks! geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Andrew Zhang China Software Development Lab, IBM
Re: [classlib][luni] Put setInterruptAction() in our j.l.Thread stub?
Geir Magnusson Jr. wrote: This came up in another thread. Currently, java.nio.channels.spi.AbstractInterruptibleChannel depends on there being a setInterruptAction() method on java.lang.Thread. I certainly think that this kind of thing should be documented, so the question - should we add this to our Thread stub class? Yes, the VMs whose Thread do not know how to interrupt a certain understratum blocking I/O(socket read/write, select, or so) is likely to use this method. Though DRLVM using SIGUSR2 may not meet this problem( does SIGUSR2 work on windows?). I agree this must be documented. But to DRLVM, one problem is how to tell the interruption is necessary(say, user invoke wake() or some other methods to ask them to stop) or can be ignored(say, caused by other unrelated interruption and can be recover like recently fix to hysock.c and socket.c). geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Best Regards! Jimmy, Jing Lv China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][luni] Put setInterruptAction() in our j.l.Thread stub?
Geir Magnusson Jr. wrote: This came up in another thread. Currently, java.nio.channels.spi.AbstractInterruptibleChannel depends on there being a setInterruptAction() method on java.lang.Thread. I certainly think that this kind of thing should be documented, so the question - should we add this to our Thread stub class? I think so, actually it has been added as part of patch for HARMONY-635 with documentations, but it was removed later for unknown reasons...I can recover it if no one objects. geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Paulex Yang China Software Development Lab IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][luni] socketus interruptus - fix committed
Geir Magnusson Jr. wrote:
I committed the initial fix to the socket interrupt problem. I stared
at it a while and did what I thought the simplest thing possible. (Most
of the staring was trying to grok some of the intent in the socket.c and
hysock.c code...
Simply put, I ensured that hysock_select() just dealt w/ that return
code correctly, translating to the HSOCK error code. (I also did a bit
of reformatting... apologies if it really upsets someone - I'll put it
back). The result is that hysock_select() still behaves the same.
I also modified one function in socket.c - the pollSelectRead() call -
to deal with the interrupt return code from hysock_select().
I *think* I got it right, and am hoping that some others can review and
comment. I'm embarrassed to have used a 'goto' (mimicing the style
there), but didn't want to do the rewrite I wanted to while also fixing
the interrupt problem. :) (I also want some better tests before we take
it apart...)
I've taken a quick review on the two files, and I like the reformatting
:) Maybe the goto can be avoid, but this does not matter much.
I notice the port lib, say hysock.c is modified, adding a line:
if (errno == EINTR) {
rc = portLibrary-error_set_last_error(portLibrary, errno,
HYPORT_ERROR_SOCKET_INTERRUPTED);
}
IMHO, we can avoid this modification, for method in socket.c the result
is judged by the return value(result), not last_error. IMHO, we'd
better do no modification on port lib. Please correct me if I'm wrong.
This of course fixes the problems w/ Tomcat that we created w/ the DRLVM
thread manager fix, so I'm going to try to spin a new snapshot tonight.
Also, I'll go and treat the other usages of hysock_select() to deal w/
this return code, but after there's been a period of review and comment
for these changes.
I have no objection if everything goes well, but still worry about how
to tell the difference between a necessary interruption(user
interruption) and this recover-able interruption.
geir
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Best Regards!
Jimmy, Jing Lv
China Software Development Lab, IBM
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][luni] socketus interruptus - fix committed
Jimmy, Jing Lv wrote:
Geir Magnusson Jr. wrote:
I committed the initial fix to the socket interrupt problem. I stared
at it a while and did what I thought the simplest thing possible.
(Most of the staring was trying to grok some of the intent in the
socket.c and hysock.c code...
Simply put, I ensured that hysock_select() just dealt w/ that return
code correctly, translating to the HSOCK error code. (I also did a
bit of reformatting... apologies if it really upsets someone - I'll
put it back). The result is that hysock_select() still behaves the same.
I also modified one function in socket.c - the pollSelectRead() call -
to deal with the interrupt return code from hysock_select().
I *think* I got it right, and am hoping that some others can review
and comment. I'm embarrassed to have used a 'goto' (mimicing the
style there), but didn't want to do the rewrite I wanted to while also
fixing the interrupt problem. :) (I also want some better tests
before we take it apart...)
I've taken a quick review on the two files, and I like the reformatting
:) Maybe the goto can be avoid, but this does not matter much.
It can certainly be avoided, but I didn't want to change too much at
this time.
I notice the port lib, say hysock.c is modified, adding a line:
if (errno == EINTR) {
rc = portLibrary-error_set_last_error(portLibrary, errno,
HYPORT_ERROR_SOCKET_INTERRUPTED);
}
IMHO, we can avoid this modification, for method in socket.c the result
is judged by the return value(result), not last_error. IMHO, we'd
better do no modification on port lib. Please correct me if I'm wrong.
Well, yes, it is judged by the return value, but if the semantics of
hyscok_ is that if there is an error, the platform error is set via
_error_set_last_error, then I wanted to follow the convention.
This was one more thing to chase down- I figured I'd just follow along
for now :)
This of course fixes the problems w/ Tomcat that we created w/ the
DRLVM thread manager fix, so I'm going to try to spin a new snapshot
tonight.
Also, I'll go and treat the other usages of hysock_select() to deal w/
this return code, but after there's been a period of review and
comment for these changes.
I have no objection if everything goes well, but still worry about how
to tell the difference between a necessary interruption(user
interruption) and this recover-able interruption.
I've been thinking about this a lot, and I just don't know. There is no
concept for this up in Java, so it's not like we're breaking anything there.
I do wonder if our concerns are overblown, that this is Just The Way
Things Are due to the history of how IO calls and signals evolved in
unix and linux.
But again, I'm not sure of myself here...
geir
geir
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [build] Use Sun 5.0_8 or Eclipse Compiler for automated builds
I think I have this issue fixed. I modified the 'build-java.xml' script to
use 'bootclasspath' instead of 'classpath' in the 'javac' task [1].
Please test it out and let me know if this works. It works for me on WinXP
and Sun JDK 5.0_8 and resolves the issue mentioned below.
[1]
http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/make/
build-java.xml?r1=440948r2=441358diff_format=h
-Original Message-
From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED]
Sent: Wednesday, September 06, 2006 10:07 PM
To: harmony-dev@incubator.apache.org
Subject: Re: [build] Use Sun 5.0_8 or Eclipse Compiler for automated
builds
Nathan Beyer wrote:
-Original Message-
From: Richard Liang [mailto:[EMAIL PROTECTED]
Sun compiler (5.0_8) also has some unexpected behavior. See[1]
[1]http://mail-archives.apache.org/mod_mbox/incubator-harmony-
dev/200608.mbox/[EMAIL PROTECTED]
I've found that a second or third ant build takes care of it.
LOL
That's not a solution.
What I've
noticed though is that the failures are all linking to elements from
classes
in luni-kernel. I'm looking at it, but I think there are some issues
with
what's put on the bootclasspath. I've already found one discrepancy
between
some of our 'luni-kernel' stubs and the spec. The Method.invoke() uses a
vararg and our stub didn't have this.
Cool.
-Nathan
There are a number of places that use ReferenceQueues and Reference,
but
can't be generified because of a bug in the Sun compilers prior to
5.0_8. At
the end of this email is an example of code that causes a compiler
error
in
previous releases. This issue does not affect the Eclipse compiler.
I've
run
a full rebuild as of revision 440796 and everything compiles fine with
both
the Eclipse compiler and Sun 5.0_8 compiler.
-Nathan
private static final ReferenceQueueObject cacheQueue = new
ReferenceQueueObject();
private static final class CacheEntry extends
WeakReferenceObject
{
String key;
CacheEntry(Object jar, String key, ReferenceQueueObject
queue)
{
super(jar, queue);
this.key = key;
}
}
// ... code using the queue
CacheEntry entry;
// This cast fails on Sun 5.0_7 and prior compilers
while ((entry = (CacheEntry)cacheQueue.poll()) != null) {
jarCache.remove(entry.key);
}
// . more code
--
Richard Liang
China Software Development Lab, IBM
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [build] Use Sun 5.0_8 or Eclipse Compiler for automated builds
I guess I have to take this one back. It seemingly killed the automated
linux build. I reverted the change, so hopefully that will fix the build.
Anyone with a Linux box willing to test out this change? Like I mentioned,
it works perfectly fine on WinXP.
Note: This would all go away if we used the Eclipse compiler - there's no
default bootclasspath to get in the way.
-Nathan
-Original Message-
From: Nathan Beyer [mailto:[EMAIL PROTECTED]
Sent: Thursday, September 07, 2006 10:12 PM
To: harmony-dev@incubator.apache.org
Subject: RE: [build] Use Sun 5.0_8 or Eclipse Compiler for automated
builds
I think I have this issue fixed. I modified the 'build-java.xml' script to
use 'bootclasspath' instead of 'classpath' in the 'javac' task [1].
Please test it out and let me know if this works. It works for me on WinXP
and Sun JDK 5.0_8 and resolves the issue mentioned below.
[1]
http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/mak
e/
build-java.xml?r1=440948r2=441358diff_format=h
-Original Message-
From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED]
Sent: Wednesday, September 06, 2006 10:07 PM
To: harmony-dev@incubator.apache.org
Subject: Re: [build] Use Sun 5.0_8 or Eclipse Compiler for automated
builds
Nathan Beyer wrote:
-Original Message-
From: Richard Liang [mailto:[EMAIL PROTECTED]
Sun compiler (5.0_8) also has some unexpected behavior. See[1]
[1]http://mail-archives.apache.org/mod_mbox/incubator-harmony-
dev/200608.mbox/[EMAIL PROTECTED]
I've found that a second or third ant build takes care of it.
LOL
That's not a solution.
What I've
noticed though is that the failures are all linking to elements from
classes
in luni-kernel. I'm looking at it, but I think there are some issues
with
what's put on the bootclasspath. I've already found one discrepancy
between
some of our 'luni-kernel' stubs and the spec. The Method.invoke() uses
a
vararg and our stub didn't have this.
Cool.
-Nathan
There are a number of places that use ReferenceQueues and Reference,
but
can't be generified because of a bug in the Sun compilers prior to
5.0_8. At
the end of this email is an example of code that causes a compiler
error
in
previous releases. This issue does not affect the Eclipse compiler.
I've
run
a full rebuild as of revision 440796 and everything compiles fine
with
both
the Eclipse compiler and Sun 5.0_8 compiler.
-Nathan
private static final ReferenceQueueObject cacheQueue = new
ReferenceQueueObject();
private static final class CacheEntry extends
WeakReferenceObject
{
String key;
CacheEntry(Object jar, String key, ReferenceQueueObject
queue)
{
super(jar, queue);
this.key = key;
}
}
// ... code using the queue
CacheEntry entry;
// This cast fails on Sun 5.0_7 and prior compilers
while ((entry = (CacheEntry)cacheQueue.poll()) != null)
{
jarCache.remove(entry.key);
}
// . more code
--
Richard Liang
China Software Development Lab, IBM
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: harmony-dev-
[EMAIL PROTECTED]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [build] Use Sun 5.0_8 or Eclipse Compiler for automated builds
Nathan Beyer wrote:
I think I have this issue fixed. I modified the 'build-java.xml' script to
use 'bootclasspath' instead of 'classpath' in the 'javac' task [1].
Why? What changed in the Sun compiler that warrants this?
Can we just switch to the eclipse compiler?
geir
Please test it out and let me know if this works. It works for me on WinXP
and Sun JDK 5.0_8 and resolves the issue mentioned below.
[1]
http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/make/
build-java.xml?r1=440948r2=441358diff_format=h
-Original Message-
From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED]
Sent: Wednesday, September 06, 2006 10:07 PM
To: harmony-dev@incubator.apache.org
Subject: Re: [build] Use Sun 5.0_8 or Eclipse Compiler for automated
builds
Nathan Beyer wrote:
-Original Message-
From: Richard Liang [mailto:[EMAIL PROTECTED]
Sun compiler (5.0_8) also has some unexpected behavior. See[1]
[1]http://mail-archives.apache.org/mod_mbox/incubator-harmony-
dev/200608.mbox/[EMAIL PROTECTED]
I've found that a second or third ant build takes care of it.
LOL
That's not a solution.
What I've
noticed though is that the failures are all linking to elements from
classes
in luni-kernel. I'm looking at it, but I think there are some issues
with
what's put on the bootclasspath. I've already found one discrepancy
between
some of our 'luni-kernel' stubs and the spec. The Method.invoke() uses a
vararg and our stub didn't have this.
Cool.
-Nathan
There are a number of places that use ReferenceQueues and Reference,
but
can't be generified because of a bug in the Sun compilers prior to
5.0_8. At
the end of this email is an example of code that causes a compiler
error
in
previous releases. This issue does not affect the Eclipse compiler.
I've
run
a full rebuild as of revision 440796 and everything compiles fine with
both
the Eclipse compiler and Sun 5.0_8 compiler.
-Nathan
private static final ReferenceQueueObject cacheQueue = new
ReferenceQueueObject();
private static final class CacheEntry extends
WeakReferenceObject
{
String key;
CacheEntry(Object jar, String key, ReferenceQueueObject
queue)
{
super(jar, queue);
this.key = key;
}
}
// ... code using the queue
CacheEntry entry;
// This cast fails on Sun 5.0_7 and prior compilers
while ((entry = (CacheEntry)cacheQueue.poll()) != null) {
jarCache.remove(entry.key);
}
// . more code
--
Richard Liang
China Software Development Lab, IBM
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[classlib] is it me, or is there a problem w/ the auto fetch of msvcr71.dll?
Seems like it gets a 500 and then goes to home page of dlldump.com geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] is it me, or is there a problem w/ the auto fetch of msvcr71.dll?
There is Harmony-1362 right about this... - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] is it me, or is there a problem w/ the auto fetch of msvcr71.dll?
The dlldump.com was down for a few days when 1362 was created. It became up for a few days then. And now msvcr71.dll is unavailable since yesterday. It looks like dlldump.com has some problems. SY, Alexey 2006/9/8, Alexey Varlamov [EMAIL PROTECTED]: There is Harmony-1362 right about this... - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Alexey A. Petrenko Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[classlib][luni]upgrade java.lang.Character to 5.0
Hi all, I have looked through the java.lang.Character and found there were several methods missing in Harmony. I'll try to implement these methods if no one objects :) All of these methods are coming with Supplementary Character Support of Tiger. That is, we should handle the character whose code point is after U+ in our code. After doing some research, I found there're two ways to achieve: 1.Maintain a HashMap contains the information of supplementary character and retrieve from it when these methods were invoked. 2.Delegate these methods to ICU4J, which provides extensions to the java.lang.Character class. What's your opinion? Any suggestion are welcome :) -- Tony Wu China Software Development Lab, IBM
Re: [classlib][luni]upgrade java.lang.Character to 5.0
On 9/8/06, Tony Wu [EMAIL PROTECTED] wrote: Hi all, I have looked through the java.lang.Character and found there were several methods missing in Harmony. I'll try to implement these methods if no one objects :) Great! Go ahead! All of these methods are coming with Supplementary Character Support of Tiger. That is, we should handle the character whose code point is after U+ in our code. After doing some research, I found there're two ways to achieve: 1.Maintain a HashMap contains the information of supplementary character and retrieve from it when these methods were invoked. Where does the data come from? 2.Delegate these methods to ICU4J, which provides extensions to the java.lang.Character class. I prefer this option, although ICU doesn't reponse very quickly. If icu4j works well, I think there's no reason for Harmony to reinvent the wheel. If there are some series bugs in ICU4J which may affect our goal, it's another story. For now, I strongly recommened you to study icu4j and take a try! Good luck. :-) What's your opinion? Any suggestion are welcome :) -- Tony Wu China Software Development Lab, IBM -- Andrew Zhang China Software Development Lab, IBM
Re: [classlib][luni]upgrade java.lang.Character to 5.0
Tony Wu 写道: Hi all, I have looked through the java.lang.Character and found there were several methods missing in Harmony. I'll try to implement these methods if no one objects :) All of these methods are coming with Supplementary Character Support of Tiger. That is, we should handle the character whose code point is after U+ in our code. After doing some research, I found there're two ways to achieve: 1.Maintain a HashMap contains the information of supplementary character and retrieve from it when these methods were invoked. 2.Delegate these methods to ICU4J, which provides extensions to the java.lang.Character class. What's your opinion? Any suggestion are welcome :) This task is to update current implementation of java.lang.Character, about some new feature of J2SE 5.0, it's important to reduce the risk of changing such a core class. The HashMap method may introduce more complexity and more maintenance effort into Harmony development, so I think delegating to ICU4J is the better choice. The only concern is that: does the ICU4J we currently using meet our need perfectly? - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][luni]upgrade java.lang.Character to 5.0
On 9/8/06, Robert Hu [EMAIL PROTECTED] wrote: Tony Wu 写道: Hi all, I have looked through the java.lang.Character and found there were several methods missing in Harmony. I'll try to implement these methods if no one objects :) All of these methods are coming with Supplementary Character Support of Tiger. That is, we should handle the character whose code point is after U+ in our code. After doing some research, I found there're two ways to achieve: 1.Maintain a HashMap contains the information of supplementary character and retrieve from it when these methods were invoked. 2.Delegate these methods to ICU4J, which provides extensions to the java.lang.Character class. What's your opinion? Any suggestion are welcome :) This task is to update current implementation of java.lang.Character, about some new feature of J2SE 5.0, it's important to reduce the risk of changing such a core class. The HashMap method may introduce more complexity and more maintenance effort into Harmony development, so I think delegating to ICU4J is the better choice. The only concern is that: does the ICU4J we currently using meet our need perfectly? IMHO, the icu4j_3.4.4 which supports Unicode 4.1 will meet our requirement. Best regards, Richard - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Richard Liang China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
