harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexey Varlamov" <alexey.v.varla...@gmail.com>
Subject Re: [DRLVM] DRLVM default GC was switched from GCv4.1 to GCv5
Date Tue, 24 Apr 2007 16:09:59 GMT
2007/4/24, Mikhail Fursov <mike.fursov@gmail.com>:
> 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.

OK, actually I meant the part of VM which manages components loading
and initialization, sorry for confusion. So instead of adding any of
specified startup packages to bootclasspath as it happens now, it
should first check if corresponding component is really present in
runtime configuration and skip otherwise.

> EM does not know what 'server' or 'client' mode is either.
> It's just different configuration files from EM POV.

Yep, still it processes it's content and can transform to VM
properties depending on setup.
So it could either filter out some properties (based on component name
encoded in property name or such) or let VM care of it.

>
> 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
View raw message