I didn't look at the MMTk source, but IMHO the special translation of
bytecodes is not nessasary in first stage. If the functionality
implemented as methods which are handled specially in jikes, in
interpreter they can be implemented as native methods. Anyway, I do
not insist on the use of
On 6/2/06, Ivan Volosyuk [EMAIL PROTECTED] wrote:
I didn't look at the MMTk source, but IMHO the special translation of
bytecodes is not nessasary in first stage. If the functionality
implemented as methods which are handled specially in jikes, in
interpreter they can be implemented as native
2006/6/1, Weldon Washburn [EMAIL PROTECTED]:
On 5/31/06, Ivan Volosyuk [EMAIL PROTECTED] wrote:
2006/6/1, Rana Dasgupta [EMAIL PROTECTED]:
It may be worth considering if we want JET to just call the barrier
functionality( with from/to/and slot locations )and the barrier helper
2006/6/1, Weldon Washburn [EMAIL PROTECTED]:
On 6/1/06, Ivan Volosyuk [EMAIL PROTECTED] wrote:
2006/6/1, Weldon Washburn [EMAIL PROTECTED]:
On 5/31/06, Ivan Volosyuk [EMAIL PROTECTED] wrote:
2006/6/1, Rana Dasgupta [EMAIL PROTECTED]:
We have in DRLVM implementation the atomic exchange
Hi Weldon/Ivan,
This has been a long thread/dialog. I am going to try and summarize where
we stand at this stage ( for my own understanding ) and also to invite
comments on implementation direction and suggestions from knowledgeable VM
developers on the list. Please fill in if I miss or
On 6/1/06, Rana Dasgupta [EMAIL PROTECTED] wrote:
Hi Weldon/Ivan,
This has been a long thread/dialog. I am going to try and summarize where
we stand at this stage ( for my own understanding ) and also to invite
comments on implementation direction and suggestions from knowledgeable VM
On 5/31/06, Weldon Washburn [EMAIL PROTECTED] wrote:
DRLVM contains a simple JIT called Jitrino.JET in addition to a highly
optimizing JIT. The simple JIT seems to be a better choice for
starting the write barrier work.
Looking at Jitrino.JET sources, it looks like the best place to add
write
2006/5/31, Mikhail Fursov [EMAIL PROTECTED]:
No, this method is used to store operand stack item to local variable. If
you're interested in writing to fields then Compiler::gen_field_op is the
right place. We can generate a call to VM or GC helper in this method. To
create a call to any VM
On 5/31/06, Ivan Volosyuk [EMAIL PROTECTED] wrote:
2006/5/31, Mikhail Fursov [EMAIL PROTECTED]:
No, this method is used to store operand stack item to local
variable. If
you're interested in writing to fields then Compiler::gen_field_op is
the
right place. We can generate a call to VM or GC
On 5/31/06, Rana Dasgupta [EMAIL PROTECTED] wrote:
On 5/31/06, Ivan Volosyuk [EMAIL PROTECTED] wrote:
2006/5/31, Mikhail Fursov [EMAIL PROTECTED]:
No, this method is used to store operand stack item to local
variable. If
you're interested in writing to fields then Compiler::gen_field_op
2006/6/1, Rana Dasgupta [EMAIL PROTECTED]:
How will it affect VM or GC ? The WBs will also require support from
both VM
and GC. Do you have ideas on VM/GC interface for this?
Also what will be usage and testing scenarios in the nearest future?
The VMGC interfaces is already exists in
On 5/31/06, Ivan Volosyuk [EMAIL PROTECTED] wrote:
2006/6/1, Rana Dasgupta [EMAIL PROTECTED]:
It may be worth considering if we want JET to just call the barrier
functionality( with from/to/and slot locations )and the barrier helper
actually do everything ... including generating the
All,
I have been looking at DRLVM contained in JIRA Harmony-438. As far as
I can tell, it does not have write barrier support. Write barrier
support is pretty much required for high performance garbage
collectors. In anticipation of using DRLVM with modern GCs like MMTK,
I'd like to add write
13 matches
Mail list logo
