Folks,
There were several interesting email chains about Harmony VM and MMTK
last year. This topic died in large part because there was no JVM.
Since then, several JVMs have been donated. I volunteer to do an
initial investigation of porting MMTK to the recent DRLVM donation.
From a quick
+1
TestNG is a next generation of JUnit and standardize a lot of solutions
JUnit develops reinvent every time.
On 5/24/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote:
Also look at TestNG. Someday when I find the time, I'm going to make
the argument we should switch, and don't wish to be held
On 24 May 2006 at 12:50, Mikhail Loenko [EMAIL PROTECTED] wrote:
2006/5/24, Stepan Mishura [EMAIL PROTECTED]:
On 5/24/06, Mikhail Loenko wrote:
2006/5/24, Geir Magnusson Jr :
I'd like to propose that we choose what we judge to be the best
RMI implementation, and the best math
Hi, Andrew,
I've prepared new patch with your fixes.
Thank you for your suggestion.
Regards,
Svetlana
-Original Message-
From: Andrew Zhang [mailto:[EMAIL PROTECTED]
Sent: Wednesday, May 24, 2006 8:34 AM
To: harmony-dev@incubator.apache.org
Subject: Re: [jira] Updated: (HARMONY-491)
Hi,
It is hard to track decisions made on harmony-dev mailing list and I've
tried to summarize them[1]. The mail archive is quite big and most probably
I missed or misunderstand something. Feel free to send patches to improve
web-page content.
[1]
Great!
2006/5/24, Stepan Mishura [EMAIL PROTECTED]:
Hi,
It is hard to track decisions made on harmony-dev mailing list and I've
tried to summarize them[1]. The mail archive is quite big and most probably
I missed or misunderstand something. Feel free to send patches to improve
web-page
Very useful document.
Now a have a reason to file some more bugs to JIRA against classlib sources
that violates this agreement.
**
On 5/24/06, Mikhail Loenko [EMAIL PROTECTED] wrote:
Great!
2006/5/24, Stepan Mishura [EMAIL PROTECTED]:
Hi,
It is hard to track decisions made on harmony-dev
This is a question for Apache legal. Will the existing licenses allow
Harmony incubator volunteers to port MMTK to one of the incubator's
JVMs? Can the modifications to the JVM be checked-in Harmony svn
repository?
There is no desire to put MMTK source in the Harmony repository. MMTK
stays at
Hi Weldon,
Does your research show that MMTk has a functional dependency on Write
Barriers? My understanding of write barriers is as an optimization. Also,
the contribution GC is not generational. So..I am not sure how this would be
tested etc.
Thanks,
Rana
On 5/23/06, Weldon Washburn
Stepan,
Thanks for your great job!
But now we should try to add to this list ALL the discussin results :)
SY, Alexey
2006/5/24, Stepan Mishura [EMAIL PROTECTED]:
Hi,
It is hard to track decisions made on harmony-dev mailing list and I've
tried to summarize them[1]. The mail archive is quite
oops. I forgot to cc:
-- Forwarded message --
From: Weldon Washburn [EMAIL PROTECTED]
Date: May 24, 2006 6:43 AM
Subject: Re: [DRLVM] proposal to port MMTK to drlvm
To: [EMAIL PROTECTED]
Daniel,
I really appreciate your offer to help. On the surface, our
backgrounds are
oops, I forgot to cc:
-- Forwarded message --
From: Weldon Washburn [EMAIL PROTECTED]
Date: May 24, 2006 11:23 AM
Subject: Re: [DRLVM] proposal to port MMTK to drlvm
To: [EMAIL PROTECTED]
On 5/24/06, Daniel Feinberg [EMAIL PROTECTED] wrote:
that is cool, so the other thing i
On 5/24/06, Rana Dasgupta [EMAIL PROTECTED] wrote:
Hi Weldon,
Does your research show that MMTk has a functional dependency on Write
Barriers?
Good question. I want to play by Apache rules. I am waiting for
Apache legal to inform us if we can port MMTK to an Apache Harmony
JVM.
My
My understanding of write barriers is as an optimization.
That fits with my understanding of write barriers also. I do not
know for certain but suspect that MMTK can somehow be configured such
that write barriers are not required for correctness. Maybe Dan
Feinberg can tell the mailing list.
I have a patch for drlvm which enables use of write barriers. This
works in interpreter mode only yet. I can put it on jira if somebody
is interested. The write barriers are tested with an algorithm which
does per-slot validation and should work fine.
--
Ivan
2006/5/24, Daniel Feinberg [EMAIL
-- Forwarded message --
From: Daniel Feinberg [EMAIL PROTECTED]
Date: May 24, 2006 2:13 PM
Subject: Re: [DRLVM] proposal to port MMTK to drlvm
To: Weldon Washburn [EMAIL PROTECTED]
Something like a reference counter does not really need a write
barrier. They are mostly used when
On 5/24/06, Ivan Volosyuk [EMAIL PROTECTED] wrote:
I have a patch for drlvm which enables use of write barriers. This
works in interpreter mode only yet. I can put it on jira if somebody
is interested.
This is helpful. Please post the patch. I will take a look at it
sometime soon.
Thanks
Hey everyone..
I was trying to build the jvm on Linux. I´m using SUSE Linux and GCC 4.
I am facing a little problem with macro expansion and some help would be
greatly appreciated.
While trying to build the jvm, I get the following error:
class.c: In function ‘class_load_resolve_clinit’:
Note that read barriers are also needed if you want to implement a GC
like Baker's real time copying collector that uses incremental
forwarding.
Rodrigo
On 5/24/06, Weldon Washburn [EMAIL PROTECTED] wrote:
On 5/24/06, Ivan Volosyuk [EMAIL PROTECTED] wrote:
I have a patch for drlvm which
On 5/24/06, Rodrigo Kumpera [EMAIL PROTECTED] wrote:
Note that read barriers are also needed if you want to implement a GC
like Baker's real time copying collector that uses incremental
forwarding.
Rodrigo, good point. For initial MMTK bring up, I would like to keep
things as simple as
2006/5/25, Weldon Washburn [EMAIL PROTECTED]:
On 5/24/06, Ivan Volosyuk [EMAIL PROTECTED] wrote:
I have a patch for drlvm which enables use of write barriers. This
works in interpreter mode only yet. I can put it on jira if somebody
is interested.
This is helpful. Please post the patch. I
On 5/24/06, Daniel Feinberg [EMAIL PROTECTED] wrote:
So i have something to chime in with. Since this could be simple from
the beginning and grow more complex as we develop it, we could start
with an interface to the VM. This part is fairly isolated in the code.
I think that as a starting point
Agree. We have the GC interfaces declared in:
vm/include/open/gc.h
vm/include/open/vm_gc.h
The interfaces hide implementation of VM, providing functionality to
get root set in stop-the-world state, callbacks for object allocation
and write barriers.
Please, take a look at it. If you have
-- Forwarded message --
From: Daniel Feinberg [EMAIL PROTECTED]
Date: May 24, 2006 7:04 PM
Subject: Re: [DRLVM] proposal to port MMTK to drlvm
To: Ivan Volosyuk [EMAIL PROTECTED]
This is good. The JikesRVM and MMTK code is also built like this with
an interface between the two.
Hi, Svetlana,
Welcome :)
On 5/24/06, Samoilenko, Svetlana V [EMAIL PROTECTED] wrote:
Hi, Andrew,
I've prepared new patch with your fixes.
Thank you for your suggestion.
Regards,
Svetlana
-Original Message-
From: Andrew Zhang [mailto:[EMAIL PROTECTED]
Sent: Wednesday, May 24, 2006
We have developed a GC prototype written in Java, which can work with
DRLVM to run SPECJVM98.
1. The key idea of this work is not the GC itself (as a prototype),
but the Java GC adapter. The idea is, we made the interface for C VM
- Java GC interactions as an seperate adapter, so that hopefully
On 5/24/06, Ivan Volosyuk [EMAIL PROTECTED] wrote:
Agree. We have the GC interfaces declared in:
hmm... who is the we? Perhaps you are referring to Harmony DRLVM
donation. Incidentally, my original question about MMTK interface
vm/include/open/gc.h
vm/include/open/vm_gc.h
The interfaces
On 5/24/06, Xiao-Feng Li [EMAIL PROTECTED] wrote:
We have developed a GC prototype written in Java, which can work with
DRLVM to run SPECJVM98.
This is good. Please put the rough prototype in a zip file and post
to Harmony JIRA. It would be good to look at even an early, rough
version while
28 matches
Mail list logo
