On Wed, 19 Jun 2024 21:22:10 GMT, Maurizio Cimadamore
wrote:
>> Jorn Vernee has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - review comments
>> - add man page
>
> src/jdk.jdeps/share/man/jnativescan.1 line 68:
>
>> 66: .TP
>> 67:
On Wed, 19 Jun 2024 21:16:46 GMT, Jorn Vernee wrote:
>> This PR adds a new JDK tool, called `jnativescan`, that can be used to find
>> code that accesses native functionality. Currently this includes `native`
>> method declarations, and methods marked with `@Restricted`.
>>
>> The tool
On Wed, 19 Jun 2024 19:59:19 GMT, Jorn Vernee wrote:
>> src/jdk.jdeps/share/classes/com/sun/tools/jnativescan/JNativeScanTask.java
>> line 76:
>>
>>> 74: URI location = m.reference().location().orElseThrow();
>>> 75: Path path = Path.of(location);
>>> 76:
> This PR adds a new JDK tool, called `jnativescan`, that can be used to find
> code that accesses native functionality. Currently this includes `native`
> method declarations, and methods marked with `@Restricted`.
>
> The tool accepts a list of class path and module path entries through
>
On Wed, 19 Jun 2024 18:57:43 GMT, Jorn Vernee wrote:
>> I can do that, but I think this will always be a bit awkward since these
>> types don't have a common super type that exposes the needed information.
>
>> these types don't have a common super type that exposes the needed
>> information
>
On Wed, 19 Jun 2024 21:13:33 GMT, Jorn Vernee wrote:
>> This PR adds a new JDK tool, called `jnativescan`, that can be used to find
>> code that accesses native functionality. Currently this includes `native`
>> method declarations, and methods marked with `@Restricted`.
>>
>> The tool
On Wed, 19 Jun 2024 18:02:08 GMT, Jorn Vernee wrote:
>> src/jdk.jdeps/share/classes/com/sun/tools/jnativescan/ClassResolver.java
>> line 126:
>>
>>> 124:
>>> 125: private static Map packageToSystemModule() {
>>> 126: List descriptors =
>>> ModuleFinder.ofSystem()
>>
>>
On Wed, 19 Jun 2024 19:00:22 GMT, Jorn Vernee wrote:
>> This PR adds a new JDK tool, called `jnativescan`, that can be used to find
>> code that accesses native functionality. Currently this includes `native`
>> method declarations, and methods marked with `@Restricted`.
>>
>> The tool
On Wed, 19 Jun 2024 17:41:36 GMT, Maurizio Cimadamore
wrote:
>> Jorn Vernee has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Update src/jdk.jdeps/share/classes/com/sun/tools/jnativescan/Main.java
>>
>> Co-authored-by: Maurizio
On Tue, 18 Jun 2024 11:29:20 GMT, Magnus Ihse Bursie wrote:
> From the JBS description:
>
> We use various POSIX functions in the JDK in shared code, and possibly even
> in Windows-specific code. The UCRT optionally provides the relevant
> functionality under alternate names with leading
On Wed, 19 Jun 2024 17:45:14 GMT, Jorn Vernee wrote:
>> src/jdk.jdeps/share/classes/com/sun/tools/jnativescan/RestrictedMethodFinder.java
>> line 120:
>>
>>> 118: Optional info =
>>> systemClassResolver.lookup(methodRef.owner());
>>> 119: if (!info.isPresent()) {
>>>
On Wed, 19 Jun 2024 18:09:15 GMT, Jorn Vernee wrote:
> these types don't have a common super type that exposes the needed information
No wait, they actually do :) That's just `MemberRefEntry`.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/19774#discussion_r1646604479
> This PR adds a new JDK tool, called `jnativescan`, that can be used to find
> code that accesses native functionality. Currently this includes `native`
> method declarations, and methods marked with `@Restricted`.
>
> The tool accepts a list of class path and module path entries through
>
On Tue, 18 Jun 2024 11:29:20 GMT, Magnus Ihse Bursie wrote:
> From the JBS description:
>
> We use various POSIX functions in the JDK in shared code, and possibly even
> in Windows-specific code. The UCRT optionally provides the relevant
> functionality under alternate names with leading
On Wed, 19 Jun 2024 18:00:37 GMT, Jorn Vernee wrote:
>> src/jdk.jdeps/share/classes/com/sun/tools/jnativescan/JNativeScanTask.java
>> line 81:
>>
>>> 79:
>>> 80: Map>>
>>> allRestrictedMethods;
>>> 81: try(ClassResolver classesToScan =
>>>
On Wed, 19 Jun 2024 17:28:23 GMT, Maurizio Cimadamore
wrote:
>> This PR adds a new JDK tool, called `jnativescan`, that can be used to find
>> code that accesses native functionality. Currently this includes `native`
>> method declarations, and methods marked with `@Restricted`.
>>
>> The
On Wed, 19 Jun 2024 17:53:12 GMT, Maurizio Cimadamore
wrote:
>> This PR adds a new JDK tool, called `jnativescan`, that can be used to find
>> code that accesses native functionality. Currently this includes `native`
>> method declarations, and methods marked with `@Restricted`.
>>
>> The
On Tue, 18 Jun 2024 16:30:37 GMT, Jorn Vernee wrote:
> This PR adds a new JDK tool, called `jnativescan`, that can be used to find
> code that accesses native functionality. Currently this includes `native`
> method declarations, and methods marked with `@Restricted`.
>
> The tool accepts a
On Wed, 19 Jun 2024 17:25:07 GMT, Jorn Vernee wrote:
>> src/jdk.jdeps/share/classes/com/sun/tools/jnativescan/RestrictedMethodFinder.java
>> line 43:
>>
>>> 41: import java.util.*;
>>> 42:
>>> 43: class RestrictedMethodFinder {
>>
>> The name of this is a bit confusing as this class looks
On Wed, 19 Jun 2024 17:30:08 GMT, Maurizio Cimadamore
wrote:
>> This PR adds a new JDK tool, called `jnativescan`, that can be used to find
>> code that accesses native functionality. Currently this includes `native`
>> method declarations, and methods marked with `@Restricted`.
>>
>> The
On Tue, 18 Jun 2024 16:30:37 GMT, Jorn Vernee wrote:
> This PR adds a new JDK tool, called `jnativescan`, that can be used to find
> code that accesses native functionality. Currently this includes `native`
> method declarations, and methods marked with `@Restricted`.
>
> The tool accepts a
On Tue, 18 Jun 2024 16:30:37 GMT, Jorn Vernee wrote:
> This PR adds a new JDK tool, called `jnativescan`, that can be used to find
> code that accesses native functionality. Currently this includes `native`
> method declarations, and methods marked with `@Restricted`.
>
> The tool accepts a
On Tue, 18 Jun 2024 16:30:37 GMT, Jorn Vernee wrote:
> This PR adds a new JDK tool, called `jnativescan`, that can be used to find
> code that accesses native functionality. Currently this includes `native`
> method declarations, and methods marked with `@Restricted`.
>
> The tool accepts a
On Tue, 18 Jun 2024 16:30:37 GMT, Jorn Vernee wrote:
> This PR adds a new JDK tool, called `jnativescan`, that can be used to find
> code that accesses native functionality. Currently this includes `native`
> method declarations, and methods marked with `@Restricted`.
>
> The tool accepts a
On Tue, 18 Jun 2024 16:30:37 GMT, Jorn Vernee wrote:
> This PR adds a new JDK tool, called `jnativescan`, that can be used to find
> code that accesses native functionality. Currently this includes `native`
> method declarations, and methods marked with `@Restricted`.
>
> The tool accepts a
On Wed, 19 Jun 2024 17:16:54 GMT, Maurizio Cimadamore
wrote:
>> This PR adds a new JDK tool, called `jnativescan`, that can be used to find
>> code that accesses native functionality. Currently this includes `native`
>> method declarations, and methods marked with `@Restricted`.
>>
>> The
On Tue, 18 Jun 2024 16:30:37 GMT, Jorn Vernee wrote:
> This PR adds a new JDK tool, called `jnativescan`, that can be used to find
> code that accesses native functionality. Currently this includes `native`
> method declarations, and methods marked with `@Restricted`.
>
> The tool accepts a
> We use 2 ParkEvent instances per thread. The ParkEvent objects are never
> freed, but they are recycled when a thread dies, so the number of live
> ParkEvent instances is proportional to the maximum number of threads that
> were live at any time.
>
> On Windows, the ParkEvent object wraps a
On Wed, 19 Jun 2024 14:30:23 GMT, Roger Riggs wrote:
> One more tool. or... Could this be coalesced into a tool that does deprscan
> and restricted methods, and other "lint" type checks? I might go so far as to
> suggest it be extensible and accept patterns or regular expressions for
>
On Wed, 19 Jun 2024 15:15:43 GMT, Magnus Ihse Bursie wrote:
>> This patch contains a set of changes to improve static builds. They will
>> pave the way for implementing a full static-only java launcher. The changes
>> here will:
>>
>> 1) Make sure non-exported symbols are made local in the
> This patch contains a set of changes to improve static builds. They will pave
> the way for implementing a full static-only java launcher. The changes here
> will:
>
> 1) Make sure non-exported symbols are made local in the static libraries.
> This means that the risk of symbol conflict is
> This patch contains a set of changes to improve static builds. They will pave
> the way for implementing a full static-only java launcher. The changes here
> will:
>
> 1) Make sure non-exported symbols are made local in the static libraries.
> This means that the risk of symbol conflict is
On Wed, 19 Jun 2024 14:12:13 GMT, Daniel Jeliński wrote:
>> src/hotspot/os/windows/os_windows.cpp line 5565:
>>
>>> 5563: prd = MAXTIMEOUT;
>>> 5564: }
>>> 5565: HighResolutionInterval *phri = nullptr;
>>
>> @djelinski Is this even used?
>
> yeah, it's the C++ construction where
On Tue, 18 Jun 2024 16:30:37 GMT, Jorn Vernee wrote:
> This PR adds a new JDK tool, called `jnativescan`, that can be used to find
> code that accesses native functionality. Currently this includes `native`
> method declarations, and methods marked with `@Restricted`.
>
> The tool accepts a
On Tue, 18 Jun 2024 16:30:37 GMT, Jorn Vernee wrote:
> This PR adds a new JDK tool, called `jnativescan`, that can be used to find
> code that accesses native functionality. Currently this includes `native`
> method declarations, and methods marked with `@Restricted`.
>
> The tool accepts a
On Wed, 19 Jun 2024 13:59:23 GMT, Viktor Klang wrote:
>> We use 2 ParkEvent instances per thread. The ParkEvent objects are never
>> freed, but they are recycled when a thread dies, so the number of live
>> ParkEvent instances is proportional to the maximum number of threads that
>> were live
On Tue, 18 Jun 2024 21:01:15 GMT, Daniel Jeliński wrote:
> We use 2 ParkEvent instances per thread. The ParkEvent objects are never
> freed, but they are recycled when a thread dies, so the number of live
> ParkEvent instances is proportional to the maximum number of threads that
> were live
On Tue, 18 Jun 2024 21:01:15 GMT, Daniel Jeliński wrote:
> We use 2 ParkEvent instances per thread. The ParkEvent objects are never
> freed, but they are recycled when a thread dies, so the number of live
> ParkEvent instances is proportional to the maximum number of threads that
> were live
This PR adds a new JDK tool, called `jnativescan`, that can be used to find
code that accesses native functionality. Currently this includes `native`
method declarations, and methods marked with `@Restricted`.
The tool accepts a list of class path and module path entries through
`--class-path`
On Tue, 18 Jun 2024 16:30:37 GMT, Jorn Vernee wrote:
> This PR adds a new JDK tool, called `jnativescan`, that can be used to find
> code that accesses native functionality. Currently this includes `native`
> method declarations, and methods marked with `@Restricted`.
>
> The tool accepts a
On Wed, 19 Jun 2024 12:09:41 GMT, Thomas Stuefe wrote:
> With UseHeavyMonitors, even uncontended locks are inflated to OMs.
I don't think that matters much for the changed code; only the implementation
of park/unpark methods changed, and these methods are called for contended
locks only.
I
On Wed, 19 Jun 2024 11:40:16 GMT, Daniel Jeliński wrote:
> As you found out already, the implementation is based on a hash table, so
> access will be slower with many threads waiting at the same time. The hash
> table is stored in user space (in PEB), and the implementation reportedly
>
On Tue, 18 Jun 2024 21:01:15 GMT, Daniel Jeliński wrote:
> We use 2 ParkEvent instances per thread. The ParkEvent objects are never
> freed, but they are recycled when a thread dies, so the number of live
> ParkEvent instances is proportional to the maximum number of threads that
> were live
On Tue, 18 Jun 2024 21:01:15 GMT, Daniel Jeliński wrote:
> We use 2 ParkEvent instances per thread. The ParkEvent objects are never
> freed, but they are recycled when a thread dies, so the number of live
> ParkEvent instances is proportional to the maximum number of threads that
> were live
44 matches
Mail list logo
