RFC: cannot run hotspot with bootstrap jdk1.7.0_45: see 8014399: Remove JVM_SetProtectionDomain from hotspot:

Daniel D. Daugherty daniel.daugherty at oracle.com
Mon Nov 4 19:11:34 PST 2013


On 11/4/13 12:36 PM, Francis ANDRE wrote:
> Hi Dan
>
> I looked at the 8027113 decouple the '-XXaltjvm=<path>' option from 
> the gamma launcher issue and the fix proposal.
>
> +            tagData("LocalDebuggerCommandArguments", 
> "-XXaltjvm=$(TargetDir) "
> +                    + "-Dsun.java.launcher.is_altjvm=true "
> +                    + "-XX:+UnlockDiagnosticVMOptions 
> -XX:+PauseAtExit");
>              tagData("LocalDebuggerEnvironment", "JAVA_HOME=" + 
> cfg.get("JdkTargetRoot"));
>
>
> Here 2 comments:
>
> 1/ Specifying -XXaltjvm=$(TargetDir) won't work because the path 
> $(TargetDir) is a DOS path and then all '\' will be removed by java as 
> you can see below

I've tested the above code in my VS2010 IDE setup and it does work.
The -XXaltjvm=... part is not modified by my fix and the DOS path
part worked before my fix and after.


> FrancisANDRE at idefix 
> /cygdrive/Z/JDK/hsx/jdk7u/build/windows-i586/j2sdk-image
> $ ./bin/java 
> -XXaltjvm=Z:\JDK\hsx\hotspot-rt\hotspot\build\vs-i486\compiler1\debug 
> -Dsun.java.launc
> her=gamma
> Error: missing `Z:JDKhsxhotspot-rthotspotbuildvs-i486compiler1debug' 
> JVM at `Z:\JDK\hsx\jdk7u\build\
> windows-i586\j2sdk-image\jre\bin\Z:JDKhsxhotspot-rthotspotbuildvs-i486compiler1debug\jvm.dll'. 
>
> Please install or use the JRE or JDK that contains these missing 
> components.

The above looks like you are trying to run the command from the XML 
generation
code on a shell command line. In that situation, the backslashes are 
interpreted
by the shell and they don't work without escaping. When the IDE does the
command invocation, it doesn't have a problem with the non-escaped
backslashes.


> 2/ Instead of -Dsun.java.launcher.is_altjvm=true, why not use 
> -Dsun.java.launcher=altjvm which avoid the bool is_altjvm?

I didn't opt for that style of fix because the launcher is not
actually 'gamma' (old code) or 'altjvm' (the above code) and I
don't like lying about the launcher that is in use. The launcher
being used to launch the VM in this case is the 'java' launcher.
When you look at what is passed as VM args inside the debugger
for the pre-fix code, it is:

     -Dsun.java.launcher=gamma <other_args> -Dsun.java.launcher=java

and that kind of drove me a bit crazy. I picked:

     -Dsun.java.launcher.is_altjvm=true

because 'is_altjvm' is an attribute of the way we are using the Sun
java launcher so it makes sense that it should a sun.java.launcher.XXX
attribute. In this case, it is a boolean attribute so...

Thanks for taking a look at the code even before it went out for
official code review. Please let me know if this resolves your
concerns.

Dan



>
> Francis
>
> Le 04/11/2013 14:52, Daniel D. Daugherty a écrit :
>> On 11/4/13 2:20 AM, David Holmes wrote:
>>> On 4/11/2013 4:48 PM, Francis ANDRE wrote:
>>>> David,
>>>>
>>>> Le 03/11/2013 22:24, David Holmes a écrit :
>>>>> Francis,
>>>>>
>>>>> On 2/11/2013 10:58 PM, Francis ANDRE wrote:
>>>>>> Hi
>>>>>>
>>>>>> Building hotspot-rt using this repository
>>>>>> http://hg.openjdk.java.net/hsx/hotspot-rt on a WXP/Cygwin/VS2010
>>>>>> platform and running
>>>>>>
>>>>>> C:/Progra~1/Java/jdk1.7.0_45\bin\java.exe
>>>>>> -XXaltjvm=Z:/JDK/hotspot-rt/hotspot/build\vs-i486/compiler1/debug
>>>>>> -Dsun.java.launcher=gamma
>>>>>
>>>>> The gamma launcher has been removed partly because of this kind of
>>>>> problem. You can not use a hs25 VM in a JDK7 any more. The "hotspot
>>>>> express" release model, where newer VMs could be used in older 
>>>>> JDKs is
>>>>> no more. The VM and JDK are once again tightly connected.
>>>> No problem with the VM and JDK being once again tightly connected once
>>>> the bootstrap process is correct, but in my case, the 
>>>> ProjectCreator for
>>>> MSVC102 generates this line of command for the hsx/hotspot-rt 
>>>> repository
>>>>
>>>>    <PropertyGroup
>>>> Condition="'$(Configuration)|$(Platform)'=='compiler1_fastdebug|Win32'"> 
>>>>
>>>> <LocalDebuggerCommand>C:/Progra~1/Java/jdk1.7.0_45\bin\java.exe</LocalDebuggerCommand> 
>>>>
>>>>
>>>> <LocalDebuggerCommandArguments>-XXaltjvm=$(TargetDir)
>>>> -Dsun.java.launcher=gamma</LocalDebuggerCommandArguments>
>>>> <LocalDebuggerEnvironment>JAVA_HOME=C:/Progra~1/Java/jdk1.7.0_45</LocalDebuggerEnvironment> 
>>>>
>>>>
>>>>    </PropertyGroup>
>>>>
>>>> which is exactly the command line I displayed below
>>>>
>>>> C:/Progra~1/Java/jdk1.7.0_45\bin\java.exe
>>>> -XXaltjvm=Z:/JDK/hotspot-rt/hotspot/build\vs-i486/compiler1/debug
>>>> -Dsun.java.launcher=gamma
>>>
>>> I don't use ProjectCreator but it looks like it needs to be modified 
>>> as this is no longer a generally valid approach.
>>
>> See this bug for work that is going for exactly this issue:
>>
>> 8027113 decouple the '-XXaltjvm=<path>' option from the gamma launcher
>>
>> This fix won't make HSX-25, but it will be in early for JDK9.
>>
>> Dan
>>
>>
>>>
>>>>>> produces the following exception
>>>>>>
>>>>>> _JVM_SetProtectionDomain at 12 is not found in the dynamic linked 
>>>>>> library
>>>>>> jvm.dll
>>>>>>
>>>>>>
>>>>>> The definition of SetProtectionDomain has been removed from the 
>>>>>> jdk8 jvm
>>>>>> but not its reference in the jdk7 java.exe, thus it is not possible
>>>>>> anymore to build/run a jdk8 release with a bootstrap release as 
>>>>>> of jdk7
>>>>>> that contains such reference. Thus I am proposing to build a jdk7
>>>>>> release without any reference to the _JVM_SetProtectionDomain entry
>>>>>> point by back-porting the 8014399  to the jdk7u distribution.
>>>>>
>>>>> That might be possible but there are likely to be other things -
>>>>> particularly in the area of invokeDynamic and MethodHandles that will
>>>>> prevent hs25 from operating within 7u45.
>>>> InvokeDynamic is a new opcode that will be produced only by jdk8, if I
>>>> understand well. What I am requesting is just a backport of the
>>>> reference to SetProtectionDomain -- this changeset 37aa82c52317 -- so
>>>> that a JDK8 be produced/tested with a jdk7 as bootstrap jdk.
>>>
>>> invokeDynamic was introduced in JDK7. There have been numerous 
>>> changes in the related VM implementation for it and MethodHandles 
>>> (and other parts of java.lang.invoke API's) that may prevent a new 
>>> VM from running in a 7u45 JDK.
>>>
>>> David
>>> -----
>>>
>>>> Currently, I applied  locally  this changeset 37aa82c52317 and
>>>> ba9dacff9c9d to the hsx/jdk7u repo and use it to bootstrap jdk8. Tests
>>>> are in progress. I will keek you updated on the results.
>>>>>
>>>>> David
>>>>> -----
>>>>>
>>>>>>
>>>>>>
>>>>>> Francis
>>>>>>
>>>>>>
>>>>>
>>>>
>>
>>
>



More information about the hotspot-runtime-dev mailing list