scover further requirements. On the Linux
mailing lists it looks like sysconf() will expand to return cores info for
multicore systems and the NUMA api's on Linux are a different bunch
altogether.
Thanks,
Rana
On 11/1/06, Xiao-Feng Li <[EMAIL PROTECTED]> wrote:
>
> Very in
Hi, I submited a patch to enable parallel compaction of GCv5. It now
works in Windows. Please don't expect any performance improvement yet
since I care only about the framework at the moment. And it's not a
full parallel compactor because not all phases are parallelized, but
that would be easier.
For what it's worth, I'll add my humble +1.
>
> Etienne
>
> Xiao-Feng Li wrote:
> > Agreed, so plus me.
> >
> > Thanks,
> > xiaofeng
> >
> > On 11/8/06, Rana Dasgupta <[EMAIL PROTECTED]> wrote:
> >
> >> On 11/7/06, W
Agreed, so plus me.
Thanks,
xiaofeng
On 11/8/06, Rana Dasgupta <[EMAIL PROTECTED]> wrote:
On 11/7/06, Weldon Washburn <[EMAIL PROTECTED]> wrote:
>
> All,
>
> It looks like the debate on class unloading has concluded.
>
> Let's vote on implementing Robin's proposal.
>
> +1
>
>Weldon
>
> PS -
Ok, thanks for the info. :-) -xiaofeng
On 11/7/06, Mikhail Fursov <[EMAIL PROTECTED]> wrote:
On 11/7/06, Xiao-Feng Li <[EMAIL PROTECTED]> wrote:
>
> Agreed. Without the explanation of JET as only a fast path, I also
> thought JET and OPT are two different JITs. And actua
Agreed. Without the explanation of JET as only a fast path, I also
thought JET and OPT are two different JITs. And actually as I can
recall, JET and OPT are indeed treated as two different JITs that the
EM can select in the JITs chain.
Honestly, "different paths" give me an impression that they a
I'd suggest to commit this patch since I have to admit that to define
a type as parenthesis may not be a good code style.
Thanks,
xiaofeng
On 11/5/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
How about fixing the intel compiler? :)
I suppose there's no harm, and if so, we'll find out...
On 11/3/06, Robin Garner <[EMAIL PROTECTED]> wrote:
Xiao-Feng Li wrote:
> Robin, good idea.
>
> I understand the main difference between your design and Aleksey's
> proposal 1 is, the tracing in your design stops as vtable, but
> Aleksey's continues to class
Except for the MMTk integration temporary need, I think the only
reason is to test the interface so that some GC/VM developer may not
break it unintentionally. But two GCs (v4.1/v5) are enough at the
moment for interface maintenance.
Thanks,
xiaofeng
On 11/2/06, Geir Magnusson Jr. <[EMAIL PROTEC
On 11/2/06, Robin Garner <[EMAIL PROTECTED]> wrote:
Xiao-Feng Li wrote:
> On 11/1/06, Mikhail Fursov <[EMAIL PROTECTED]> wrote:
>> On 01 Nov 2006 16:05:41 +0600, Egor Pasko <[EMAIL PROTECTED]> wrote:
>> >
>> > On the 0x214 day of Apache Harmony Mikh
Robin, good idea.
I understand the main difference between your design and Aleksey's
proposal 1 is, the tracing in your design stops as vtable, but
Aleksey's continues to classloader. On the other hand, your approach
requires an extra step to sweep the vtables in order to determine the
classloade
rectly. __cpuid() uses old style cpuid and takes input from
eax only instead of eax, ecx . GetSystemInfo() uses the registers in short
mode when doing cpuid, so I think it fails for wow. It is amazing how
Windows works at all!
On 11/1/06, Xiao-Feng Li <[EMAIL PROTECTED]> wrote:
>
>
ou are right, since my machine is X86-64bit. :-) I will
try the API you pointed.
Thanks,
xiaofeng
2006/11/1, Xiao-Feng Li <[EMAIL PROTECTED]>:
> Yes, both SUN JRE and DRLVM returns 1 for me. Java API has the same
> problem. :-) Probably it should introduce an
> availableCoresPerPro
Yes, both SUN JRE and DRLVM returns 1 for me. Java API has the same
problem. :-) Probably it should introduce an
availableCoresPerProcessor() or something more comprehensive.
Thanks,
xiaofeng
On 11/1/06, Mikhail Fursov <[EMAIL PROTECTED]> wrote:
On 11/1/06, Xiao-Feng Li <[EMAIL
On 11/1/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
Xiao-Feng Li wrote:
> Hi, I am using port_CPUs_number() for GCv5 to get the processor
> number, but my desktop returns one processor with it on Windows
> although my processor is dual-core. (port_CPUs_numbe
"2". I have Prescott, 1CPU, 2 hyperthreads, WindowsXP.
JNIEXPORT jint JNICALL
Java_java_lang_VMExecutionEngine_getAvailableProcessors
(JNIEnv *, jclass)
{
return port_CPUs_number();
}
So if it's broken for you it's broken in Java too.
On 11/1/06, Xiao-Feng Li <
Hi, I am using port_CPUs_number() for GCv5 to get the processor
number, but my desktop returns one processor with it on Windows
although my processor is dual-core. (port_CPUs_number is defined in
port_sysinfo.h).
I think we need more general form of processor number retrieval API
that can return
On 11/1/06, Mikhail Fursov <[EMAIL PROTECTED]> wrote:
On 01 Nov 2006 16:05:41 +0600, Egor Pasko <[EMAIL PROTECTED]> wrote:
>
> On the 0x214 day of Apache Harmony Mikhail Fursov wrote:
> > On 01 Nov 2006 15:56:28 +0600, Egor Pasko <[EMAIL PROTECTED]> wrote:
> > >
> > > agreed. not patching .. just
[3] Haim Kermany, Erez Petrank. The Compressor: concurrent,
incremental, and parallel compaction. In Proceedings of the 2006 ACM
SIGPLAN Conference on Programming Languages Design and Implementation
(PLDI 2006), Pages 354-363, 2006.
Xiao-Feng Li wrote:
> Weldon, the problem is, there is no well
On 10/30/06, Weldon Washburn <[EMAIL PROTECTED]> wrote:
On 10/29/06, Xiao-Feng Li <[EMAIL PROTECTED]> wrote:
>
> Weldon, the problem is, there is no well-established parallel
> compaction algorithms. So far the best known work are 1. SUN's work;
> 2. IBM's wo
On 10/31/06, Pavel Pervov <[EMAIL PROTECTED]> wrote:
Ignatenko vs Gagnon proposal checklist follows. :)
> In accordance with Section 2.17.8 of the JVM spec, class unloading (and
> its related native resource cleanup) can only happen when the class
> loader instance becomes unreachable. For thi
On 10/30/06, Mikhail Fursov <[EMAIL PROTECTED]> wrote:
Just my $0.02:
Actually VM_thread contains thread-local data. The VM_thread is a thread
local data by itself. HyThread keeps a pointer to it, so VM_thread is always
accessed from HyThread.
Some of the components, e.g. GCv4 and GCv5, keeps all
t a compile time
switch so that that folks focused on production quality VM don't trip on
it. Even assuming the implementation of the Compressor algorithm is bug
free, there may be unforeseen performance problems that surface with
different workloads.
On 10/29/06, Xiao-Feng Li <[EMAIL PROT
uh... reference counting for class loader, interesting.
One thing could you help to clarify: how can the classloader know
there is class (loaded by it) that has surviving objects? We need
trace the object header to find the class then to find the classloader
and then to mark the classloader? Is t
nvironment?
I think some adaptive choice is better. It means we need provide the
choices at first. :-) I guess it's not a big overhead to have two
parallel compactors.
Thanks,
xiaofeng
Sorry for all these questions before reading the book :-)
Rana
> On 10/27/06, Xiao-Feng Li <[EMA
If we
can't use on 32 bit machines with plenty of ram, we can use it on 64
bit machines.
What about enabling the algorithm at runtime if required conditions
are met, otherwise falling back to some other algorithm?
--
Ivan
On 10/28/06, Xiao-Feng Li <[EMAIL PROTECTED]> wrote:
> Hi, al
ecause helper classes can use static final variables.
Another example: EMThreadSupport class - it's part of EM profile collection
framework written in Java.
On 10/28/06, Xiao-Feng Li <[EMAIL PROTECTED]> wrote:
>
> Mikhail, what methods should the initialization call for helper
Mikhail, what methods should the initialization call for helpers? I
think only class loading is enough. Right?
Thanks,
xiaofeng
On 10/28/06, Mikhail Fursov <[EMAIL PROTECTED]> wrote:
On 10/28/06, Xiao-Feng Li <[EMAIL PROTECTED]> wrote:
>
> For helpers, we can let the ow
On 10/27/06, Mikhail Fursov <[EMAIL PROTECTED]> wrote:
On 10/27/06, Weldon Washburn <[EMAIL PROTECTED]> wrote:
>
> On 10/26/06, Xiao-Feng Li <[EMAIL PROTECTED]> wrote:
> >
> > Hi, Mikhail, would you please educate me why this helper inlining work
> >
Hi, all, the plan for GCv5 parallel compaction is to apply the idea of
Compressor [1]. But it has an issue I want to discuss with you.
Compressor needs to reserve an unmapped virtual space for compaction.
The size of the reserved part is the same as that of copy reserve
space in a semi-space colle
On 10/28/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
Xiao-Feng Li wrote:
> All, I think the problem now is mainly about the class unloading
> design not about whether class unloading happens in server
> environment.
I think the problem is if class unloading happens c
All, I think the problem now is mainly about the class unloading
design not about whether class unloading happens in server
environment.
Class unloading is definitely a feature required in future; but with
the significance of the required modifications in JVM by this class
unloading design 2 (usi
For helpers, we can let the owning components to initialize them
through VM interfaces if this is possible. And this is done when the
owning components are initialized by the VM.
Thanks,
xiaofeng
On 10/27/06, Mikhail Fursov <[EMAIL PROTECTED]> wrote:
VM gurus,
In the previous thread called "[d
Rana, this would be very useful for us to understand the GC behavior.
Thanks for this.
There is a synthesis benchmark GCold that can be also used for this
study. We were using it for a while.
Thanks,
xiaofeng
On 10/28/06, Rana Dasgupta <[EMAIL PROTECTED]> wrote:
Hi,
I ran a simple test that
Hi, Mikhail, would you please educate me why this helper inlining work
depends on mmtk.jar? If only the unboxed classes are used, why can't
we write a simple replacement? That's just easy.
Thanks,
xiaofeng
On 10/26/06, Mikhail Fursov <[EMAIL PROTECTED]> wrote:
Folks,
I'm preparing the first pat
All my congratulations!!
Thanks,
xiaofeng
On 10/26/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
I am happy to report that the Apache Board was willing to consider our
proposal and voted to accept it at today's board meeting.
As stated in the Incubation vote, this is a necessary condition
Ivan, agree. The multi-slot TLS allocation is only a superset that
keeps backward compatibility.
Btw, I was familiar with Linux TLS implementation (in Linuxthreads),
it was arranged into multiple-levels (like the inode blocks for a file
in filesystem). So the supported number of TLS keys can be l
No problem, I can modify GCv5 for this. Thanks, -xiaofeng
On 10/25/06, Mikhail Fursov <[EMAIL PROTECTED]> wrote:
On 10/25/06, Xiao-Feng Li <[EMAIL PROTECTED]> wrote:
>
> We probably want to delay this optimization in TM until we have
> evidance for it, since what Mikhail wa
e with Mikhail that it could be benefitial to have
data directly available in TLS without additional pointer dereference.
If we will have corresponding interface function to allocate more then
one void pointer at once in TLS it can be used as optimization.
--
Ivan
On 10/25/06, Xiao-Feng Li <[EMAIL
On 10/25/06, Mikhail Fursov <[EMAIL PROTECTED]> wrote:
On 10/25/06, Xiao-Feng Li <[EMAIL PROTECTED]> wrote:
>
> Why do we need multiple slots? Can't we use just one slot, which
> stores a pointer to a user data structure (the GC_Thread_Info in this
> case)?
>
Yes
On 10/25/06, Mikhail Fursov <[EMAIL PROTECTED]> wrote:
On 10/25/06, Xiao-Feng Li <[EMAIL PROTECTED]> wrote:
>
> Hi, Mikhail, how about this:
>
> In GC thread init:
> gc_tls_data_ptr = malloc_gc_tls_data(sizeof(GC_Thread_Info) );
> gc_tls_key = thread_create_tl
+ offset_of_free_in_gc_tls);
Can't this work? Sounds like I missed something?
Thanks,
xiaofeng
On 10/25/06, Mikhail Fursov <[EMAIL PROTECTED]> wrote:
On 10/25/06, Xiao-Feng Li <[EMAIL PROTECTED]> wrote:
>
> Mikhail, I guess there is miscommunication. I didn't sug
25/06, Mikhail Fursov <[EMAIL PROTECTED]> wrote:
Xiao-Feng,
On 10/25/06, Xiao-Feng Li <[EMAIL PROTECTED]> wrote:
>
> Mikhail, we want to seperate the GC module from TM so that only
> limited VM APIs are accessed from GC. That means, we want a simpler
> API to get GC thread in
Mikhail, we want to seperate the GC module from TM so that only
limited VM APIs are accessed from GC. That means, we want a simpler
API to get GC thread info than accessing GC TLS data individually.
Using info.get_tls_current_free() to access a field info of GC TLS
data looks like not very elegant
On 10/21/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
We're trying something a little different. I think Roy Fielding one
said something along the lines of "when a community gets organized
enough to vote itself out of the Incubator, it's appropriate."
So to bring the Harmony community and
URL: http://issues.apache.org/jira/browse/HARMONY-1900
This patch has made following improvements mainly:
1. It can work in non-generational mode. To enable it, edit file
gen/gc_for_barrier.cpp to change the NEED_BARRIER to FALSE. This
feature can help to debug and test GC correctness with and w
Mikhail, I think our opinions are pretty close about this topic now.
Thanks,
xiaofeng
On 10/18/06, Mikhail Fursov <[EMAIL PROTECTED]> wrote:
On 10/18/06, Xiao-Feng Li <[EMAIL PROTECTED]> wrote:
>
> Pavel's looks like more flexible, but I have a question with the
>
Very comprehensive list and the GC part is also a good summary that
catches those in my mind.
We probably want to categorize the items into something like "bugs",
"limitations", "enhancements" and "features wanted" so that
contributors can have a clear picture on DRLVM functionalities.
Thanks,
x
Hi, I think Pavel and Mikhail's proposals are essentially the same.
Pavel's looks like more flexible, but I have a question with the
special interface approach: is it possible that sometimes we want to
call a library native method in fast way? If possible, shall we
require all library classes that
On 10/17/06, Geir Magnusson Jr <[EMAIL PROTECTED]> wrote:
The Harmony PPMC has been discussing and has approved asking to graduate
from the Apache Incubator and become a Top Level Project. This means
that we would become an official project of the Apache Software Foundation.
In terms of our day
Good idea. -xiaofeng
On 10/17/06, Gregory Shimansky <[EMAIL PROTECTED]> wrote:
Hello
You know that drlvm was donated by Intel and there was some period of time
while drlvm was developed internally. We had an internal bugzilla server to
track the issues. In an effort to move all development to t
I've had a quick look and believe it is a good improvement over the
existing version.
Thanks,
xiaofeng
On 10/16/06, Konovalova, Svetlana <[EMAIL PROTECTED]> wrote:
Folks,
I took a close look at "Hot to Write GC" [1] and created a patch for this doc
[JIRA 1881]. I fixed formatting, brushed up
My vote:
FC4/5, Suse11, Windows XP/2003
X86 (both 32bit and 64bit), and IPF
I guess it's a bit unclear to say IA64 in the community. It would be
clearer to use "X86 64bit" or "IPF (Itanium)".
Thanks,
xiaofeng
On 10/16/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
We're a volunteer projec
On 10/16/06, Ivan Volosyuk <[EMAIL PROTECTED]> wrote:
On 10/16/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
> Ivan Volosyuk wrote:
> > GC v4.1 has additional
> > requirement from VM/JIT in order to support collection during
> > enumeration. Other existing DRLVM's GCs doesn't has such require
Some of my comments inlined.
On 10/16/06, Weldon Washburn <[EMAIL PROTECTED]> wrote:
It looks like this JIRA has been closed. I ask the below questions. It may
make sense to reopen this JIRA.
1)
Mikhail Fursov said, "With this fix JIT precaches all offsets for mananaged
pointers in a method b
GC should be enabled in waiting state. In case that a GC can happen,
the code should do bookkeeping to guarantee the correctness.
Thanks,
xiaofeng
On 10/13/06, Evgueni Brevnov <[EMAIL PROTECTED]> wrote:
Hi,
I do the following:
hythread_suspend_disable();
hysem_wait(semaphore);
hythread_susp
On 10/12/06, Mikhail Fursov <[EMAIL PROTECTED]> wrote:
> 2) The problem: Where to keep GC magic code? This code is GC specific and
> > must be available for bootstrap classloader.
> > JIT can know all the details which magic code to inline (the helper
> type,
> > the helper signature) from its pr
Mikhail, thanks for the hard work. Ivan has given some good comments.
Please see my late comments below inlined. Thanks, -xiaofeng
On 10/11/06, Mikhail Fursov <[EMAIL PROTECTED]> wrote:
GC, VM gurus!
The problems I see:
1) The problem: GC helper must know GC_Thread_Info struct offsets.
This
Yes, I agree.
This is related to the issue I found in bootstrapping JVM. Since DRLVM
is largely written in C (C++) and partially written in Java, the
bootstrapping process should be more clearly to avoid this kind of
bug. That is all the system level code that are written in Java
probably can be
Y-1806, the GC's gc_requires_barriers() will be taken
into account.
If gc_requires_barriers()==true, then write barrier code (for C-based
GC) will be inserted even
without a command line switch (-Djit.JET.arg.wb4c=true).
--
Thanks,
Alex
Xiao-Feng Li wrote:
> Fursov and Alex,
>
Thanks, this is helpful. -xiaofeng
On 10/10/06, Mikhail Fursov <[EMAIL PROTECTED]> wrote:
On 10/10/06, Xiao-Feng Li <[EMAIL PROTECTED]> wrote:
>
> Hi, when I debug DRLVM, I have a question about the bootstrapping
> process: why is Jitrino initialized only when a method is
Thanks
Evgueni
On 10/10/06, Xiao-Feng Li <[EMAIL PROTECTED]> wrote:
> Hi, when I debug DRLVM, I have a question about the bootstrapping
> process: why is Jitrino initialized only when a method is compiled?
> Shouldn't it be initialized right away in or before vm_init() before
> an
still impacts you.
Thanks
Evgueni
On 10/10/06, Xiao-Feng Li <[EMAIL PROTECTED]> wrote:
> Hi, when I debug DRLVM, I have a question about the bootstrapping
> process: why is Jitrino initialized only when a method is compiled?
> Shouldn't it be initialized right away in or bef
Hi, when I debug DRLVM, I have a question about the bootstrapping
process: why is Jitrino initialized only when a method is compiled?
Shouldn't it be initialized right away in or before vm_init() before
any method need compiling, just as gc_init() is initialized before any
object is allocated?
Th
g
On 10/10/06, Xiao-Feng Li <[EMAIL PROTECTED]> wrote:
Good news is, I tried the write barrier implementation with today's
SVN head, it runs with GCv5 perfectly.
Well the running of GCv5 exposes some debug problem in DRLVM threading
part. I need add two lines of code in GCv5 to work ar
thread_local());
return;
}
Thanks,
xiaofeng
On 10/10/06, Xiao-Feng Li <[EMAIL PROTECTED]> wrote:
Hi, when I tested with GCv5 in DRLVM, I found there is design issue in
threading part. That is, after gc is initiated (gc_init) in runtime,
the main thread can't allocate object based on
Hi, when I tested with GCv5 in DRLVM, I found there is design issue in
threading part. That is, after gc is initiated (gc_init) in runtime,
the main thread can't allocate object based on its allocation context
(thread local gc info), because the allocation context is not
initialized (gc_thread_ini
be it.
Thanks,
xiaofeng
On 10/10/06, Xiao-Feng Li <[EMAIL PROTECTED]> wrote:
Thanks to Fursov and Alex for the write barrier submission. JIRA-1580
will be closed.
Wish is committed as soon as possible that people can run GCv5 with it.
http://issues.apache.org/jira/browse/HARMONY-1785
Thank
p this thread up to date: the "WB for JET" code was commited to
http://issues.apache.org/jira/browse/HARMONY-1785 by Alex.
On 10/8/06, Mikhail Fursov <[EMAIL PROTECTED]> wrote:
>
> Ok I'll try to do it tomorrow. So you will have it on your monday's
> morning in J
mmand line invocation once the above has
happened. Its unlikely the above will disturb it.
On 10/9/06, Xiao-Feng Li <[EMAIL PROTECTED]> wrote:
>
> Salikh, right. I've submitted a patch to support both GC build.
> Hopefully Weldon will commit it today. Thanks,
>
> -
Salikh, right. I've submitted a patch to support both GC build.
Hopefully Weldon will commit it today. Thanks,
-xiaofeng
On 10/9/06, Salikh Zakirov <[EMAIL PROTECTED]> wrote:
Weldon Washburn wrote:
> On second thought, you are right. I don't really should not be hacking on
> the framework rig
olks. How about using gcv4_1 and gcv5. Also, at least for a while
we need to be able to build and run gcv4.
On 10/8/06, Xiao-Feng Li <[EMAIL PROTECTED]> wrote:
>
> I've submitted a patch to the JIRA to make DRLVM compile two GCs, one
> under gc_cc/ directory (originally gc/
r tomorrow and report what runs.
> Provided this code sits well w/ drlvm tree, I will go ahead an commit to
> vm/gcv5
>
> On 10/6/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
>>
>>
>>
>> Xiao-Feng Li wrote:
>> > The submitted revision is downlo
That's great, thank you very much! -xiaofeng
On 10/8/06, Mikhail Fursov <[EMAIL PROTECTED]> wrote:
Xiao-Feng,
Is it OK if I commit it tomorrow? So you have it on October09 morning ?
On 10/8/06, Xiao-Feng Li <[EMAIL PROTECTED]> wrote:
>
> On 9/29/06, Mikhail Fursov &l
On 10/1/06, Weldon Washburn <[EMAIL PROTECTED]> wrote:
If h1580 is based on svn revision number that is before BBC.patch, I
recommend closing h1580 and opening a new JIRA. (I recently closed H-816
for similar reasons.) Also, if Yu-Nan He's patch does not work with current
svn head, this patch n
On 9/29/06, Mikhail Fursov <[EMAIL PROTECTED]> wrote:
Egor,
I think this is right suggestion to synchronize our WB and H1580
implementations.
AFAIK H1580 uses old JET version and is not compatible with the latest
compiler version.
If it's true, our implementation for the new JET/OPT version will
g GCV5 in today or tomorrow and report what runs.
Provided this code sits well w/ drlvm tree, I will go ahead an commit to
vm/gcv5
On 10/6/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
>
>
>
> Xiao-Feng Li wrote:
> > The submitted revision is downloadable in JIRA-1428 at
rovement
Components: DRLVM
Environment: These files were only tested on Windows with VS.NET 2003.
Reporter: Xiao-Feng Li
Assigned To: weldon washburn
Attachments: gc_v5.001.zip, GCv5-mc001.zip, gcv5-r0.10.zip
This archive has a couple of files implem
Thanks to Egor and Gregory's responses to the JET write barrier patch.
Those help. I was away from JIT development for a while. :-)
Since the patch is small, if needed, please feel free to modify it as
a JIRA update, or a committer to merge it then we submit new patch
later. Basically the write b
On 27 Sep 2006 17:20:36 +0700, Egor Pasko <[EMAIL PROTECTED]> wrote:
I am curious about the switch
VM_Global_State::loader_env->use_lil_stubs. Does everything work in
both true and false? What do we need this switch for? Doesn't it
induce unnecessary complication/duplication?
The LIL stub has b
On 9/28/06, Gregory Shimansky <[EMAIL PROTECTED]> wrote:
On Wednesday 27 September 2006 14:20 Egor Pasko wrote:
> On the 0x1F1 day of Apache Harmony Xiao-Feng Li wrote:
> > Thanks. Yes, this is supposed to be review by JIT person. On the other
> > hand, if JIT person has
obably be best if a JIT person committed this patch. Maybe
Stephan Mishura?
If its not committed soon, bug me and I will do it.
On 9/26/06, Xiao-Feng Li <[EMAIL PROTECTED]> wrote:
>
> Hi, the patch attached in JIRA 1580 (submitted by YuNan) is a write
> barrier implementation
Hi, the patch attached in JIRA 1580 (submitted by YuNan) is a write
barrier implementation for JET that GCv5 is going to use (it doesn't
impact anything else). It would be great if some commiter can help to
review and commit it. Thanks. -xiaofeng
http://issues.apache.org/jira/browse/HARMONY-1580?
gc.xml is under \build\make\components\vm\ .
Thanks,
xiaofeng
On 9/21/06, Rana Dasgupta <[EMAIL PROTECTED]> wrote:
On 9/20/06, Weldon Washburn <[EMAIL PROTECTED]> wrote:
>
> On 9/20/06, Xiao-Feng Li <[EMAIL PROTECTED]> wrote:
> > >
> > > On 9/21/0
Weldon, the gc.xml needs a minor change to play with the mark-compaction GC:
-
+
Thanks,
xiaofeng
On 9/20/06, Weldon Washburn <[EMAIL PROTECTED]> wrote:
On 9/19/06, Xiao-Feng Li <[EMAIL PROTECTED]> w
On 9/21/06, Rana Dasgupta <[EMAIL PROTECTED]> wrote:
Very nice and fast Xiao Feng :-) I read through your first submission and
had a couple of thoughts on how this could progress. Is it that to hook up
the two seperately managed spaces, some of the policies ( eg., promote
everything and have an u
understand, so it's encouraged
for everybody who is interested in GC development to download and have
a play. Comments are welcome!
Thanks,
xiaofeng
-- Forwarded message --
From: Xiao-Feng Li (JIRA) <[EMAIL PROTECTED]>
Date: Sep 20, 2006 2:15 PM
Subject: [jira] Update
On 9/18/06, Oliver Deakin <[EMAIL PROTECTED]> wrote:
Xiao-Feng Li wrote:
> On 9/14/06, Jimmy, Jing Lv <[EMAIL PROTECTED]> wrote:
>> Interesting topic, I'm still dreaming of "free()" in Java (This dream
>> begins at the very beginning when I see Java
On 9/15/06, Ivan Volosyuk <[EMAIL PROTECTED]> wrote:
There was a command line switch -Dvm.dlls=. It
allowed to select GC dll at startup. AFAIK, for now, the method is
broken. Anyway, we can add the property gc.dll: -Dgc.dll=
--
Ivan
Good idea. And we need add multiple GCs build as well. Than
On 9/15/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
> Yes, it is always desirable to keep the existing version runnable.
>
> Since I will submit code as JIRA issue or update from time to time as
> the development proceeds, the initial submissions are only for
> developers, will not be ready
On 9/15/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote:
Xiao-Feng Li wrote:
> GCv5 is a proposed next GC version for Harmony VM. It's just starting.
> Any people who are interested are welcome to comment the design or
> participate the development. Please notice mess
luck!
On 9/14/06, Xiao-Feng Li <[EMAIL PROTECTED]> wrote:
>
> Hi, Leo, your concerns about the potential impact of GC on system
> performance (time and memory) are quite reasonable. Yes, there is no
> single GC algorithm that wins all situations. Some dynamic adaptation
> are
On 9/15/06, Ivan Volosyuk <[EMAIL PROTECTED]> wrote:
Well, common practise is to allocate most of the physical memory for
java heap and let the GC to deal with it. Different GC algorithms will
produce different pause times with different frequencies.
For your case, I think, it will be optimal to
On 9/14/06, Xiao-Feng Li <[EMAIL PROTECTED]> wrote:
Well, it is not so easy to support "free()" in JVM as it looks like,
and may not really bring benefit. Even worse, it may introduce unsafe
code, which was one of the major design goals of Java/JVM. That said,
Typo
On 9/14/06, Jimmy, Jing Lv <[EMAIL PROTECTED]> wrote:
Interesting topic, I'm still dreaming of "free()" in Java (This dream
begins at the very beginning when I see Java, as C/C++ is my first
program language )However, it seems RI will never give us "free()". :)
Only a thought, Java may offer a k
ll become a powerful
supplement for static analysis.
Good luck!
On 9/14/06, Xiao-Feng Li <[EMAIL PROTECTED]> wrote:
>
> Hi, Dear Leo,
>
> There are a couple of known approaches to collect short-lived objects.
>
> The most common approach is generational GC, which is designed
Hi, Dear Leo,
There are a couple of known approaches to collect short-lived objects.
The most common approach is generational GC, which is designed
specifically with the assumption that most objects die young in normal
applications. Simply put, the objects are arranged into spaces
according to t
has no document associated, since it's too early
and unstable for serious document efforts; but I think it is simple
and concise enough for any people who are interested in GC
development.
Thanks,
xiaofeng
-- Forwarded message --
From: Xiao-Feng Li (JIRA) <[EMAIL PROTECTE
update?
- Weldon
On 8/22/06, Xiao-Feng Li <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> Going on what's in the email called, "[DRLVM][GC] Goals for
> 2006/2007", I put together a top-level design of GC. The intention is
> to use this design to guide the implementation of H
Fursov, what are the intrinsics supports you want to implement? The
code below you gave has only a few examples. I think it would be a
good idea to well define the instrinsics before code them.
Thanks,
xiaofeng
On 8/28/06, Mikhail Fursov <[EMAIL PROTECTED]> wrote:
Folks,
Here is the example of
1 - 100 of 144 matches
Mail list logo