Platform dependent flag adjustments
Vladimir Kozlov
vladimir.kozlov at oracle.com
Thu Oct 18 06:53:14 PDT 2012
Agree. And it would be nice to call VM_Version::initialize() before
Arguments::parse() (I never liked that we call it twice on SPARC) and use it
only to determine hardware parameters and call do_pd_flag_adjustments() after
arguments parsing. I think it is good project.
Thanks,
Vladimir
David Holmes wrote:
> On 18/10/2012 3:47 AM, Vladimir Kozlov wrote:
>> We usually do flags adjustment for platforms in vm_version_<arc>.cpp
>> files. VM_Version_init() is called after Arguments::parse(args).
>
> Yes - but it is unfortunate in that VM_Version::initialize() method is
> not the obvious place to do such things, but it is a platform specific
> initialization hook that is invoked at near-enough the right time. That
> said, it all depends on what these flags do as to whether tweaking them
> in VM_Version::initialize() is too late, as a lot of other
> initialization has happened by then.
>
> Further if these are really OS specific rather than arch specific flags
> then VM_Version::initialize() may not be the right place at all, in
> which case os::init2(), as Harold mentioned, may be a better choice.
>
> There's no nice neat simple solution here. Ultimately you may need a
> per-arch and per-OS hook per-flag, and even then you might also need
> pre- and post- variants to get the order right! So what we have is quite
> ad-hoc and often just implemented in the most convenient way at the time.
>
> David
> -----
>
>
>> Vladimir
>>
>> Volker Simonis wrote:
>>> Hi,
>>>
>>> for our PowerPC/AIX port I'm currently looking for a place where I can
>>> do platform dependent adjustments to command line arguments which are
>>> available on special platforms only.
>>>
>>> For our private ports, we did all these adjustments conditionally in
>>> 'parse_each_vm_init_arg()' and I noticed that the original version of
>>> this method already contains platforms specific parts (e.g.
>>> SOLARIS_ONLY(..)). But these solution is not very attractive because
>>> it clutters shared code. It also seems unintuitive to handle platform
>>> dependent flags which are declared in special platform dependent files
>>> (e.g. src/cpu/<arch>/vm/globals_<arch>.hpp:) in a central shared
>>> method. Finally the current solution will scale poorly with new
>>> platform ports coming into the OpenJDK.
>>>
>>> I also noticed that the the 'Arguments' class declares a static method
>>> 'do_pd_flag_adjustments()'. Unfortunately this method is never defined
>>> nor called. I saw that this method was there from the initial checkin
>>> and I'm wondering if this was a first attempt to generalize the flag
>>> adjustment?
>>>
>>> Or perhaps there's an even better way to do platform dependent flag
>>> adjustments which I've just missed?
>>>
>>> Any insights and hints are highly welcome.
>>>
>>> Regards,
>>> Volker
More information about the hotspot-runtime-dev
mailing list