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 informative! Thanks, Rana.
-xiaofeng
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.
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 actually as I can
recall, JET
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 -- When class
Xiao-Feng Li wrote:
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
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
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/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 reporting
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
, 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 [EMAIL PROTECTED] wrote:
Hi, I am using port_CPUs_number
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_number is defined in
port_sysinfo.h
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 PROTECTED] wrote
, 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
availableCoresPerProcessor() or something more
. __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:
On 11/1/06, Alexey Varlamov
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 Mikhail Fursov wrote:
On 01 Nov 2006 15:56:28 +0600, Egor Pasko
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
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
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 this to
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 work and 3. Compressor. No one knows which one
: 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-established parallel
compaction algorithms. So far
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 helpers? I
think only class loading
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, all, the plan for GCv5 parallel
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 [EMAIL PROTECTED] wrote:
Hi, all
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
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 owning components to initialize
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
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
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
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 cleanly. Period
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
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
depends on mmtk.jar? If only the unboxed classes are used
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
, 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 info than accessing GC TLS data
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_tls_key();
thread_set_tls_data( gc_tls_key
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 you can store a pointer
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 PROTECTED
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 wants is just to inline GC tls
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
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
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 the
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
special interface approach
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
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
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,
xiaofeng
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 requirement
and
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 project, so
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
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
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
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
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();
do unsafe actions
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
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
(vm_get_gc_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 its allocation
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 around the problem
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?
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 before vm_init() before
any method need
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
any method need compiling, just
, 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,
Since the JIT/VM can determine
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
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 right
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,
-xiaofeng
On 10/9/06, Salikh Zakirov [EMAIL PROTECTED] wrote
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 JIRA
On 10/8/06, Xiao-Feng Li [EMAIL PROTECTED
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
Thanks,
xiaofeng
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
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
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 [EMAIL PROTECTED] wrote:
Egor
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:
http://issues.apache.org/jira/secure/attachment/12342430
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/ of gcv4.1), the other under
gc_gen
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 implementing an early version of a
trace-forward
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:
http://issues.apache.org/jira/secure
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 better solution, GCv5 would
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
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
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
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 for JET that GCv5 is going
to 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] Updated: (HARMONY
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
, Weldon Washburn [EMAIL PROTECTED] wrote:
On 9/19/06, Xiao-Feng Li [EMAIL PROTECTED] wrote:
Hi, a new attachment is submitted to GCv5 as an update to JIRA 1428.
(https://issues.apache.org/jira/browse/HARMONY-1428), which is a
mark-compaction GC. This GC is going to be connected with last
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, as C/C++ is my first
program language )However
On 9/15/06, Ivan Volosyuk [EMAIL PROTECTED] wrote:
There was a command line switch -Dvm.dlls=full path to GC. 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=path to GC
--
Ivan
Good idea. And we need add multiple
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
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
specifically with the assumption that most
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 key
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 here: which was ... -- well
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
/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 desirable.
We would like to introduce
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 messages with [DRLVM][GC
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 to
. It 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 PROTECTED]
Date: Sep
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 Harmony GCV5.
Briefly the goals are to build
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
. 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
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
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,
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 Harmony GCV5.
Briefly the goals are to build a Generational
Weldon, I experimented with last two bits for marking and forwarding
without problem.
The GC_OBJECT_MARK_BIT_MASK is for obj_info field, not the vt field. (
So far as I experimented, it's only used for heap verification).
Thanks,
xiaofeng
On 8/24/06, Weldon Washburn [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 Harmony GCV5.
Briefly the goals are to build a Generational Mark-Compaction (GenMC)
garbage collector, initially
On 8/18/06, Robin Garner [EMAIL PROTECTED] wrote:
Object org.vmmagic.utility.accessVmStructure(identifier)
This is a good idea to keep in mind. We can introduce it when needed.
At the moment for service fast-path inlining, I guess specific JIT
intrisics are enough.
or even better, declare
On 8/17/06, Rana Dasgupta [EMAIL PROTECTED] wrote:
- So we will write the inlinable fastpaths wherever possible in pure
Java, using an annotated calling convention to call the slowpath ( to
support developer freedom :-) ).
- Where the fastpaths cannot be expressible in pure Java,
1 - 100 of 129 matches
Mail list logo
