Re: [DRLVM] write barrier -- some preliminary design ideas for Jitrino.JET
2006/6/14, Weldon Washburn [EMAIL PROTECTED]: Alex, It looks like the JIT needs to support write barriers written in both C as well as Java. Its probably best to think of the C write barrier as a conventional vm helper call. For a garbage collector written in Java like MMTk, the write barrier is actually Java code. Injecting a vm helper call and crossing the JNI boundary twice per each MMTk write barrier will be a nightmare to debug. Most likely performance would be unacceptable even for debug. Can't we inline the Java write barrier with JIT? For a general purpose GC/VM interface, it is best not to assume the GC algorithm will always scan all the static variables containing reference pointers. The write barrier needs to also be applied to putstatic. Either way can be correct, but I agree to have write barrier support for putstatic that can be toggled off if that's desired. -- Thanks, Ming
Re: [jira] Commented: (HARMONY-499) Java 5 Enhancement: java.net.HttpURLConnection should send request head with a connection-field of Keep-Alive
Hello Alexander, I agree that my implementation about Connection: Keep-Alive is incorrect. Thank you. And as mentioned in the spec of Persistent Connections[1]: . /The support for HTTP keep-Alive is done transparently. However, it can be controlled by system properties http.keepAlive, and http.maxConnections, as well as by HTTP/1.1 specified request and response headers. The system properties that control the behavior of Keep-Alive are: http.keepAlive=boolean default: true Indicates if keep alive (persistent) connections should be supported. http.maxConnections=int default: 5 Indicates the maximum number of connections per destination to be kept alive at any given time/ . So we SHALL provide some kind of cache mechanism to support Persistent Connections, would you mind raise a separate JIRA about this issue? Thanks a lot. 1.http://java.sun.com/j2se/1.5.0/docs/guide/net/http-keepalive.html Alexander Kleymenov (JIRA) wrote: [ http://issues.apache.org/jira/browse/HARMONY-499?page=comments#action_12414202 ] Alexander Kleymenov commented on HARMONY-499: - Hello, I am working on HttpsURLConnection and noticed this JIRA report. I went through the Java 5 Enhancements for Networking and could not found any statements for HttpURLConnection. Then I examined the HTTP protocol specification (RFC 2616 can be found at http://www.ietf.org/rfc/rfc2616.txt). It says: HTTP/1.1 applications that do not support persistent connections MUST include the close connection option in every message. The source file of HttpURLConnection implementation does not seem to support persistent connections. So recent changes made to the class org.apache.harmony.luni.internal.net.www.protocol.http.HttpURLConnection (Connection: close -- Connection: Keep-Alive) seem to be incorrect without implementation of support for persistent connections. Thanks, Alexander Java 5 Enhancement: java.net.HttpURLConnection should send request head with a connection-field of Keep-Alive --- Key: HARMONY-499 URL: http://issues.apache.org/jira/browse/HARMONY-499 Project: Harmony Type: Improvement Components: Classlib Reporter: Richard Liang Assignee: Tim Ellison Priority: Minor Attachments: luni.src.net.diff Hello, java.net.HttpURLConnection should send request head with a default connection-field of Keep-Alive. Currently in its implementation, it sends a connection-field of close, but does not close its own socket after connection, which may cause low performance and strange behavior on some servers. Best regards, Richard -- Richard Liang China Software Development Lab, IBM
Re: [DRLVM] MMTk vmmagic classes, can someone w/ compiler experience help me?
Weldon Washburn wrote: All, I am hoping someone who has worked on compilers can actually do the JIT modifications. I don't have much experience in compilers. I am trying to get MMTk write barriers integrated into Harmony DRLVM. I came up with the following scheme. I don't know if it is correct. It would be great if someone from the MMTk crowd looked at it. If it helps, I can also post this message on Jikes/MMTk mailing list. Build a shim between the DRLVM class loader and Jitrino.JET. The shim would contain a lookup table that would map _local_ variables of specific types to int. In particular, the shim would re-map local variables of the below types to int: Address Extent Offset Word The reason for the shim is to avoid modifying the class loader. This should reduce the maintenance burden. Java source code that creates objects of the above classes is a now a problem. For example, Java source code that does: int xx = 33; Address a1 = new Address(xx); MMTk never creates instances of the unboxed magic types, so this shouldn't be a problem. cheers - 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] MMTk vmmagic classes, can someone w/ compiler experience help me?
Robin Garner wrote: Weldon Washburn wrote: All, I am hoping someone who has worked on compilers can actually do the JIT modifications. I don't have much experience in compilers. I am trying to get MMTk write barriers integrated into Harmony DRLVM. I came up with the following scheme. I don't know if it is correct. It would be great if someone from the MMTk crowd looked at it. If it helps, I can also post this message on Jikes/MMTk mailing list. Build a shim between the DRLVM class loader and Jitrino.JET. The shim would contain a lookup table that would map _local_ variables of specific types to int. In particular, the shim would re-map local variables of the below types to int: Address Extent Offset Word The reason for the shim is to avoid modifying the class loader. This should reduce the maintenance burden. Java source code that creates objects of the above classes is a now a problem. For example, Java source code that does: int xx = 33; Address a1 = new Address(xx); MMTk never creates instances of the unboxed magic types, so this shouldn't be a problem. Oh, and 'int' is a bad choice, since it is always 32 bits. These types should be whatever the natural word length of the target architecture is. cheers - 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] MMTK porting issues, take one
Rodrigo Kumpera wrote: On 6/2/06, Weldon Washburn [EMAIL PROTECTED] wrote: All, Perhaps the following is already covered in documentation. If this is the case, please tell me where to find it. Below are some initial questions regarding porting MMTK to DRLVM. A question about org.vmmagic.pragma.InlinePragma class. The comments in the code says, This pragma indicates that a particular method should always be inlined by the optimizing compiler. Just to be clear, will there be any correctness issues if a non-optimizing compiler does not do any inlining? AFAIK the inline pragmas are used to clearly define the alocation fast path for the optimizing compiler. Not just the allocation fast path, but that's the idea. The pragmas are probably most important in the write barriers, where both the InlinePragma and NoInlinePragma are important (see In or Out? Putting write barriers in their place., Blackburn McKinley, ISMM '02). It looks like we have to get Jitrino.JET to generate funny binaries for all the classes in the org.vmmagic.unboxed package. Is this correct? Are there any other packages that bend the type safety rules we need to worry about? The magic types are how the MMTK does pointer operations and unsigned math, the compiler must emit special code for the methods and statics of these classes. Actually it's pretty easy to emit such code from a non-optimizing compiler. It looks like org.vmmagic.unboxed.Extent needs the JIT to specifically emit instructions that do unsigned arithmetic. Is this correct? Correct. A question on org.vmmagic.unboxed.ObjectReference class --- there is a comment that says, Note: this is a JikesRVM specific extension to vmmagic. But a grep of MMTK source shows hundreds of uses of this class. Does the comment mean that MMTK should not use ObjectReference class? Or maybe in the future MMTK will not use ObjectReference class? I think the comment is actually incorrect. cheers - 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] need a quick answer re how things are linked...
Hi Geir. Yes, you are right, to get rid of using hynio.dll and hymath.dll you should change vm/vmcore/src/init/properties.cpp. It is done in the patch for Jira Issue #601. But I have no answer for your question unfortunately, why it was done.. =( Thanks. Nataly On 6/15/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: I figured that one out... it was in properties.cpp Let me ask - why are DLLs specified in cpp files like this? geir Geir Magnusson Jr wrote: Ok, so I've gotten quite a bit done (I think) and stuff builds using the classlib as it is in /enhanced/classlib/trunk using it's own build artifacts. So my tests are failing. java/lang/UnsatisfiedLinkError : Failed loading library C:\dev\apache\harmony\enhanced\drlvm\trunk\build\win_ia32_msvc_release\deploy\jre\bin\hynio.dll: The specified module could not be found. Hm. We don't *have* a hynio.dll. When I look around, I find that it's being referenced by vmcore.dll For the life of me, I can't figure out why this is so. (This is my problem with the generated stuff. You just can't search for anything...) So... please, if someone on the DRL team is around, how do I get vmcore.dll to stop referencing hynio.dll, which doesn't exist anymore? 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: [tools] HARMONY-598 (Keytool - added keystore loading, keytool-specific exception type, misc.)
Mikhail,
the user working with Keytool may need to know what operation of
Keytool failed and the cause of the failure.
The messages in IOException, CertificateException and others are API
or provider specific and therefore are not so useful for the user.
In exceptions thrown by me I set the message showing the __Keytool
operation__ which has the problem and some details. This is what is
expected from the tool.
2006/6/13, Mikhail Loenko [EMAIL PROTECTED]:
Hi Anton
Sorry I'm not a guru in keytools but why catch exceptions and resend them?
+try {
+// try to load the keystore
+keyStore.load(fis, storePass);
+} catch (NoSuchAlgorithmException e) {
+throw new NoSuchAlgorithmException(
+Failed to find the algorithm to check the
keystore integrity,
+e);
+} catch (CertificateException e) {
+throw new CertificateException(
+Failed to load a certificate from the keystore. , e);
+} catch (IOException e) {
+throw (IOException) new IOException(Failed to load the
keystore. )
+.initCause(e);
+}
+return keyStore;
+}
Thanks,
Mikhail
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Thanks,
Anton
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [testing][classlib] running api tests only -- new option
There is a page Building the Classlibrary Code [1], I'll add and Running the Unit Tests and add a section there Thanks, Mikhail 2006/6/14, Geir Magnusson Jr [EMAIL PROTECTED]: How about on the website where you are already talking about how tests are organized? Or maybe we need a new developers page? or a testing page to start The Grand Testing Subset of the Apache Harmony Project? Mikhail Loenko wrote: Sure. Can you suggest a proper place? 2006/6/14, Geir Magnusson Jr [EMAIL PROTECTED]: I assume you'll document this somewhere? Mikhail Loenko wrote: For the modules that have both impl and api tests I'm going to add possibility to skip impl tests, like this: ant -f build-test.xml -Dtest.noimpl=true -Dtest.jre.home=... If no objection I'll integrate changes so that the work on splitting the tests could be continued. (BTW, volunteers are welcome!) With that option we still have many tests failing and some hanging up, so either those tests are incorrect or implementation-specific. Thanks, Mikhail - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - 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: [tools] HARMONY-598 (Keytool - added keystore loading, keytool-specific exception type, misc.)
Ok, I see
2006/6/15, Anton Rusanov [EMAIL PROTECTED]:
Mikhail,
the user working with Keytool may need to know what operation of
Keytool failed and the cause of the failure.
The messages in IOException, CertificateException and others are API
or provider specific and therefore are not so useful for the user.
In exceptions thrown by me I set the message showing the __Keytool
operation__ which has the problem and some details. This is what is
expected from the tool.
2006/6/13, Mikhail Loenko [EMAIL PROTECTED]:
Hi Anton
Sorry I'm not a guru in keytools but why catch exceptions and resend them?
+try {
+// try to load the keystore
+keyStore.load(fis, storePass);
+} catch (NoSuchAlgorithmException e) {
+throw new NoSuchAlgorithmException(
+Failed to find the algorithm to check the
keystore integrity,
+e);
+} catch (CertificateException e) {
+throw new CertificateException(
+Failed to load a certificate from the keystore. , e);
+} catch (IOException e) {
+throw (IOException) new IOException(Failed to load the
keystore. )
+.initCause(e);
+}
+return keyStore;
+}
Thanks,
Mikhail
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Thanks,
Anton
-
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]
[OT] mail configuration (was: [drlvm] what I'm doing...)
Geir Magnusson Jr wrote: [...] Also, is there a way you can get your mail client to not quote what you are replying to as an attachment? If you notice in the message I'm replying to, it appears that your sig and what you quoted is an attachment. It doesn't survive the reply I don't think it is an attachment. It is just that the sig is placed before the quoted message, therefore your mail client discard it as part of the signature. It would also be nice, if the apache mailing list mailer (EZMLM ???) could be configured so that the four line message appended to each post appears as sig, i.e. -- in the first line. In order to avoid being included in quoted replies ;-) [...] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Nektarios K. Papadopoulos - 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] Modularising the native code - it begins!
Tim Ellison wrote: Oliver Deakin wrote: snip but now that I look at it I see that the depends/files dir contains the Harmony properties files, so maybe I'm wrong. Those are launcher-specific, so don't get too attached to them, I'll I'll try.. ;) It looks like the .properties files contain some messages for the port lib and zip, which I guess will need to be split out and put into their respective native components. move them out to the tools/launcher directory where they better belong. So, with the removal of these Harmony internal files from depends, that directory becomes external dependencies only again, meaning we shouldn't put the makefile includes there? Regards, Oliver Regards, Tim -- 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]
[admin] test - please ignore
test, please ignore 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: [testing] AWT, Swing Java2D
Mark Hindess wrote: On 6 June 2006 at 6:27, Geir Magnusson Jr [EMAIL PROTECTED] wrote: zoe slattery wrote: Hi Geir Hi Zoe! Long time no hear, here! Geir Magnusson Jr wrote: Mark Hindess wrote: [SNIP] The build machine I'm running is produces summaries of the missing classes for a number of applications on every build. Currently showing: Can you share this script somewhere? See HARMONY-165 /jira/browse/HARMONY-165 for a script which does the same thing. It's not exactly the same script - but does give the same results (I hope) What's the difference? I split the process into four steps: 1) Obtain reference lists of classes defined by the 1.4, 5.0, 6.0 APIs. You only need to do this once. 2) Create a class load list for an application - w/java -verbose:class 3) Create a list of classes provide by a Harmony jre - I did this by scanning the jars in the jre. You only need to do this when the JRE changes. 4) List all the classes in the result of 2) that are also in 1) but not in 3). That is, API classes used by not in Harmony. IIRC, Zoe's script combined steps 1), 3), and 4) so steps 1) and 3) were repeated for each application. This was fine for casual use but didn't really scale for our build process. One thing that might be interesting would be to configure a CGI/servlet to accept output from 2) via a HTTP file upload and compare it to a current version of 3) and produce the brief report of missing classes. So people could create a log with their favourite app on a RI and see if there is any chance it will work on Harmony. Cool! Why not provides a URL to update the newest 3) so that anyone can download and compare it with the output from 2) locally? I think download is always easier to manage than upload. If the 3) is too large, we can handle it in the other direction, provide list of the 1) minus 3) download, and of course the 4) needs to be changed to: List all the classes in joint set of 2) and [1)-3)]. So when can I download this Harmony Enablement Validation tool? ;) Regards, Mark. - 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: [OT] mail configuration
Nektarios K. Papadopoulos wrote: Geir Magnusson Jr wrote: [...] Also, is there a way you can get your mail client to not quote what you are replying to as an attachment? If you notice in the message I'm replying to, it appears that your sig and what you quoted is an attachment. It doesn't survive the reply I don't think it is an attachment. It is just that the sig is placed before the quoted message, therefore your mail client discard it as part of the signature. You are exactly right :) I assume that Denis is using outlook - I've seen outlook do that, and I never figured out how to fix it. My apologies. Is there a way to put the sig at the bottom? It would also be nice, if the apache mailing list mailer (EZMLM ???) could be configured so that the four line message appended to each post appears as sig, i.e. -- in the first line. In order to avoid being included in quoted replies ;-) Hm. It is part of the message though, not a sig. I tend to just snip them off manually. 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: [classlib] Modularising the native code - it begins!
On 14 June 2006 at 16:45, Oliver Deakin [EMAIL PROTECTED] wrote: Mark Hindess wrote: snip On 14 June 2006 at 7:24, Geir Magnusson Jr [EMAIL PROTECTED] wrote: Oliver Deakin wrote: 2) The makefiles for each native component include two files (defines.mak and rules.mak on windows and makefile.include and rules.mk on linux) that are generic across all components. The question is: where should these common files be located once the natives are moved into the modules? At the moment, I can't really see an obvious location where all modules could access them. The only option I've thought of so far is to have one copy of the files i n each module that contains native code (so that would be one copy in each of archive, auth, luni, prefs and text). The files would be located under /modules/modulename/src/main/native, and shared by all the native components under that module. Any preferences/ideas about this? I think that works. I've been having similar thoughts about this re drlvm, and have been using the classlib make config as a reference. I'm trying to limit the amount of duplicated things because I'm slothful and lazy and don't want to maintain them. I'd rather not maintain lots of copies. Could we not keep the shared parts in the deploy (I was tempted to say hdk) somehow? It's might sound a little crazy but actually given that we want modules to be consistent with other compiled artifacts it's actually quite useful to have common structure, variable and compile flag settings. I would also prefer if we could find a good central place to keep these rather than many copies - do you have any suggestions? In the support sub-directory? The support tree is already required by most (all?) modules. I renamed the originally contributed 'test_support' tree to support since I figured we might have other support files. For example java code for ant tasks if the build gets to hard to manage with basic ant. -Mark - 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] need a quick answer re how things are linked...
Hello Nataly, Geir I think the main reason why the list of DLLs is in CPP code is that from the names of libraries it constructs full paths to the files in VM location. Why the list of DLL names is hardcoded is a historical leftover. We didn't presume that may change often. It contains the DLLs which have to be preloaded on startup by VM in order to allow the base APIs to initialize. The rest of native code is loaded in a normal way with System.loadLibrary. Hardcoding the list is probably bad for development purposes but RI does the same. Try to rename some library like zip.dll and it will not start. Do you think it should be changed? 2006/6/15, Nataly Naumova [EMAIL PROTECTED]: Hi Geir. Yes, you are right, to get rid of using hynio.dll and hymath.dll you should change vm/vmcore/src/init/properties.cpp. It is done in the patch for Jira Issue #601. But I have no answer for your question unfortunately, why it was done.. =( Thanks. Nataly On 6/15/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: I figured that one out... it was in properties.cpp Let me ask - why are DLLs specified in cpp files like this? geir Geir Magnusson Jr wrote: Ok, so I've gotten quite a bit done (I think) and stuff builds using the classlib as it is in /enhanced/classlib/trunk using it's own build artifacts. So my tests are failing. java/lang/UnsatisfiedLinkError : Failed loading library C:\dev\apache\harmony\enhanced\drlvm\trunk\build\win_ia32_msvc_release\deploy\jre\bin\hynio.dll: The specified module could not be found. Hm. We don't *have* a hynio.dll. When I look around, I find that it's being referenced by vmcore.dll For the life of me, I can't figure out why this is so. (This is my problem with the generated stuff. You just can't search for anything...) So... please, if someone on the DRL team is around, how do I get vmcore.dll to stop referencing hynio.dll, which doesn't exist anymore? 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
Re: [drlvm] need a quick answer re how things are linked...
Gregory Shimansky wrote: Hello Nataly, Geir I think the main reason why the list of DLLs is in CPP code is that from the names of libraries it constructs full paths to the files in VM location. Why the list of DLL names is hardcoded is a historical leftover. We didn't presume that may change often. It contains the DLLs which have to be preloaded on startup by VM in order to allow the base APIs to initialize. The rest of native code is loaded in a normal way with System.loadLibrary. I see - that explains it. Hardcoding the list is probably bad for development purposes but RI does the same. Try to rename some library like zip.dll and it will not start. Do you think it should be changed? I dunno. I just was baffled. 2006/6/15, Nataly Naumova [EMAIL PROTECTED]: Hi Geir. Yes, you are right, to get rid of using hynio.dll and hymath.dll you should change vm/vmcore/src/init/properties.cpp. It is done in the patch for Jira Issue #601. But I have no answer for your question unfortunately, why it was done.. =( Thanks. Nataly On 6/15/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: I figured that one out... it was in properties.cpp Let me ask - why are DLLs specified in cpp files like this? geir Geir Magnusson Jr wrote: Ok, so I've gotten quite a bit done (I think) and stuff builds using the classlib as it is in /enhanced/classlib/trunk using it's own build artifacts. So my tests are failing. java/lang/UnsatisfiedLinkError : Failed loading library C:\dev\apache\harmony\enhanced\drlvm\trunk\build\win_ia32_msvc_release\deploy\jre\bin\hynio.dll: The specified module could not be found. Hm. We don't *have* a hynio.dll. When I look around, I find that it's being referenced by vmcore.dll For the life of me, I can't figure out why this is so. (This is my problem with the generated stuff. You just can't search for anything...) So... please, if someone on the DRL team is around, how do I get vmcore.dll to stop referencing hynio.dll, which doesn't exist anymore? 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: [classlib] [testing] java.beans tests
Sure we need to test protected methods and fields. Moreover we need to test private methods either via API or by other means. Alexei, it would be good if you point to a simple test that shows difference in behavior, quote the spec and describe, why you think Harmony does things right. Thanks, Mikhail 2006/6/14, Richard Liang [EMAIL PROTECTED]: Alexei Zakharov wrote: BTW, all questionable methods of PersistenceDelegate interface are protected rather than public. Do we need to test it at all? Hello Alexei, IMHO, we need to test the protected methods, which are also part of API. 2006/6/14, Alexei Zakharov [EMAIL PROTECTED]: Mikhail, Tim, I suggest that you raise a few examples here. The first example that comes to my mind is the RI's implementation of PersistenceDelegate for java.lang.String class. (Persistence delegate is a class that manages persistence details of his target class and is used by java.beans.XMLEncoder). RI's imeplementation just does nothing and returns null there applicable. It seems that RI guys simply created a stub class they do not actually use. Most likely they embedded String-handling logic in some other place in code. IMHO such a decision doesn't fully correspond the idea of persistence delegates as a place for persistence-handling logic. BTW, our StringPersistenceDelegateTest (point 2 in my classification) also expects some non-stub behavior from StringPersistenceDelegate. It seems that people who have created this test also don't like this aspect of the RI's implementation. :) 2006/6/14, Tim Ellison [EMAIL PROTECTED]: Alexei Zakharov wrote: Hello to everyone, I am currently investigating tests for java.beans module. Great. As far as I understand there were two separate contributions of java.beans tests from two different parties. And these contributions were merged into the single combined test suite we have now in svn. As a result currently we have about 400 test case failures (excluded) out of approximately 1200. After spending some time on this I realize that we have two types of issues here: 1. Test checks the compliance with very deep detail of RI's behavior (that is not in spec). 2. Test expects the behavior that differs from the RI's behavior as well as from our implementation's behavior. As for point 1, I'm unsure here. Do we really need to be completely identical to the RI in terms of public methods behavior? Some RI decisions are strange. We need to work the same (possibly unspecified) way as the reference implementation to ensure compatibility for Java apps. An example of some areas we already thought about are listed here [1]. If the decision is strange so that you think it is bug then we may choose to depart from the RI's behavior after discussion on this list, but if it is wrong because you disagree with the approach, then I'm afraid that compatibility wins g. I suggest that you raise a few examples here. For point 2, I believe we should rewrite or delete such tests. Agreed -- please indicate with your JIRA patch why you think they are wrong, and that will help people review you rewrite/deletion request. Thoughts, suggestions? I'm happy that you are looking into this, and look forward to your patches! Regards, Tim -- Alexei Zakharov, Intel Middleware Product Division -- Richard Liang China Software Development Lab, IBM - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] Modularising the native code - it begins!
Mark Hindess wrote: On 14 June 2006 at 16:45, Oliver Deakin [EMAIL PROTECTED] wrote: Mark Hindess wrote: snip On 14 June 2006 at 7:24, Geir Magnusson Jr [EMAIL PROTECTED] wrote: Oliver Deakin wrote: snip I think that works. I've been having similar thoughts about this re drlvm, and have been using the classlib make config as a reference. I'm trying to limit the amount of duplicated things because I'm slothful and lazy and don't want to maintain them. I'd rather not maintain lots of copies. Could we not keep the shared parts in the deploy (I was tempted to say hdk) somehow? It's might sound a little crazy but actually given that we want modules to be consistent with other compiled artifacts it's actually quite useful to have common structure, variable and compile flag settings. I would also prefer if we could find a good central place to keep these rather than many copies - do you have any suggestions? In the support sub-directory? The support tree is already required by most (all?) modules. I renamed the originally contributed 'test_support' tree to support since I figured we might have other support files. For example java code for ant tasks if the build gets to hard to manage with basic ant. This idea seemed quite appealing at first, but having had a look at the support directory it still looks very much like a test support bundle, even if it isn't named as such. There is a manifest and src directory in there that gives it the appearance of another module, so adding in a build directory, or something similar, might confuse things. Perhaps initially I will put them in a build subdir of depends, just to get these patches going. Then in the future maybe the support directory will be reorganised so it isn't as test oriented, and these can be moved. Sound fair? Regards, Oliver -Mark - 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]
[apps] freemind
Good day, I've built Harmony with AWT + Swing and tried to run Freemind (http://freemind.sourceforge.net/) on it. It is Swing application. It worked fine in general - I've created a simple 'map' (sort of scheme) in it and saved the file. The only problem I've noticed is that the upper menu (File, Edit, ...) sometimes disappeared after redraws. After resizing the window menu became visible again. -- Regards, Anton Luht, 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: [apps] freemind
Which platform? Wishes, -- Anton Avtamonov, Intel Middleware Products Division On 6/15/06, Anton Luht [EMAIL PROTECTED] wrote: Good day, I've built Harmony with AWT + Swing and tried to run Freemind (http://freemind.sourceforge.net/) on it. It is Swing application. It worked fine in general - I've created a simple 'map' (sort of scheme) in it and saved the file. The only problem I've noticed is that the upper menu (File, Edit, ...) sometimes disappeared after redraws. After resizing the window menu became visible again. -- Regards, Anton Luht, Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [apps] freemind
2006/6/15, Anton Luht [EMAIL PROTECTED]: I've built Harmony with AWT + Swing and tried to run Freemind (http://freemind.sourceforge.net/) on it. It is Swing application. It worked fine in general - I've created a simple 'map' (sort of scheme) in it and saved the file. Great! :) The only problem I've noticed is that the upper menu (File, Edit, ...) sometimes disappeared after redraws. After resizing the window menu became visible again. Can you try to minimize the testcase and file it in JIRA? -- 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]
[build] AWT, Java2D and SWING contribution
Good day, I've come across several issues while building this contribution and would like to share this experience: 1. line 197 (directory layout section) \---cms || |+--- icc34.h |+--- lcms.h |+--- lcms114.lib and/or liblcms.ia32 and/or liblcms.ipf line 300: 9. Copy ./include/icc34.h and ./include/lcms.h to the EXTERNAL_LIBS_DIR/lcms directory. the correct dir is lcms 2. line 174 : EXTRACT_DIR/Harmony/depends/build line 209: Further in the document, EXTERNAL_LIBS_DIR denotes the directory EXTRACT_DIR/Harmony/depends/build. The build searches for libs in another place: copylib.win: BUILD FAILED C:\temp\Harmony-SVN\Harmony\modules\awt\make\build.xml:320: The following error occurred while executing this line: C:\temp\Harmony-SVN\Harmony\modules\awt\make\native\common\gl.xml:97: Warning: C ould not find file C:\temp\Harmony-SVN\Harmony\depends\libs\build\png\libpng.lib to copy. 3. Build copies files to Harmony\deploy\jre dir while all other .jar and .dll files are in Harmony\deploy\jdk\jre 4. Don't forget to add misc.jar to bootclasspath.properties , for example add to the end of file: bootclasspath.38=misc.jar -- Regards, Anton Luht, 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] AWT, Java2D and SWING contribution
On 15 June 2006 at 17:32, Anton Luht [EMAIL PROTECTED] wrote: Good day, I've come across several issues while building this contribution and would like to share this experience: 1. line 197 (directory layout section) \---cms || |+--- icc34.h |+--- lcms.h |+--- lcms114.lib and/or liblcms.ia32 and/or liblcms.ipf line 300: 9. Copy ./include/icc34.h and ./include/lcms.h to the EXTERNAL_LIBS_DIR/lcms directory. the correct dir is lcms This is fixed by HARMONY-534. -Mark. - 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] MMTk write barrier -- questions about which writeBarrier() API to use
Robin, Thanks. The below helps. I reread the unboxed package. It now makes much more sense. I think I finally understand it. Sorry for being so dense. Please tell me if the following is correct: For 32-bit machine, instances of class Address are simply 32-bit integers. //the jit intentionally breaks the type system and assigns the first argument, obj1, to the location holding oref // the jit sees oref as a regular java object, oref will be gc enumerated ObjectReference oref = ObjectReference.fromObject(obj1); //the jit sees adr as an int, oref.toAddress() is an intrinsic method // that simply takes the this ptr and moves it to the //32-bit int location containing adr //adr is never gc enumerated Address adr = oref.toAddress(); On 6/15/06, Robin Garner [EMAIL PROTECTED] wrote: Weldon Washburn wrote: All, Perhas the MMTk crowd knows the answer to the following questions. Can I simply not use org.mmtk.plan.PlanLocal.writeBarrier(ObjectReference src, Address slot, ObjectReference tgt, Offset metaDataA, int metaDataB, int mode);? Instead, I want to only use writeBarrier(ObjectReference src, Offset srcOffset, ObjectReference dst, Offset dstOffset, int bytes);. Will this be a problem? The two writebarriers are for separate cases. The first is a putfield write barrier, the second is a special case for a reference array copy. Questions about the incoming args: ObjectReference src From the JITs perspective, an ObjectReference is indistinguishable from a java.lang.Object. Is this true? False? Yes, but MMTk assumes that its target language is not necessarily Java. An ObjectReference is a pointer to a heap object, whatever that may be in the language being managed. Address slot When is Address slot argument actually created? Does this Address object live long enough such that its value field needs to be updated following a copying GC? Is the answer the same for both Jikes and the Rotor ports? A write barrier should never be invoked on an object that is being copied. An Address is an unboxed type, so objects of that type are never created. Offset srcOffset In DRLVM, the classloader resolves a field offset once and it never changes. Does it make sense for the classloader to create all the Offset objects during load time? Initially, I want to create these objects _outside_ the formal java heap to have tight control over object movement and deletion. Basically, I don't want the Offset object to ever move or ever be deleted during the initial stages of MMTk integration. Offset objects are never created. Think of an offset as a primitive type with methods. A question about how jikesrvm-2.4.4/MMTk handles objects that are not inside the offical heap. Are these objects simply ignored? I know that ECMA CLI spec requires that objects which are not in the official heap must be ignored. I simply don't know if this requirement is incorporated in 2.4.4/MMTk source base. Any object that MMTk encounters must be in the heap that it manages. In JikesRVM/MMTk, there are a minimum of 4 regions of the heap, VM, Immortal, LOS and then any plan-specific region. I think the objects you are referring to would be in the VM space ??? While it looks like a lot of work to get DRLVM to generate Offset object properly, it looks like even a bigger job to modify MMTk to replace Offset class with an int that holds a given field's offset. Any opinions on this statement? Not true, IMO. The JikesRVM compiler replaces Offset objects with a primitive type of the natural word length of the machine. Hope this helps, Robin - 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 - 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] AWT, Java2D and SWING contribution
2006/6/15, Anton Luht [EMAIL PROTECTED]: 2. line 174 : EXTRACT_DIR/Harmony/depends/build line 209: Further in the document, EXTERNAL_LIBS_DIR denotes the directory EXTRACT_DIR/Harmony/depends/build. The build searches for libs in another place: copylib.win: BUILD FAILED C:\temp\Harmony-SVN\Harmony\modules\awt\make\build.xml:320: The following error occurred while executing this line: C:\temp\Harmony-SVN\Harmony\modules\awt\make\native\common\gl.xml:97: Warning: C ould not find file C:\temp\Harmony-SVN\Harmony\depends\libs\build\png\libpng.lib to copy. Create a JIRA issue, please. -- 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: [build] AWT, Java2D and SWING contribution
Anton, the token in brackets (like [build]) for this message should be [classlib] as it pertains to the classlib... Thanks for being diligent and using it though :) geir Anton Luht wrote: Good day, I've come across several issues while building this contribution and would like to share this experience: 1. line 197 (directory layout section) \---cms || |+--- icc34.h |+--- lcms.h |+--- lcms114.lib and/or liblcms.ia32 and/or liblcms.ipf line 300: 9. Copy ./include/icc34.h and ./include/lcms.h to the EXTERNAL_LIBS_DIR/lcms directory. the correct dir is lcms 2. line 174 : EXTRACT_DIR/Harmony/depends/build line 209: Further in the document, EXTERNAL_LIBS_DIR denotes the directory EXTRACT_DIR/Harmony/depends/build. The build searches for libs in another place: copylib.win: BUILD FAILED C:\temp\Harmony-SVN\Harmony\modules\awt\make\build.xml:320: The following error occurred while executing this line: C:\temp\Harmony-SVN\Harmony\modules\awt\make\native\common\gl.xml:97: Warning: C ould not find file C:\temp\Harmony-SVN\Harmony\depends\libs\build\png\libpng.lib to copy. 3. Build copies files to Harmony\deploy\jre dir while all other .jar and .dll files are in Harmony\deploy\jdk\jre 4. Don't forget to add misc.jar to bootclasspath.properties , for example add to the end of file: bootclasspath.38=misc.jar - 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] what I'm doing...
On 6/9/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: Sorry, I'm already wading through it. I'll be happy to see it to use for reference though. If someone is going to work on something, please speak up here first. geir Hi all! I want to suggest the solution for getting rid of classlib building completely. It requires a little patching of the current build. The changes are the following: - remove all the classlib descriptors (make/components/classlib* ) - add the new descriptor for the classlib libraries copying (e.g. make/extra/classlib.xml), that will copy all the libraries from the built classlib - change a little several other descriptors: for vm.vmi, vm.hello and vm.kernel_classes to point to the classlib *.jar and *.lib and change win/lnx.properties to point to the fresh Harmony sources. So the build will work the following way: if one defines CLASSLIB_HOME property (from the command line or in property file), the build will take the libraries from it. If this property is unset or the classlib wasn't built, the build says that one should build the classlib first (which has been downloaded already during the build update). But such solution requires the patching DRLVM first, as I suggested in Jira issue 601, because the current vm doesn't work with the fresh Harmony. Nataly Naumova, Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [drlvm] what I'm doing...
Nataly Naumova wrote: On 6/9/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: Sorry, I'm already wading through it. I'll be happy to see it to use for reference though. If someone is going to work on something, please speak up here first. geir Hi all! I want to suggest the solution for getting rid of classlib building completely. It requires a little patching of the current build. The changes are the following: - remove all the classlib descriptors (make/components/classlib* ) I've done that - add the new descriptor for the classlib libraries copying (e.g. make/extra/classlib.xml), that will copy all the libraries from the built classlib - change a little several other descriptors: for vm.vmi, vm.hello and vm.kernel_classes to point to the classlib *.jar and *.lib and change win/lnx.properties to point to the fresh Harmony sources. So the build will work the following way: if one defines CLASSLIB_HOME property (from the command line or in property file), the build will take the libraries from it. If this property is unset or the classlib wasn't built, the build says that one should build the classlib first (which has been downloaded already during the build update). But such solution requires the patching DRLVM first, as I suggested in Jira issue 601, because the current vm doesn't work with the fresh Harmony. This is pretty much what I've done. When I check it in later today (I'm cleaning things up now...) we can pick at it and fix it.. :) geir Nataly Naumova, Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Fwd: [classlib][NIO|VMI]Interruptible channel implementation - how to interact with Thread?]
Paulex Yang wrote:
Jimmy, Jing Lv wrote:
Archie Cobbs wrote:
Paulex Yang wrote:
Seems Thread's implementation must be aware of what operation it is
blocking on. So I propose the following solution:
I don't think the VM or java.lang.Thread needs to be involved.
First of all, the code performing the blocking operation knows
what kind of operation it is, so when it wakes up abnormally it
can take the appropriate action. This code doesn't necessarily
reside in java.lang.Thread.
In Classpath the java.nio stuff is all implemented in native
libraries without the VM or java.lang.Thread being specially
aware of anything. However, classlib's design may be different
enough to need it (I haven't studied it as much as you guys).
E.g., the java.nio native code does invoke Thread.interrupt() and
Thread.interrupted(), but these are normal, API-specified methods.
Might be worth taking a look for some design ideas.
Thanks Archie, it sounds interesting :).
As I study few about Classpath, I still have a question here. As we
know, there are three states of blocking on a thread. One is wait(),
sleep() and so forth, thread class handle them itself, it is easy to
interrupt; and one is blocking on I/O, invoke Thread.interrupt() may
be not enough as it is blocked on a system call, e.g., call read on
socket may not return until it receive something or it is closed. In
this way, the Thread.interrupt should know how to close the socket to
perform the real interruption. The question is: how can the thread
know if it is blocked on wait() or I/O operation currently? I think
this is the reason why Paulex require Thread to be involved. So I'm
very interested in what does Classpath do here to stop I/O operation
without get involved?
Actually Thread.interrupt() is required to handle four different scenario:
1. wait(), join(), etc, throw InterruptException
2. blocking I/O, close the channel, and throw ClosedByInterruptException
3. blocking select, wake up the selector
4. none of above, just set the thread's interrupt status
So if we don't involve Thread and want to implment scenario 2 and 3, we
may find the situation is:
a. If Thread cannot judge scenario 2/3, so it may think they are both
scenario 4, so Thread.interrupt() just set the interrupt status and do
nothing else, the I/O operation is still blocking there, we cannot get
it actually interrupted.
b. If Thread can find the thread is blocking somewhere, and it considers
all blocking as scenario 1, so the InterruptException is thrown, but
considering scenario 3, Selector.select() should be waked up without
exception, while our selector only has the end() executed in finally
block like below, how does end() catch the thrown InterruptException and
handle it silently?
try {
begin();
// Perform blocking I/O operation here
...
} finally {
end();
}
c. If Thread can magically find the thread is blocking on I/O or select,
it may need to set the interrupt status, and make the blocked Java
method return with some error, so that the end() can check them.
Further, the Thread needs to know if this blocking I/O is
interruptible in Java, for example, the ServerSocket.accept() and
ServerSocketChannel.accept() probably uses same system call, but Thread
should know ServerSocket cannot be interrupted while ServerSocketChannel
can...I have no any idea how Thread can do this without interaction with
NIO channels.
So, Archie, I'm very interested in how Classpath handle this problem.
Would you please help to give more details for it (if no legal concern)?
To be honest I'm not sure how exactly it works, or even that it does (I haven't
played with the nio stuff at all).. I only know that Thread implementations in
Classpath don't have special stuff for NIO channels.
Taking a look at Classpath...
In Classpath, if select(2) returns EINTR, the select just returns normally
(with nothing selected) and then the code checks Thread.interrupted().
If set, it closes and throws the exception as necessary.
Also, on UNIX at least, one thread may close a file descriptor that
another thread is waiting on and the second thread will immediately
wake up with an error. So that case is easy to handle.
So the only hard part is waking up the sleeping thread that you have
interrupted. Once it wakes up, the rest can be handled in Java.
A thread blocking on select() will get EINTR if a signal is received. A thread
can signal other threads (via native code) using pthread_kill(). So one
approach would be for the VM to signal a thread with an otherwise ignored
signal when that thread is interrupted. The only possibilities I see are:
1. Interrupt select(2) with a signal
2. select(2) listens on an additional secret file descriptor for reading
and the VM writes a byte into it
3. select(2) is called with a short timeout, and each time it returns
with timeout we check Thread.interrupted(), then try again.
#1 is most efficient and simplest, but requires VM
Re: [classlib] Modularising the native code - it begins!
Oliver Deakin wrote: Tim Ellison wrote: Oliver Deakin wrote: snip but now that I look at it I see that the depends/files dir contains the Harmony properties files, so maybe I'm wrong. Those are launcher-specific, so don't get too attached to them, I'll I'll try.. ;) It looks like the .properties files contain some messages for the port lib and zip, which I guess will need to be split out and put into their respective native components. move them out to the tools/launcher directory where they better belong. So, with the removal of these Harmony internal files from depends, that directory becomes external dependencies only again, meaning we shouldn't put the makefile includes there? As Geir wrote elsewhere, it makes sense to share all resources at the appropriate level within the project, so if the makefile rules are to be used by drlvm as well as classlib then they would find a home in the /dependencies (or whatever it is called) that is a peer of them. If it makes sense that the rules are classlib wide then put them in classlib/depends (or whatever) and so on. The actual dir names are open for debate. Regards, Tim -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[drlvm] build - first round done
Ok, first round is committed. It's been tested on winXP, not linux, and will get to that later, there still are some tweaks... First, this is pretty primitive, and some things are really crude. I'm sure we'll collectively fix and evolve. The two main things : 1) it uses a property to find the classlib on the local filesystem, it doesn't build it, and assumes that it's done. 2) it works (according to build test) w/ the newest version of classlib I'm going to keep drilling on it. I'd like to reuse the work that was there to help get a shared dependency cache for all components of Harmony. I'm also going to take a swipe at doing the 'federation' we talked about last week. Suggestions and discussion always welcome. 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][java.math]performance improvement for java.math package
Hi Vladimir, thank you very much for this new optimization of math from, as you said, enterprise-level applications point of view. Of course we are considering this optimization (H551) as well for the combination of the different math implementations into a new and more efficient one. In fact we are already working on a new version combining H39+380 with H199 and are introducing some of H551 optimizations as well. On the other hand, we are for the moment postponing some other of your optimizations for a future version since introducing them now would break, in my opinion prematurely, a nice design property we have so far: BigDecimal depends only on public features of BigInteger. So, we are following this plan: 1) integration of H39+H380 with H199 and with part of H551 2) optimization of this with more advanced algorithms 3) introducing remaining optimization from H551 For the point 2) above I would still like to have independence between BigDecimal and BigInteger. I hope you agree with this plan. I would also be grateful if you could be more specific when you mention enterprise-level applications. We are looking for realistic applications of math in order to be able to get an idea of how the implementations will work in practice. So far we had only found a few applications in cryptography and in number factorization (actually, they are applications of BigInteger only). Could you point me to the applications you had in mind so that we can add them to our (so far) small collection of applications? Are those applications for which float or double are not enough? Thanks again, Daniel On 6/2/06, Vladimir Strigun [EMAIL PROTECTED] wrote: Our team has done some analysis of current Harmony implementation of java.math package. The implementation was considered from the performance point of view and I'd like to share results of our work with you. The analysis and tuning was made from the enterprise-level applications point of view which are known to use BigInteger and BigDecimal for storing numeric information. In most cases the numbers there fit well within 32 bits. So coming from the BigDecimal perspective which is really important for these applications and taking into account some specifics (small numbers) we made some optimizations in both BigDecimal and BigInteger. The latter was tuned specifically for BigDecimal: - Special handling for small numbers (fit within 32 bit) was added to all methods - Frequently used constants (0..10) were cached and reused by valueOf method (no need to create a new instance of BigInteger) - as well as were powers of 10 (0..10) - methods add(), divide(), divideAndRemainer() in BigInteger were optimized for short values if both arguments can fit in 32 bits the resulting BigInteger is created by valueOf method. If we consider enterprise level applications, we can imagine that toString() method is also frequently used. The method was analyzed and as a result we combined toString() methods in BigDecimal and BigInteger to one unified method in BigInteger. Method BigInteger.toDecimalScaledString(int scale) now is used from both BigInteger and BigDecimal. This way allows reducing amount of created objects and data copying. In addition, size calculation was modified for resulting array. In the new implementation the size is calculated with less precision. Because allocated char array will be copied into String and collected by GC after toString() then it is not a problem if the allocated char array will be slightly bigger then necessary. I've attached the changes we made for BigInteger and BigDecimal to Harmony-551 We also have created a set of micro benchmarks (which I'll to attach to JIRA as well) which shows that our special-case handling doesn't break the performance for other cases and we do not degrade in common, and, of course, all unit tests pass with new version. Below you can find several comparisons in performance between current version and the fixed one. === Ops/sec for toString() method of BigDecimal Number Current fixed one of digits version 2 11215354 4 774 7514 8 615 6748 12 743 5543 16 623 4494 24 389 4895 32 306 3496 48 232 5815 64 224 3761 128 91 87 Ops/sec for divide method of BigInteger Number Current fixed one of digits version 2 52476315 4 46236497 8 55607491 12 838 838 16 25332063 24 16891717 32 23972494 48 21432131 64 613 525 128 13991418 Ops/sec for subtract method of BigInteger Number Current fixed one of digits version 2 39204394 4 33003302 8 51785640 12 957 913 16 37942904 24 20571962 32 34213241 48 34692828 64 652 610 128 23182246 === Unfortunately we haven't look thoroughly to ITC contribution, so it may
[classlib][build] AWT, Swing and Misc modules build problems
Since Harmony layout changed again, these modules are failed to build with the initial version build scripts. To be more concrete build scripts cannot find the jni.h file. They also place the resulting jars and libraries to the wrong place: deploy/jre instead of deploy/jdk/jre. To track this issue I've created new JIRA issue: http://issues.apache.org/jira/browse/HARMONY-607. And I've attached needed diffs there. SY, Alexey -- Alexey A. Petrenko Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib][build] AWT, Swing and Misc modules build problems
Yes 2006/6/15, Geir Magnusson Jr [EMAIL PROTECTED]: thanks - did you link it to the orig? Alexey Petrenko wrote: Since Harmony layout changed again, these modules are failed to build with the initial version build scripts. To be more concrete build scripts cannot find the jni.h file. They also place the resulting jars and libraries to the wrong place: deploy/jre instead of deploy/jdk/jre. To track this issue I've created new JIRA issue: http://issues.apache.org/jira/browse/HARMONY-607. And I've attached needed diffs there. SY, Alexey - 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: [jira] Updated: (HARMONY-607) Build scripts for HARMONY-528 contribution needs modification
Alexey, In theory, the changes Oliver has been making should mean that all the headers that form part of the classlib API should be accessible in deploy/include (similarly the .lib/.a files should be in deploy/lib). It should not be necessary to include files by pointing directly to the native-src tree. That's the theory, but I suspect there are headers that are not getting moved to the deploy/include tree as they should be. Can you try picking up the includes from there and report what doesn't work? Unless we fix this it will break again when Oliver begins refactoring the native code to the modules tree. If we fix it then it should stay fixed. Regards, Mark. On 15 June 2006 at 15:23, Alexey Petrenko (JIRA) [EMAIL PROTECTED] wrote: [ http://issues.apache.org/jira/browse/HARMONY-607?page=all ] Alexey Petrenko updated HARMONY-607: Attachment: swing.build.xml.diff SWING module build script patch Build scripts for HARMONY-528 contribution needs modification - Key: HARMONY-607 URL: http://issues.apache.org/jira/browse/HARMONY-607 Project: Harmony Type: Bug Components: Classlib Reporter: Alexey Petrenko Attachments: awt.build.xml.diff, misc.build.xml.diff, swing.build.xml.diff Harmony build layout is changed. So build scripts from HARMONY-528 can not find headers and put the result l ibraries into wrong place. I'll prepare the path. -- 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: [jira] Updated: (HARMONY-607) Build scripts for HARMONY-528 contribution needs modification
Ok, I'll try this tomorrow. But in this case all headers should be copied before any building. It is the only possible problem. 2006/6/15, Mark Hindess [EMAIL PROTECTED]: Alexey, In theory, the changes Oliver has been making should mean that all the headers that form part of the classlib API should be accessible in deploy/include (similarly the .lib/.a files should be in deploy/lib). It should not be necessary to include files by pointing directly to the native-src tree. That's the theory, but I suspect there are headers that are not getting moved to the deploy/include tree as they should be. Can you try picking up the includes from there and report what doesn't work? Unless we fix this it will break again when Oliver begins refactoring the native code to the modules tree. If we fix it then it should stay fixed. Regards, Mark. On 15 June 2006 at 15:23, Alexey Petrenko (JIRA) [EMAIL PROTECTED] wrote: [ http://issues.apache.org/jira/browse/HARMONY-607?page=all ] Alexey Petrenko updated HARMONY-607: Attachment: swing.build.xml.diff SWING module build script patch Build scripts for HARMONY-528 contribution needs modification - Key: HARMONY-607 URL: http://issues.apache.org/jira/browse/HARMONY-607 Project: Harmony Type: Bug Components: Classlib Reporter: Alexey Petrenko Attachments: awt.build.xml.diff, misc.build.xml.diff, swing.build.xml.diff Harmony build layout is changed. So build scripts from HARMONY-528 can not find headers and put the result l ibraries into wrong place. I'll prepare the path. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Alexey A. Petrenko Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using mx4j for javax.management
On 13 June 2006 at 9:31, Geir Magnusson Jr [EMAIL PROTECTED] wrote: That's been the plan :) I've had some conversations with Simone about this a while ago - I'd really like to see the code come here since I think he seens an end of life for MX4J as an indep project w/ jmx in Java SE. I'll see if I can rekindle that convo here... That would be great. Is there any reason not to commit the JIRA to use the binary in the meantime? Regards, Mark. Mark Hindess wrote: I created a JIRA about this issue, see: https://issues.apache.org/jira/browse/HARMONY-560 There is a patch attached if anyone wants to test it. The license is at: http://mx4j.sourceforge.net/docs/ch01s06.html Any thoughts or comments about whether this is a reasonable thing to do? Regards, Mark. - 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: Using mx4j for javax.management
no, we can use the binary... Mark Hindess wrote: On 13 June 2006 at 9:31, Geir Magnusson Jr [EMAIL PROTECTED] wrote: That's been the plan :) I've had some conversations with Simone about this a while ago - I'd really like to see the code come here since I think he seens an end of life for MX4J as an indep project w/ jmx in Java SE. I'll see if I can rekindle that convo here... That would be great. Is there any reason not to commit the JIRA to use the binary in the meantime? Regards, Mark. Mark Hindess wrote: I created a JIRA about this issue, see: https://issues.apache.org/jira/browse/HARMONY-560 There is a patch attached if anyone wants to test it. The license is at: http://mx4j.sourceforge.net/docs/ch01s06.html Any thoughts or comments about whether this is a reasonable thing to do? Regards, Mark. - 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] I modified build.xml to stop running the clean target on every invocation
I hope that no one really is bothered by that. It's just so annoying :) If you are, feel free to put it back (or I will ) and then lets discuss? 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: Fwd: [DRLVM] proposal to port MMTK to drlvm
On 6/14/06, Robin Garner [EMAIL PROTECTED] wrote: The port to rotor was done by Andrew Gray at ANU, and was based on my work integrating MMTk into C-based runtimes. The approach used was to apply a source code transformation to turn the MMTk 'magic' into native methods (using CNI) on primitive types, and compile MMTk with gcj. It is described in detail in my honours thesis. This confirms what I saw in the code. A bunch more pieces are falling into place. We will probably won't use GCJ or CNI. Instead, I am thinking of JITing MMTk at boot time just before calling GC init(). This will slow down boot but hopefully not make booting unbearable for developers. The hope is that it will be easy to put intrinsics into the JIT, jitrino.jet for all the classes in the unboxed package. Its sort of inlining but not in the traditional sense. The source transformer code is licensed as public domain, but would need considerable modification to work on the current MMTk code base. A far better approach would be to implement the vmmagic types in gcj. Or with a *.class to binary image compiler mentioned above. The bulk of the C code in the interface to Rotor is specific to rotor, and would need to be re-implemented for DRLVM anyway. Agreed. It might be nice to take a peek at the Rotor code to get ideas on how things could be implemented. The MMTk - VM interface is much cleaner these days: as Daniel points out, MM_Interface defines the JikesRVM - MMTk interface, and MMTk's interface to the vm is the package org.mmtk.vm. I am reading all the interface code now. I hope to have a general outline of the MMTk to drlvm port in a few days. I would be much appreciated if you can review it and tell me what to fix. MMTk is compiled to a JAR file against stubs for this package, and the directory ext/JikesRVM contains the JikesRVM-specific implementation of the interface. Its good to learn this. A first step will be to compile MMTk all by itself and put all of it in a JAR file. By the way, do you know how much effort it was to port MMTK to Rotor? Thanks for all the help. Weldon -- Weldon Washburn 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] odd problems when running tests under linux...
I just got my ubuntu box setup, and when running the test suite, I see this : [junit] Exception in thread main java.lang.NoClassDefFoundError: org.apache.harmony.luni.www.protocol.jar.JarURLConnection [junit] at com.ibm.oti.vm.VM.shutdown(VM.java:264) [junit] at java.lang.Runtime.exitImpl(Native Method) [junit] at java.lang.Runtime.exit(Runtime.java:215) [junit] at java.lang.System.exit(System.java:525) [junit] at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:571) I'm very willing to entertain the idea that I have something misconfigured or a wrong version of something - I've been throwing things onto the box as fast as I can... I'm under the latest ubuntu v6, have Sun's JDK5 on the machine, got the latest v3 j9 VM installed... what else do I need to tell you? geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[drlvm] apr question (linux)
Why exactly is APR slightly massaged and then specially built? Why can't we just do the regular ./configure - make sequence to build it? 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: [Fwd: [classlib][NIO|VMI]Interruptible channel implementation - how to interact with Thread?]
Archie,
Thank you for the explanation, I'm appreciated most of your suggestion,
because mostly I planned to do the same thing as part of interruption
and asynchronized close implementation. But actually the problem is how
Thread can understand what the other thread is blocking on. Please see
my comments inline:
Archie Cobbs wrote:
Paulex Yang wrote:
Jimmy, Jing Lv wrote:
Archie Cobbs wrote:
Paulex Yang wrote:
Seems Thread's implementation must be aware of what operation it
is blocking on. So I propose the following solution:
I don't think the VM or java.lang.Thread needs to be involved.
First of all, the code performing the blocking operation knows
what kind of operation it is, so when it wakes up abnormally it
can take the appropriate action. This code doesn't necessarily
reside in java.lang.Thread.
In Classpath the java.nio stuff is all implemented in native
libraries without the VM or java.lang.Thread being specially
aware of anything. However, classlib's design may be different
enough to need it (I haven't studied it as much as you guys).
E.g., the java.nio native code does invoke Thread.interrupt() and
Thread.interrupted(), but these are normal, API-specified methods.
Might be worth taking a look for some design ideas.
Thanks Archie, it sounds interesting :).
As I study few about Classpath, I still have a question here. As we
know, there are three states of blocking on a thread. One is
wait(), sleep() and so forth, thread class handle them itself, it is
easy to interrupt; and one is blocking on I/O, invoke
Thread.interrupt() may be not enough as it is blocked on a system
call, e.g., call read on socket may not return until it receive
something or it is closed. In this way, the Thread.interrupt should
know how to close the socket to perform the real interruption. The
question is: how can the thread know if it is blocked on wait() or
I/O operation currently? I think this is the reason why Paulex
require Thread to be involved. So I'm very interested in what does
Classpath do here to stop I/O operation without get involved?
Actually Thread.interrupt() is required to handle four different
scenario:
1. wait(), join(), etc, throw InterruptException
2. blocking I/O, close the channel, and throw ClosedByInterruptException
3. blocking select, wake up the selector
4. none of above, just set the thread's interrupt status
So if we don't involve Thread and want to implment scenario 2 and 3,
we may find the situation is:
a. If Thread cannot judge scenario 2/3, so it may think they are both
scenario 4, so Thread.interrupt() just set the interrupt status and
do nothing else, the I/O operation is still blocking there, we cannot
get it actually interrupted.
b. If Thread can find the thread is blocking somewhere, and it
considers all blocking as scenario 1, so the InterruptException is
thrown, but considering scenario c, Selector.select() should be waked
up without exception, while our selector only has the end() executed
in finally block like below, how does end() catch the thrown
InterruptException and handle it silently?
try {
begin();
// Perform blocking I/O operation here
...
} finally {
end();
}
c. If Thread can magically find the thread is blocking on I/O or
select, it may need to set the interrupt status, and make the blocked
Java method return with some error, so that the end() can check them.
Further, the Thread needs to know if this blocking I/O is
interruptible in Java, for example, the ServerSocket.accept() and
ServerSocketChannel.accept() probably uses same system call, but
Thread should know ServerSocket cannot be interrupted while
ServerSocketChannel can...I have no any idea how Thread can do this
without interaction with NIO channels.
So, Archie, I'm very interested in how Classpath handle this problem.
Would you please help to give more details for it (if no legal concern)?
To be honest I'm not sure how exactly it works, or even that it does
(I haven't
played with the nio stuff at all).. I only know that Thread
implementations in
Classpath don't have special stuff for NIO channels.
Taking a look at Classpath...
In Classpath, if select(2) returns EINTR, the select just returns
normally
(with nothing selected) and then the code checks Thread.interrupted().
If set, it closes and throws the exception as necessary.
Yes I noticed that select(2) on Linux has this good feature, but I
cannot find similar way on Windows:(.
Also, on UNIX at least, one thread may close a file descriptor that
another thread is waiting on and the second thread will immediately
wake up with an error. So that case is easy to handle.
Yes, that's what I tried to do in the InterruptAction which is given to
Thread.setInterruptAction(). The problem here is not *how* to close the
file descriptor, but is if thread B want to interrupt thread A, the B
don't know *if* there are any file descriptor to be closed for A or
*which* file descriptor to close.
Re: [classlib] I modified build.xml to stop running the clean target on every invocation
I think it should be there. As I remember Mark added it there after build failures. Old files could make the build mistakenly passing. Thanks, Mikhail 2006/6/16, Geir Magnusson Jr [EMAIL PROTECTED]: I hope that no one really is bothered by that. It's just so annoying :) If you are, feel free to put it back (or I will ) and then lets discuss? 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: [classlib] [testing] java.beans tests
A user might have one's own com.foo.HisStringPersistenceDelegate extending
java.beans.PersistenceDelegate and that class might invoke
protected void initialize() from the super class.
If our and RI's initialize work differently then we are in trouble
Thanks,
Mikhail
2006/6/16, Alexei Zakharov [EMAIL PROTECTED]:
To test RI's private methods you need to know the fact of their
existence at least.
As for protected methods, I agree in general. We need to test it and
to follow the behavior of RI. But in this particular case with
java.beans.PersistenceDelegate I am not 100% sure this makes much
sense.
Ok, let's be more specific. About how can we test it. We have the
following picture here:
===
package java.beans;
public abstract class PersistenceDelegate {
protected void initialize(..) {...}
protected abstract Expression instantiate(...);
...
}
package com.blah.blah.beans;
class MyStringPersistenceDelegate extends java.beans.PersistenceDelegate {
protected void initialize(..) {
// does some implementation-specific stuff
}
protected Expression instantiate(...) {
...
// returns propriatery representation of String in terms of
// java.beans.Expression
}
}
package java.beans;
public class Encoder {
public PersistenceDelegate getPersistenceDelegate(Class type) {
if (type.equals(String.class)) {
return new com.blah.blah.beans.MyStringPersistenceDelegate();
}
...
}
...
}
===
Now we like to understand how user is affected if our implementation
of MyStringPersistenceDelegate differs from RI. The user can do
something like
Encoder enc = new Encoder();
PersistenceDelegate pd = enc.getPersistenceDelegate(String.class);
Expression exp = pd.instantiate(...);
from his/her code. (NOTE: this is the only way the user can be
affected by persistence delegates.)
But, this will work only in two cases:
1) The user extends MyStringPersistenceDelegate. But since this class
is the RI internal class with arbitrary name this will not work on
Harmony anyway because we most likely use different class names for
internal classes.
2) The user extends java.beans package with additional class. This can
happen. But this is not a recommended practice. Such a user probably
should know what he/she is doing and be ready to face with problems.
So I'm not sure if we should care about these cases.
I will write in the separate message why I don't like RI's
StringPersistenceDelegate and why IMHO Harmony does things right.
2006/6/15, Mikhail Loenko [EMAIL PROTECTED]:
Sure we need to test protected methods and fields. Moreover we need
to test private methods either via API or by other means.
Alexei, it would be good if you point to a simple test that shows
difference in behavior, quote the spec and describe, why you think
Harmony does things right.
Thanks,
Mikhail
2006/6/14, Richard Liang [EMAIL PROTECTED]:
Alexei Zakharov wrote:
BTW, all questionable methods of PersistenceDelegate interface are
protected rather than public. Do we need to test it at all?
Hello Alexei,
IMHO, we need to test the protected methods, which are also part of API.
2006/6/14, Alexei Zakharov [EMAIL PROTECTED]:
Mikhail, Tim,
I suggest that you raise a few examples here.
The first example that comes to my mind is the RI's implementation of
PersistenceDelegate for java.lang.String class. (Persistence delegate
is a class that manages persistence details of his target class and is
used by java.beans.XMLEncoder). RI's imeplementation just does nothing
and returns null there applicable. It seems that RI guys simply
created a stub class they do not actually use. Most likely they
embedded String-handling logic in some other place in code. IMHO such
a decision doesn't fully correspond the idea of persistence delegates
as a place for persistence-handling logic.
BTW, our StringPersistenceDelegateTest (point 2 in my classification)
also expects some non-stub behavior from StringPersistenceDelegate. It
seems that people who have created this test also don't like this
aspect of the RI's implementation. :)
2006/6/14, Tim Ellison [EMAIL PROTECTED]:
Alexei Zakharov wrote:
Hello to everyone,
I am currently investigating tests for java.beans module.
Great.
As far as I
understand there were two separate contributions of java.beans tests
from two different parties. And these contributions were merged into
the single combined test suite we have now in svn. As a result
currently we have about 400 test case failures (excluded) out of
approximately 1200. After spending some time on this I realize
that we
have two types of issues here:
1. Test checks the compliance with very deep detail of RI's
behavior (that
is not in spec).
2. Test expects the behavior that differs from the RI's behavior
as well as
from our
Re: [classlib] [testing] java.beans tests
Probably this method is overridden by subclasses, there are similar examples
in the classlib it's a normal practice
2006/6/16, Alexei Zakharov [EMAIL PROTECTED]:
Alexei, it would be good if you point to a simple test that shows
difference in behavior, quote the spec and describe, why you think
Harmony does things right.
The spec says about persistence delegates: The PersistenceDelegate
class takes the responsibility for expressing the state of an instance
of a given class in terms of the methods in the class's public API.
I don't like to worry the collective mind with details of black-box
testing methology I use here. This is not so important. The important
thing is the result: it seems RI version of StringPersistenceDelegate
looks something like that:
class StringPersistenceDelegate extends PersistenceDelegate {
...
// Should be the main method of the persistence delegate.
// Should return the internal representation of the given
// java.lang.String object as a sequence of atmoic actions.
protected Expression instantiate(Object obj, Encoder encoder) {
return null;
}
}
I don't belive this implementation really express state of
java.lang.String instance. However, the target XML produced by
XMLEncoder - the final result of all this activity - shows that
strings are handled correctly by RI. I suppose they move String
handling logic to some other place.
2006/6/15, Mikhail Loenko [EMAIL PROTECTED]:
Sure we need to test protected methods and fields. Moreover we need
to test private methods either via API or by other means.
Alexei, it would be good if you point to a simple test that shows
difference in behavior, quote the spec and describe, why you think
Harmony does things right.
Thanks,
Mikhail
2006/6/14, Richard Liang [EMAIL PROTECTED]:
Alexei Zakharov wrote:
BTW, all questionable methods of PersistenceDelegate interface are
protected rather than public. Do we need to test it at all?
Hello Alexei,
IMHO, we need to test the protected methods, which are also part of API.
2006/6/14, Alexei Zakharov [EMAIL PROTECTED]:
Mikhail, Tim,
I suggest that you raise a few examples here.
The first example that comes to my mind is the RI's implementation of
PersistenceDelegate for java.lang.String class. (Persistence delegate
is a class that manages persistence details of his target class and is
used by java.beans.XMLEncoder). RI's imeplementation just does nothing
and returns null there applicable. It seems that RI guys simply
created a stub class they do not actually use. Most likely they
embedded String-handling logic in some other place in code. IMHO such
a decision doesn't fully correspond the idea of persistence delegates
as a place for persistence-handling logic.
BTW, our StringPersistenceDelegateTest (point 2 in my classification)
also expects some non-stub behavior from StringPersistenceDelegate. It
seems that people who have created this test also don't like this
aspect of the RI's implementation. :)
2006/6/14, Tim Ellison [EMAIL PROTECTED]:
Alexei Zakharov wrote:
Hello to everyone,
I am currently investigating tests for java.beans module.
Great.
As far as I
understand there were two separate contributions of java.beans tests
from two different parties. And these contributions were merged into
the single combined test suite we have now in svn. As a result
currently we have about 400 test case failures (excluded) out of
approximately 1200. After spending some time on this I realize
that we
have two types of issues here:
1. Test checks the compliance with very deep detail of RI's
behavior (that
is not in spec).
2. Test expects the behavior that differs from the RI's behavior
as well as
from our implementation's behavior.
As for point 1, I'm unsure here. Do we really need to be completely
identical to the RI in terms of public methods behavior? Some RI
decisions are strange.
We need to work the same (possibly unspecified) way as the reference
implementation to ensure compatibility for Java apps. An example of
some areas we already thought about are listed here [1].
If the decision is strange so that you think it is bug then we may
choose to depart from the RI's behavior after discussion on this list,
but if it is wrong because you disagree with the approach, then I'm
afraid that compatibility wins g. I suggest that you raise a few
examples here.
For point 2, I believe we should rewrite or delete such tests.
Agreed -- please indicate with your JIRA patch why you think they are
wrong, and that will help people review you rewrite/deletion request.
Thoughts, suggestions?
I'm happy that you are looking into this, and look forward to your
patches!
Regards,
Tim
--
Alexei
Re: [classlib] I modified build.xml to stop running the clean target on every invocation
On 6/16/06, Geir Magnusson Jr wrote: Mikhail Loenko wrote: I think it should be there. As I remember Mark added it there after build failures. Old files could make the build mistakenly passing. I don't understand. What prevents someone from doing $ ant clean; ant; to solve that? Then we have to perform clean explicitly each time that seems for me annoying too. I was OK with clean as a default action. Thanks, Stepan. geir Thanks, Mikhail 2006/6/16, Geir Magnusson Jr [EMAIL PROTECTED]: I hope that no one really is bothered by that. It's just so annoying :) If you are, feel free to put it back (or I will ) and then lets discuss? 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][vm] Prerequisites for java.util.concurrent
Nathan, I've attached an implementation of PriorityQueue at Harmony-574. Would you please to look if it is OK for concurrency to use? Thank you. Nathan Beyer wrote: Sorry if I was confusing, the PriorityQueue is just a dependency of the j.u.c. There are a few classes that us it internally, including the PriorityBlockingQueue. -Original Message- From: Paulex Yang [mailto:[EMAIL PROTECTED] Sent: Monday, June 12, 2006 2:18 AM To: harmony-dev@incubator.apache.org Subject: Re: [classlib][vm] Prerequisites for java.util.concurrent Nathan, I'm working on the j.u.PriorityQueue (harmony-574), but I didn't find anything related to atomic or lock on this class? The spec on this class said: *Note that this implementation is not synchronized.* Multiple threads should not access a PriorityQueue instance concurrently if any of the threads modifies the list structurally. Instead, use the thread-safe |PriorityBlockingQueue| cid:part1.06010603.05020808@gmail.com class. So I guess you meant j.u.c.PriorityBlockingQueue here? which indeed requires some operations to be atomic, such as clear(), etc. Please correct me if I missed something here. Paulex. Nathan Beyer wrote: -Original Message- From: Tim Ellison [mailto:[EMAIL PROTECTED] Nathan Beyer wrote: I've been working with the java.util.concurrent code to see what we'd need to have in place to get this code to be a part of Harmony. System.nanoTime() - A number of the classes rely on the new nanoTime method. I'm assuming this would just be marked as a native method like currentTimeMillis in luni-kernel, which would leave it up to the VMs implement. I can easily stub out the Java code. Anyone interested in getting our VMs to implement this method? I'm guessing that if IBM donates an updated VME for 1.5 usage, this would also be provided.maybe? It's in the Harmony port library as: U_64 VMCALL hytime_hires_clock (struct HyPortLibrary *portLibrary) [1] http://svn.apache.org/viewvc/incubator/harmony/enhanced/classlib/trunk/doc /vm_doc/html/hytime_8c.html?view=co Annotations - There are a few places where the @SuppressWarnings annotation is used. Building the annotations themselves is trivial, but we'll actually need to be using Java 5 class files to properly compile annotation class files. These can be commented out until the 5 class file support is enabled. Sounds like all Harmony-oriented VMs are happy for us to move to the 1.5 compiler, even if getting the runtime annotation info may not be there yet. Cool. I think the sooner we move forward, the better...at least more fun. Anyway, I think we're probably stretching the capabilities of the 1.5 source to 1.4 bytecodes functionality as far as it can go. PriorityQueue - There's at least one dependency on this class. I think someone is already working on this one though. VMI Atomicity/Lock API - All of the AtomicXXX classes are delegated to a VM-specific API for atomic gets and sets. This API will need to be defined and then implemented by the various VMs. Many of the lock APIs also make use of this API. Do these have to be VM-specific? To be honest, I'm not sure. It may be possible to write this code in a VM-agnostic way, but someone who's a bit more familiar with the underlying concepts and the native code should a peek at it. (Any VM folks have a thought?) The only reason I'm guessing it's VM-specific at the moment is just a hunch, since the atomic guarantees and lock support ties into the memory models guarantees, which is maintained by the VM, it seemed apropos. Arrays.copyOf() - Several classes utilize a set of Arrays.copyOf() methods, which are new in Java SE 6 [1]. We'd either have to rework these implementations to use System.arraycopy or just implement the new methods. AbstractMap.SimpleEntryK,V - The ConcurrentHashMap uses this class as a base class for Map.Entry objects. This is a new public class, which is also part of Java SE 6 [2]. Either this code can be reworked to just implement the Map.Entry interface, or the SimpleEntry class can be built out, which should be trivial. Strange that there are 6.0 dependencies. Is there a j.u.concurrent maintenance stream we can track rather than the dev stream? Regards, Tim Thoughts, comments, questions? [1] http://java.sun.com/javase/6/docs/api/java/util/Arrays.html [2] http://java.sun.com/javase/6/docs/api/java/util/AbstractMap.SimpleEntry.ht
[classlib][NIO]Fix the FIXMEs
I've attached the patch of Selector implementation for Harmony-41, if it is accepted, the NIO modules' API should be *completed*, but I found that there are lots of FIXME and TODOs in the nio module(more than 50!), and I've found some possibilities to improve the native codes during Harmony-41 patches creation. I've skimmed over them in Eclipse, and seems some of them are easy, but most of them need some consideration. If no one objects, I'm volunteer to look at these FIXMEs and TODOs(partly because some of them, say, network channel test, are caused by myself), and do some tidy-up work, further, because this is not an easy task, would anyone kindly like to help? -- 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] I modified build.xml to stop running the clean target on every invocation
but that means that you touch one file, the whole thing gets rebuilt. Doesn't make much sense... Let me ask - how do you use this? geir Stepan Mishura wrote: On 6/16/06, Geir Magnusson Jr wrote: Mikhail Loenko wrote: I think it should be there. As I remember Mark added it there after build failures. Old files could make the build mistakenly passing. I don't understand. What prevents someone from doing $ ant clean; ant; to solve that? Then we have to perform clean explicitly each time that seems for me annoying too. I was OK with clean as a default action. Thanks, Stepan. geir Thanks, Mikhail 2006/6/16, Geir Magnusson Jr [EMAIL PROTECTED]: I hope that no one really is bothered by that. It's just so annoying :) If you are, feel free to put it back (or I will ) and then lets discuss? 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: [classlib] I modified build.xml to stop running the clean target on every invocation
Paulex Yang wrote: Stepan Mishura wrote: On 6/16/06, Geir Magnusson Jr wrote: Mikhail Loenko wrote: I think it should be there. As I remember Mark added it there after build failures. Old files could make the build mistakenly passing. I don't understand. What prevents someone from doing $ ant clean; ant; to solve that? Then we have to perform clean explicitly each time that seems for me annoying too. I was OK with clean as a default action. So do we have the choice not to clean when running the script manually? yes - you have to type ant build or something. I've never seen a default clean before, which is why I find it annoying :) geir Thanks, Stepan. geir Thanks, Mikhail 2006/6/16, Geir Magnusson Jr [EMAIL PROTECTED]: I hope that no one really is bothered by that. It's just so annoying :) If you are, feel free to put it back (or I will ) and then lets discuss? 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: [classlib] odd problems when running tests under linux...
Try to unset JAVA_HOME variable. It helps sometimes... 2006/6/16, [EMAIL PROTECTED] [EMAIL PROTECTED]: I just got my ubuntu box setup, and when running the test suite, I see this : [junit] Exception in thread main java.lang.NoClassDefFoundError: org.apache.harmony.luni.www.protocol.jar.JarURLConnection [junit] at com.ibm.oti.vm.VM.shutdown(VM.java:264) [junit] at java.lang.Runtime.exitImpl(Native Method) [junit] at java.lang.Runtime.exit(Runtime.java:215) [junit] at java.lang.System.exit(System.java:525) [junit] at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:571) I'm very willing to entertain the idea that I have something misconfigured or a wrong version of something - I've been throwing things onto the box as fast as I can... I'm under the latest ubuntu v6, have Sun's JDK5 on the machine, got the latest v3 j9 VM installed... what else do I need to tell you? geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Alexey A. Petrenko Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] [testing] Coverage (was Re: 37% of total test execution time is spent in a single test)
The current reports don't provide code source linking. Are you going to add it? There were no information for 'security' and 'auth' modules, but, I have updated the pages and now there is source code linking for all modules. One more issue to discuss: excluded classes present in the coverage table now with 0 coverage. May be it is more convenient do not have these classes in coverage tables at all? In this case one won't wonder why the class has 0 coverage - go to exclude list to look at the class and decide whether the class is really untested or just excluded from coverage, instead, all really uncovered classes will be shown with 0 coverage, if a class is missed in coverage table – it is in exclude list. Thanks, Vladimir Now I have 2 questions/ issues to discuss: 1) preferable VM to calculate coverage (seems, the exclude list is a little bit different for j9 and drlvm) If the only difference is the exclude list then I'd suggest using VM with the shortest one. :-) 2) preferable sorting mode for results (by name, by blocks or by methods) IMHO, sorting by name looks more natural. Thanks, Stepan. Thanks, Vladimir SNIP -- 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][NIO]Fix the FIXMEs
Andrew Zhang wrote: Hi, Paulex, I'm interested in NIO module and very willing to help you tidyup FIXME TODO list. Great! Thank you! Do you have any detail plan? Actuallynot yet. But seems they can be separated like: file related / network related / spi / buffer. You are free to select one of them as start, I myself prefer to start at spi, because I was working on Harmony-41 recently, which are highly related to SPI. Ideas? Thanks! On 6/16/06, Paulex Yang [EMAIL PROTECTED] wrote: I've attached the patch of Selector implementation for Harmony-41, if it is accepted, the NIO modules' API should be *completed*, but I found that there are lots of FIXME and TODOs in the nio module(more than 50!), and I've found some possibilities to improve the native codes during Harmony-41 patches creation. I've skimmed over them in Eclipse, and seems some of them are easy, but most of them need some consideration. If no one objects, I'm volunteer to look at these FIXMEs and TODOs(partly because some of them, say, network channel test, are caused by myself), and do some tidy-up work, further, because this is not an easy task, would anyone kindly like to help? -- 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] -- 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]
[classlib][util] HARMONY-574: Java 5 Enhancement:new class java.util.PriorityQueue
Hi Paulex!
fyi the following method:
public int compare(Object object1, Object object2) {
// test cast
E e1 = (E) object1;
E e2 = (E) object2;
return 0;
}
compiles to the following bytecode:
0:aload_1
1:astore_3
2:aload_2
3:astore 4
5:iconst_0
6:ireturn
So, it does not have any cast testing.
I'll slightly update the test if you don't mind
Thanks,
Mikhail
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] I modified build.xml to stop running the clean target on every invocation
On 6/16/06, Geir Magnusson Jr wrote: but that means that you touch one file, the whole thing gets rebuilt. Doesn't make much sense... Let me ask - how do you use this? Right, if one file is updated it doesn't make sense to rebuild everything so I type 'ant build'. But usually there are several updates in different modules and I prefer to make 'clean' before building - just to avoid having debris of the previous build. Thanks, Stepan. geir Stepan Mishura wrote: On 6/16/06, Geir Magnusson Jr wrote: Mikhail Loenko wrote: I think it should be there. As I remember Mark added it there after build failures. Old files could make the build mistakenly passing. I don't understand. What prevents someone from doing $ ant clean; ant; to solve that? Then we have to perform clean explicitly each time that seems for me annoying too. I was OK with clean as a default action. Thanks, Stepan. geir Thanks, Mikhail 2006/6/16, Geir Magnusson Jr [EMAIL PROTECTED]: I hope that no one really is bothered by that. It's just so annoying :) If you are, feel free to put it back (or I will ) and then lets discuss? geir -- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
