Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

FVM integration #217

Merged
merged 82 commits into from
Apr 1, 2022
Merged

FVM integration #217

merged 82 commits into from
Apr 1, 2022

Conversation

raulk
Copy link
Member

@raulk raulk commented Dec 17, 2021

No description provided.

Comment on lines 49 to 50
initial_pages: 1024, //FIXME
max_pages: 32768, // FIXME
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Stebalien any sense of the values we want to set here? Noting that WASM page size is 64KiB, so we may want to start with 16 pages (1MiB), and have no upper limit for M0? We probaly want to instrument the WASM runtime to record the pages we ended up allocating with every execution.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No upper limit for now. We probably also need an exception for cron.

And yeah, we need to measure it. Then 10x at least.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note: I'd actually base the max memory on the total callstack. So we'll configure some max pages here, then set max_pages to max_pages - used_pages when instantiating a new instance.

state_root_ptr: *const u8,
state_root_len: libc::size_t,
blockstore_id: u64,
externs_id: u64,
Copy link
Member Author

@raulk raulk Dec 17, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think externs can be stateless if the blockstore is not folded into the externs, and kept as a separate entity (which seems to be where we're trending), but need to think more about this.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

At the very least, we'd need to be able to tell go which blockstore it should use. But if we go that way, caching will be really hard.

I'd rather go the other way and use a single ID for both externs and the blockstore. Basically, just get rid of the cgo blockstore and replace it with a cgo externs (using the same logic).

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We've now combined them. We allow passing them as separate "handles", but under the hood we're using the same object.

rust/src/fvm/machine.rs Outdated Show resolved Hide resolved
rust/src/fvm/machine.rs Outdated Show resolved Hide resolved
rust/src/fvm/machine.rs Outdated Show resolved Hide resolved
Comment on lines 221 to 257
pub unsafe extern "C" fn fil_fvm_machine_finish_message(
machine_id: u64,
// TODO: actual message
) {
// catch_panic_response(|| {
init_log();

info!("fil_fvm_machine_flush_message: start");

let machines = FVM_MAP.lock().unwrap();
let machine = machines.get(&machine_id);
match machine {
Some(machine) => {
todo!("execute message")
}
None => {
todo!("invalid machine id")
}
}

info!("fil_fvm_machine_flush_message: end");
// })
}
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think we have a "finish message" operation. What we finish is the machine, which flushes all effectively linked blocks to the blockstore, and returns the new state root CID.

@Stebalien do we expect the node to construct the receipts root, or do we want to accumulate receipts in the machine, to then return the root?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I expect the node to deal with that, honestly. Basically:

  1. The VM handles the state-tree only.
  2. The Node handles everything related to the blockchain.

rust/src/fvm/types.rs Outdated Show resolved Hide resolved
@cryptonemo
Copy link
Contributor

Currently requires filecoin-project/ref-fvm#277

Box::leak(return_bytes);
}

// TODO: Do something with the backtrace.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is this expected to be done before being merged?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wasn't planning on it.


#[no_mangle]
pub unsafe extern "C" fn fil_fvm_machine_execute_message(
executor: *mut libc::c_void,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why is this a void pointer, instead of a pointer to a concrete type?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The concrete type is opaque. Ideally, we'd use rust-lang/rust#43467. But c_void is the best we can do for now.

See https://docs.rs/libc/0.2.121/libc/enum.c_void.html for how this works.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To be clear, the concrete type is opaque to go.


use cid::Cid;
use ffi_toolkit::{catch_panic_response, raw_ptr, rust_str_to_c_str, FCPResponseStatus};
use futures::executor::block_on;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is the futures executor the one being used across the fvm?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  1. We use the async-std executor inside the conformance tests.
  2. We don't use async at all inside the FVM itself.
  3. We need this here just to read the car file. Which we should probably just convert to sync.

Copy link
Contributor

@arajasek arajasek left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looked at this with fresh-ish eyes, and it seems good.

bls.go Show resolved Hide resolved
cgo/errors.go Outdated Show resolved Hide resolved
fvm.go Show resolved Hide resolved
That way we can't get a mismatch.
fvm.go Outdated
func (f *FVM) ApplyMessage(msgBytes []byte, chainLen uint) (*ApplyRet, error) {
// NOTE: we need to call KeepAlive here (and below) because go doesn't guarantee that the
// receiver will live to the end of the function. If we don't do this, go _will_ garbage
// collecting the FVM, causing us to run the finalizer while we're in the middle of using
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Comment typo

rust/src/fvm/machine.rs Show resolved Hide resolved
pub error_msg: *const libc::c_char,
pub status_code: FCPResponseStatus,
pub exit_code: u64,
pub return_ptr: *const u8,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should probably confirm a leakcheck test to be sure -- this still strikes me as a leak.

rust/src/proofs/api.rs Show resolved Hide resolved
pub error_msg: *const libc::c_char,
pub status_code: FCPResponseStatus,
pub exit_code: u64,
pub return_ptr: *const u8,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hrm, I'm trying to leak-check this and getting core dumps -- can anyone else give that a go to see if it's just me?

Something like:

$ time valgrind --leak-check=full -s target/release/deps/filcrypto-0b2e0900682a616d test_sealing_aggregation_v1_1 --ignored > LOG 2>&1
Illegal instruction (core dumped)

real    0m1.282s
user    0m1.055s
sys     0m0.084s

pub error_msg: *const libc::c_char,
pub status_code: FCPResponseStatus,
pub exit_code: u64,
pub return_ptr: *const u8,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems to run fine otherwise :-(

$ target/release/deps/filcrypto-0b2e0900682a616d test_sealing_aggregation_v1_1 --ignored

running 1 test
test proofs::api::tests::test_sealing_aggregation_v1_1 ... ok

test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 12 filtered out; finished in 12.17s

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants