harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dmitry Yershov" <dmitry.yers...@gmail.com>
Subject Re: [drlvm] the big soup of VM properties (HARMONY-1626)
Date Tue, 10 Oct 2006 04:30:14 GMT
There are my thoughts about VM properties. I observe some problem with
current VM properties implementation:
1) The current VM properties initialization is rather chaotic:
    * Some properties stored into two places: Properties class and array of
      VmStandardProperty structure. A certain algorithms use properties from
      first place. But other algorithms use properties from second place.
    * There are plenty of functions working with properties (on
initialization stage,
       see create_vm function of vm_main.cpp). Number of it may be reduced
       (and I see some ways to do that).
    * There are two arrays contain predefined properties.
    * There is very interesting implementation of
InsertSystemProperties function
       (see java_lang_VMExecutionEngine.cpp). Properties described in this
       function should be defined earlier. This function should read their from
       Properties table.
2) Redefining by user (through command line option –D<key>=<value>)
    some properties (i.e. "vm.other_natives_dlls") crashed VM.
3) VM properties table is not thread safe.

So, I propose the following:
1) Redevelop VM properties module according to attached proposal. This
    * May be based on apr hashtable.
    * Thread safe.
    * Introduces public (for java and VM side) and private (for VM side only)
      properties. It allows us to avoid VM crashes when some key properties
      (i.e. "vm.other_natives_dlls") redefined by user.
2) Do "deep" source code refactoring. After that we should have clear and
    strong algorithms of property initialization and usage. Some redundant VM
    properties and arrays of predefined properties should be throw out
on this stage.


2006/10/6, Geir Magnusson Jr. <geir@pobox.com>:
> So one of the interesting things that jumped out of me is the number of
> various library and boot classpath properties that we have floating
> around, and I'd like to
> 1) understand this
> 2) get rid of all the ones that we don't need
> Is there a defined set we need to support?  Anyone have suggestions?
> geir

View raw message