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 Wed, 25 Apr 2007 07:34:12 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, 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.


Both  gc.dll and  gc.jar are the parts of the one GC. So the option to use
custom gc.dll without specification of which gc.jar to use can be the reason
of the problem.
Another solution can be is to specify not gc.dll but
gc.<component_description> file in command line. In this file all gc
properties could be stored: which dll, which mode and which java helpers to
use.
In this case we can share the names of Java helpers between different
implementations.

-- 
Mikhail Fursov

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