Re: Proposal of a new version of AsyncGetCallTrace

[Remi Forax]

Knowing if there is a C stackframe in the middle of the stack while blocking on 
a synchronized is an important feature for a profiler when loom will land.

Rémi

- Original Message -
> From: "Bechberger, Johannes" 
> To: "hotspot-dev" , 
> hotspot-jfr-...@openjdk.java.net, "serviceability-dev"
> 
> Sent: Friday, March 18, 2022 10:43:58 AM
> Subject: Proposal of a new version of AsyncGetCallTrace

> Hi,
> 
> I would like propose to
> 
> 1. Replace duplicated stack walking code with unified API
> 2. Create a new version of AsyncGetCallTrace, tentatively called
> "AsyncGetCallTrace2", with more information on more frames using the unified
> API
> 
> A demo (as well as this text) is available at
> https://github.com/parttimenerd/asgct2-demo
> if you want to see a prototype of this proposal in action.
> 
> Unify Stack Walking
> 
> 
> There are currently multiple implementations of stack walking in JFR and for
> AsyncGetCallTrace.
> They each implement their own extension of vframeStream but with comparable
> features
> and check for problematic frames.
> 
> My proposal is, therefore, to replace the stack walking code with a unified 
> API
> that
> includes all error checking and vframeStream extensions in a single place.
> The prosposed new class is called StackWalker and could be part of
> `jfr/recorder/stacktrace` [1].
> This class also supports getting information on C frames so it can be
> potentially
> used for walking stacks in VMError (used to create hs_err files), further
> reducing the amount of different stack walking code.
> 
> AsyncGetCallTrace2
> 
> 
> The AsyncGetCallTrace call has seen increasing use in recent years
> in profilers like async-profiler.
> But it is not really an API (not exported in any header) and
> the information on frames it returns is pretty limited
> (only the method and bci for Java frames) which makes implementing
> profilers and other tooling harder. Tools like async-profiler
> have to resort to complicated code to partially obtain the information
> that the JVM already has.
> Information that is currently hidden and impossible to obtain is
> 
> - whether a compiled frame is inlined (currently only obtainable for the 
> topmost
> compiled frames)
>  -  although this can be obtained using JFR
> - C frames that are not at the top of the stack
> - compilation level (C1 or C2 compiled)
> 
> This information is helpful when profiling and tuning the VM for
> a given application and also for profiling code that uses
> JNI heavily.
> 
> Using the proposed StackWalker class, implementing a new API
> that returns more information on frames is possible
> as a thin wrapper over the StackWalker API [2].
> This also improves the maintainability as the code used
> in this API is used in multiple places and is therefore
> also better tested than the previous implementation, see
> [1] for the implementation.
> 
> The following describes the proposed API:
> 
> ```cpp
> void AsyncGetCallTrace2(asgct2::CallTrace *trace, jint depth, void* ucontext);
> ```
> 
> The structure of `CallTrace` is the same as the original
> `ASGCT_CallTrace` with the same error codes encoded in <= 0
> values of `num_frames`.
> 
> ```cpp
> typedef struct {
>  JNIEnv *env_id;   // Env where trace was recorded
>  jint num_frames;  // number of frames in this trace
>  CallFrame *frames;// frames
>  void* frame_info; // more information on frames
> } CallTrace;
> ```
> 
> The only difference is that the `frames` array also contains
> information on C frames and the field `frame_info`.
> The `frame_info` is currently null and can later be used
> for extended information on each frame, being an array with
> an element for each frame. But the type of the
> elements in this array is implementation specific.
> This akin to `compile_info` field in JVMTI's CompiledMethodLoad
> [3] and used for extending the information returned by the
> API later.
> 
> Protoype
> 
> 
> Currently `CallFrame` is implemented in the prototype [4] as
> 
> ```cpp
> typedef struct {
>  void *machine_pc;   // program counter, for C and native frames 
> (frames
>  of native methods)
>  uint8_t type;   // frame type (single byte)
>  uint8_t comp_level; // highest compilation level of a method related 
> to
>  a Java frame
>  // information from original CallFrame
>  jint bci;   // bci for Java frames
>  jmethodID method_id;// method ID for Java frames
> } CallFrame;
> ```
> 
> The `FrameTypeId` is based on the frame type in JFRStackFrame:
> 
> ```cpp
> enum FrameTypeId {
>  FRAME_INTERPRETED = 0,
>  FRAME_JIT = 1, // JIT compiled
>  FRAME_INLINE  = 2, // inlined JITed methods
>  FRAME_NATIVE  = 3, // native wrapper to call C methods from Java
>  FRAME_CPP = 4  // c/c++/... frames, stub frames have CompLevel_all
> };
> ```
> 
> The `comp_level` states the 

Re: RFR: 8200559: Java agents doing instrumentation need a means to define auxilary classes

[Remi Forax]

- Mail original -
> De: "Rafael Winterhalter" 
> À: "core-libs-dev" , "serviceability-dev" 
> 
> Envoyé: Vendredi 16 Avril 2021 15:52:07
> Objet: RFR: 8200559: Java agents doing instrumentation need a means to define 
> auxilary classes

> To allow agents the definition of auxiliary classes, an API is needed to allow
> this. Currently, this is often achieved by using `sun.misc.Unsafe` or
> `jdk.internal.misc.Unsafe` ever since the `defineClass` method was removed 
> from
> `sun.misc.Unsafe`.

You can already use Lookup.defineClass() + privateLookupIn() + 
Instrumentation.redefineModule() for that ?

Rémi

> 
> -
> 
> Commit messages:
> - 8200559: Java agents doing instrumentation need a means to define auxiliary
> classes
> 
> Changes: https://git.openjdk.java.net/jdk/pull/3546/files
> Webrev: https://webrevs.openjdk.java.net/?repo=jdk=3546=00
>  Issue: https://bugs.openjdk.java.net/browse/JDK-8200559
>  Stats: 185 lines in 4 files changed: 185 ins; 0 del; 0 mod
>  Patch: https://git.openjdk.java.net/jdk/pull/3546.diff
>  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3546/head:pull/3546
> 
> PR: https://git.openjdk.java.net/jdk/pull/3546

Re: RFR: JDK-8225056 VM support for sealed classes

[Remi Forax]

- Mail original -
> De: "David Holmes" 
> À: "Harold David Seigel" , "hotspot-runtime-dev" 
> ,
> "amber-dev" , "core-libs-dev" 
> , "serviceability-dev"
> 
> Envoyé: Mardi 19 Mai 2020 07:26:38
> Objet: Re: RFR: JDK-8225056 VM support for sealed classes

> Hi Harold,
> 
> Adding serviceability-dev for the serviceability related changes.
> 
> Nit: "VM support for sealed classes"
> 
> This RFR covers the VM, core-libs, serviceability and even some
> langtools tests. AFAICS only the javac changes are not included here so
> when and where will they be reviewed and under what bug id? Ideally
> there will be a single JBS issue for "Implementation of JEP 360: Sealed
> types". It's okay to break up the RFRs across different areas, but it
> should be done under one bug id.
> 
> Overall this looks good. I've looked at all files and mainly have some
> style nits in various places. But there are some more significant items
> below.
> 
> On 14/05/2020 7:09 am, Harold Seigel wrote:
>> Hi,
>> 
>> Please review this patch for JVM and Core-libs support for the JEP 360
>> Sealed Classes preview feature.  Code changes include the following:
>> 
>>   * Processing of the new PermittedSubclasses attribute to enforce that
>>     a class or interface, whose super is a sealed class or interface,
>>     must be listed in the super's PermittedSubclasses attribute.
>>   * Disallow redefinition of a sealed class or interface if its
>>     redefinition would change its PermittedSubclasses attribute.
>>   * Support API's to determine if a class or interface is sealed and, if
>>     it's sealed, return a list of its permitted subclasses.
>>   * asm support for the PermittedSubclasses attribute
> 
> I assume Remi is providing the upstream support in ASM? :) But also see
> below ...


Currently the version of ASM used JDK already supports sealed classes but with 
the attribute named PermittedSubtypes instead of PermittedSubclasses.
This patch renames the attribute which is the right thing to do.
Then when JDK 15 will be released, we will release ASM 9 with full support of 
PermittedSubclasses, with the right method names, docs, etc, that will be then 
integrated in JDK 16.

So with my ASM hat, the changes to the 3 ASM classes are good.

Rémi

Re: Review Request: 8238358: Implementation of JEP 371: Hidden Classes

[Remi Forax]

- Mail original -
> De: "David Holmes" 
> À: "mandy chung" , "Vicente Romero" 
> , "jan lahoda"
> 
> Cc: "serviceability-dev" , "hotspot-dev" 
> ,
> "core-libs-dev" , "valhalla-dev" 
> 
> Envoyé: Samedi 28 Mars 2020 00:01:58
> Objet: Re: Review Request: 8238358: Implementation of JEP 371: Hidden Classes

> Hi Mandy,

Hi David,

> 
> On 28/03/2020 8:29 am, Mandy Chung wrote:
>> Hi Vicente,
>> 
>> hasNestmateAccess is about VM supports static nestmates on JDK release
>>  >= 11.
>> 
>> However this is about javac --release 14 and the compiled classes may
>> run on JDK 14 that lambda and string concat spin classes that are not
>> nestmates. I have a patch with Jan's help:
>> 
>> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/8171335/webrev-javac-target-release-14/index.html
> 
> + /**
> +  * The VM does not support access across nested classes
> (8010319).
> +  * Were that ever to change, this should be removed.
> +  */
> + boolean isPrivateInOtherClass() {
> 
> I'm not at all sure what this means - access across different nests?
> (I'm not even sure what that means.)

Access inside the same nest.
As you know, until now, a lambda proxy is a VM anonymous class that can only 
see the private fields of the class declaring the lambda (the host class) and 
not the private fields of a class of the nest (the enclosing classes in term of 
Java the language).

Rémi

> 
> Thanks,
> David
> -
> 
>> 
>> (you can apply the above patch on valhalla repo "nestmates" branch)
>> 
>> About testing, I wanted to run BridgeMethodsForLambdaTest and
>> TestLambdaBytecode test with --release 14 but it turns out not
>> straight-forward.  Any help would be appreciated.
>> 
>> thanks
>> Mandy
>> 
>> On 3/27/20 2:15 PM, Vicente Romero wrote:
>>> Hi Mandy,
>>>
>>> The patch for nestmates [1] could be used as a reference. There a new
>>> method was added to class `com.sun.tools.javac.jvm.Target`, named:
>>> `hasNestmateAccess` which checks if a target is ready for nestmates or
>>> not. I think that you can follow a similar approach here.
>>>
>>> Thanks,
>>> Vicente
>>>
>>> [1] http://hg.openjdk.java.net/jdk/jdk/rev/2f2af62dfac7
>>>
>>> On 3/27/20 12:29 PM, Mandy Chung wrote:
 Hi Jan,

 Good point.  The javac change only applies to JDK 15 and later and
 the lambda proxy class is not a nestmate when running on JDK 14 or
 earlier.

 I probably need the help from langtools team to fix this.  I'll give
 it a try.

 Mandy

 On 3/27/20 4:31 AM, Jan Lahoda wrote:
> Hi Mandy,
>
> Regarding the javac changes - should those be switched on/off
> depending the Target? Or, if one compiles with e.g. --release 14,
> will the newly generated output still work on JDK 14?
>
> Jan
>
> On 27. 03. 20 0:57, Mandy Chung wrote:
>> Please review the implementation of JEP 371: Hidden Classes. The
>> main changes are in core-libs and hotspot runtime area.  Small
>> changes are made in javac, VM compiler (intrinsification of
>> Class::isHiddenClass), JFR, JDI, and jcmd.  CSR [1]has been
>> reviewed and is in the finalized state (see specdiff and javadoc
>> below for reference).
>>
>> Webrev:
>> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.03
>>
>>
>> Hidden class is created via `Lookup::defineHiddenClass`. From JVM's
>> point
>> of view, a hidden class is a normal class except the following:
>>
>> - A hidden class has no initiating class loader and is not
>> registered in any dictionary.
>> - A hidden class has a name containing an illegal character
>> `Class::getName` returns `p.Foo/0x1234` whereas `GetClassSignature`
>> returns "Lp/Foo.0x1234;".
>> - A hidden class is not modifiable, i.e. cannot be redefined or
>> retransformed. JVM TI IsModifableClass returns false on a hidden.
>> - Final fields in a hidden class is "final".  The value of final
>> fields cannot be overriden via reflection. setAccessible(true) can
>> still be called on reflected objects representing final fields in a
>> hidden class and its access check will be suppressed but only have
>> read-access (i.e. can do Field::getXXX but not setXXX).
>>
>> Brief summary of this patch:
>>
>> 1. A new Lookup::defineHiddenClass method is the API to create a
>> hidden class.
>> 2. A new Lookup.ClassOption enum class defines NESTMATE and STRONG
>> option that
>>     can be specified when creating a hidden class.
>> 3. A new Class::isHiddenClass method tests if a class is a hidden
>> class.
>> 4. Field::setXXX method will throw IAE on a final field of a hidden
>> class
>>     regardless of the value of the accessible flag.
>> 5. JVM_LookupDefineClass is the new JVM entry point for
>> Lookup::defineClass
>>     and defineHiddenClass to create a class from 

Re: Review Request: 8238358: Implementation of JEP 371: Hidden Classes

[Remi Forax]

Hi Mandy,
in ReflectionFactory, why in the case of a constructor the check to the 
anonymous class is removed ?

in BytecodeGenerator, the comment "// bootstrapping issue if using condy"
can be promoted on top of clinit, because i ask myself the same question seeing 
a static block was generated

in AbstractValidatingLambdaMetafactory.java, the field caller is not used after 
all ?

regards,
Rémi

- Mail original -
> De: "mandy chung" 
> À: "valhalla-dev" , "core-libs-dev" 
> ,
> "serviceability-dev" , "hotspot-dev" 
> 
> Envoyé: Vendredi 27 Mars 2020 00:57:39
> Objet: Review Request: 8238358: Implementation of JEP 371: Hidden Classes

> Please review the implementation of JEP 371: Hidden Classes. The main
> changes are in core-libs and hotspot runtime area.  Small changes are
> made in javac, VM compiler (intrinsification of Class::isHiddenClass),
> JFR, JDI, and jcmd.  CSR [1]has been reviewed and is in the finalized
> state (see specdiff and javadoc below for reference).
> 
> Webrev:
> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/webrev.03
> 
> Hidden class is created via `Lookup::defineHiddenClass`. From JVM's point
> of view, a hidden class is a normal class except the following:
> 
> - A hidden class has no initiating class loader and is not registered in
> any dictionary.
> - A hidden class has a name containing an illegal character
> `Class::getName` returns `p.Foo/0x1234` whereas `GetClassSignature`
> returns "Lp/Foo.0x1234;".
> - A hidden class is not modifiable, i.e. cannot be redefined or
> retransformed. JVM TI IsModifableClass returns false on a hidden.
> - Final fields in a hidden class is "final".  The value of final fields
> cannot be overriden via reflection.  setAccessible(true) can still be
> called on reflected objects representing final fields in a hidden class
> and its access check will be suppressed but only have read-access (i.e.
> can do Field::getXXX but not setXXX).
> 
> Brief summary of this patch:
> 
> 1. A new Lookup::defineHiddenClass method is the API to create a hidden
> class.
> 2. A new Lookup.ClassOption enum class defines NESTMATE and STRONG
> option that
>    can be specified when creating a hidden class.
> 3. A new Class::isHiddenClass method tests if a class is a hidden class.
> 4. Field::setXXX method will throw IAE on a final field of a hidden class
>    regardless of the value of the accessible flag.
> 5. JVM_LookupDefineClass is the new JVM entry point for Lookup::defineClass
>    and defineHiddenClass to create a class from the given bytes.
> 6. ClassLoaderData implementation is not changed.  There is one primary CLD
>    that holds the classes strongly referenced by its defining loader.
> There
>    can be zero or more additional CLDs - one per weak class.
> 7. Nest host determination is updated per revised JVMS 5.4.4. Access control
>    check no longer throws LinkageError but instead it will throw IAE with
>    a clear message if a class fails to resolve/validate the nest host
> declared
>    in NestHost/NestMembers attribute.
> 8. JFR, jcmd, JDI are updated to support hidden classes.
> 9. update javac LambdaToMethod as lambda proxy starts using nestmates
>    and generate a bridge method to desuger a method reference to a
> protected
>    method in its supertype in a different package
> 
> This patch also updates StringConcatFactory, LambdaMetaFactory, and
> LambdaForms
> to use hidden classes.  The webrev includes changes in nashorn to hidden
> class
> and I will update the webrev if JEP 372 removes it any time soon.
> 
> We uncovered a bug in Lookup::defineClass spec throws LinkageError and
> intends
> to have the newly created class linked.  However, the implementation in 14
> does not link the class.  A separate CSR [2] proposes to update the
> implementation to match the spec.  This patch fixes the implementation.
> 
> The spec update on JVM TI, JDI and Instrumentation will be done as
> a separate RFE [3].  This patch includes new tests for JVM TI and
> java.instrument that validates how the existing APIs work for hidden
> classes.
> 
> javadoc/specdiff
> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/api/
> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/specdiff/
> 
> JVMS 5.4.4 change:
> http://cr.openjdk.java.net/~mchung/valhalla/webrevs/hidden-classes/Draft-JVMS-HiddenClasses.pdf
> 
> CSR:
> https://bugs.openjdk.java.net/browse/JDK-8238359
> 
> Thanks
> Mandy
> [1] https://bugs.openjdk.java.net/browse/JDK-8238359
> [2] https://bugs.openjdk.java.net/browse/JDK-8240338
> [3] https://bugs.openjdk.java.net/browse/JDK-8230502

Re: RFR: 8229516: Thread.isInterrupted() always returns false after thread termination

[Remi Forax]

Hi David,
in java.lang.Thread interrupt0 should be renamed to setInterruptEvent, because 
what it does now
and I don't really understand the comment in interrupted(), if a thread is 
interrupted by two other threads calling interrupt(), you will loose an 
interrupt anyway.

Rémi

- Mail original -
> De: "David Holmes" 
> À: "hotspot-runtime-dev" , "hotspot 
> compiler"
> , "core-libs-dev" 
> , "Doug Simon"
> , "TOM.RODRIGUEZ" , 
> "serviceability-dev"
> , "Roger Riggs" 
> Envoyé: Mardi 29 Octobre 2019 08:42:08
> Objet: RFR: 8229516: Thread.isInterrupted() always returns false after thread 
> termination

> Bug: https://bugs.openjdk.java.net/browse/JDK-8229516
> CSR: https://bugs.openjdk.java.net/browse/JDK-8232676 (already approved)
> webrev: http://cr.openjdk.java.net/~dholmes/8229516/webrev/
> 
> This cross-cuts core-libs, hotspot-runtime and the JIT compilers, but
> only in small pieces each. There is also a small touch to serviceability
> code.
> 
> This change is "simply" moving the "interrupted" field out of the
> osThread and into the java.lang.Thread so that it can be set
> independently of whether the thread is alive (and to make things easier
> for loom in the near future). It is very straightforward:
> 
> - old scheme
>   - interrupted field is in osThread
>   - VM can read/write directly
>   - Java code calls into VM to read/write
> 
> - new scheme
>   - interrupted field is in java.lang.Thread
>   - VM has to use javaCalls to read/write "directly"
>   - Java code can read/write directly
> 
> No changes to any of the semantics regarding the actual interrupt
> mechanism. Special thanks to Patricio for tracking down a bug I had
> introduced in that regard!
> 
> Special Note (Hi Roger!): on windows we still need to set/clear the
> _interrupt_event used by the Process.waitFor logic. To facilitate
> clearing via Thread.interrupted() I had to introduce a native method
> that is a no-op except on Windows. This seemed the cheapest and least
> intrusive means to achieve this.
> 
> Other changes revolve around the fact we used to have an intrinsic for
> Thread.isInterrupted and that is not needed any more. So we strip some
> code out of C1/C2.
> 
> The changes in the JVMCI/Graal code are a bit more far reaching as
> entire classes disappear. I've cc'd Doug and Tom at Vladimir's request
> so that they can comment on the JVMCI changes and whether I have gone
> too far or not far enough. There are a bunch of tests for interruption
> in JVMCI that could potentially be deleted if they are only intended to
> test the JVMCI handling of interrupt:
> 
> ./jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.jtt/src/org/graalvm/compiler/jtt/threads/Thread_isInterrupted*.java
> 
> Testing:
>  - Tiers 1-3 on all Oracle platforms
>  - Focused testing on Linux x64:
> - Stress runs of JSR166TestCase
> - Anything that seems to use interrupt():
>   - JDK
> - java/lang/Thread
> - java/util/concurrent
> - jdk/internal/loader/InterruptedClassLoad.java
> - javax/management
> - java/nio/file/Files
> - java/nio/channels
> - java/net/Socket/Timeouts.java
> - java/lang/Runtime/shutdown/
> - java/lang/ProcessBuilder/Basic.java
> - com/sun/jdi/
>   - Hotspot
> - vmTestbase/nsk/monitoring/
> - vmTestbase/nsk/jdwp
> - vmTestbase/nsk/jdb/
> - vmTestbase/nsk/jdi/
> - vmTestbase/nsk/jvmti/
> - runtime/Thread
> - serviceability/jvmti/
> - serviceability/jdwp
> - serviceability/sa
> 
> Thanks,
> David
> -

Re: PRE-RFR: 8177154: Default configuration should disallow loading agents

[Remi Forax]

Please,
can we have a discussion on the merit of not of allowing loadAgent by default 
before discussing about how to implement that.

There is only one interesting method in VirtualMachine, loadAgent, and if this 
method do not work by default,
there is no point to have the whole API. If you have to specify a command line 
flag at load time, why not deploy the agent at load time.

So like David Holmes said in the comments of the bug, i don't understand how 
this will not disrupt every codes that using an agent at runtime.

One of strong feature that makes choosing Java on server is that you can 
attach, at runtime, a monitoring/troubleshooting tool when an event occurs,
please do not send us back to the pre Java 6 world !

regards,
Rémi

- Mail original -
> De: "Alan Bateman" 
> À: "serguei spitsyn" , "serviceability-dev" 
> ,
> hotspot-runtime-...@openjdk.java.net
> Envoyé: Vendredi 24 Mars 2017 09:59:09
> Objet: Re: PRE-RFR: 8177154: Default configuration should disallow loading 
> agents

> On 24/03/2017 08:45, serguei.spit...@oracle.com wrote:
> 
>> Please, pre-review the JDK 9 fix for:
>>   https://bugs.openjdk.java.net/browse/JDK-8177154
>>
>>
>> JDK webrev:
>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2017/hotspot/8177154-agents.jdk0/
>>
>>
>> Hotspot webrev:
>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2017/hotspot/8177154-agents.hs0/
>>
>>
> A few initial comment:
> 
> I don't think the jdk side should be dependent on the message in the
> reply, it might be simpler to do:
>throw new AgentLoadException("Failed to load agent library: " + message)
> 
> As you are changing RunnerUtil then it would be good to trim down the
> line that sets myArgs as it is way too long now for side-by-side reviews.
> 
> On the hotspot side then the flag name looks okay to me. In the message
> then "Use flag -XX:..." should be reduced to "Use -XX:..." to term the
> term "flag" out of the message.
> 
> -Alan

Re: AWT Dev JDK-8041679 Replace uses of StringBuffer with StringBuilder within the JDK

[Remi Forax]

On 05/12/2014 12:42 PM, Alan Bateman wrote:

On 12/05/2014 11:03, Paul Sandoz wrote:


It covers many areas and i have grouped the patches into such areas 
to aid reviewing. When commenting please including core-libs.
The groupings are a bit odd but I looked through the -core, -io, 
-management and -rmi patches and don't see any issues. Nothing jumped 
out to suggest that the StringBuffer could be leaked to other threads. 
There are a few cases where additional work could be done but I assume 
you want to focus on s/StringBuffer/StringBuilder/g.


You might want to hear from Remi or Kumar before including asm. I 
mention it because there might be preference to get changes to ASM 
done upstream to avoid the copy in OpenJDK from diverging. 


Hi all,
I've applied the changes to the ASM trunk so Kumar can sync when he wants,
the current revision of the trunk is 1745

cheers,
Rémi