[vmkit-commits] [PATCH] OpenJDK threading: initialize fields

Nicolas Geoffray nicolas.geoffray at gmail.com
Tue Nov 1 12:45:49 PDT 2011


Hi Will,

I think the approach is fine here. I also had to make something that looks
unclean for GNU Classpath. But the creation of the main thread is something
special, that requires special handling. So patch looks good, feel free to
commit!

Nicolas

On Tue, Nov 1, 2011 at 6:11 AM, Will Dietz <wdietz2 at illinois.edu> wrote:

> Inlined below.
>
> The main thing is the small change to explicitly set the eetop field
> to the JavaThread.
>
> The reason we set the fields *before* calling the constructor is due
> to a bit of strangeness that probably needs some discussion.
>
> In the thread constructor, it defaults to setting the
> thread-being-constructed's priority and daemon status from what the
> parent thread has for those values.  The parent thread is determined
> by a call to JVM_CurrentThread.
>
> This is all well and good except when we're using CreateJavaThread to
> create the Thread for the currently-running main thread, since this
> means the constructor will try to use the values of the thread it's
> mid-creating to initialize itself with.  And of course it does sanity
> checks on those values and things don't work out well (turns out '0'
> is an invalid priority).
>
> I thought about making this specific to the main thread construction,
> but it doesn't seem worth it since in all other cases these values
> will be overridden happily immediately anyway.
>
> I understand this is a tad hacky, but the alternatives I thought of
> seemed worse (some kinda of placeholder parent-of-main thread whose
> sole purpose in existing is to fix this field initialization issue).
>
> As always thoughts very much welcome, and thank you for your time :).
>
> ~Will
>
> >From 2dc1fa5b0da33852cfca80b67e50967d0262709a Mon Sep 17 00:00:00 2001
> From: Will Dietz <w at wdtz.org>
> Date: Thu, 27 Oct 2011 19:29:48 -0500
> Subject: [PATCH 4/8] OpenJDK threading: intialize fields, set eeetop field.
>
> ---
>  lib/J3/ClassLib/OpenJDK/JavaUpcalls.cpp |    8 ++++++--
>  1 files changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/lib/J3/ClassLib/OpenJDK/JavaUpcalls.cpp
> b/lib/J3/ClassLib/OpenJDK/JavaUpcalls.cpp
> index 476b6e3..d9fa7d7 100644
> --- a/lib/J3/ClassLib/OpenJDK/JavaUpcalls.cpp
> +++ b/lib/J3/ClassLib/OpenJDK/JavaUpcalls.cpp
> @@ -235,12 +235,16 @@ void Classpath::CreateJavaThread(Jnjvm* vm,
> JavaThread* myth,
>
>   name = vm->asciizToStr(thName);
>
> +  // Initialize the values
> +  priority->setInstanceInt32Field(th, (uint32)5);
> +  daemon->setInstanceInt8Field(th, (uint32)false);
> +
>   // call Thread(ThreadGroup,String) constructor
>   initThread->invokeIntSpecial(vm, newThread, th, &Group, &name);
>
>   // Store reference to the JavaThread for this thread in the 'eetop' field
> -  // TODO: Don't do this until we have the tracing handled.
> -  // eetop->setInstanceLongField(th, (long)myth);
> +  // GC-safe since 'eetop' is of type 'long'
> +  eetop->setInstanceLongField(th, (long)myth);
>  }
>
>  void Classpath::InitializeThreading(Jnjvm* vm) {
> --
> 1.7.5.1
> _______________________________________________
> vmkit-commits mailing list
> vmkit-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/vmkit-commits
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/vmkit-commits/attachments/20111101/25673f7a/attachment.html>


More information about the vmkit-commits mailing list