OOB, Unreachable, ... structure needed to handle various exceptions. {offset, exception_code}

After patching the dynamic bound limit in emit_memory_op, the CacheGen size of Singlepass is reduced by 1.37MB.

As the bound check code decreases, the write exception decreases, but it is about 4.8 times larger than the code size. I guess some Inefficiency here.

result of code analysis, The code offset range where the exception occurs is to insert 1 byte each. Therefore, the size of the code and the size of the exception table are proportional to some extent.

fn mark_range_with_exception_code<F: FnOnce(&mut Assembler) -> R, R>(
    a: &mut Assembler,
    etable: &mut ExceptionTable,
    code: ExceptionCode,
    f: F,
) -> R {
    let begin = a.get_offset().0;
    let ret = f(a);
    let end = a.get_offset().0;
    for i in begin..end {
        etable.offset_to_code.insert(i, code);
    }
    ret
}

Do it after #39 to avoid a collision.

I found the description below in the enable_float option.
'Disabling use of floating-point instructions is not yet implemented.'

https://github.com/bytecodealliance/cranelift/blob/4afc658f4325f508e7dcc35d4050bff3aa444714/cranelift-codegen/meta/src/shared/settings.rs#L71

Unable to disable floating point causes non-deterministic problem.
It is necessary to understand the actual implementation in version 0.59.0 and the implementation situation in version 0.59.0 later.

After the module cached, 'drop' remains the biggest overhead.

From drop_in_place, it is released according to the implementation of rust lang, so it is difficult to accurately estimate which object is the overhead caused by dropping it from the profile alone.

However, looking at wasmer_runtime_core::sys::unix::memory::...drop in the middle, it is presumed that the largest occurrence occurs when the vm memory area held by the instance object is destroyed.

let res = call_handle_raw(&mut instance, params, msg);
    *gas_used = instance.create_gas_report().used_internally;
    
    instance.recycle();
    Ok(res?)

In the do_handle of go-cosmwasm, the instance created every time is sync destruction.
The function recycle is called, but in reality it is not recycled. so directly destroyed.

So, I thought that if instance destruction (deallocation) was handled in a separate thread, the above overhead could be eliminated further.

Check if https://github.com/CosmWasm/cosmwasm-simulate can be used for simulator

Thanks!
I tried "Adjacently tagged". But just adding this derive caused the Wasm bytecode could not be deserialized. that I've seen before, and the store failed.

When I made it Untagged instead, it was successful.
Therefore, I'm going to add #[serde(untagged)] to the enum of Msg in the rust library.

Originally posted by @shiki-tak in https://github.com/line/link-modules/pull/22#discussion_r509144602

It seems for us to be able to use the Adjacently tag and the deserializer of derive

I wonder why this uses a manually implemented deserializer rather than use derive as follows.

#[derive(Serialize, Deserialize, Clone, Debug, PartialEq, JsonSchema)]
#[serde(untagged)]
pub enum Token {
    FT(FungibleToken),
    NFT(NonFungibleToken),
}

Additionally, using Adjacently tag, seems to be able to reduce the depth of response struct.

#[derive(Serialize, Deserialize, Clone, Debug, PartialEq, JsonSchema)]
#[serde(tag = "type", content = "value")]
pub enum Token {
    #[serde(rename = "collection/FT")]
    FT(FungibleToken),
    #[serde(rename = "collection/NFT")]
    NFT(NonFungibleToken),
}

let res = serde_json::from_str::<Vec<Token>>(json);

but we can discuss reducing depth on another issue.

Originally posted by @whylee259 in #35 (comment)

• cherry pick (CosmWasm/cosmwasm#607)
• performance check
• memory profiling

• check schedule
• check requirements

wasmerio/wasmer#1299

The reason why the read_region patch was needed, the present situation of having a large minimum to maximum performance range(0.10.0), should be reproduced in the latest version(0.13.0).

cosmos-sdk is linked to the 0.40.0 stargate version, so script porting is required.

rename QueryXxxxParam to XxxxParam

Originally posted by @shiki-tak in #35 (comment)

As our vm repositories are forked from CosmWasm's one, we have to organize the strategy of versioning and update commit.

The current repos as follows.

• line/link-modules
• line/wasmvm
• line/cosmwasm
• line/wasmer

The versioning rules, we can think about as following two.

• Do we have our own versioning rule?
  • It is suitable to apply semantic versioning and conventional commit.
  • Not intuitively to know the upstream version
  • Are we in a step to maintain it independent of the upstream repo?
• Do we use as subversion of the upstream version?
  e.g.) 0.12.0-0.0.1
  • It is not the semantic versioning rule.
  • intuitively to know the upstream version
  • Do you need to know the upstream version frequently?

The update commit rules as follows.

• keep upstream commits
  • we can keep upstream commits on our repo.
  • verbose (CosmWasm/cosmwasm does create a merge commit for PR)
• squash commit
  • we can know the changes on the PR page or other links(e.g. CosmWasm/cosmwasm@v0.11.0...v0.12.0).
  • brevity

moved from https://github.com/line/link/issues/1061