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]
[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.Collection [javac] required: java.util.EnumSet [javac] EnumSet set = (EnumSet) collection; [javac] ^ When I compile in Eclipse 3.2 there's no error. -Nathan
Re: [DRLVM][GC] Goals for 2006/2007
Hi Nadya, We should actually do the reverse. Hold the discussion and decisions online, and then make sure that the documents, eg, the VM Developer's Guide etc. are not outdated. Thanks, Rana On 8/17/06, Morozova, Nadezhda <[EMAIL PROTECTED]> wrote: >All, >I found some GC requirements description in the OPEN spec [1], section >5.3.5 and something inside 6.*. How does those suggestions relate to >what is being discussed? >Do you think we can use that doc as the basis and maybe track major >decisions there? Mail threads tend to drop, and are not always a >convenient means of finding the final decision for an issue :)
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]
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] high-level design proposal for GCV5
The HARMONY-881 patch was submitted quite some time ago. I'm also looking forward to see it integrated. -- Regards, Ivan On 8/25/06, Xiao-Feng Li <[EMAIL PROTECTED]> wrote: 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] -- Ivan 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][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.
*os.any* - group of tests which pass on any platform. IMHO, most of our
tests should be in this group.
*os.* - 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. are mutually exclusive, that is,
tests in os.any group should not be in os.win.IA32.
2) [Test state] state.broken, state.broken.
*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.* - 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. 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., 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:
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: [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]
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: but was: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: [jira] Created: (HARMONY-1116) [classlib][text] Bidi.getLength() result differs from RI when flag > 61
On 8/9/06, Denis Kishenko <[EMAIL PROTECTED]> wrote:
Behavior of Harmony Bidi implementation differs from RI when Bidi is
created with flag parameter more then 61 According spec flag should be
a combination of predefined constants and 62 is invalid value.
I filed this issue as non-bug difference. Does anybody have objection?
Hello, Denis!
I've took a look into this bug and also have an opinion that this is a
non-bug difference.
As it's written in the spec flags argument could be one of the predefined
values.
Verification of other non-predefined values is undescribed in the spec.
I think in this case we should be compatible for predefined values and we
shouldn't care if Harmony
implementation has another behavior than RI for non-specified flags values.
Regards,
Ilya.
2006/8/9, Denis Kishenko (JIRA) <[EMAIL PROTECTED]>:
> [classlib][text] Bidi.getLength() result differs from RI when flag > 61
> ---
>
> Key: HARMONY-1116
> URL: http://issues.apache.org/jira/browse/HARMONY-1116
> Project: Harmony
> Issue Type: Bug
> Components: Non-bug differences from RI
>Reporter: Denis Kishenko
>
>
> RI returns 0 for java.text.Bidi.getLength() if object was created via
Bidi(String paragraph, int flags) with flag>61 like below:
>
> Bidi bd = new Bidi("Java is the best", 62);
>
> From the specification for Bidi constructor:
> flags - a collection of flags that control the algorithm. The algorithm
> understands the flags DIRECTION_LEFT_TO_RIGHT, DIRECTION_RIGHT_TO_LEFT,
> DIRECTION_DEFAULT_LEFT_TO_RIGHT, and DIRECTION_DEFAULT_RIGHT_TO_LEFT.
> Other values are reserved.
>
> - Test --
>
> import java.text.*;
>
> public class bug9383 {
>public static void main (String[] args) {
>try {
>Bidi bd = new Bidi("Java is the best", 62);
>System.out.println("len="+bd.getLength());
> } catch (Exception e) {
> e.printStackTrace();
> }
>}
> }
>
> Output
---
>
> RI
> len=0
>
> Harmony
> len=16
>
>
>
>
>
> --
> 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
>
>
>
--
Denis M. Kishenko
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]
--
--
Ilya Okomin
Intel Middleware Products Division
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]
[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: [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]
Re: performance of drlvm
On 8/25/06, zouqiong <[EMAIL PROTECTED]> wrote: 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. Ok, I will read all of them on this weekend and hope I will be more educated in algorithm you decided to use. Now, I read only 3rd paper and see that this is not enough to understand all of the details. 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. I would suggest to try this library: http://perfmon2.sourceforge.net/ (paper: http://perfmon2.sourceforge.net/ols2006-perfmon2.pdf) PAPI was a good library several years ago but today it's development is frozen and AFAIK P4 support is incomplete. Why do you worry about profiling overhead if you can counfigure PMU to store in buffer only one event per million? 2.How to abstract the Data Reference Trace for JAVA? Egor had given some clue on it. 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. 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? -- Mikhail Fursov
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: [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: [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][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
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][GC] high-level design proposal for GCV5
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. -- Regards, Ivan On 8/25/06, Xiao-Feng Li <[EMAIL PROTECTED]> wrote: Ivan, there is no disagreement on the importance of those verifications (or validations) for Harmony GC. :-) What I was saying is we need more thinking on the design than the rough idea, such as when, how, what, etc. Have you any good idea on the write barrier verfication design? Thanks, -xiaofeng On 8/24/06, Ivan Volosyuk <[EMAIL PROTECTED]> wrote: > > > It might also make sense to design in a write barrier verifier. The > > > concept is to verify that all the old-to-young pointers are properly > > > handled. One way of doing this is to force a full heap mark. Then > > > compare the full heap mark's old-to-young pointers to what the write > > > barrier mechanism derived. > > > > This needs more thinking. The old-to-yound pointers got in a full-heap > > marking have only live ones. But I think the idea to have some write > > barrier verifier is interesting, e..g, the rememebered set has to be a > > superset of live old-to-yound pointers. > > IMHO, write barrier verifier is a _must_ to have feature for us. The > same applies to full heap tracing-validation. As VM and JIT code are > subject of changes, it should be the way to isolate bugs introduced by > GC and the ones coming from VM/JIT. > -- > Ivan > > > > > Thanks, > > xiaofeng > > - > 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] -- Ivan 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][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: [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
>> .(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.(Editor.java:191)
>>at org.tigris.gef.base.Editor.(Editor.java:172)
>>
>>
>> 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
>>
>>
>> --
