RFR: 8177845: Need a mechanism to load Graal
peter.levart at gmail.com
Wed Apr 19 08:12:59 UTC 2017
On 04/19/2017 09:42 AM, Peter Levart wrote:
> On 04/19/2017 09:37 AM, Peter Levart wrote:
> Also, while we are at it, the following javadocs in the
> getSavedProperty() do not apply any more:
> 138 * It accesses a private copy of the system properties so
> 139 * that user's locking of the system properties object will not
> 140 * cause the library to deadlock.
> In JDK 9, Properties class does not use locking any more on the
> Properties instance for get()/getProperty() methods...
> Regards, Peter
I also noticed the following comment:
// TODO: the Property Management needs to be refactored and
// the appropriate prop keys need to be accessible to the
// calling classes to avoid duplication of keys.
private static Map<String, String> savedProps;
...which is not entirely true. Neither keys nor values are duplicated
(they are just referenced in the new copy of the Properties/Map object).
What is duplicated is an excessive amount of internal objects, such as
array slots and Map.Entry objects. If this is a concern, then we could
use the new immutable Map implementation that is available in JDK 9, so
the following lines in my webrev:
182 Map<String, String> sp = new HashMap<>((Map)props);
183 // only main thread is running at this time, so savedProps and
184 // its content will be correctly published to threads
185 savedProps = Collections.unmodifiableMap(sp);
Could be changed into:
Map<String, String> sp =
// only main thread is running at this time, so savedProps
// will be correctly published to threads started later
savedProps = sp;
...to save some excessive space (the implementation is a linear-probe
hashtable which keeps keys and values directly in an array without
wrapping them with Map.Entry objects).
More information about the hotspot-dev