Re: [drlvm][jit] MMTk-style magics implementation in Jitrino.OPT compiler
On 9/30/06, Weldon Washburn [EMAIL PROTECTED] wrote: Good! I look forward to seeing vm helpers written in vmmagic. Yes, this is the final goal and I hope we will start the implementation of VM helpers using magics package this week. The only item left to do is to restore JET support for your experiments with GC. I'm going to commit the patch in a day. Weldon, I finished vmmagic implementation in OPT compiler and there are no known bugs left. I tested the code with Eclipse and several benchmarks - nothing is broken, all applications work OK. Could I ask you to add the 'magics' support code into the trunk? The patch name is 'magic4.diff' in H1489 -- Mikhail Fursov
Re: [drlvm][jit] MMTk-style magics implementation in Jitrino.OPT compiler
Mikhail, I just now committed magic5.diff, H1489. Let me know when the next JIRA is ready. I want your mods committed so that I can resume MMTk integration. Thanks Weldon On 10/2/06, Mikhail Fursov [EMAIL PROTECTED] wrote: I forgot to test the last patch on Linux. Now the build is fixed for Linux too and I attached to the H1489 the new patch: 'magic5.diff' On 10/2/06, Mikhail Fursov [EMAIL PROTECTED] wrote: On 9/30/06, Weldon Washburn [EMAIL PROTECTED] wrote: Good! I look forward to seeing vm helpers written in vmmagic. Yes, this is the final goal and I hope we will start the implementation of VM helpers using magics package this week. The only item left to do is to restore JET support for your experiments with GC. I'm going to commit the patch in a day. Weldon, I finished vmmagic implementation in OPT compiler and there are no known bugs left. I tested the code with Eclipse and several benchmarks - nothing is broken, all applications work OK. Could I ask you to add the 'magics' support code into the trunk? The patch name is ' magic4.diff' in H1489 -- Mikhail Fursov -- Mikhail Fursov -- Weldon Washburn Intel Middleware Products Division
Re: [drlvm][jit] MMTk-style magics implementation in Jitrino.OPT compiler
On 9/29/06, Mikhail Fursov [EMAIL PROTECTED] wrote:
All,
I finished 'unboxed' package implementation in Jitrino.OPT. The patch is
in
JIRA 1489
The potential problems:
1) We still do not have a test suite.
Hmmm... I fixed up the vmmagic test suite and gave it back to the owners .
It should be donated to open source soon.
2) Two bugs in Jitrino.OPT CG prevents us from use load/store by offset
operations sometimes. I going to fix both of these bugs on Monday.
Anyway, I think we will be ready to write helpers with 'magics' next week.
Good! I look forward to seeing vm helpers written in vmmagic.
On 9/22/06, Robin Garner [EMAIL PROTECTED] wrote:
On 9/21/06, Mikhail Fursov [EMAIL PROTECTED] wrote:
Weldon, Robin
thank you for the comments.
There are just a few steps left to do before Jitrino.OPT will have
usable
unboxed package implementation.
Right now I'm working on atomic operations (prepare/attempt pair),
and
I
do
not completely understand the semantic of the 'prepare' method.
The prepareXYZ method looks like a simple load and is not an atomic
operation by itself. Are there any examples that describe these
operations
in details?
Robin will correct me if I am wrong.
I think the idea is that this is a generic API intended to be used for
accessing compare and swap facilities on a bunch of different
hardware.
And the actual hardware has different memory models, different CAS
semantics, etc.
Basically the generic facility needed is to first read the CAS target
memory
location (this is the prepare). If the memory is sitting at a
specific
value (this is the do something), then do an attempt as follows:
old_contents = CAS(expected_specfic_value_that_I_just_read,
some_new_value,
target_memory_location)
If the old_contents are identical to
expected_specific_value_that_I_just_read, we know that the CAS
succeeded.
In other words, you won the competition. Otherwise you lost.
I imagine the following situation in user's code:
prepareXYZ()
do something
attempt()
Is this code correct?
You're correct.
The prepare/attempt was designed to match architectures (PPC, Alpha ...)
with a load-locked/store-conditional instruction pair.
The standard code fragment for a synchronized update is
do {
oldVal = x.prepare();
newVal = f(oldVal);
} while (!x.attempt(oldVal,newVal));
As an aside, vmmagic should probably have CAS as a primitive rather than
prepare/attempt, but I don't think that's going to happen in the
immediate
future.
cheers
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Mikhail Fursov
--
Weldon Washburn
Intel Middleware Products Division
Re: [drlvm][jit] MMTk-style magics implementation in Jitrino.OPT compiler
All,
I finished 'unboxed' package implementation in Jitrino.OPT. The patch is in
JIRA 1489
The potential problems:
1) We still do not have a test suite.
2) Two bugs in Jitrino.OPT CG prevents us from use load/store by offset
operations sometimes. I going to fix both of these bugs on Monday.
Anyway, I think we will be ready to write helpers with 'magics' next week.
On 9/22/06, Robin Garner [EMAIL PROTECTED] wrote:
On 9/21/06, Mikhail Fursov [EMAIL PROTECTED] wrote:
Weldon, Robin
thank you for the comments.
There are just a few steps left to do before Jitrino.OPT will have
usable
unboxed package implementation.
Right now I'm working on atomic operations (prepare/attempt pair), and
I
do
not completely understand the semantic of the 'prepare' method.
The prepareXYZ method looks like a simple load and is not an atomic
operation by itself. Are there any examples that describe these
operations
in details?
Robin will correct me if I am wrong.
I think the idea is that this is a generic API intended to be used for
accessing compare and swap facilities on a bunch of different
hardware.
And the actual hardware has different memory models, different CAS
semantics, etc.
Basically the generic facility needed is to first read the CAS target
memory
location (this is the prepare). If the memory is sitting at a
specific
value (this is the do something), then do an attempt as follows:
old_contents = CAS(expected_specfic_value_that_I_just_read,
some_new_value,
target_memory_location)
If the old_contents are identical to
expected_specific_value_that_I_just_read, we know that the CAS
succeeded.
In other words, you won the competition. Otherwise you lost.
I imagine the following situation in user's code:
prepareXYZ()
do something
attempt()
Is this code correct?
You're correct.
The prepare/attempt was designed to match architectures (PPC, Alpha ...)
with a load-locked/store-conditional instruction pair.
The standard code fragment for a synchronized update is
do {
oldVal = x.prepare();
newVal = f(oldVal);
} while (!x.attempt(oldVal,newVal));
As an aside, vmmagic should probably have CAS as a primitive rather than
prepare/attempt, but I don't think that's going to happen in the immediate
future.
cheers
-
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Mikhail Fursov
Re: [drlvm][jit] MMTk-style magics implementation in Jitrino.OPT compiler
Weldon, Robin thank you for the comments. There are just a few steps left to do before Jitrino.OPT will have usable unboxed package implementation. Right now I'm working on atomic operations (prepare/attempt pair), and I do not completely understand the semantic of the 'prepare' method. The prepareXYZ method looks like a simple load and is not an atomic operation by itself. Are there any examples that describe these operations in details? I imagine the following situation in user's code: prepareXYZ() do something attempt() Is this code correct? On 9/21/06, Robin Garner [EMAIL PROTECTED] wrote: Weldon Washburn wrote: On 9/20/06, Mikhail Fursov [EMAIL PROTECTED] wrote: I put the update into JIRA. This update still has a lot of bugs, but is significantly more stable then the initial one. My plan is to work on lock prefix support in Jitrino.OPT CG tomorrow, so if somebody is interested to enhance the current implementation there will no conflicts in our work. + There are several issues to discuss that are not clear to me: 1) Do we allow to save magic class into object fields? If yes, GC must be aware about magics and do not enumerate magic fields. Actually, the GC issues are taken care of at a higher level. The developer who is using vmmagics must extend the Uninterruptible class. That's not actually strictly true, there's also the UninterruptiblePragma exception. More generally, the burden is on the programmer to ensure that objects that you hold an Address of don't move while you hold the reference, and these pragmas are one method of doing that. You could also use locks etc (in theory at least). Another issue is that storing an unboxed object from vmmagic into an arbitrary object field has to be thought through very carefully by the developer. Or else there will be stale pointers running around that will cause hard crashes. In any case it is not a JIT responsibility. If the developer puts an object of type vmmagic Address in the heap then later retrieves a stale pointer, disaster will hit. I know because I have done this accidentally. Magic loads and stores also don't trigger read/write barriers, so the programmer needs to manually insert barriers if they would have been called. 4) Why do we need all of these types: Word, Offset, Extent if they are all just platform dependent unsigned integers? I understand that code of garbage collectors already uses these types and we must support them all, but what was the initial reason to introduce all of them? I thought the same thing when I first started working on MMTk port. Now I see there is benefit in the different types because it makes the code easier to read and also allows java type system to catch dumb errors that otherwise would be left to debugging stage. Once upon a time, magic fields were all just ints, and the present variety evolved over time, precisely for this reason. An ObjectReference may seem mysterious to the casual observer (why don't we just use Object ?). This is present so that MMTk can support languages other than Java (Haskell was my original target, and we have done C#), and also so because the object model of the VM that executes MMTk code may not necessarily be the same as the system that MMTk is managing. So an ObjectReference is the 'moral equivalent' of an object. Thats all for today. Will provide an update in a day or two. On 9/18/06, Weldon Washburn [EMAIL PROTECTED] wrote: On 9/18/06, Mikhail Fursov [EMAIL PROTECTED] wrote: All, I'm working on the implementation of MMTk's org.vmmagic.unboxedorg/vmmagic/unboxed/package-frame.html package functionality in Jitrino.OPT compiler. If you are interested to participate in the development, I propose to discuss all details in this mail thread. The current state: Part of the functionality of vmmagic package is done in the magic1.patch . See JIRA 1489 (http://issues.apache.org/jira/browse/HARMONY-1489) Tasks that are not finished: 1) Support of unsigned types. 2) Support of atomic prepare/attempt operations 3) Testing suit for vmmagic package. 4) EM64T support I hope items 1) and 2) will be finished in a week or even sooner if someone helps. After it's done the item 4) won't be a problem. I think that the problem (at least for me) is item 3): we need a test suite for vmmagic package. I saw several tests in Weldon's drlvm/trunk/vm/MMTk folder, but this is not sufficient to cover the whole vmmagic package. Does anyone know/can_write a reliability test suite for vmmagic we can use in Harmony? A regression test for vmmagic exists. I have been trying to get it donated and posted to MMTk repository. Its been a couple of months and no response. I will find out if it can be donated to Apache. -- Mikhail Fursov -- Weldon Washburn Intel Middleware Products Division -- Mikhail Fursov
Re: [drlvm][jit] MMTk-style magics implementation in Jitrino.OPT compiler
On 9/21/06, Mikhail Fursov [EMAIL PROTECTED] wrote: Weldon, Robin thank you for the comments. There are just a few steps left to do before Jitrino.OPT will have usable unboxed package implementation. Right now I'm working on atomic operations (prepare/attempt pair), and I do not completely understand the semantic of the 'prepare' method. The prepareXYZ method looks like a simple load and is not an atomic operation by itself. Are there any examples that describe these operations in details? Robin will correct me if I am wrong. I think the idea is that this is a generic API intended to be used for accessing compare and swap facilities on a bunch of different hardware. And the actual hardware has different memory models, different CAS semantics, etc. Basically the generic facility needed is to first read the CAS target memory location (this is the prepare). If the memory is sitting at a specific value (this is the do something), then do an attempt as follows: old_contents = CAS(expected_specfic_value_that_I_just_read, some_new_value, target_memory_location) If the old_contents are identical to expected_specific_value_that_I_just_read, we know that the CAS succeeded. In other words, you won the competition. Otherwise you lost. I imagine the following situation in user's code: prepareXYZ() do something attempt() Is this code correct? On 9/21/06, Robin Garner [EMAIL PROTECTED] wrote: Weldon Washburn wrote: On 9/20/06, Mikhail Fursov [EMAIL PROTECTED] wrote: I put the update into JIRA. This update still has a lot of bugs, but is significantly more stable then the initial one. My plan is to work on lock prefix support in Jitrino.OPTCG tomorrow, so if somebody is interested to enhance the current implementation there will no conflicts in our work. + There are several issues to discuss that are not clear to me: 1) Do we allow to save magic class into object fields? If yes, GC must be aware about magics and do not enumerate magic fields. Actually, the GC issues are taken care of at a higher level. The developer who is using vmmagics must extend the Uninterruptible class. That's not actually strictly true, there's also the UninterruptiblePragma exception. More generally, the burden is on the programmer to ensure that objects that you hold an Address of don't move while you hold the reference, and these pragmas are one method of doing that. You could also use locks etc (in theory at least). Another issue is that storing an unboxed object from vmmagic into an arbitrary object field has to be thought through very carefully by the developer. Or else there will be stale pointers running around that will cause hard crashes. In any case it is not a JIT responsibility. If the developer puts an object of type vmmagic Address in the heap then later retrieves a stale pointer, disaster will hit. I know because I have done this accidentally. Magic loads and stores also don't trigger read/write barriers, so the programmer needs to manually insert barriers if they would have been called. 4) Why do we need all of these types: Word, Offset, Extent if they are all just platform dependent unsigned integers? I understand that code of garbage collectors already uses these types and we must support them all, but what was the initial reason to introduce all of them? I thought the same thing when I first started working on MMTk port. Now I see there is benefit in the different types because it makes the code easier to read and also allows java type system to catch dumb errors that otherwise would be left to debugging stage. Once upon a time, magic fields were all just ints, and the present variety evolved over time, precisely for this reason. An ObjectReference may seem mysterious to the casual observer (why don't we just use Object ?). This is present so that MMTk can support languages other than Java (Haskell was my original target, and we have done C#), and also so because the object model of the VM that executes MMTk code may not necessarily be the same as the system that MMTk is managing. So an ObjectReference is the 'moral equivalent' of an object. Thats all for today. Will provide an update in a day or two. On 9/18/06, Weldon Washburn [EMAIL PROTECTED] wrote: On 9/18/06, Mikhail Fursov [EMAIL PROTECTED] wrote: All, I'm working on the implementation of MMTk's org.vmmagic.unboxedorg/vmmagic/unboxed/package-frame.html package functionality in Jitrino.OPT compiler. If you are interested to participate in the development, I propose to discuss all details in this mail thread. The current state: Part of the functionality of vmmagic package is done in the magic1.patch . See JIRA 1489 (http://issues.apache.org/jira/browse/HARMONY-1489) Tasks that are not finished: 1) Support of unsigned types. 2) Support of atomic
Re: [drlvm][jit] MMTk-style magics implementation in Jitrino.OPT compiler
On 9/21/06, Mikhail Fursov [EMAIL PROTECTED] wrote:
Weldon, Robin
thank you for the comments.
There are just a few steps left to do before Jitrino.OPT will have
usable
unboxed package implementation.
Right now I'm working on atomic operations (prepare/attempt pair), and I
do
not completely understand the semantic of the 'prepare' method.
The prepareXYZ method looks like a simple load and is not an atomic
operation by itself. Are there any examples that describe these
operations
in details?
Robin will correct me if I am wrong.
I think the idea is that this is a generic API intended to be used for
accessing compare and swap facilities on a bunch of different hardware.
And the actual hardware has different memory models, different CAS
semantics, etc.
Basically the generic facility needed is to first read the CAS target
memory
location (this is the prepare). If the memory is sitting at a specific
value (this is the do something), then do an attempt as follows:
old_contents = CAS(expected_specfic_value_that_I_just_read,
some_new_value,
target_memory_location)
If the old_contents are identical to
expected_specific_value_that_I_just_read, we know that the CAS succeeded.
In other words, you won the competition. Otherwise you lost.
I imagine the following situation in user's code:
prepareXYZ()
do something
attempt()
Is this code correct?
You're correct.
The prepare/attempt was designed to match architectures (PPC, Alpha ...)
with a load-locked/store-conditional instruction pair.
The standard code fragment for a synchronized update is
do {
oldVal = x.prepare();
newVal = f(oldVal);
} while (!x.attempt(oldVal,newVal));
As an aside, vmmagic should probably have CAS as a primitive rather than
prepare/attempt, but I don't think that's going to happen in the immediate
future.
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][jit] MMTk-style magics implementation in Jitrino.OPT compiler
I put the update into JIRA. This update still has a lot of bugs, but is significantly more stable then the initial one. My plan is to work on lock prefix support in Jitrino.OPT CG tomorrow, so if somebody is interested to enhance the current implementation there will no conflicts in our work. + There are several issues to discuss that are not clear to me: 1) Do we allow to save magic class into object fields? If yes, GC must be aware about magics and do not enumerate magic fields. 2) Do we allow to a method to return a magic class? 3) Do we allow to a method to accept a magic class as a parameter? If yes, we need some modifications in VM code. 4) Why do we need all of these types: Word, Offset, Extent if they are all just platform dependent unsigned integers? I understand that code of garbage collectors already uses these types and we must support them all, but what was the initial reason to introduce all of them? Thats all for today. Will provide an update in a day or two. On 9/18/06, Weldon Washburn [EMAIL PROTECTED] wrote: On 9/18/06, Mikhail Fursov [EMAIL PROTECTED] wrote: All, I'm working on the implementation of MMTk's org.vmmagic.unboxedorg/vmmagic/unboxed/package-frame.html package functionality in Jitrino.OPT compiler. If you are interested to participate in the development, I propose to discuss all details in this mail thread. The current state: Part of the functionality of vmmagic package is done in the magic1.patch . See JIRA 1489 (http://issues.apache.org/jira/browse/HARMONY-1489) Tasks that are not finished: 1) Support of unsigned types. 2) Support of atomic prepare/attempt operations 3) Testing suit for vmmagic package. 4) EM64T support I hope items 1) and 2) will be finished in a week or even sooner if someone helps. After it's done the item 4) won't be a problem. I think that the problem (at least for me) is item 3): we need a test suite for vmmagic package. I saw several tests in Weldon's drlvm/trunk/vm/MMTk folder, but this is not sufficient to cover the whole vmmagic package. Does anyone know/can_write a reliability test suite for vmmagic we can use in Harmony? A regression test for vmmagic exists. I have been trying to get it donated and posted to MMTk repository. Its been a couple of months and no response. I will find out if it can be donated to Apache. -- Mikhail Fursov -- Weldon Washburn Intel Middleware Products Division -- Mikhail Fursov
Re: [drlvm][jit] MMTk-style magics implementation in Jitrino.OPT compiler
On 9/20/06, Mikhail Fursov [EMAIL PROTECTED] wrote: I put the update into JIRA. This update still has a lot of bugs, but is significantly more stable then the initial one. My plan is to work on lock prefix support in Jitrino.OPT CG tomorrow, so if somebody is interested to enhance the current implementation there will no conflicts in our work. + There are several issues to discuss that are not clear to me: 1) Do we allow to save magic class into object fields? If yes, GC must be aware about magics and do not enumerate magic fields. Actually, the GC issues are taken care of at a higher level. The developer who is using vmmagics must extend the Uninterruptible class. Another issue is that storing an unboxed object from vmmagic into an arbitrary object field has to be thought through very carefully by the developer. Or else there will be stale pointers running around that will cause hard crashes. In any case it is not a JIT responsibility. If the developer puts an object of type vmmagic Address in the heap then later retrieves a stale pointer, disaster will hit. I know because I have done this accidentally. 2) Do we allow to a method to return a magic class? Yes. We also allow vmmagic parameters. You might want to take a look at Jitrino.JET to see what needs to be supported. 3) Do we allow to a method to accept a magic class as a parameter? If yes, we need some modifications in VM code. I know. I stumbled on this the hard way. I have patches for this in JIRA Harmony-1260. I have not committed this code yet. Its a very heavily used code path and I want someone else to try it to make sure it won't disrupt anything before I commit it. 4) Why do we need all of these types: Word, Offset, Extent if they are all just platform dependent unsigned integers? I understand that code of garbage collectors already uses these types and we must support them all, but what was the initial reason to introduce all of them? I thought the same thing when I first started working on MMTk port. Now I see there is benefit in the different types because it makes the code easier to read and also allows java type system to catch dumb errors that otherwise would be left to debugging stage. Thats all for today. Will provide an update in a day or two. On 9/18/06, Weldon Washburn [EMAIL PROTECTED] wrote: On 9/18/06, Mikhail Fursov [EMAIL PROTECTED] wrote: All, I'm working on the implementation of MMTk's org.vmmagic.unboxedorg/vmmagic/unboxed/package-frame.html package functionality in Jitrino.OPT compiler. If you are interested to participate in the development, I propose to discuss all details in this mail thread. The current state: Part of the functionality of vmmagic package is done in the magic1.patch . See JIRA 1489 (http://issues.apache.org/jira/browse/HARMONY-1489) Tasks that are not finished: 1) Support of unsigned types. 2) Support of atomic prepare/attempt operations 3) Testing suit for vmmagic package. 4) EM64T support I hope items 1) and 2) will be finished in a week or even sooner if someone helps. After it's done the item 4) won't be a problem. I think that the problem (at least for me) is item 3): we need a test suite for vmmagic package. I saw several tests in Weldon's drlvm/trunk/vm/MMTk folder, but this is not sufficient to cover the whole vmmagic package. Does anyone know/can_write a reliability test suite for vmmagic we can use in Harmony? A regression test for vmmagic exists. I have been trying to get it donated and posted to MMTk repository. Its been a couple of months and no response. I will find out if it can be donated to Apache. -- Mikhail Fursov -- Weldon Washburn Intel Middleware Products Division -- Mikhail Fursov -- Weldon Washburn Intel Middleware Products Division
Re: [drlvm][jit] MMTk-style magics implementation in Jitrino.OPT compiler
Weldon Washburn wrote: On 9/20/06, Mikhail Fursov [EMAIL PROTECTED] wrote: I put the update into JIRA. This update still has a lot of bugs, but is significantly more stable then the initial one. My plan is to work on lock prefix support in Jitrino.OPT CG tomorrow, so if somebody is interested to enhance the current implementation there will no conflicts in our work. + There are several issues to discuss that are not clear to me: 1) Do we allow to save magic class into object fields? If yes, GC must be aware about magics and do not enumerate magic fields. Actually, the GC issues are taken care of at a higher level. The developer who is using vmmagics must extend the Uninterruptible class. That's not actually strictly true, there's also the UninterruptiblePragma exception. More generally, the burden is on the programmer to ensure that objects that you hold an Address of don't move while you hold the reference, and these pragmas are one method of doing that. You could also use locks etc (in theory at least). Another issue is that storing an unboxed object from vmmagic into an arbitrary object field has to be thought through very carefully by the developer. Or else there will be stale pointers running around that will cause hard crashes. In any case it is not a JIT responsibility. If the developer puts an object of type vmmagic Address in the heap then later retrieves a stale pointer, disaster will hit. I know because I have done this accidentally. Magic loads and stores also don't trigger read/write barriers, so the programmer needs to manually insert barriers if they would have been called. 4) Why do we need all of these types: Word, Offset, Extent if they are all just platform dependent unsigned integers? I understand that code of garbage collectors already uses these types and we must support them all, but what was the initial reason to introduce all of them? I thought the same thing when I first started working on MMTk port. Now I see there is benefit in the different types because it makes the code easier to read and also allows java type system to catch dumb errors that otherwise would be left to debugging stage. Once upon a time, magic fields were all just ints, and the present variety evolved over time, precisely for this reason. An ObjectReference may seem mysterious to the casual observer (why don't we just use Object ?). This is present so that MMTk can support languages other than Java (Haskell was my original target, and we have done C#), and also so because the object model of the VM that executes MMTk code may not necessarily be the same as the system that MMTk is managing. So an ObjectReference is the 'moral equivalent' of an object. Thats all for today. Will provide an update in a day or two. On 9/18/06, Weldon Washburn [EMAIL PROTECTED] wrote: On 9/18/06, Mikhail Fursov [EMAIL PROTECTED] wrote: All, I'm working on the implementation of MMTk's org.vmmagic.unboxedorg/vmmagic/unboxed/package-frame.html package functionality in Jitrino.OPT compiler. If you are interested to participate in the development, I propose to discuss all details in this mail thread. The current state: Part of the functionality of vmmagic package is done in the magic1.patch . See JIRA 1489 (http://issues.apache.org/jira/browse/HARMONY-1489) Tasks that are not finished: 1) Support of unsigned types. 2) Support of atomic prepare/attempt operations 3) Testing suit for vmmagic package. 4) EM64T support I hope items 1) and 2) will be finished in a week or even sooner if someone helps. After it's done the item 4) won't be a problem. I think that the problem (at least for me) is item 3): we need a test suite for vmmagic package. I saw several tests in Weldon's drlvm/trunk/vm/MMTk folder, but this is not sufficient to cover the whole vmmagic package. Does anyone know/can_write a reliability test suite for vmmagic we can use in Harmony? A regression test for vmmagic exists. I have been trying to get it donated and posted to MMTk repository. Its been a couple of months and no response. I will find out if it can be donated to Apache. -- Mikhail Fursov -- Weldon Washburn Intel Middleware Products Division -- Mikhail Fursov - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[drlvm][jit] MMTk-style magics implementation in Jitrino.OPT compiler
All, I'm working on the implementation of MMTk's org.vmmagic.unboxedorg/vmmagic/unboxed/package-frame.html package functionality in Jitrino.OPT compiler. If you are interested to participate in the development, I propose to discuss all details in this mail thread. The current state: Part of the functionality of vmmagic package is done in the magic1.patch. See JIRA 1489 (http://issues.apache.org/jira/browse/HARMONY-1489) Tasks that are not finished: 1) Support of unsigned types. 2) Support of atomic prepare/attempt operations 3) Testing suit for vmmagic package. 4) EM64T support I hope items 1) and 2) will be finished in a week or even sooner if someone helps. After it's done the item 4) won't be a problem. I think that the problem (at least for me) is item 3): we need a test suite for vmmagic package. I saw several tests in Weldon's drlvm/trunk/vm/MMTk folder, but this is not sufficient to cover the whole vmmagic package. Does anyone know/can_write a reliability test suite for vmmagic we can use in Harmony? -- Mikhail Fursov
Re: [drlvm][jit] MMTk-style magics implementation in Jitrino.OPT compiler
On 9/18/06, Mikhail Fursov [EMAIL PROTECTED] wrote: All, I'm working on the implementation of MMTk's org.vmmagic.unboxedorg/vmmagic/unboxed/package-frame.html package functionality in Jitrino.OPT compiler. If you are interested to participate in the development, I propose to discuss all details in this mail thread. The current state: Part of the functionality of vmmagic package is done in the magic1.patch. See JIRA 1489 (http://issues.apache.org/jira/browse/HARMONY-1489) Tasks that are not finished: 1) Support of unsigned types. 2) Support of atomic prepare/attempt operations 3) Testing suit for vmmagic package. 4) EM64T support I hope items 1) and 2) will be finished in a week or even sooner if someone helps. After it's done the item 4) won't be a problem. I think that the problem (at least for me) is item 3): we need a test suite for vmmagic package. I saw several tests in Weldon's drlvm/trunk/vm/MMTk folder, but this is not sufficient to cover the whole vmmagic package. Does anyone know/can_write a reliability test suite for vmmagic we can use in Harmony? A regression test for vmmagic exists. I have been trying to get it donated and posted to MMTk repository. Its been a couple of months and no response. I will find out if it can be donated to Apache. -- Mikhail Fursov -- Weldon Washburn Intel Middleware Products Division
