Re: performance of drlvm
En, I list some paper I have read. 1.Efficient Representations and Abstractions for Quantifying and Exploiting Data Reference Locality. 2.Bursty Tracing: A Framework for Low-Overhead Temporal Profiling 3.Dynamic Hot Data Stream Prefetching for General-Purpose Programs 4.Profile-guided Proactive Garbage Collection for Locality Optimization list 1-4 provide the framework to trace, and the algorithm to process the trace. If you want to learn more about SEQUITUR algorithm, you can read 5.Whole Program Paths All these paper can be found by using Goole. From these paper, you can find more that you need to read. And the problems I faced now are: 1. Which library to choose to profile the Data Reference Trace. PAPI? We need to know the pc of the instructions which incur most of the cache miss. I am afraid of the profiling overhead. 2.How to abstract the Data Reference Trace for JAVA? Egor had given some clue on it. And now I want to know the schedule for this project. I expect to join it. But I am not familiar with GC and interface for profile in drlvm, can you give me some clue or suggestion to learn them as soon as possible. Thanks. -- Best Regards, Qiong,Zou
Re: [vm] ArgoUML application crashes IBM VME
On 8/24/06, Oliver Deakin [EMAIL PROTECTED] wrote: Vladimir Gorr wrote: On 8/23/06, Oliver Deakin [EMAIL PROTECTED] wrote: Hi Vladimir, Ive taken a quick look at your bug report, and at first glance the Windows stack trace says: Caused by: java.lang.UnsatisfiedLinkError: gl (Not found in com.ibm.oti.vm.bootstrap.library.path) at java.lang.ClassLoader.loadLibraryWithPath(ClassLoader.java:113) at java.lang.ClassLoader.loadLibraryWithClassLoader( ClassLoader.java:97) at java.lang.System.loadLibrary(System.java:758) at org.apache.harmony.awt.gl.windows.WinGraphicsEnvironment .clinit(WiGraphicsEnvironment.java:38) which basically tells me that you are missing gl.dll. In fact, if you look at WinGraphicsEnvironment at line 38, there is a System.loadLibrary (gl) call. You need to build with the -Dwith.awt.swing=true flag set on the ant command line to get this. If you do this and rerun argouml, the app. splash screen comes up, but is halted after a short time by the following error: Exception in thread main java.lang.reflect.InvocationTargetException at java.lang.reflect.AccessibleObject.invokeV(AccessibleObject.java:27) at java.lang.reflect.Method.invoke(Method.java:258) at com.ibm.oti.vm.JarRunner.main(JarRunner.java:42) Caused by: java.lang.NoSuchMethodError: java/applet/Applet.getAppletContext()Ljava/applet/AppletContext; at org.tigris.gef.base.Globals.getAppletContext(Globals.java:86) at org.tigris.gef.base.Globals.showStatus(Globals.java:145) at org.tigris.gef.base.Editor.pushMode(Editor.java:282) at org.tigris.gef.base.Editor.init(Editor.java:191) at org.tigris.gef.base.Editor.init(Editor.java:172) SNIP! which is not a surprise since our Applet class is just an empty shell. Looks like we cannot run this until we have Applet. It might be interesting if you ran one of the class load investigation tools contributed to Harmony (I think there might be two) to see how far away we are from running this - perhaps the results could be added to the website? The JIRAs containing these tools are listed at the bottom of [1] Uhhh... It's not very easy to build GL on Windows. Obviously this process should (and can) be rendered automatic. I hope it can ;) Oliver, I've got same result as you have. I also have info about all classes have not been implemented in the Harmony for this application (argoUML). At least the filter_classes tool (H-165) generates the following list: Great! Thanks for getting this list together. I guess these should all be covered by our xerces dependency - so it appears that the only thing standing between us and running ArgoUML is the Applet implementation? I'm slightly unsure. We need to develop the Applet to understand this. I mean new unimplemented classes can be found out after the InvocationTargetException disappers. Is there somewhere you can put this on the wiki/website so that we dont lose it? Looks like an interesting test app. Yes, it makes sense, I think. Although I don't know what the right place is? Thanks, Vladimir. Regards, Oliver cat missing_classes.txt javax/xml/parsers/SAXParserFactory javax/xml/parsers/ParserConfigurationException javax/xml/parsers/DocumentBuilderFactory javax/xml/parsers/DocumentBuilder javax/xml/parsers/SAXParser javax/xml/transform/Source javax/xml/transform/Result javax/xml/transform/TransformerException javax/xml/transform/TransformerConfigurationException org/w3c/dom/Node org/w3c/dom/NodeList org/w3c/dom/Document org/w3c/dom/Element org/w3c/dom/TypeInfo org/w3c/dom/CharacterData org/w3c/dom/Comment org/w3c/dom/DocumentType org/w3c/dom/NamedNodeMap org/w3c/dom/Attr org/w3c/dom/Text org/w3c/dom/events/EventTarget org/w3c/dom/events/DocumentEvent org/xml/sax/AttributeList org/xml/sax/EntityResolver org/xml/sax/InputSource org/xml/sax/SAXException org/xml/sax/DTDHandler org/xml/sax/ContentHandler org/xml/sax/ErrorHandler org/xml/sax/Parser org/xml/sax/XMLReader org/xml/sax/Attributes org/xml/sax/Locator org/xml/sax/ext/EntityResolver2 org/xml/sax/ext/Attributes2 org/xml/sax/ext/Locator2 org/xml/sax/helpers/DefaultHandler org/xml/sax/helpers/AttributesImpl Thanks, Vladimir. I will take a look at the Linux crash next and see if I can get anywhere with that. Ill add the above stack trace to the JIRA. Regards, Oli [1] http://incubator.apache.org/harmony/roadmap.html Vladimir Gorr wrote: ArgoUML application (http://argouml.tigris.org) crashes IBM VME. I've created new issue (H-1257) where the logs are. Could anybody please look at this problem and fix it? Thanks, Vladimir. -- 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:
Re: [ClassLib][Instrument]Put tests to Harmony (and Support_Exec)
Jimmy, Jing Lv wrote: Oliver Deakin wrote: Jimmy, Jing Lv wrote: Hi, The development on instrument is going to an end (I may still apply a few patches of refine). And the tests for it do help a lot in finding bugs and applying compatibility with RI, and special thanks to Stepan and Support_Exec. :) However, I still have a problem with Support_Exec, it usually, if not always, meets a problem in loading kernel classes. Tracing into the code, I find it add a parameter -Xbootclasspath: to launcher with a System Property(com.ibm.oti.system.class.path, I'm using J9 for DRLVM not ready for jvmti yet). But the property was null on my workspace. After deleting that parameter, I get all tests pass using both Ant and eclipse. So can someone tell me how to handle this? Or can I make a little update to it? One problem here will be that com.ibm.oti.system.class.path went out with VME v3. In VME v4 we use org.apache.harmony.boot.class.path (see modules\luni\src\main\native\luni\shared\luniglob.c). Looking at Support_Exec, it appears that this setting is out of date and should be updated with the new value. Does this fix your problem? I see :) So could I fix this value? Yes - I'd say it definitely *should* be fixed! Regards, Oliver All existing tests has pass on both Harmony and RI in my workspace(Linux/windows) when make a little change to lib name. Though VM may not be updated for it very soon, I'd like to add tests to Harmony, make it excluded first until VM ready, in order that some one who is interested can check by making a little change and run tests. Any comments/suggestions? Sounds like a good idea - it seems that the workaround to run on the IBM VME is pretty straightforward, so people will be able to run the tests if they want to. Then when a new VME is out and/or drlvm catches up we can make the tests live. Great, if no objections I'll apply tests soon :) Regards, Oliver -- Oliver Deakin IBM United Kingdom Limited - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Resolved: (HARMONY-1271) Writing '\n' to LogStream produces stack overflow
Mark,
can you please commit the fix for
http://issues.apache.org/jira/browse/HARMONY-994.
It is very close issue for this one.
Thanks in advance.
SY, Alexey
2006/8/25, Mark Hindess (JIRA) [EMAIL PROTECTED]:
[ http://issues.apache.org/jira/browse/HARMONY-1271?page=all ]
Mark Hindess resolved HARMONY-1271.
---
Resolution: Fixed
Thanks Alexey. Fixed in r436711. Please check this has been applied as
expected and resolves this issue.
Writing '\n' to LogStream produces stack overflow
-
Key: HARMONY-1271
URL: http://issues.apache.org/jira/browse/HARMONY-1271
Project: Harmony
Issue Type: Bug
Components: Classlib
Reporter: Alexey Petrenko
Assigned To: Mark Hindess
Attachments: HARMONY-1271.diff
The following test case fails on Harmony with stack overflow.
import java.rmi.server.*;
import java.io.*;
public class HarmonyLogStreamTest {
public static void main(String [] args) {
try {
LogStream ls = LogStream.log(tst);
System.out.println(ls);
ls.write((int)'\n');
System.out.println(Test passed);
} catch (Throwable e) {
System.out.println(unexpected error: + e);
//e.printStackTrace();
}
}
}
--
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
--
Alexey A. Petrenko
Intel Middleware Products Division
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DRLVM][VM] -- which header bits are available for GC mark and GC forwarding use?
Weldon, look at the patch in http://issues.apache.org/jira/browse/HARMONY-1269. I have already done this work. After the patch you have whole lowest byte + 2 bits in the second byte for GC use; in expense of implementing hashcode by GC. In my understanding the hashcode can be reduced to 2 status bits in object info: 00. hashcode is not set 01. hashcode is set (hashcode is the address of object) 11. hashcode is set and object is moved (hashcode is no longer the address of object) This layout require assistance from GC (which is missing in GC_V4). I suggest using interface function: gc_get_hashcode() in GC-to-VM interface which will know exactly the layout of bits in the lowest byte of hashcode and will do all the needed actions depending on the GC implementation. -- Regards, Ivan On 8/25/06, Weldon Washburn [EMAIL PROTECTED] wrote: On 8/24/06, Salikh Zakirov [EMAIL PROTECTED] wrote: In any way, currently there is no single header file in the system, which would describe the object structure. Rather, DRLVM uses some static assumptions about object header, which are not enforced by any common include file. This would be a nice thing to solve... Good point. There needs to be a discussion on harmony-dev regarding how the object header bits are sliced and diced. From talking to the MMTk guys (Steve Blackburn) it seems MMTk wants to have one byte of object header for private use. Its unclear to me if this will be a performance problem for a product JVM. I think the hashCode can be reduced to one bit plus the object's current address at first HashCode() invocation. I'd put this hash bit in the GC byte. And make the GC byte the lowest byte in the header word. The remaining 3bytes could be used for fat/thin locks. Are there any remaining fields unaccounted for? Thoughts? -- 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: [jira] Resolved: (HARMONY-1271) Writing '\n' to LogStream produces stack overflow
On 25 August 2006 at 13:05, Alexey Petrenko [EMAIL PROTECTED]
wrote:
Mark,
can you please commit the fix for
http://issues.apache.org/jira/browse/HARMONY-994.
It is very close issue for this one.
Yeah, I noticed. I'm just doing it. ;-)
And I'll add the one-line for the regression test of 1271.
-Mark.
Thanks in advance.
SY, Alexey
2006/8/25, Mark Hindess (JIRA) [EMAIL PROTECTED]:
[ http://issues.apache.org/jira/browse/HARMONY-1271?page=all ]
Mark Hindess resolved HARMONY-1271.
---
Resolution: Fixed
Thanks Alexey. Fixed in r436711. Please check this has been applied as ex
pected and resolves this issue.
Writing '\n' to LogStream produces stack overflow
-
Key: HARMONY-1271
URL: http://issues.apache.org/jira/browse/HARMONY-1271
Project: Harmony
Issue Type: Bug
Components: Classlib
Reporter: Alexey Petrenko
Assigned To: Mark Hindess
Attachments: HARMONY-1271.diff
The following test case fails on Harmony with stack overflow.
import java.rmi.server.*;
import java.io.*;
public class HarmonyLogStreamTest {
public static void main(String [] args) {
try {
LogStream ls = LogStream.log(tst);
System.out.println(ls);
ls.write((int)'\n');
System.out.println(Test passed);
} catch (Throwable e) {
System.out.println(unexpected error: + e);
//e.printStackTrace();
}
}
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: htt
p://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/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]
-
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][GC] high-level design proposal for GCV5
Ivan Volosyuk wrote: Yes, I have experimented with per-slot verification of write barrier. The idea was the following: each word in java heap has external mirror record. After garbage collection all mirror records are synchronized with the heap. Each write barrier updates mirror record with corresponding data. Before next garbage collection there is a trace for all reachable objects in heap which validates that each slot contains the same data as the mirror. The idea is quite simple. Even that, it helped my find number of places in VM code which have updated slots in heap without call to write barrier. The results of the work are in HARMONY-504. The scheme has one impotant limitation. When several threads write to single slot, this verifier may report false-positive result of missing write barrier. But, I didn't see such situtations in any workloads I have tested it with. The infrastructure based on the same idea, but independent of GC implementation is submitted as HARMONY-881. It provides patch for the VM, which incorporates the heap mirroring framework for write barrier verification into the VM core, and can work with any garbage collector. - 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][GC] high-level design proposal for GCV5
Ivan, Salikh, good idea and thanks for the info. We'd want to apply the work into Harmony GC. Thanks, xiaofeng On 8/25/06, Salikh Zakirov [EMAIL PROTECTED] wrote: Ivan Volosyuk wrote: Yes, I have experimented with per-slot verification of write barrier. The idea was the following: each word in java heap has external mirror record. After garbage collection all mirror records are synchronized with the heap. Each write barrier updates mirror record with corresponding data. Before next garbage collection there is a trace for all reachable objects in heap which validates that each slot contains the same data as the mirror. The idea is quite simple. Even that, it helped my find number of places in VM code which have updated slots in heap without call to write barrier. The results of the work are in HARMONY-504. The scheme has one impotant limitation. When several threads write to single slot, this verifier may report false-positive result of missing write barrier. But, I didn't see such situtations in any workloads I have tested it with. The infrastructure based on the same idea, but independent of GC implementation is submitted as HARMONY-881. It provides patch for the VM, which incorporates the heap mirroring framework for write barrier verification into the VM core, and can work with any garbage collector. - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Resolved: (HARMONY-1271) Writing '\n' to LogStream produces stack overflow
Thanks :)
2006/8/25, Mark Hindess [EMAIL PROTECTED]:
On 25 August 2006 at 13:05, Alexey Petrenko [EMAIL PROTECTED]
wrote:
Mark,
can you please commit the fix for
http://issues.apache.org/jira/browse/HARMONY-994.
It is very close issue for this one.
Yeah, I noticed. I'm just doing it. ;-)
And I'll add the one-line for the regression test of 1271.
-Mark.
Thanks in advance.
SY, Alexey
2006/8/25, Mark Hindess (JIRA) [EMAIL PROTECTED]:
[ http://issues.apache.org/jira/browse/HARMONY-1271?page=all ]
Mark Hindess resolved HARMONY-1271.
---
Resolution: Fixed
Thanks Alexey. Fixed in r436711. Please check this has been applied as ex
pected and resolves this issue.
Writing '\n' to LogStream produces stack overflow
-
Key: HARMONY-1271
URL: http://issues.apache.org/jira/browse/HARMONY-1271
Project: Harmony
Issue Type: Bug
Components: Classlib
Reporter: Alexey Petrenko
Assigned To: Mark Hindess
Attachments: HARMONY-1271.diff
The following test case fails on Harmony with stack overflow.
import java.rmi.server.*;
import java.io.*;
public class HarmonyLogStreamTest {
public static void main(String [] args) {
try {
LogStream ls = LogStream.log(tst);
System.out.println(ls);
ls.write((int)'\n');
System.out.println(Test passed);
} catch (Throwable e) {
System.out.println(unexpected error: + e);
//e.printStackTrace();
}
}
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: htt
p://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/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]
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Alexey A. Petrenko
Intel Middleware Products Division
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[classlib] HARMONY-790 is not reproducible
Committers, can anybody of you close HARMONY-790 issue please. Since it is not reproducible on current build. We got a huge number of open JIRA issues which are has patches or not reproducible... 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: [DRLVM][VM] -- which header bits are available for GC mark and GC forwarding use?
On 8/25/06, Weldon Washburn [EMAIL PROTECTED] wrote: On 8/24/06, Salikh Zakirov [EMAIL PROTECTED] wrote: In any way, currently there is no single header file in the system, which would describe the object structure. Rather, DRLVM uses some static assumptions about object header, which are not enforced by any common include file. This would be a nice thing to solve... Good point. There needs to be a discussion on harmony-dev regarding how the object header bits are sliced and diced. From talking to the MMTk guys (Steve Blackburn) it seems MMTk wants to have one byte of object header for private use. Its unclear to me if this will be a performance problem for a product JVM. I think the hashCode can be reduced to one bit plus the object's current address at first HashCode() invocation. I'd put this hash bit in the GC byte. And OK, then what this one bit will be used for? Where do we keep the hash code after the object is moved and it's address is changed? Perhaps I'm not getting the idea... make the GC byte the lowest byte in the header word. The remaining 3bytes could be used for fat/thin locks. Are there any remaining I think this is a good idea to use the different bytes for GC and Object's monitor purposes. It can help monitor's and GC's algorithms to work independently and avoid extensive atomic operations whenever it is possible. Thanks, Andrey. fields unaccounted for? Thoughts? -- 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] -- Andrey Chernyshev 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-1137) [classlib][swing/text] unit test AbstractDocument_DefaultDocumentEventTest fails
Hello, Can someone take a look and apply patches from HARMONY-1137 [1]? There's also a patch to un-exclude the tests which stop failing after applying the patch for HARMONY-1028 [2]. These tests are: javax.swing.text.AbstractDocument_DefaultDocumentEventTest, javax.swing.text.AbstractDocument_ElementEditTest, javax.swing.text.AbstractDocument_UpdateTest. Thanks, Alexey. [1] https://issues.apache.org/jira/browse/HARMONY-1137 [2] https://issues.apache.org/jira/browse/HARMONY-1028 -- Alexey A. Ivanov Intel Middleware Product Division -Original Message- From: Alexey A. Ivanov (JIRA) [mailto:[EMAIL PROTECTED] Sent: Friday, August 25, 2006 4:59 PM To: Ivanov, Alexey A Subject: [jira] Updated: (HARMONY-1137) [classlib][swing/text] unit test AbstractDocument_DefaultDocumentEventTest fails [ http://issues.apache.org/jira/browse/HARMONY-1137?page=all ] Alexey A. Ivanov updated HARMONY-1137: -- Attachment: swing-build-unexclude-tests.patch After fixing the issue HARMONY-1028, the AbstractDocument_ tests excluded from run have stopped failing. After applying patches from this issue, no test case should fail in the AD_DefaultDocumentEventTest too. So swing-build-unexclude-tests.patch removes such tests from the exclude section. [classlib][swing/text] unit test AbstractDocument_DefaultDocumentEventTest fails - --- Key: HARMONY-1137 URL: http://issues.apache.org/jira/browse/HARMONY-1137 Project: Harmony Issue Type: Bug Components: Classlib Reporter: Alexey A. Ivanov Attachments: swing-build-unexclude-tests.patch, UndoRedoNames_Src.patch, UndoRedoNames_Tests.patch The following tests fail becuase of incorrect tests: testGetUndoPresentationName(javax.swing.text.AbstractDocument_DefaultDo cume ntEventTest) junit.framework.ComparisonFailure: expected:...addition but was:...Text added at javax.swing.text.AbstractDocument_DefaultDocumentEventTest.testGetUndoP rese ntationName(AbstractDocument_DefaultDocumentEventTest.java:241) testGetRedoPresentationName(javax.swing.text.AbstractDocument_DefaultDo cume ntEventTest) junit.framework.ComparisonFailure: expected:...addition but was:...Text added at javax.swing.text.AbstractDocument_DefaultDocumentEventTest.testGetRedoP rese ntationName(AbstractDocument_DefaultDocumentEventTest.java:247) testGetPresentationName(javax.swing.text.AbstractDocument_DefaultDocume ntEv entTest) junit.framework.ComparisonFailure: expected:addition but was:Text added at javax.swing.text.AbstractDocument_DefaultDocumentEventTest.testGetPrese ntat ionName(AbstractDocument_DefaultDocumentEventTest.java:253) The text to compare with should be fetched from the UIManager. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [classlib] HARMONY-790 is not reproducible
On 25 August 2006 at 15:47, Alexey Petrenko [EMAIL PROTECTED] wrote: Committers, can anybody of you close HARMONY-790 issue please. Since it is not reproducible on current build. Is the regression test also obsolete - i.e. covered elsewhere? If not, then perhaps that should be integrated before we close the bug. We got a huge number of open JIRA issues which are has patches or not reproducible... Thanks for helping by looking at these. If you spot others and send messages and/or add comments in JIRA I'll take a look at them. 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]
[classlib][TestNG] groups of Harmony test
Hello All,
Now let's talk about the TestNG groups. I have read the related threads
which posted by George, Vladimir Ivanov and Alexei Zakharov. All of them
are good discussion about TestNG groups.
IMHO, we may define Harmony test groups according the following 4
dimensions:
1) [Platform] os.any, os.platform id
*os.any* - group of tests which pass on any platform. IMHO, most of our
tests should be in this group.
*os.platform id* - group of tests which are designed for one specific
platform. A test may be in more than one of the groups. e.g.,
@Test(groups={os.win.IA32, os.linux.IA32})
** os.any and os.platform id are mutually exclusive, that is,
tests in os.any group should not be in os.win.IA32.
2) [Test state] state.broken, state.broken.platform id
*state.broken* - group of tests which fail on every platform, because
of bugs of tests or implementation. We need to fix the bugs of tests or
implementation to make them pass.
*state.broken.platform id* - groups of test which only fail on one
specific platform. A test may be in more than one of the groups. e.g.,
@Test(groups={state.broken.linux.IA32, os.broken.linux.IA64})
**state.broken.platform id group may be used as a convenient way
to indicate that a test is platform-specific. e.g., If we support 10
platforms, and one test are designed for 9 platforms except for MacOS,
instead of list 9 os.platform id, we can just use state.broken.MacOS
3) [Test type] type.api, type.impl
*type.api* - group of tests which are tests for APIs in the Java
Specification
*type.impl* - groups of tests which are tests for Harmony-specific
implementation
** type.api and type.impl are also mutually exclusive.
4) [Test Level] level.unit, level.integration, level.system,
level.stress, etc. (Levels of Test refer to the increase in complexity
as moving through test cycle. )
** A test may be in more than one of the groups.
** In fact, some tests such as System tests are the verification of
the entire system. Maybe we'll put them into a separate project. e.g.,
harmony/enhanced/SVT (System Verification Test).
If we want to run all the unit test for APIs on windows, we may use
TestNG groups to select the tests:
groups
run
include name=os.any /
include name=type.api /
include name=os.win.IA32 /
exclude name=state.broken /
exclude name=state.broken.win.IA32 /
/run
/groups
Well, I think our most of existing tests are in the groups of {os.any,
type.api, level.unit}, and I have asked TestNG to add a new option
-groups for its JUnitConverter which allow us to specify the test
groups when migrate from JUnit test to TestNG test.
Thanks for reading so far, and I will highly appreciate your comments or
suggestion. ;-)
--
Richard Liang
China Software Development Lab, IBM
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DRLVM][VM] -- which header bits are available for GC mark and GC forwarding use?
On 8/25/06, Andrey Chernyshev [EMAIL PROTECTED] wrote: On 8/25/06, Weldon Washburn [EMAIL PROTECTED] wrote: On 8/24/06, Salikh Zakirov [EMAIL PROTECTED] wrote: In any way, currently there is no single header file in the system, which would describe the object structure. Rather, DRLVM uses some static assumptions about object header, which are not enforced by any common include file. This would be a nice thing to solve... Good point. There needs to be a discussion on harmony-dev regarding how the object header bits are sliced and diced. From talking to the MMTk guys (Steve Blackburn) it seems MMTk wants to have one byte of object header for private use. Its unclear to me if this will be a performance problem for a product JVM. I think the hashCode can be reduced to one bit plus the object's current address at first HashCode() invocation. I'd put this hash bit in the GC byte. And OK, then what this one bit will be used for? Where do we keep the hash code after the object is moved and it's address is changed? Perhaps I'm not getting the idea... Hashcode for the moved object can be allocated just after the end of the object. This is done in GC v4.1 (HARMONY-1269). For more details how it can be done, look at my previous posting in this thread. The problem is, that changes required for existing algorithms to use this approach. E.g. it is not so easy to do this in Gc_v4. So, use of GC interface function gc_get_hashcode() can help. Some of algorithm may store hashcode in object info bits, others can use more advanced approaches. make the GC byte the lowest byte in the header word. The remaining 3bytes could be used for fat/thin locks. Are there any remaining I think this is a good idea to use the different bytes for GC and Object's monitor purposes. It can help monitor's and GC's algorithms to work independently and avoid extensive atomic operations whenever it is possible. Thanks, Andrey. - 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][GC] Goals for 2006/2007
On 8/15/06, Robin Garner [EMAIL PROTECTED] wrote: Weldon Washburn wrote: All, There is rough consensus that the immediate goal for Harmony JVM is to reliably run simple commercial workloads with acceptable performance. In regards to a garbage collector for a Harmony JVM in 2006 there are some data points worth noting. 1) A quick survey shows most basic commercial JVMs implement a generational collector. 2) While the existing drlvm garbage collector, gcv4, implements some interesting advanced concepts, it is not currently a generational collector. 3) The MMTk port to drlvm is not yet finished. Even assuming MMTk's generational configuration is appropriate, it is still too early to put this garbage collector on the roadmap for a 2006 Harmony JVM. It might be worth revisiting in 2007. But it's too far away to debate at this time. Given the above data points, the following is a first stab at requirements for Harmony GCV5. The intention is to set down some basic parameters. 1) Generational Collector with mark/compacting mature object space Why mark/compact specifically ? The easiest approach would be to add a copying nursery 'in front' of the exiting GCV4 mature space, and then look at replacing/updating the implementation of the mature space. This could be achieved with virtually no change to the mature space collector. As an aside, best performance with a generational collector also comes from an Appel-style nursery, ie the nursery size is essentially (heap-mature)/2. The rest of the worklist seems uncontroversial to me, but I wonder how much work it is to implement these vs getting MMTk working. Good point, it seems that this is a way to go. One thing which bothers me much is that the code of GCV4 is quite bloated. Some cleaning for the code might be required before. -- Regards, Ivan - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[classlib] Sun compiler change?
Is anyone else using the latest Sun JDK, v5.0 Update 8 on Windows? I'm seeing a compilation error in the LUNI that I don't see with 5.0 Update 7. Here's the error I'm getting. compile: [mkdir] Created dir: C:\dev\harmony\enhanced\classlib\trunk\build\classes [javac] Compiling 3173 source files to C:\dev\harmony\enhanced\classlib\trun k\build\classes [javac] C:\dev\harmony\enhanced\classlib\trunk\modules\luni\src\main\java\ja va\util\MiniEnumSet.java:78: inconvertible types [javac] found : java.util.Collectioncapture of ? extends E [javac] required: java.util.EnumSetE [javac] EnumSetE set = (EnumSetE) collection; [javac] ^ When I compile in Eclipse 3.2 there's no error. -Nathan
Re: performance of drlvm
On 8/25/06, Mikhail Fursov [EMAIL PROTECTED] wrote: On 8/25/06, zouqiong [EMAIL PROTECTED] wrote: ... This is the key problem. I hope I will have an opinion on it when I read all of the articles you mentioned. The only idea I have now is that using an address of an object is not a problem. Once GC moves objects we can ask it to patch our references too. And now I want to know the schedule for this project. I expect to join it. But I am not familiar with GC and interface for profile in drlvm, can you give me some clue or suggestion to learn them as soon as possible. Thanks. What is your question about the GC? If you can use enumeratable GC references, they will be automatically repointed by garbage collector. In your case it may be even better to use weak roots and weak references, if you don't want to hold object when having the last reference to it. -- Ivan I'm also not a guru in GC, but I think there are a lot of people here who know the answers and can help in the area they are interested. So the proposal is: 1) You make the schedule and lead this project. I can help you with dynamic recompilation scenarios implementations and with JIT code generation and optimizations. 2) Why do not to implement classic Chilimbi algorithm first and enhance it with PMU data when it's tested? - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
