RFR 8203381 Replace InstanceKlass::allocate_instance_handle with JavaCalls::construct_new_instance
ioi.lam at oracle.com
Sat May 19 01:46:32 UTC 2018
Thanks for the review.
In some cases, such as create_initial_thread, we must do
ik->allocate_instance_handle() and JavaCalls::call_special in 2 steps,
and set some thread states in between the 2 steps.
Also, there are other use of JavaCalls::call_special for invoke instance
methods that are not constructors.
Therefore, we cannot hide JavaCalls::call_special.
On 5/18/18 11:04 AM, yumin qi wrote:
> Hi, Ioi
> Very nice clean-up for Thread creation.
> One question, should we replace all the JavaCalls::call_special
> with JavaCalls::construct_new_instance (there are three versions) and
> make JavaCalls::call_special an internal implementation? I did see
> many places using JavaCalls::call_special.
> On Fri, May 18, 2018 at 9:36 AM, Ioi Lam <ioi.lam at oracle.com
> <mailto:ioi.lam at oracle.com>> wrote:
> This patch removes a lot of the boilerplate code for allocating a
> Java object and calling its constructor. Hopefully the code is cleaner
> and easier to read.
> Added assert(InstanceKlass::is_initialized(), ...) in case where
> we cannot call JavaCalls::construct_new_instance for thread objects.
> Replaced unnecessary SystemDictionary::resolve_or_null() calls with
> Tested with hs-tier[1,2,3,4,5]
> - Ioi
More information about the hotspot-runtime-dev