harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mikhail Fursov" <mike.fur...@gmail.com>
Subject Re: [DRLVM] DRLVM default GC was switched from GCv4.1 to GCv5
Date Tue, 24 Apr 2007 15:50:37 GMT
On 4/24/07, Alexey Varlamov <alexey.v.varlamov@gmail.com> wrote:
>
> 2007/4/24, Mikhail Fursov <mike.fursov@gmail.com>:
> > On 4/24/07, Sergey Kuksenko <sergey.kuksenko@gmail.com> wrote:
> > >
> > > On 4/24/07, Xiao-Feng Li <xiaofeng.li@gmail.com> wrote:
> > > >
> > > > Actually there is a JIRA for this submitted by Yunan He. Mikhail has
> a
> > > > quick patch submitted as well, but then we think it might not be
> very
> > > > urgent at the moment since he needs more time to have a good
> solution
> > > > for both 32 and 64 bit platforms. I personally think Mikhail can
> take
> > > > more time for this issue.
> > >
> > > But, without it we can't run DRLVM in server mode.
> > > (yes, we can with manual config manupulation, but it is bad and will
> > > confuse
> > > others who don't know such details and want to run Harmony DRLVM in
> sever
> > > mode).
> > >
> > > Standardizing names for all VM helpers is a good idea.
> > There are some problems that must be solved before.
> > One of the problems is: a conflict between multiple Java implementations
> of
> > a helper. Only one of the implementations must be added to bootstrap
> > classpath. Today all of the implementations (both gc_gen and gc_cc jars)
> are
> > in bootstrap. So we need an interface to allow adding custom item into
> > bootstrap classpath. After we have it GC can use this API to add its own
> > helpers and helpers from different GC can share the same name.
>
> We can just customize emconf properties and their semantics, so that
> EM will be more selective depending on which components are loaded at
> runtime. Then it is enough to package different impls separately and
> tie specific jars to concrete components via emconf.
> I don't think more specialized API worths it,


I do not understand what do you propose here. EM does not understand JIT
nor GC properties, it just passes it to VM.
EM does not know what 'server' or 'client' mode is either.
It's just different configuration files from EM POV.

moreover GC should not
> care which execution engine and which mode is active.
>
> Yes, the only thing GC should care about is availability of its own
helpers. All other runtime configuration settings can be prepared outside of
GC.


-- 
Mikhail Fursov

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message