date:20220606

Re: RFR: 8286850: [macos] Add support for signing user provided app image [v2]

2022-06-06 Thread Alexander Matveev

Hi Michael,

See below.

On Jun 5, 2022, at 5:58 PM, Michael Hall 
mailto:mik3h...@gmail.com>> wrote:


./build/*/images/jdk/bin/jpackage --app-image 
~/HalfPipe/halfpipe_jpkg/outputdir/HalfPipe.app --mac-sign 
--mac-signing-key-user-name "Developer ID Application: Michael Hall 
(5X6BXQB3Q7)"
Bundler Mac DMG Package skipped because of a configuration problem: When using 
an external app image you must specify the app name.
Advice to fix: Set the app name via the -name CLI flag, the 
fx:application/@name ANT attribute, or via the 'appName' bundler argument.

./build/*/images/jdk/bin/jpackage --app-image 
~/HalfPipe/halfpipe_jpkg/outputdir/HalfPipe.app --mac-sign 
--mac-signing-key-user-name "Developer ID Application: Michael Hall 
(5X6BXQB3Q7)" --name HalfPipe
Warning: Using unsigned app-image to build signed dmg.

*** The app-image was actually a signed one. I’m not sure that matters. Also 
since this would normally be my intention should there be a warning? ***

codesign -v --verbose=4 ~/HalfPipe/halfpipe_jpkg/outputdir/HalfPipe.app
/Users/mjh/HalfPipe/halfpipe_jpkg/outputdir/HalfPipe.app: valid on disk
/Users/mjh/HalfPipe/halfpipe_jpkg/outputdir/HalfPipe.app: satisfies its 
Designated Requirement

*** Seems successful ***

Thanks again.


Possibly my mistake somehow but codesign seems to flag something if the 
application is actually unsigned.

${PACKAGER} \
--verbose \
   --add-modules java.desktop,java.prefs,java.se \
   --type app-image \
--input ./input \
--app-version 1.0  \
--name BlackJack\ Blastoff_Unsigned \
--main-jar bjb.jar \
--main-class org.bjb.BlackJackApp \
--java-options '-Xmx1024m -XX:+UseG1GC -XX:MaxGCPauseMillis=50  
-Dapple.laf.useScreenMenuBar=true 
-Dcom.apple.mrj.application.apple.menu.about.name=BlackjackBlastoff 
-Dapple.awt.application.name=Blackjack\ Blastoff’

[19:41:02.231] Creating app package: BlackJack Blastoff_Unsigned.app in 
/Users/mjh/Blackjack_Blastoff/bjb/bjb_jpkg
[19:41:05.516] Command [PID: -1]:
   jlink --output /Users/mjh/Blackjack_Blastoff/bjb/bjb_jpkg/BlackJack 
Blastoff_Unsigned.app/Contents/runtime/Contents/Home --module-path 
/Library/Java/JavaVirtualMachines/jdk-18.jdk/Contents/Home/jmods --add-modules 
java.desktop,java.prefs,java.se --strip-native-commands 
--strip-debug --no-man-pages --no-header-files
[19:41:05.517] Output:

[19:41:05.518] Returned: 0

[19:41:05.545] Using default package resource JavaApp.icns [icon] (add 
BlackJack Blastoff_Unsigned.icns to the resource-dir to customize).
[19:41:05.547] Preparing Info.plist: 
/Users/mjh/Blackjack_Blastoff/bjb/bjb_jpkg/BlackJack 
Blastoff_Unsigned.app/Contents/Info.plist.
[19:41:05.547] Using default package resource Info-lite.plist.template 
[Application Info.plist] (add Info.plist to the resource-dir to customize).
[19:41:05.550] Using default package resource Runtime-Info.plist.template [Java 
Runtime Info.plist] (add Runtime-Info.plist to the resource-dir to customize).
[19:41:05.551] Succeeded in building Mac Application Image package

./build/*/images/jdk/bin/jpackage --app-image 
~/Blackjack_Blastoff/bjb/bjb_jpkg/BlackJack\ Blastoff_Unsigned.app --mac-sign 
--mac-signing-key-user-name "Developer ID Application: Michael Hall 
(5X6BXQB3Q7)" --name BlackJack_Blastoff_Unsigned
Warning: Using unsigned app-image to build signed dmg.

open BlackJack_Blastoff_Unsigned-1.0.dmg

codesign -v --verbose=4 /Volumes/BlackJack_Blastoff_Unsigned/BlackJack\ 
Blastoff_Unsigned.app
/Volumes/BlackJack_Blastoff_Unsigned/BlackJack Blastoff_Unsigned.app: code has 
no resources but signature indicates they must be present
This is correct. You generated unsigned application image and then package it 
into DMG with signing enabled. In this case we will not sign app image. Only 
installer package will get signed and it applies only to PKG. DMG does not have 
any signing. This is was same behavior as before JDK-8286850.

You need to sign app image first:
./build/*/images/jdk/bin/jpackage --type app-image --app-image 
~/Blackjack_Blastoff/bjb/bjb_jpkg/BlackJack\ Blastoff_Unsigned.app --mac-sign 
--mac-signing-key-user-name "Developer ID Application: Michael Hall 
(5X6BXQB3Q7)" --name BlackJack_Blastoff_Unsigned

Then run command to generate DMG or PKG. Enable signing if you want PKG to be 
signed. No need to specify it for DMG if you generating DMG from predefined 
application image.

As for "code has no resources but signature indicates they must be present” I 
believe it is due to JDK-8277493 and it was fixed in JDK 19.


I am using the installed jdk18 to create the app-image. Would that need to be 
done with the same jdk with the changes applied?
Yes, if you need to sign app image after post processing it should be generated 
with JDK version which contains JDK-8286850 fix. Unless something will change 
jpackage from JDK 20 should able to sign app image generated by JDK 19, but JDK 
19 jpackage will not able to sign app image generated by JDK 18.

This is do to additional values are stored

Re: RFR: 8283667: [vectorapi] Vectorization for masked load with IOOBE with predicate feature [v5]

2022-06-06 Thread Xiaohong Gong

On Mon, 6 Jun 2022 15:41:06 GMT, Paul Sandoz  wrote:

> Looks good. As a follow on PR I think it would be useful to add constants 
> `OFFSET_IN_RANGE` and `OFFSET_OUT_OF_RANGE`, then it becomes much clearer in 
> source and you can drop the `/* offsetInRange */` comment on the argument.

Hi @PaulSandoz , thanks for the advice! I'v rebased the codes and added these 
two constants in the latest patch. Thanks again for the review!

-

PR: https://git.openjdk.java.net/jdk/pull/8035

Re: RFR: 8283667: [vectorapi] Vectorization for masked load with IOOBE with predicate feature [v6]

2022-06-06 Thread Xiaohong Gong

> Currently the vector load with mask when the given index happens out of the 
> array boundary is implemented with pure java scalar code to avoid the IOOBE 
> (IndexOutOfBoundaryException). This is necessary for architectures that do 
> not support the predicate feature. Because the masked load is implemented 
> with a full vector load and a vector blend applied on it. And a full vector 
> load will definitely cause the IOOBE which is not valid. However, for 
> architectures that support the predicate feature like SVE/AVX-512/RVV, it can 
> be vectorized with the predicated load instruction as long as the indexes of 
> the masked lanes are within the bounds of the array. For these architectures, 
> loading with unmasked lanes does not raise exception.
> 
> This patch adds the vectorization support for the masked load with IOOBE 
> part. Please see the original java implementation (FIXME: optimize):
> 
> 
>   @ForceInline
>   public static
>   ByteVector fromArray(VectorSpecies species,
>byte[] a, int offset,
>VectorMask m) {
>   ByteSpecies vsp = (ByteSpecies) species;
>   if (offset >= 0 && offset <= (a.length - species.length())) {
>   return vsp.dummyVector().fromArray0(a, offset, m);
>   }
> 
>   // FIXME: optimize
>   checkMaskFromIndexSize(offset, vsp, m, 1, a.length);
>   return vsp.vOp(m, i -> a[offset + i]);
>   }
> 
> Since it can only be vectorized with the predicate load, the hotspot must 
> check whether the current backend supports it and falls back to the java 
> scalar version if not. This is different from the normal masked vector load 
> that the compiler will generate a full vector load and a vector blend if the 
> predicate load is not supported. So to let the compiler make the expected 
> action, an additional flag (i.e. `usePred`) is added to the existing 
> "loadMasked" intrinsic, with the value "true" for the IOOBE part while 
> "false" for the normal load. And the compiler will fail to intrinsify if the 
> flag is "true" and the predicate load is not supported by the backend, which 
> means that normal java path will be executed.
> 
> Also adds the same vectorization support for masked:
>  - fromByteArray/fromByteBuffer
>  - fromBooleanArray
>  - fromCharArray
> 
> The performance for the new added benchmarks improve about `1.88x ~ 30.26x` 
> on the x86 AVX-512 system:
> 
> Benchmark  before   After  Units
> LoadMaskedIOOBEBenchmark.byteLoadArrayMaskIOOBE   737.542 1387.069 ops/ms
> LoadMaskedIOOBEBenchmark.doubleLoadArrayMaskIOOBE 118.366  330.776 ops/ms
> LoadMaskedIOOBEBenchmark.floatLoadArrayMaskIOOBE  233.832 6125.026 ops/ms
> LoadMaskedIOOBEBenchmark.intLoadArrayMaskIOOBE233.816 7075.923 ops/ms
> LoadMaskedIOOBEBenchmark.longLoadArrayMaskIOOBE   119.771  330.587 ops/ms
> LoadMaskedIOOBEBenchmark.shortLoadArrayMaskIOOBE  431.961  939.301 ops/ms
> 
> Similar performance gain can also be observed on 512-bit SVE system.

Xiaohong Gong has updated the pull request with a new target base due to a 
merge or a rebase. The pull request now contains seven commits:

 - Add constant OFFSET_IN_RANGE and OFFSET_OUT_OF_RANGE
 - Merge branch 'jdk:master' into JDK-8283667
 - Merge branch 'jdk:master' into JDK-8283667
 - Use integer constant for offsetInRange all the way through
 - Rename "use_predicate" to "needs_predicate"
 - Rename the "usePred" to "offsetInRange"
 - 8283667: [vectorapi] Vectorization for masked load with IOOBE with predicate 
feature

-

Changes: https://git.openjdk.java.net/jdk/pull/8035/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=8035=05
  Stats: 453 lines in 44 files changed: 174 ins; 21 del; 258 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8035.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8035/head:pull/8035

PR: https://git.openjdk.java.net/jdk/pull/8035

Re: RFR: 8287663 Add a regression test for JDK-8287073

2022-06-06 Thread Ioi Lam

On Mon, 6 Jun 2022 23:07:06 GMT, Ioi Lam  wrote:

> We should try to consolidate these test cases to improve maintainability.

I filed [JDK-8287185](https://bugs.openjdk.org/browse/JDK-8287185)

-

PR: https://git.openjdk.java.net/jdk/pull/8993

Re: RFR: 8286850: [macos] Add support for signing user provided app image [v2]

2022-06-06 Thread Alexander Matveev

Hi Michael,

Printing "Warning: Using unsigned app-image to build signed dmg.” with signed 
application should be fixed with JDK-8286850. Did you reproduce it on build 
containing JDK-8286850?

Thanks,
Alexander

> On Jun 5, 2022, at 3:06 PM, Michael Hall  wrote:
> 
> 
> 
>> On Jun 5, 2022, at 8:56 AM, Michael Hall  wrote:
>> 
>> 
>> Fwiw, I was going to take a look at this but my build failed.
>> 
>> === Output from failing command(s) repeated here ===
>> * For target support_native_java.desktop_liblcms_cmstypes.o:
>> /Users/mjh/Documents/GitHub/jdk/src/java.desktop/share/native/liblcms/cmstypes.c:3441:132:
>>  error: parameter 'SizeOfTag' set but not used 
>> [-Werror,-Wunused-but-set-parameter]
>> void *Type_ProfileSequenceId_Read(struct _cms_typehandler_struct* self, 
>> cmsIOHANDLER* io, cmsUInt32Number* nItems, cmsUInt32Number SizeOfTag)
>>  
>> ^
>> /Users/mjh/Documents/GitHub/jdk/src/java.desktop/share/native/liblcms/cmstypes.c:5137:125:
>>  error: parameter 'SizeOfTag' set but not used 
>> [-Werror,-Wunused-but-set-parameter]
>> void *Type_Dictionary_Read(struct _cms_typehandler_struct* self, 
>> cmsIOHANDLER* io, cmsUInt32Number* nItems, cmsUInt32Number SizeOfTag)
>>  
>>  ^
>> 2 errors generated.
>> 
>> 
>> OS/X 12.4
>> 
>> 2.4 GHz Quad-Core Intel Core i5
>> 
>> If I should post that somewhere else let me know.
>> 
> 
> Again fwiw, I commented out references to SizeOfTag in the two methods and 
> got a good build.
> 
> ./build/*/images/jdk/bin/jpackage --app-image 
> ~/HalfPipe/halfpipe_jpkg/outputdir/HalfPipe.app --mac-sign 
> --mac-signing-key-user-name "Developer ID Application: Michael Hall 
> (5X6BXQB3Q7)"
> Bundler Mac DMG Package skipped because of a configuration problem: When 
> using an external app image you must specify the app name. 
> Advice to fix: Set the app name via the -name CLI flag, the 
> fx:application/@name ANT attribute, or via the 'appName' bundler argument.
> 
> ./build/*/images/jdk/bin/jpackage --app-image 
> ~/HalfPipe/halfpipe_jpkg/outputdir/HalfPipe.app --mac-sign 
> --mac-signing-key-user-name "Developer ID Application: Michael Hall 
> (5X6BXQB3Q7)" --name HalfPipe
> Warning: Using unsigned app-image to build signed dmg.
> 
> *** The app-image was actually a signed one. I’m not sure that matters. Also 
> since this would normally be my intention should there be a warning? ***
> 
> codesign -v --verbose=4 ~/HalfPipe/halfpipe_jpkg/outputdir/HalfPipe.app
> /Users/mjh/HalfPipe/halfpipe_jpkg/outputdir/HalfPipe.app: valid on disk
> /Users/mjh/HalfPipe/halfpipe_jpkg/outputdir/HalfPipe.app: satisfies its 
> Designated Requirement
> 
> *** Seems successful ***
> 
> Thanks again.
>

Re: JDK-8186958 - Behaviour of large values for numMapping in WeakHashMap.newWeakHashMap API

2022-06-06 Thread Stuart Marks

Hi Jai,

The error

java.lang.OutOfMemoryError: Java heap space

indicates that the VM really has run out of memory. Presumably if you increased the
heap size, it would actually be able to allocate that memory. You might have to add
the /othervm test directive and add JVM options to require a larger heap.

The table size must be a power of two, so the largest table size that will be
allocated is 1 << 30 or 1073741824 as you noted. That will take about 8GB of heap
(in the no-compressed-OOP case). That's not terribly large, but we might want to
check to see if there are other tests that require that much memory.

As you also noted, WeakHashMap eagerly allocates its table whereas LinkedHashMap and
HashMap do not. I think this is an acceptable behavior variation. Note that we had
to avoid this case in WhiteboxResizeTest:

https://github.com/openjdk/jdk/blob/master/test/jdk/java/util/HashMap/WhiteBoxResizeTest.java#L167

We might have to make similar special cases here for WHM.

I don't think we need to document this behavior difference. More precisely: this
kind of implementation variation doesn't need to be specified. In the future we
might change WHM to allocate lazily.

The API should accommodate extremely large values of numMappings. Even if it's
larger than 1 << 30 and the table size is allocated at 1 << 30, it's still possible
to add numMappings mappings without resizing. (Memory permitting, of course.) Doing
so will violate the load factor invariant, and it might result in more collisions
than one would like, but it should still work.

I think we just need to decide whether we want to have a test that allocates this
much memory, and if so, to apply the necessary settings to make sure the JVM has
enough heap.

s'marks

On 6/6/22 12:01 AM, Jaikiran Pai wrote:
In a recent enhancement we added new APIs to construct LinkedHashMap, HashMap and
WeakHashMap instances as part of https://bugs.openjdk.java.net/browse/JDK-8186958.

Since we missed adding tests for that change, I have been working on adding some
basic tests for this change as part of
https://bugs.openjdk.java.net/browse/JDK-8285405. The draft PR is here
https://github.com/openjdk/jdk/pull/9036.

It's in draft state because it has uncovered an aspect of this change that we might
have to address or document for these new APIs. Specifically, the tests I added now
have a test which does the equivalent of:

// numMappings = 2147483647
var w = WeakHashMap.newWeakHashMap(Integer.MAX_VALUE);

Similar tests have been added for HashMap and LinkedHashMap too, but for the sake of
this discussion, I'll focus on WeakHashMap. Running this code/test runs into:

test NewWeakHashMap.testNewWeakHashMapNonNegative(2147483647): failure
java.lang.OutOfMemoryError: Java heap space
at java.base/java.util.WeakHashMap.newTable(WeakHashMap.java:194)
at java.base/java.util.WeakHashMap.(WeakHashMap.java:221)
at java.base/java.util.WeakHashMap.(WeakHashMap.java:238)
at java.base/java.util.WeakHashMap.newWeakHashMap(WeakHashMap.java:1363)
at NewWeakHashMap.testNewWeakHashMapNonNegative(NewWeakHashMap.java:69)

This exception happens with only WeakHashMap. LinkedHashMap and HashMap don't show
this behaviour. It appears that WeakHashMap eagerly creates an large array (of
length 1073741824 in this case) in the newTable method which gets called by its
constructor.

This raises a few questions about these new APIs - these APIs take an integer and
the document allows positive values. So the current Integer.MAX_VALUE in theory is a
valid integer value for this API. Should these APIs document what might happen when
such a large numMapping is passed to it? Should that documentation be different for
different classes (as seen the HashMap and LinkedHashMap behave differently as
compared to WeakHashMap)? Should this "numMappings" be considered a hard value? In
other words, the current documentation of this new API states:

"Creates a new, empty WeakHashMap suitable for the expected number of mappings

and its initial capacity is generally large enough so that the expected number
of mappings can be added without resizing the map."

The documentation doesn't seem to guarantee that the resizing won't occur. So in
cases like these where the numMappings is a very large value, should the
implementation(s) have logic which doesn't trigger this OOM error?

75 matches

Mail list logo