On 4/24/07, Alexey Varlamov <[EMAIL PROTECTED]> wrote:
2007/4/24, Mikhail Fursov <[EMAIL PROTECTED]>: > On 4/24/07, Alexey Varlamov <[EMAIL PROTECTED]> wrote: > > > > 2007/4/24, Mikhail Fursov <[EMAIL PROTECTED]>: > > > On 4/24/07, Sergey Kuksenko <[EMAIL PROTECTED]> wrote: > > > > > > > > On 4/24/07, Xiao-Feng Li <[EMAIL PROTECTED]> 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
